ramayasket 23 июл 2023 в 12:03

Элегантные «квантовые» микросервисы

Средний

22 мин

5.5K

Программирование*.NET*C#*Микросервисы*

Кейс

Комментарии 33

Закреплённые комментарии

titan_pc 28 июл 2023 в 18:48

А это не про "Моно-репозиторий" случаем рассказ. Удобная штука, кстати. Экономит человеческие ресурсы. Вот для техно-гигантов это шок конечно читать такое, что одна команда тащит целый проект на себе. У них там по 15 человек на один микросервис. А тут человек 5-6 на проект. И надо микросервисно сделать условно Авито. Естественно язык там будет один. Естественно люди придут к моно-репе. Будут код делить на слои. Техно слой закатают в либу, опубликуют локально, ибо руководство против опен-сорса условно например. Крутой термин "Квантовый сервис". Мне зашёл. Такие решение появляются от квантовых бюджетов и сроков, кстати. И о чудо, они даже работают и rps держат не хуже истинных микросервисов. А почему, да потому что там даже связи бизнес модели можно не через шины делать а просто кодом. Огонь, пушка, топчик. И шок контент. Техно-гигантам не читать. Это не микросервисы. Это квантовые сервисы. За ними будущее. Как за квантовыми компьютерами.

Nurked 23 июл 2023 в 12:14

Спасибо большое! Моя компания занимается консультированием в области IT. Мы переписываем подобные решения ввиде наипростейшего монолита на голанге, котрый гоняется на одной EC2 medium размера. Не подскажите, где посмотреть список ваших клиентов?

auddu_k 23 июл 2023 в 13:00

Классный текст, спасибо ? Есть о чем подискутировать

"Квантовая архитектура" позволяет по максимуму устранить дублирование кода.

А всегда ли "дублирование" - это зло? Кажется этот момент стоит уточнить, возможно, ввести ограничение на применимость подхода. Что именно у вас зарыто в общей либе?

В своих проектах стараемся разделять весь код на то, что сделал один раз и с большой вероятностью не меняем (условно называем "инфраструктурный код"), и то, что меняется, логику, которая чаще уникальна (условно " бизнес-код").

Так вот, инфраструктурный код унифицируем по структуре и копируем от сервиса к сервису, а бизнесовый - он уникален и составляет суть сервиса.

Таким образом мы снижаем нагрузку на обновление-доработку общей либы, которая конечно тоже есть.

ramayasket 23 июл 2023 в 13:19

сделал один раз и с большой вероятностью не меняем

У нас тоже были такие мысли, но опыт показал, что практически всё со временем приходится менять. Поэтому дублирование признано у нас злом. С другой стороны, мы ни разу не пожалели об исключённом дублировании.

Oceanshiver 23 июл 2023 в 13:07

Интересно, когда уже генерация кода Т4 станет устоявшимся анти-паттерном?

ramayasket 23 июл 2023 в 13:22

Мы не находим в этом ничего "анти". Прекрасно работающее, технологичное средство. Единственное ограничение - не надо загружать в шаблон разрабатываемые сборки. Он их начинает держать даже после отрабатывания шаблона.

Oceanshiver 25 июл 2023 в 23:02

Еще найдете, не переживайте )

ramayasket 26 июл 2023 в 04:44

Звучит так, как будто я только что нашёл T4. Я им пользуюсь лет 15... думаю хватило времени чтобы обнаружить всё что возможно.

shai_hulud 23 июл 2023 в 15:03

Можете развернуть мысль о том что "T4" это анти-паттерн?

akurilov 23 июл 2023 в 15:50

Если вы ссылаетесь на два процессора (это такой класс с бизнес-логикой), то уместные имена будут: ClientProcessor, OrderProcessor, чтобы отличить один процессор от другого.

Называть что-либо "процессор" - это уже антипаттерн.

https://stackoverflow.com/questions/5569666/what-is-a-better-name-than-manager-processor-etc

ramayasket 23 июл 2023 в 16:26

Мы нашли, что это самый информативный и удобный термин. Отказываться от него, просто потому, что кто-то назвал его антипаттерном - это странно.

Hardcoin 25 июл 2023 в 13:50

Антипаттерны так и рождаются. Кто-то находит неподходящий термин удобным, распространяет идею. Через год в программе появляется второй процессор (бизнес-требования меняются) и люди понимают, что называть первый просто "processor" было неправильно.

У вас второго шага просто не произошло ещё.

ramayasket 25 июл 2023 в 13:53

В тех случаях, о которых мы пишем, такого не предвидится. Кроме того, у нас классы маленькие, даже если второй процессор появится, rename variable в студии делается за секунду.

Второй ответ на ваш комментарий - YAGNI.

akurilov 23 июл 2023 в 16:00

Представьте себе изменение, которое надо применить ко всем контроллерам во всех микросервисах.

Собственно, это единственная проблема, которую такой монолитный подход решает. В остальном монолит только создаёт проблемы.

Но зачем изменения во всех микросервис ах? Микросервисы должны быть независимы по определению и вообще могут быть написаны на разных языках.

ramayasket 23 июл 2023 в 16:27

Микросервисы, при всей их отдельности - это часть большой системы, которая эволюционирует. Соответственно, есть изменения, которые распространяются на систему целиком и на все МС.

akurilov 23 июл 2023 в 16:47

Всё взаимодействие с микросервисом должно быть ограничено его API и SLA. Остальное должно быть внутренним делом команды или разработчика, который его поддерживает. Откуда взяться изменениям для всех? Не политика ли случаем?

ramayasket 23 июл 2023 в 21:09

У нас все микросервисы разрабатываются одной и той же командой. От случая к случаю появляется идея, которая применима ко всем МС.

akurilov 23 июл 2023 в 21:21

Дайте догадаюсь, это - нефункциональные требования и даже не SLA. В таких случаях новый модный фреймворк обычно обкатывают на новых микросервис ах, избавляясь от риска заодно сломать старые.

Ну а вообще, для единственной команды которая поддерживает сразу весь функционал, нужды в микросервисах вероятно, и нет

blood_develop 23 июл 2023 в 17:00

Все, конечно, элегантно пишете, и про дублирование, и про репликацию с транзакциями.. но после прочтения осталалось послевкусие.. сложности что ли

Вот прилетела вам две баги, одна инфраструктурная, одна - бизнесовая. Как вы их отлаживаете?

Как у вас с онбордингом? Сложно ли "среднему" разрабу приступить к работе, разобраться в проекте?

Есть ли какие-то правила ограничения вложенности/наследуемости компонентов? Вангую невозможность разобраться с используемостью (контракта/процессора)-наследника в десятом поколении

ramayasket 23 июл 2023 в 21:01

Инфраструктурные баги очень редки, не более 5-7% от общего числа. Они, конечно, исправляются в первую очередь, как правило.

Насчёт онбординга, пока такой проблемы не возникало, т.к. новых разработчиков на горизонте нет. Но вообще, эта статья задумывалась, в том числе, как указание на необходимость существенно расширить документацию путём добавления технического писателя.

Что касается наследования, у нас, как правило, глубина 2, в редких случаях 3.

blood_develop 23 июл 2023 в 17:02

Ну и еще вопрос о транзакции. Что у вас стоит за надежностью? Например, если когда отвалится шина?

ramayasket 23 июл 2023 в 21:02

Отвалится ли шина, или SQL-сервер, значит откат не произойдёт. Мы с самого начала согласились, что надёжность распределённых транзакций не превышает надёжности серверов.

-1

Aquahawk 25 июл 2023 в 13:20

Ни разу не видел ничего хорошего от игры в https://en.wikipedia.org/wiki/Code_golf в продакшн коде.

ramayasket 25 июл 2023 в 13:22

Ну, мы в эту игру и не играем. Мы не стремимся сделать код короче любой ценой, мы устраняем избыточность.

Aquahawk 25 июл 2023 в 13:26

Ну на мой взгляд устранение избыточности это и есть укорочение любой ценой. Ведь любой символ который можно удалить избыточен. Или не любой. Кстати, а почему бы не изъять отступы? И переменные как a,b,c,d,e называть, меньше же читать? А вообще очень здраво про всё это написано в соседнем посте https://habr.com/ru/articles/750114/

ramayasket 25 июл 2023 в 13:28

Код может быть либо избыточен, либо оптимален, либо укорочен максимально. Вы говорите о максимальной краткости, а мы стремимся к золотой середине. В статье же ясно написано - "без перегибов".

Формула элегантности включает в себя гармонию, т.е. код должен быть сбалансирован (золотая середина). Сверх-сокращённый код столь же плох, как и простыни.

posledam 27 июл 2023 в 09:23

Главное не подменять понятия и не заниматься самообманом.

Вот вы пишите, что вместо строковых констант применяете enum-ы. Но ведь это обман. У константы можно поменять имя, и значение константы не изменится. У константы можно поменять значение, и при этом никакой код, использующий константу не поменяется. Здесь вы не можете сделать ни того, ни другого. И семантически, enum это перечисление с числовым значением, а не справочник строк.

По поводу сбалансированности. Отказ от var при чём не везде и без чётких критериев как-то играет против любого баланса.

Мне показалось, что вы вплотную подошли к границе "создадим свой ЯП поверх C#", где-то вопреки правилам, а где-то наоборот крайне консервативно (no-var). Серьёзные перекосы.

ramayasket 27 июл 2023 в 09:35

1) Мы применяем enum'ы в четырёх случаях, в одном из которых 120 элементов, соответствующих именам таблиц - а отнюдь не везде.

2) Поменять название или значение - в данном случае подпадает под YAGNI.

3) Не вижу обоснования, как явное указание типа отходит от золотой середины.

posledam 28 июл 2023 в 01:39

Не важно в каких случаях, если вы enum используете как строковую константу, при чём по её имени члена.

if( some == $"{MyEnum.MyValue}" ) ...

if( some == "MyValue" ) ...

Почему бы тогда просто не использовать строки? Ибо первый вариант настолько плох, насколько это вообще в принципе возможно. Ну наверное nameof :)

Очень легко. Если имя типа можно заменить на var, тогда имя типа явно лишнее.

IDE сегодня достаточно продвинутые, чтобы отображать всю нужную информацию. Зачем этот обезьяний труд, как будто код пишется в блокноте и там же читается?

Статья мне понравилась, хотя есть спорные решения, и в статье есть противоречия.