Вступление
Чуть ли не каждый второй, кто впервые сталкивается с MSA (Micro Service Architecture), на первых порах восклицает: «Да я эти микросервисы еще …надцать лет назад». Отчасти они правы. И я тоже был из этой самой половины, и не понимал — почему такой шум?
В самом деле! Ведь MSA — это тоже про разработку софта. Какие здесь могут быть революции? Все методики знакомы. В некоторых местах можно даже удивиться: «А разве бывает по-другому»? Фанаты Agile и DevOps тоже скажут, что это всё наше, родное.
Но всё же прошу вас набраться терпения и продолжить читать дальше.
Что такое микросервисная архитектура (MSA)
Если перефразировать Википедию, то определение микросервисной архитектуре может быть таким:
MSA — принципиальная организация распределенной системы на основе микросервисов и их взаимодействия друг с другом и со средой по сети, а также принципов, направляющих проектирование архитектуры, её создание и эволюцию.
Что такое микросервис (MS)
С архитектурой разобрались быстро. С микросервисами давайте поподробнее.
Понять суть микросервиса проще всего на сравнении, или даже противопоставлении его крупному приложению — монолиту. В отличии от MSA, я не буду давать определение микросервису, а перечислю его наиболее важные характеристики.
А дальше мы рассмотрим каждую из них подробнее.
Я выделил восемь свойств микросервиса:
- Он небольшой.
- Он независимый.
- Он строится вокруг бизнес-потребности и использует ограниченный контекст (Bounded Context).
- Он взаимодействует с другими микросервисами по сети на основе паттерна Smart endpoints and dumb pipes.
- Его распределенная суть обязывает использовать подход Design for failure.
- Централизация ограничена сверху на минимуме.
- Процессы его разработки и поддержки требуют автоматизации.
- Его развитие итерационное.
Уже на этом месте те, которые якобы создавали микросервисы в доисторические времена, должны задуматься, действительно ли всё было так продвинуто… Лично я на этой стадии перешел в разряд сомневающихся.
Небольшой
Что такое «небольшой»? Такая малоинформативная формулировка! На самом деле, по-другому не скажешь. Каждый должен самостоятельно определиться с размером. Лучше всего на практике. В качестве индикативных оценок можно ориентироваться на рекомендации экспертов. Размер микровервиса должен быть таким, чтобы выполнялось одно из условий:
- Один сервис может развивать одна команда не более чем из дюжины человек.
- Команда из полудюжины человек может развивать полдюжины сервисов.
- Контекст (не только бизнеса, но и разработки) одного сервиса помещается в голове одного человека.
- Один сервис может быть полностью переписан одной командой за одну Agile-итерацию.
Независимый
Микросервисная архитектура — воплощение паттернов High Cohesion и Low Coupling. Всё, что противоречит этому, отвергается беспощадно. В противном случае команду ждут большие проблемы. Так что микросервис обязан быть независимым компонентом.
Здесь попрошу вас не начинать холивар о том, что же такое «компонент». Давайте в рамках этой статьи сойдемся на том, что
Компонент — это единица ПО, код которой может быть независимо заменен или обновлен.
Конечно любая мало-мальски серьезная программа пишется с разбиением на компоненты, которые, безусловно, основываются на тех же принципах. Но в монолите общая кодовая база открывает возможности для нарушения низкой связанности. И при слабой дисциплине рано или поздно код превращается в спагетти.
Под такую формулировку компонента подходят и сторонние библиотеки. Здесь сложнее с нарушением границ произвольными связями, но не на много.
В то же время методология разбиения на отдельные микросервисы вынуждает придерживаться жесткого их разделения, ведь они должны отвечать более жестким критериям независимости.
Так, каждый микросервис работает в своем процессе и поэтому должен явно обозначить свой API. Учитывая, что другие компоненты могут использовать только этот API, и к тому же он удаленный, минимизация связей становится жизненно важной.
Такое разделение дает явный выигрыш с точки зрения независимого развития разных компонентов. И с учетом этого различные языки вводят конструкции, позволяющие явное создание независимых компонентов (например, модули в Java 9), и это перестает быть прерогативой микросервисного подхода.
Не хочу, чтобы создалось впечатление, будто в микросервисной архитектуре запрещено использование библиотек. Их использование не приветствуется, поскольку так или иначе приводит к зависимостям между микросервисами, но всё же допускается. Как правило, это допущение распространяется на инфраструктурные функции вроде логирования, вызова удаленного API, обработки ошибок и тому подобного.
Независимость микросервисов позволяет организовать независимый жизненный цикл разработки, создавать отдельные сборки, тестировать и развертывать.
Поскольку размер микросервисов невелик, то очевидно, что в крупных системах их будет немало. Управлять ими вручную будет сложно. Поэтому команда обязана иметь приемлемый уровень автоматизации согласно Continuous integration и Continuous Delivery.
Где же микросервис (бизнес-потребность)
Итак, вы решили спроектировать новый микросервис.
Определение его границ — самый важный шаг. От этого будет зависеть вся дальнейшая жизнь микросервиса, и это серьёзно повлияет на жизнь команды, отвечающей за него.
Основной принцип определения зоны ответственности микросервиса — сформировать её вокруг некоторой бизнес-потребности. И чем она компактнее, чем формализованней её взаимоотношения с другими областями, тем проще создать новый микросервис. В общем, довольно стандартный посыл. На нем основывается создание любых других компонентов. Вопрос только в том, чтобы в дальнейшем выдержать эту зону ответственности, что мы и обсуждали в предыдущем параграфе.
Когда границы микросервиса заданы и он выделен в отдельную кодовую базу, защитить эти границы от постороннего влияния не составляет труда. Далее внутри микросервиса создают свой микромир, опираясь на паттерн «ограниченного контекста». В микросервисе для любого объекта, для любого действия может быть своя интерпретация, отличная от других контекстов.
Но что делать, если границы оказались неправильными? В этом случае изменение функциональности в новом микросервисе ведет к изменению функциональности в других микросервисах. В результате «поплывут» интерфейсы всех зависимых микросервисов, а за ними интеграционные тесты. И всё превращается в снежный ком. А если эти микросервисы ещё и принадлежат разным командам, то начинаются межкомандные встречи, согласования и тому подобное. Так что правильные границы микросервиса — это основа здоровой микросервисной архитектуры.
Чтобы минимизировать ошибки при определении границ, нужно вначале их продумать. Поэтому оправданным является подход Monolith First, когда вначале систему развивают в традиционной парадигме, а когда появляются устоявшиеся области, их выделяют в микросервисы. Но всё течет и меняется. И границы тоже могут меняться. Главное, чтобы выигрыш от разбиения превышал сложности пересмотра этих границ. Такой подход к постепенному формированию набора микросервисов похож на итерационное развитие, используемое в Agile, ещё его называют «эволюционным проектированием» (Evolutionary Design).
Есть ещё одно интересное следствие создания микросервисов, соответствующее закону Конвея (Conwey Law).
Если организация использует монолитное приложение, то оно нарушает соответствие структуре и коммуникациям внутри организации. А команды разработчиков строятся вокруг архитектурных слоев монолита: UI, серверная логика, база данных.
Микросервисная архитектура приводит IT и бизнес в гармонию, с точки зрения Конвея. Поскольку микросервисы формируются вокруг бизнес-потребностей конкретных бизнес-подразделений, то архитектура предприятия начинает повторять оргструктуру и каналы социальной и бизнес-коммуникации. А команды становятся кроссфункциональными и формируются вокруг этих бизнес-потребностей / бизнес-подразделений.
Поскольку разные микросервисы получаются независимыми не только логически, но и технологически, а создавать их могут разные команды, ничто не мешает для каждого случая подбирать подходящие языки программирования, фреймворки и даже операционные системы.
Интеграция. Smart endpoints and dumb pipes
Интеграция микросервисов обходится без ESB, как центрального промежуточного звена. Наверное, комьюнити уже натерпелось от неудачных вариантов реализации этого подхода. То, что были и удачные — не принимается в расчет. Впрочем, ESB ещё и противоречит таким критериям как децентрализация и независимость. Таким образом, сложность интеграции распределяется с центрального звена в виде ESB непосредственно на интегрируемые компоненты: «умные конечные точки».
Для интеграции, как правило, используются простые текстовые протоколы, основанные на HTTP, чтобы нивелировать возможную технологическую разность микросервисов. REST-подобные протоколы являются практически стандартом. Как исключение, могут использоваться бинарные протоколы типа Java RMI или .NET Remoting.
Здесь есть дилемма. Конечно бинарные протоколы гораздо эффективнее. Но, во-первых, появляются технологические ограничения. Во-вторых, на бинарных протоколах сложнее реализовывать шаблон Tolerant Reader, сохраняя эффективность. В-третьих, опять появляется зависимость провайдера и потребителей, поскольку они оперируют одними и теми же объектами и методами, то есть связаны по кодовой базе.
Другая отличительная черта взаимодействия микросервисов — синхронные вызовы не приветствуются. Рекомендуется использовать один синхронный вызов на один запрос пользователя, или вообще отказаться от синхронных вызовов.
И еще пара замечаний.
- Основной сложностью разбиения монолита на микросервисы является не определение их границ. Они уже должны сформироваться и устояться. Сложность заключается в том, что локальные вызовы становятся удаленными. А это влияет не только на организацию вызовов, но и на стиль взаимодействия, так как частые вызовы уже не подходят. Скорее всего, надо пересматривать сам API, делать его более крупным, а, как следствие, пересматривать логику работы компонентов.
- Поскольку асинхронное событийное взаимодействие — практически стандарт в микросервисной архитектуре, то надо разбираться в создании событийной архитектуры (Event Driven Architecture), а сами микросервисы должны соответствовать требованиям Reactive.
Design for failure для распределенной системы
Одно из наиболее критичных мест в микросервисной архитектуре — необходимость разрабатывать код для распределенной системы, составные элементы которой взаимодействуют через сеть.
А сеть ненадежна по своей природе. Сеть может просто отказать, может работать плохо, может вдруг перестать пропускать какой-то тип сообщений, потому что изменились настройки файрвола. Десятки причин и видов недоступности.
Поэтому микросервисы могут вдруг перестать отвечать, могут начать отвечать медленнее, чем обычно. И каждый удаленный вызов должен это учитывать. Должен правильно обрабатывать разные варианты отказа, уметь ждать, уметь возвращаться к нормальной работе при восстановлении контрагента.
Дополнительный уровень сложности привносит событийная архитектура. А отладку такой системы — не одного микросервиса, а системы, где много потоков разнонаправленных неупорядоченных событий — даже трудно представить. И даже если каждый из микросервисов будет безупречен с точки зрения бизнес-логики, этого мало. По аналогии со спортом, «звёзды» не гарантируют звездную команду, ведь в команде важнее не «звезды», а слаженность всех её игроков.
И поскольку сложность таких систем очень высока, то проблему решают так.
- Не доводят систему до состояния «без сучка без задоринки». Это очень дорого. Конечно, это не значит, что система валится от первого дуновения. Она просто отвечает необходимым нефункциональным требованиям. Но в ней могут присутствовать ошибки, незначительно влияющие на ее устойчивость и производительность.
- С другой стороны вкладываются в инфраструктуру, которая помогает быстрее устранять нештатные ситуации. Должно быть полное покрытие кода unit тестами, интеграционными и тестами производительности. Должен быть интеллектуальный мониторинг, который не только моментально показывает неработающие места, но и сигнализирует об ухудшении состояния системы с прогнозированием возможных сбоев. Должно быть продвинутое распределенное логирование, позволяющее оперативно проводить расследования. И часто по результатам исправляются скрытые ошибки.
Всё это полезно и любому монолиту, но для микросервисов такая инфраструктура — вопрос жизни и смерти.
Децентрализация данных
Еще один из важнейших элементов в парадигме микросервисов.
Каждому микросервису по своей базе данных!
Лозунг популиста на выборах.
На самом деле и в монолите можно побороться за изолированность компонентов, например, на уровне серверного кода. Если время от времени изоляция даёт течь, современные инструменты предлагают продвинутые инструменты рефакторинга. Пользуйтесь. Хотя, как правило, на это находится время, только когда дела уже совсем плохи.
Теперь опустимся ниже, на уровень базы данных. Почему-то здесь на изолированность обращают внимание гораздо реже. В результате через пару тройку лет активного развития в базе данных монолита образуется если не хаос, то энтропия продвинутого уровня. Чтобы её побороть, мало уже одной строчки в бэклоге. Необходимы месяцы кропотливого и долгого труда.
В микросервисной архитектуре это решается гильотиной. Общей базы данных просто нет.
Помимо изолированности есть и побочные плюсы. Например, легче реализовать Polyglot Persistence, когда база подбирается под конкретные цели. Ничто не мешает делать это и без микросервисов, и так часто делают. Но всё же в одном случае это закон, в другом — исключение.
У этой медали есть оборотная сторона. Много баз, много контекстов, как их все согласовать? Старая техника распределенных транзакций сложна и обладает низкой скоростью. Возможно это иногда можно пережить. А вот необходимость синхронного взаимодействия нескольких микросервисов не может устраивать, и это не побороть.
Проблема решается нетрадиционно для монолита: отказом от постоянной согласованности данных. Добро пожаловать в мир Eventual consistency. На первых порах это вызывает волну «справедливого» гнева. Но если разобраться, то нужна ли повсеместно немедленная согласованность данных по окончании транзакции? При детальном рассмотрении значительную часть случаев можно отбросить. Где возможно, заменяют одну распределённую транзакцию серией локальных с компенсационными механизмами. Где-то мирятся с временной несогласованностью. А возможные ошибки либо обрабатывают за счет более сложной архитектуры, либо благодаря данным мониторинга. Если ничего не получается, то в особо экстремальных случаях всё же используют распределенные транзакции. Но это, с моей точки зрения, нарушение принципов MSA.
Монолит против микросервисов
Микросервисный подход несет довольно много проблем. Их найти не трудно и каждый может поупражняться.
Например, организационные вопросы. Как удержать в согласованном по версиям состоянии сотню микросервисов, которые еще и постоянно и непредсказуемо редеплоятся. А доступ к средам у каждого инженера каждой команды? Какая команда напишет интеграционные тесты? И если кто-то согласится, то попробуй еще их напиши для такой запутанной конфигурации. А если возникает ошибка, то чья она? Только той команды, у которой сломалось? Как не узнать вечером в пятницу, что версия API N-го сервиса, которой вы пользуетесь, вдруг стала deprecated?
Да, это действительно проблемы. Но команды, которые практикуют Agile и DevOps, уже знают решение. Поэтому начинать путь к микросервисной архитектуре стоит с внедрения этих практик.
Кроме организационных есть и чисто архитектурные. Как перейти от монолита, где всё синхронно, согласованно и едино, к распределенной событийной архитектуры, основанной на множестве мелких элементов, в которой надо учитывать возможную неконсистентность данных? Одного этого достаточно, чтобы задуматься: а стоит ли игра свеч? На этом фоне, например, падение скорости обработки одного запроса кажется мелочью. Хотя бы работает!
Тогда зачем? Если у вас нет проблем с вашим «монолитом», то не надо их искать.
Но если проблемы есть, то посмотрите на плюсы MSA, и возможно она спасет вас.
Разбиение на независимые компоненты даёт безусловные и неоспоримые преимущества: легкое понимание контекста, гибкость развития, управления и масштабирования. Независимость и небольшой размер дают и неожиданные плюсы с точки зрения инфраструктуры. Вам теперь не нужна монструозная машина за 100500 долларов. Микросервисы можно устанавливать на обычные дешевые машинки. И окажется, что даже все вместе они будут стоить на порядок меньше, но работать эффективнее той самой супермашины, на которую у вас в организации, наверняка, молятся и сдувают с неё пылинки.
Здесь уместен другой лозунг от популиста. Хотя, как и предыдущий, он вполне серьезен.
Каждому микросервису по своему серверу!
Продолжим агитировать за микросервисы. Посмотрим на лидеров IT-индустрии: Amazon, Netflix, Google и другие показывают впечатляющие результаты. Их гибкость и скорость вывода новых продуктов поражают. Поэтому игра точно стоит свеч! Здесь уместно вспомнить, что в упомянутых организациях команд «уровня бог» не одна и не две. Им сложности микросервисной архитектуры вполне по зубам. И если предложить создать монолит, то они и его сделают так, что он будет сверкать путеводной звездой.
А, например, Amazon вполне себе работал на монолите, уже будучи гигантом и имея миллиардные обороты. Сайт газеты Guardian до сих пор, а возможно и навсегда, базируется на микросервисах вокруг монолита. Это говорит о том, что значительная часть задач успешно, а зачастую и легче, решается без привлечения микросервисов.
И всё же это не значит, что микросервисы не для вас. Не боги горшки обжигают. Но бросаться с головой в омут тоже не стоит. Для микросервисной архитектуры команда должна быть достаточно зрелой. Один из главных критериев: использует ли она Agile и DevOps? Команда должна быть грамотной. Это сложно формализовать, но всё же попробуйте трезво оценить возможности. Например, насколько команда продвинута в Reactive и Event-Driven Architecture? К тому же команда должна иметь подготовленную инфраструктуру для поддержки микросервисной системы.
Впрочем, достаточно. Просто попробуйте. Надеюсь, получится и понравится.
Комментарии (31)
m0Ray
10.01.2018 21:59+2Если эту рукопись попробовать сжечь, она не будет гореть: слишком много воды.
Понятно из статьи только одно: разбивать большую задачу на мелкие подзадачи с понятным и стандартным интерфейсом между ними — это круто. Ну, в общем-то, это и так было мне известно на практике. И вот ради этого такую простыню?
Bonart
10.01.2018 22:37+2Один сервис может развивать одна команда не более чем из дюжины человек.
Один сервис может быть полностью переписан одной командой за одну Agile-итерацию.Я один вижу тут противоречие?
Конечно любая мало-мальски серьезная программа пишется с разбиением на компоненты, которые, безусловно, основываются на тех же принципах. Но в монолите общая кодовая база открывает возможности для нарушения низкой связанности. И при слабой дисциплине рано или поздно код превращается в спагетти.
Простите мой французский, но сколько раз можно повторять это вранье?
Каким образом люди, которым не хватает дисциплины при использовании интерфейсов с вызовами внутри процесса, вдруг резко улучшат навыки при переходе к вызовам сетевым?
Под такую формулировку компонента подходят и сторонние библиотеки. Здесь сложнее с нарушением
границ произвольными связями, но не на многоЧего только люди ни придумают, лишь бы копипастить не бросать.
Разбиение на независимые компоненты даёт безусловные и неоспоримые преимущества:
… без всяких микросервисов с их дорогими и ненадежными сетевыми вызовами и замечательными неконсистентными данными.
С такими агитаторами микросервисной архитектуре врагов не надо, "друзья" со всем справятся сами.
shuron
10.01.2018 23:11Валидные все замечания… Под всеми подпишусь…
Вот только тут автор не до-раскрыл…
Чего только люди ни придумают, лишь бы копипастить не бросать.
Библиотеки "не нужны" которые 1) общие 2) описывают интерфейс между сервисами… Лучше копипастить пару строк, но быть абсолютно независимым в релиз-цыклах отдельных сервисов… Если вы сможете это с бибилиотеками, то без проблем.
Как пример: к простому REST сервису не надо писать спиальную клиентску библиотеку. Возможно затрыты на апдейт и синхронизацию этой библиотеки слишком привяжут развитие сервиса, к релиз-цыклам этой либы.
Это о том что необдуманыне зависимости, в долгосрочном цыкле системы, легко становятся опаснее чем любой копи-пастинг.
Bonart
10.01.2018 23:43Библиотеки "не нужны" которые 1) общие
Да здравствует копипаста!
Вот только что мы должны копипастить? Код, решающий наши задачи делится на бизнес-логику и инфраструктуру. Копипасты бизнес-логики быть не может, так как каждый микросервис решает задачи своего под-домена и пересечений с другими сервисами не должно быть по построению. Копипаста инфраструктурного кода ведет к удорожанию
поддержки на пустом месте, а у микросервисов инфраструктура и так мягко говоря недешевая, причем продуктовые задачи никакая инфраструктура сама по себе не решает.
Лучше копипастить пару строк, но быть абсолютно независимым в релиз-цыклах отдельных сервисов
Разработчики, которые умеют в такие сложные вещи, как правильное разделение на микросервисы и тотальную автоматизацию поддержки внезапно перестают понимать принцип открытости-закрытости и перестают отделать контракты от реализации?
2) описывают интерфейс между сервисами
От того, что мы не опишем контракты между сервисами, они вдруг пропадут? Ничего подобного, просто эти интерфейсы сделаются неявными, а факты их изменения и нарушения будут проявляться задним числом.
Как пример: к простому REST сервису не надо писать спиальную клиентску библиотеку
Практически на любой CRUD достаточно одного обобщенного сервиса. А там, где кончается CRUD и начинается бизнес, REST скорее вреден чем бесполезен. Кстати, формирование запросов вручную намного сложнее, многословнее и опаснее использования библиотечных оберток.
Это о том что необдуманыне зависимости
Копипаста как лекарство от зависимостей примерно то же самое что керосин как средство тушения пожара.
shuron
11.01.2018 13:49Вот только что мы должны копипастить?
Вы не должны ничего копипастить.
Вам предлогают принцип 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 тоже может препятствовать это-му стремлению, библиотеки то на яве ;) Но это не основной аргумент, просто пища для размышления.
YuryKa Автор
11.01.2018 10:41С такими агитаторами микросервисной архитектуре врагов не надо, «друзья» со всем справятся сами.
Да. Такая негативная «агитация» является намеренной. Именно для того, чтобы использование микросервисов было осознанным, а не для строчки в резюме.Bonart
11.01.2018 13:47> Да. Такая негативная «агитация» является намеренной. Именно для того, чтобы использование микросервисов было осознанным, а не для строчки в резюме.
У вас агитация специально состоит из дезинформации?
Единственная вещь, ради которой есть смысл переходить к микросервисам — селективное горизонтальное масштабирование.
Для всего остального есть гораздо более простые, дешевые и эффективные решения.
И в статье об этом ни слова.
Зато рекламы, где за плюсы микросервисов выдаются плюсы компонентного подхода, кластеризации и шардинга — вагон и маленькая тележка.
YuryKa Автор
11.01.2018 10:50Один сервис может развивать одна команда не более чем из дюжины человек.
Один сервис может быть полностью переписан одной командой за одну Agile-итерацию.
Я один вижу тут противоречие?
Все четыре пункта, приведенные в статье, противоречат друг другу, в той или иной степени. Они все являются индикативными. Достаточно выбрать один из них и ориентироваться только на него.
deeptowncitizen
11.01.2018 10:41статья выглядит слишком агитационной. в ней не описаны плюсы, а микросервисная архитектура выставлена такой себе панацеей. одна из проблем в том, что на кого-то агитация подействует и микросервис родится там, где ему не место, или как минимум не в процессе эволюции системы.
хотелось бы услышать и про минусы. сказать, что требуется DevOps/Agile team, или остановится на юнит и интеграционных тестах — это как упустить половину.
Интересно было бы услышать, как у вас обеспечивается качество и своевременность поставок сервиса. Как происходит разработка, какие виды тестов выполняются? хотя бы как вы обеспечиваете тестирование (и какое) нового функционала? Делаете ли вы это до того, как он попал в общую ветку и т.д. И как результат насколько предсказуема разработка?YuryKa Автор
11.01.2018 10:45статья выглядит слишком агитационной. в ней не описаны плюсы, а микросервисная архитектура выставлена такой себе панацеей
В статье, тем не менее, есть и упоминание минусов MSA. Возможно, их должно быть больше. Но, например, в предыдущем комментарии говорится, что с негативом перебрали.
dargo
11.01.2018 11:05Почти в каждой статье о микросерверах можно встретить пассаж о том что ESB это плохо. А что же именно плохо? Быть может автор подразумевает, что сервисы живут в прекрасном мире RESTful и все они друг друга понимают без сложной интерпретации/трансляции? Есть же куча legacy сервисов которые умеют раздавать данные только в своем собственном формате. Получается, что каждому такому сервису необходимо писать обертку типа Anti-corruption layer (https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer). ESB как раз таки и может быть такой универсальной оберткой.
Хотелось бы развернутого пояснения следующему:
Впрочем, ESB ещё и противоречит таким критериям как децентрализация и независимость. Таким образом, сложность интеграции распределяется с центрального звена в виде ESB непосредственно на интегрируемые компоненты: «умные конечные точки».
vialz
11.01.2018 11:29+1А я честно говоря не услышал призывов выжечь SOA и ESB из ландшафта. Если вам подходит классический вариант с ESB — почему бы не продолжать использовать его? Продиктовано это скиллами вашей команды, видением или легасевостью ландшафта — это уже вопрос вне рамок темы :) Да и кто мешает применять разные арх. стили в разных слоях? Райф это банк, в банках есть Бэк слой где монолиты не только превалируют, но и зачастую оправданы.
YuryKa Автор
11.01.2018 11:44В статье нет ни слова о том, что ESB это плохо. Напротив, удачные реализации этого паттерна показывают его неоспоримую пользу. Но MSA предлагает другой подход к интеграции. Подчеркиваю, не говорится, что он лучше или хуже, чем в SOA, но другой.
Децентрализация в MSA – один из основных принципов. ESB же по определению является центральным и единственным звеном, отвечающим за интеграцию. Здесь и минусы, и плюсы. С моей точки зрения, ESB реально решает проблемы интеграции (трансформация, маршрутизация, технологические различия, обработка ошибок, логирование, мониторинг) и консьюмеры и провайдеры от этого выигрывают. В MSA каждый сам за себя. И сложность интеграции (все что перечислено в предыдущих скобках) остается в самих микросервисах. Best practices в MSA решать это с помощью инфраструктурных библиотек, что скрашивает эту проблему.
vialz
11.01.2018 11:23+1На мой взгляд, статья для вводной вполне годная, хотя возможно стоило бы обозначить вначале целевую аудиторию. Планируется ли описание примера внедрения MSA в Райфе? :)
donskov-s
14.01.2018 16:54+1 к автору данного комментария. Планируется ли описание примера внедрения MSA в Райфе? Проблемы, с которыми сталкивается команда в целом и в инфраструктуре банка(релизное управление, сеть, сервера, мониторинг, логирование...)? Существуют ли реальные позитивные стороны данного архитектурного веяния?
Mendel
11.01.2018 16:13Больше всего смущает именно сеть. Можно же не монструозную ESB тащить а что-то простенькое на базе той же Редиски или на худой конец какой-то свой/коробочный/SaaS MessageQueue.
В общем мысль моя в том, что хоть ESB и является единой точкой отказа, но если она будет совсем тонкой, то это не станет проблемой.
Ogoun
11.01.2018 16:41Очень академично получается, в реальности ресурсы ограничены.
1. Smart-endpoint'ы. REST и прочее конечно хорошо, но бинарная сериализация меньше по трафику и быстрее по сериализации. На практике я использую кастомную бинарную сериализацию пакуя данные без метаинформации (по сравнению с BinarySerialization дает на 30% меньший размер и на 500% прирост к скорости сериализации), когда количество сообщений измеряется в миллионах, и вы ограничены по количеству и мощности серверов подобная оптимизация дает значительный эффект. REST использую только для интеграции с сервисами вне системы, на периферии.
2. Отказ от ESB неоправдан, и непонятен, получается каждый сервис должен знать прямые адреса сервисов с которыми обменивается данными, что убивает независимость развертывания, и простоту балансировки. Есть stateless шины сообщений, например, можно поднять кластер NATS и из коробки получить надежный и быстрый механизм взаимодействия, с балансировкой, при этом низкая цена поддержки, т.к. шина не хранит состояние.
3. Библиотеки/общий код. В реальности от этого никуда не деться, или грубо нарушать DRY или все-таки делать общий код. Конечно получается неудобно при изменении логики в инфраструктуре, это повлечет пересборку всех микросервисов, но можно облегчить себе жизнь автоматизацией развертывания и локальным nuget-хранилищем. А использование ESB позволит обновиться без остановки работы системы в целом (подняли новую версию микросервиса, убили старую, благодаря балансировке обновление прозрачно)
worldmind
Исходя из первого абзаца решил, что есть какие-то отличия новомодных микросервисов от старого доброго SOA, но, как и понятно, отличий нет.
SirEdvin
Переизобретение — это все-таки важно. А то без хайпа надо было бы самим доходить до всего.
shuron
SOA может и похожа определением (словестным) на MSA, но ИМХО речь о другом и статья это не плохо показывает.
Я свою проф. деятельность начинал в Концерне и потом консалтил еще во времена популярности SOA.
И мне кажется бизнес в свое время понял SOA так:
В Микросервисной архитектуре скорее надо применить "zoom". Тоесть речь идет о более технических сущностях конечно же в контексте современных представлений (или догм):
В мире реально существовавшего SOA, попадавшегося мне на глаза, делили по бизес фичам (capability). А часто вопрос и не задавался как делить, потому что
закон Конвея (“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”), что есть на то и пишут заглушки.
Что-то в этом роде.
П.С. заранее прошу прощение, за возможные странности моего русского языка .
worldmind
> делить cервисы можно не только по бизнес фичам но и «как угодно», например по техническим предпочтениям скалируемости одних или других сущностей.
В этом согласен, SOA это про бизнес фичи, а микросервисы могут быть и чисто техническими, остальные отличия касаются больше реализации, сама архитектура не привязана к SOAP/ESB/BPM, причём нынешним микросервисам надо поучиться у SOA наличию таких стандартов и механизмов.
Получается что в плане глубины декомпозиции микросервисы шагнули глубже, но по пути потеряли некоторые плюшки SOA.
shuron
Например?
Опять же, может это просто не входит в определение, но никто вам не мешает включить все плюшки ;)
worldmind
Те самые SOAP/WSDL/ESB/BPM при всех их недостатках были достаточно стандартным набором технологий, что упрощало интеграцию, микросервисы про них забыли, а замены не предлагают.
shuron
Упрощали? Боже упаси… Чем же все эти SOAP/WSDL упрощали… Это было достаточно жесткое соединение… Системы были достаточно не поворотливые… Вы писали все эти WSDLины? Версионировали? Это же застрел ;) Меня больше не заставите ;)
Да это хорошая тема но независима от SOAP/WSDL/ESB.
И те Ентерпрайзные дорогущие и абсолютно баговые (Oracle BPM Suite) ситемы которые работали (иногда исключительно ) через ESB вымирают! Слава богу кстати!
С появлением и развитием нормального BPMN и например Camunda (которая опен/сорс, комюнити дривен) BPM стала соотвествовать и принесла те фишки про которые в книжках ещем может и 15 лет назад писали, но которые реальные проекты из бизнеса редко приносили (по многим причинам)
П.С. возможно у меня специфический взгляд на это. Я со всем этим в Германии столкнулся.
worldmind
Я же отметил — при всех их недостатках, но они были, а нынешние микросервисы не родили никаких новых стандартов протоколов взаимодействия.
Ascott
Ну стандартом де факто стало REST + JSON вместо SOAP, swagger вместо wsdl. Про BPMN уже сказали выше. Ну а ESB — это конечно не всё? но часть функций взяли на себя различные очереди и брокеры типа ZeroMQ, RabbitMQ и т.д. Тут конечно есть нюанс — нужно договариваться о протоколах, но опять же, смотрим про первые два пункта.
shuron
да. + не нужен ESB, нарушал он принцип dump pipe.
P.S. дух временени Хабр: Разбор доклада Ивана Круглова «Строим свой Service Mesh»
YuryKa Автор
Если говорить о SOA, то начнем с того, что это все же больше про интерфейсы, за которыми скрывалась сложность реализации. То есть реализация, все же отдельно. В то время как MSA предлагает принципы и того и другого. Сравнивая принципы интеграции этих двух подходов, безусловно, можно найти много одинакового. Здесь я соглашусь, что MSA берет лучшее от SOA. И это правильно. Но все же есть и различия, и они представлены в части под названием: Интеграция. Если говорить о противопоставлении, то с моей точки зрения, все же правильнее делать это с точки зрения монолита и MSA. Но опять же – это не значит, что одно лучше, а другое хуже. Просто такое сравнение получится более многогранным.