Re[8]: О микросервисах
От: Miroff Россия  
Дата: 28.01.22 19:16
Оценка: +2
Здравствуйте, Ziaw, Вы писали:

Z>Какие стандартные отработанные решения в зрелой технологии позволяют прогнозировать SLA? Вот я привел тебе гипотетический пример SLA и результатов НТ. Как тебе может помочь здесь микросервисная технология?


Да ровно те же что и в монолите. Берешь сценарии, которые составляют SLA, определяешь сервисы, которые в них задействованы, тестируешь, снимаешь метрики, анализируешь. Плюс именно микросервисов в грануляции метрик. В монолите ты получаешь ответ "приложение делает 100RPS на стенде" и делай с таким ответом что хочешь, ни в чем себе не отказывай. Можешь профайлер запустить, если не встраивает. В микросервисах ты получаешь ответ "сервис А делает 20k RPS, Сервис Б делает 100k RPS, сервис В делает 100RPS и упирается в CPU" и тебе понятно что и как нужно масштабировать. Более того, ты эти же метрики получаешь и из продакшена и имеешь относительно адекватные профили нагрузки именно для твоего сервиса, без необходимости извлекать их из зашумленных профилей всего приложения.

Z>Я как раз хочу понять, что они такого предлагают, что вдруг стало легче? Куда делать объективная сложность, если ее помножили на сложность взаимодействия множества микросервисов? Пока получаю ответы в стиле — теперь легко делать трейсинг и сервис локаторы. Такой себе профит, по сравнению с отсутствием необходимости их делать.


Сложность, как метрика неоднородности, естественно никуда не делась. Микросервисная архитектура упрощает лишь организацию разработки путем навязывания нормальных инструментов для формализации API, мониторинга, тестирования и деплоя. Без таких инструментов микросервисы не взлетают. В отличие от монолита, где все это внедряется по остаточному принципу когда уже зад начинает пригорать. Микросервисная архитектура упрощает взаимодействие между командами благодаря тому, что у них остается меньше точек взаимодействия.

Z>Самой серьезной проблемой монолита я считаю возможность протащить туда фиговую архитектуру, рефакторинг которой станет фактически невозможным в реалиях скрама и всего такого.


2 человека и даже 20 человек это вообще не про микросервисы. Ну т.е. можно поиграться, но профита не будет. Вот 200 человек это про микросервисы. Представь себе монолит с командой в 200 человек. Да плевать уже на переиспользование алгоритмов, у них даже мердж веток в мастер будет требовать отдельного протокола и занимать недели. С микросервисами ты делишь эти 200 человек на ~20 команд которые пилят собственные модули, версионируют и документируют API, независимо деплоятся и взаимодействуют друг с другом очень ограниченно. Не особо важно что они не могут переиспользовать алгоритмы, когда одна команда пишет на python и tensorflow, а другая на Java и SQL.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.