Как стать автором
Обновить

Просто о микросервисах

Время на прочтение11 мин
Количество просмотров267K
Всего голосов 51: ↑41 и ↓10+31
Комментарии33

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

Исходя из первого абзаца решил, что есть какие-то отличия новомодных микросервисов от старого доброго SOA, но, как и понятно, отличий нет.
Переизобретение — это все-таки важно. А то без хайпа надо было бы самим доходить до всего.

SOA может и похожа определением (словестным) на MSA, но ИМХО речь о другом и статья это не плохо показывает.


Я свою проф. деятельность начинал в Концерне и потом консалтил еще во времена популярности SOA.


И мне кажется бизнес в свое время понял SOA так:


  • сервисы уровня фирмы (я начал с очень крупной, постепенно уменьшая :) ),
  • интеграция через монстрезный ESB
  • громоские протоколы
  • фокус на интеграцию (и орхестрацию) существующих в предприятии ситем. Дальше подключили процессы и BPM (на самом деле это самое интересное)
  • Работают "Архитекторы" ;)

В Микросервисной архитектуре скорее надо применить "zoom". Тоесть речь идет о более технических сущностях конечно же в контексте современных представлений (или догм):


  • каждый сервис это отдельный процесс.
  • делить рервисы можно не только по бизнес фичам но и "как угодно", например по техническим предпочтениям скалируемости одних или других сущностей.
    В мире реально существовавшего SOA, попадавшегося мне на глаза, делили по бизес фичам (capability). А часто вопрос и не задавался как делить, потому что
    закон Конвея (“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”), что есть на то и пишут заглушки.
  • Каждый сервис, можно/нужно разрабатывать, тестировать и деплоить в продукцию отдельно от остальных!
  • Набор МИКРО сервисов могут запртосто быть заменой одного лишь монолит-сервиса класса SOA 10 летней давности. Видел и такое.
  • Влияние современности: DevOps, Agile Teams, Cloud, Containers, Eventualy Consistency
  • Работают Девелоперы, ДевОпсы и если остались Архитекторы.

Что-то в этом роде.
П.С. заранее прошу прощение, за возможные странности моего русского языка .

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

В этом согласен, SOA это про бизнес фичи, а микросервисы могут быть и чисто техническими, остальные отличия касаются больше реализации, сама архитектура не привязана к SOAP/ESB/BPM, причём нынешним микросервисам надо поучиться у SOA наличию таких стандартов и механизмов.
Получается что в плане глубины декомпозиции микросервисы шагнули глубже, но по пути потеряли некоторые плюшки SOA.
микросервисы… по пути потеряли некоторые плюшки SOA

Например?
Опять же, может это просто не входит в определение, но никто вам не мешает включить все плюшки ;)

Те самые SOAP/WSDL/ESB/BPM при всех их недостатках были достаточно стандартным набором технологий, что упрощало интеграцию, микросервисы про них забыли, а замены не предлагают.
SOAP/WSDL/ESB

Упрощали? Боже упаси… Чем же все эти SOAP/WSDL упрощали… Это было достаточно жесткое соединение… Системы были достаточно не поворотливые… Вы писали все эти WSDLины? Версионировали? Это же застрел ;) Меня больше не заставите ;)


BPM

Да это хорошая тема но независима от SOAP/WSDL/ESB.
И те Ентерпрайзные дорогущие и абсолютно баговые (Oracle BPM Suite) ситемы которые работали (иногда исключительно ) через ESB вымирают! Слава богу кстати!


С появлением и развитием нормального BPMN и например Camunda (которая опен/сорс, комюнити дривен) BPM стала соотвествовать и принесла те фишки про которые в книжках ещем может и 15 лет назад писали, но которые реальные проекты из бизнеса редко приносили (по многим причинам)


П.С. возможно у меня специфический взгляд на это. Я со всем этим в Германии столкнулся.

Я же отметил — при всех их недостатках, но они были, а нынешние микросервисы не родили никаких новых стандартов протоколов взаимодействия.
Ну стандартом де факто стало REST + JSON вместо SOAP, swagger вместо wsdl. Про BPMN уже сказали выше. Ну а ESB — это конечно не всё? но часть функций взяли на себя различные очереди и брокеры типа ZeroMQ, RabbitMQ и т.д. Тут конечно есть нюанс — нужно договариваться о протоколах, но опять же, смотрим про первые два пункта.
Если говорить о SOA, то начнем с того, что это все же больше про интерфейсы, за которыми скрывалась сложность реализации. То есть реализация, все же отдельно. В то время как MSA предлагает принципы и того и другого. Сравнивая принципы интеграции этих двух подходов, безусловно, можно найти много одинакового. Здесь я соглашусь, что MSA берет лучшее от SOA. И это правильно. Но все же есть и различия, и они представлены в части под названием: Интеграция. Если говорить о противопоставлении, то с моей точки зрения, все же правильнее делать это с точки зрения монолита и MSA. Но опять же – это не значит, что одно лучше, а другое хуже. Просто такое сравнение получится более многогранным.
Понравилось, просто и понятно!
НЛО прилетело и опубликовало эту надпись здесь

Пост настолько полон воды, что посыл в нём ну просто утонул.

В принципе как и все остальные посты о микросервисах
Один сервис может развивать одна команда не более чем из дюжины человек.
Один сервис может быть полностью переписан одной командой за одну Agile-итерацию.

Я один вижу тут противоречие?


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

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


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

Чего только люди ни придумают, лишь бы копипастить не бросать.


Разбиение на независимые компоненты даёт безусловные и неоспоримые преимущества:

… без всяких микросервисов с их дорогими и ненадежными сетевыми вызовами и замечательными неконсистентными данными.


С такими агитаторами микросервисной архитектуре врагов не надо, "друзья" со всем справятся сами.

Валидные все замечания… Под всеми подпишусь…
Вот только тут автор не до-раскрыл…


Чего только люди ни придумают, лишь бы копипастить не бросать.

Библиотеки "не нужны" которые 1) общие 2) описывают интерфейс между сервисами… Лучше копипастить пару строк, но быть абсолютно независимым в релиз-цыклах отдельных сервисов… Если вы сможете это с бибилиотеками, то без проблем.
Как пример: к простому REST сервису не надо писать спиальную клиентску библиотеку. Возможно затрыты на апдейт и синхронизацию этой библиотеки слишком привяжут развитие сервиса, к релиз-цыклам этой либы.


Это о том что необдуманыне зависимости, в долгосрочном цыкле системы, легко становятся опаснее чем любой копи-пастинг.

Библиотеки "не нужны" которые 1) общие

Да здравствует копипаста!
Вот только что мы должны копипастить? Код, решающий наши задачи делится на бизнес-логику и инфраструктуру. Копипасты бизнес-логики быть не может, так как каждый микросервис решает задачи своего под-домена и пересечений с другими сервисами не должно быть по построению. Копипаста инфраструктурного кода ведет к удорожанию
поддержки на пустом месте, а у микросервисов инфраструктура и так мягко говоря недешевая, причем продуктовые задачи никакая инфраструктура сама по себе не решает.


Лучше копипастить пару строк, но быть абсолютно независимым в релиз-цыклах отдельных сервисов

Разработчики, которые умеют в такие сложные вещи, как правильное разделение на микросервисы и тотальную автоматизацию поддержки внезапно перестают понимать принцип открытости-закрытости и перестают отделать контракты от реализации?


2) описывают интерфейс между сервисами

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


Как пример: к простому REST сервису не надо писать спиальную клиентску библиотеку

Практически на любой CRUD достаточно одного обобщенного сервиса. А там, где кончается CRUD и начинается бизнес, REST скорее вреден чем бесполезен. Кстати, формирование запросов вручную намного сложнее, многословнее и опаснее использования библиотечных оберток.


Это о том что необдуманыне зависимости

Копипаста как лекарство от зависимостей примерно то же самое что керосин как средство тушения пожара.

Вот только что мы должны копипастить?

Вы не должны ничего копипастить.
Вам предлогают принцип DRY не рассматривать как принцып "Don’t Repeat Anything" или "Copy and Paste is bad"
Если вы так это понимаете то вы конечно не один. Я тоже долго так думал, пока не стал решать прблемы в системе с микросервисами и смотреть что думет люди по этому поводу…
Оказалось, что принцип то о knowledge:
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."


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

Контракт описан не библиотекой. И описан конечно же явно. Я привел REST сервис в пример, контракт REST сервиса очень явный…
Допустим вы написали Сервис User, которы умеет прочитаь и создать юзера. Но решили создать библитеку которая представлят обьект этого самого юзера напримэр на яве… Вы конечно же эту библиотеку обязаны испольтовать везде где этот User учавствует… в 100 сервисах…
и конечно же апдейтить все 100 сервисов ели в узере что-то пересмотрелось… Ну покрайней мере вам надо перепроверить везде… Удачи и держитесь там ;)


П.С. Кстати что если вы захотите написать новый сервис на Golang? Жесткое следование неправильного пятого DRY тоже может препятствовать это-му стремлению, библиотеки то на яве ;) Но это не основной аргумент, просто пища для размышления.

С такими агитаторами микросервисной архитектуре врагов не надо, «друзья» со всем справятся сами.

Да. Такая негативная «агитация» является намеренной. Именно для того, чтобы использование микросервисов было осознанным, а не для строчки в резюме.
> Да. Такая негативная «агитация» является намеренной. Именно для того, чтобы использование микросервисов было осознанным, а не для строчки в резюме.

У вас агитация специально состоит из дезинформации?
Единственная вещь, ради которой есть смысл переходить к микросервисам — селективное горизонтальное масштабирование.
Для всего остального есть гораздо более простые, дешевые и эффективные решения.
И в статье об этом ни слова.
Зато рекламы, где за плюсы микросервисов выдаются плюсы компонентного подхода, кластеризации и шардинга — вагон и маленькая тележка.
Один сервис может развивать одна команда не более чем из дюжины человек.
Один сервис может быть полностью переписан одной командой за одну Agile-итерацию.

Я один вижу тут противоречие?

Все четыре пункта, приведенные в статье, противоречат друг другу, в той или иной степени. Они все являются индикативными. Достаточно выбрать один из них и ориентироваться только на него.
статья выглядит слишком агитационной. в ней не описаны плюсы, а микросервисная архитектура выставлена такой себе панацеей. одна из проблем в том, что на кого-то агитация подействует и микросервис родится там, где ему не место, или как минимум не в процессе эволюции системы.
хотелось бы услышать и про минусы. сказать, что требуется DevOps/Agile team, или остановится на юнит и интеграционных тестах — это как упустить половину.
Интересно было бы услышать, как у вас обеспечивается качество и своевременность поставок сервиса. Как происходит разработка, какие виды тестов выполняются? хотя бы как вы обеспечиваете тестирование (и какое) нового функционала? Делаете ли вы это до того, как он попал в общую ветку и т.д. И как результат насколько предсказуема разработка?
статья выглядит слишком агитационной. в ней не описаны плюсы, а микросервисная архитектура выставлена такой себе панацеей

В статье, тем не менее, есть и упоминание минусов MSA. Возможно, их должно быть больше. Но, например, в предыдущем комментарии говорится, что с негативом перебрали.
Почти в каждой статье о микросерверах можно встретить пассаж о том что ESB это плохо. А что же именно плохо? Быть может автор подразумевает, что сервисы живут в прекрасном мире RESTful и все они друг друга понимают без сложной интерпретации/трансляции? Есть же куча legacy сервисов которые умеют раздавать данные только в своем собственном формате. Получается, что каждому такому сервису необходимо писать обертку типа Anti-corruption layer (https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer). ESB как раз таки и может быть такой универсальной оберткой.

Хотелось бы развернутого пояснения следующему:
Впрочем, ESB ещё и противоречит таким критериям как децентрализация и независимость. Таким образом, сложность интеграции распределяется с центрального звена в виде ESB непосредственно на интегрируемые компоненты: «умные конечные точки».
А я честно говоря не услышал призывов выжечь SOA и ESB из ландшафта. Если вам подходит классический вариант с ESB — почему бы не продолжать использовать его? Продиктовано это скиллами вашей команды, видением или легасевостью ландшафта — это уже вопрос вне рамок темы :) Да и кто мешает применять разные арх. стили в разных слоях? Райф это банк, в банках есть Бэк слой где монолиты не только превалируют, но и зачастую оправданы.
В статье нет ни слова о том, что ESB это плохо. Напротив, удачные реализации этого паттерна показывают его неоспоримую пользу. Но MSA предлагает другой подход к интеграции. Подчеркиваю, не говорится, что он лучше или хуже, чем в SOA, но другой.
Децентрализация в MSA – один из основных принципов. ESB же по определению является центральным и единственным звеном, отвечающим за интеграцию. Здесь и минусы, и плюсы. С моей точки зрения, ESB реально решает проблемы интеграции (трансформация, маршрутизация, технологические различия, обработка ошибок, логирование, мониторинг) и консьюмеры и провайдеры от этого выигрывают. В MSA каждый сам за себя. И сложность интеграции (все что перечислено в предыдущих скобках) остается в самих микросервисах. Best practices в MSA решать это с помощью инфраструктурных библиотек, что скрашивает эту проблему.
Сервисы-конвертеры ещё могут быть…
На мой взгляд, статья для вводной вполне годная, хотя возможно стоило бы обозначить вначале целевую аудиторию. Планируется ли описание примера внедрения MSA в Райфе? :)
+1 к автору данного комментария. Планируется ли описание примера внедрения MSA в Райфе? Проблемы, с которыми сталкивается команда в целом и в инфраструктуре банка(релизное управление, сеть, сервера, мониторинг, логирование...)? Существуют ли реальные позитивные стороны данного архитектурного веяния?
Обязательно напишем о нашем опыте применения микросервисов, например, в интернет- каналах.
Больше всего смущает именно сеть. Можно же не монструозную ESB тащить а что-то простенькое на базе той же Редиски или на худой конец какой-то свой/коробочный/SaaS MessageQueue.
В общем мысль моя в том, что хоть ESB и является единой точкой отказа, но если она будет совсем тонкой, то это не станет проблемой.
Очень академично получается, в реальности ресурсы ограничены.
1. Smart-endpoint'ы. REST и прочее конечно хорошо, но бинарная сериализация меньше по трафику и быстрее по сериализации. На практике я использую кастомную бинарную сериализацию пакуя данные без метаинформации (по сравнению с BinarySerialization дает на 30% меньший размер и на 500% прирост к скорости сериализации), когда количество сообщений измеряется в миллионах, и вы ограничены по количеству и мощности серверов подобная оптимизация дает значительный эффект. REST использую только для интеграции с сервисами вне системы, на периферии.
2. Отказ от ESB неоправдан, и непонятен, получается каждый сервис должен знать прямые адреса сервисов с которыми обменивается данными, что убивает независимость развертывания, и простоту балансировки. Есть stateless шины сообщений, например, можно поднять кластер NATS и из коробки получить надежный и быстрый механизм взаимодействия, с балансировкой, при этом низкая цена поддержки, т.к. шина не хранит состояние.
3. Библиотеки/общий код. В реальности от этого никуда не деться, или грубо нарушать DRY или все-таки делать общий код. Конечно получается неудобно при изменении логики в инфраструктуре, это повлечет пересборку всех микросервисов, но можно облегчить себе жизнь автоматизацией развертывания и локальным nuget-хранилищем. А использование ESB позволит обновиться без остановки работы системы в целом (подняли новую версию микросервиса, убили старую, благодаря балансировке обновление прозрачно)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий