у Entitty Service большое, если не сказать огромное число связей
Наверное вы подразумевали что-то наподобие «у Entity Service очень часто получается неоправданно большое число связей, чего можно избежать»?
У вас может быть баг в коде (в каком-то глубоком ифчеке, который не дотестили) до тех пор пока вы не заметили на проде и пока не откатились — у вас страдает N сервисов. А как мы видели из примера особенность Entity Service такова, что он связан почти со всеми.
И соглашусь и нет. Простые круд сервисы наиболее просты с т.з. тестируемости. Если баг в таком не найден, то архитектура тут — наименьшая из проблем.
Но вот да — у вас проблема, да вы ошиблись с балансировкой и масштабированием и да у вас страдает от этого ПРОД. Одно дело если это какой-то изолированный функционал типа регистрации черновика публикации. А другое дело если это и регистрация черновика публикации. И проверка на плагиат публикации и проверка уникальности иллюстраций и даже сервис модерирования. Т.е. разница в масштабах катастрофы разительная просто
Вот эту мысль я не совсем понял. Мы рассматриваем архитектуру системы, косяк в конфиге лоадбалансера — из другой оперы. Что вы здесь хотели сказать?
При реализации нового функционала вы можете сломать уже существующий
Это верно для любой абсолютно ситуации.
Допустим, вы меняете метод обновления заказа и удаляете оттуда один из параметров (либо добавляете)
Конкретно это — смена публичного контракта сервиса. Такое, будучи неаккуратно сделанным, приводит к проблемам в независимости от того Entity service это или нет.
Отказоустойчивость не очень высокая. Если падает все тот же сервис заказов — не работают все сценарии, в которых он участвует.
Тоже не совсем удачный пример. Здесь проблема не в том, что это entity service, а в том, что это явный боттлнек в одном инстансе без балансировщика нагрузки и прочего. А если вы хотели донести мысль что «любой entity service с практически 100% вероятностью = боттлнек --> требует доп. телодвижений для обеспечения отказоустойчивости», то это другая мысль и требует отдельного доказательства.
Сложность отладки. Если сравнивать с монолитом, то все стало хуже. Теперь код находится в разных процессах и нужны инструменты вроде Jaeger
Это верно вообще в целом если сравнивать монолит и микросервисы. В чем тут отличие конкретно entity service?
В общем я не понял ваши примеры по недостаткам. Будет здорово, если вы их как-то раскроете или перепишете.
Выше вам уже написали, что мысль «как было бы лучше» была бы более понятна на том же самом примере, здесь более не заостряю.
В примере, где мы якобы избавились от entity service, последний в цепочке сервис каталога статей по тому, как он изображен, очень смахивает на чистый круд на базе, а значит он все еще entity service. Все еще плохо, или я не понял схему?
В общем и целом, я вынес, что проблема есть, а вот детали после прочтения не представляются в ясном виде. Надеюсь, что вы каким-то образом сделаете это яснее, т.к. тема явно важная. Так или иначе, спасибо.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
enum values
{
one,
two,
three,
four,
five
};
int foo(void)
{
return rand() % (five + 1);
}
int main(void)
{
enum values f = foo();
printf("Original value = %d\n", f);
char c;
memset(&c, 0xFF, 2 * sizeof(c));
printf("New value = %d\n", f);
switch (f)
{
case one:
case two:
case three:
case four:
case five:
printf("Within range\n");
break;
default:
printf("Out of range\n");
break;
}
return 0;
}
Идея простая: из-за ошибки в коде, повреждается переменная и по факту начинает содержать значения не из перечисления. В таких случаях, дефолтный блок, написанный осмысленно, будет выступать барьером против неопределенного поведения в процессе работы приложения в рантайме. А оно бы и получилось в данном варианте, ведись работа с переменной дальше с ожиданием, что значения всегда будут в диапазоне.
Тут пару лет назад господа Зуев и Чупринов сделали перевод плюсового стандарта, проделав колоссальный объем работы. Совокупное мнение получилось неоднозначным. Тут специфика в том, что это не просто техническая литература, а еще и ISO-шная. И тут две проблемы. Во-первых, по моему глубокому убеждению, именно такую литературу нужно переводить по ISO-шным же стандартам переводов для максимальной точности. Во-вторых, чисто стандарта недостаточно. Надо как у юристов: условно том закона + том комментариев. С учетом всего, думаю PVS-Studio не захочет. Полезность сомнительна, затраты большие, покупать результат (а он выйдет по опыту книги выше недешевым) будут плохо.
Спасибо за интересный обзор. Действительно понимание таких тонкостей разработчикам дается достаточно тяжело. Кстати, на базе вашего первого примера можно вообще сделать нечто, ломающее мозг. Например:
#include <stdio.h>
int main(void) {
int a, c, b;
(void)c;
int *p = &a;
int *q = &b + 1;
printf("%p %p %d\n", (void *)p, (void *)q, p == q);
return 0;
}
Наверное вы подразумевали что-то наподобие «у Entity Service очень часто получается неоправданно большое число связей, чего можно избежать»?
И соглашусь и нет. Простые круд сервисы наиболее просты с т.з. тестируемости. Если баг в таком не найден, то архитектура тут — наименьшая из проблем.Вот эту мысль я не совсем понял. Мы рассматриваем архитектуру системы, косяк в конфиге лоадбалансера — из другой оперы. Что вы здесь хотели сказать?
В общем я не понял ваши примеры по недостаткам. Будет здорово, если вы их как-то раскроете или перепишете.
Выше вам уже написали, что мысль «как было бы лучше» была бы более понятна на том же самом примере, здесь более не заостряю.
В примере, где мы якобы избавились от entity service, последний в цепочке сервис каталога статей по тому, как он изображен, очень смахивает на чистый круд на базе, а значит он все еще entity service. Все еще плохо, или я не понял схему?
В общем и целом, я вынес, что проблема есть, а вот детали после прочтения не представляются в ясном виде. Надеюсь, что вы каким-то образом сделаете это яснее, т.к. тема явно важная. Так или иначе, спасибо.
Зато с помощью скрам-мастеров. То есть не без помощи менеджеров.
Идея простая: из-за ошибки в коде, повреждается переменная и по факту начинает содержать значения не из перечисления. В таких случаях, дефолтный блок, написанный осмысленно, будет выступать барьером против неопределенного поведения в процессе работы приложения в рантайме. А оно бы и получилось в данном варианте, ведись работа с переменной дальше с ожиданием, что значения всегда будут в диапазоне.
Имхо необходимость есть.
Подсказки появляются не для всего. Сходу напоролся на два кейса на картинках.
0xffffcbec 0xffffcbec 1gcc version 6.4.0 x86_64-pc-cygwin (-O0 -Wall -Wextra -Werror -std=c11)