что не относится к компонентам микросервисного подхода

Простым языком о микросервисной архитектуре для начинающих

Расскажем о плюсах и минусах микросервисов, а также выясним, кому подходит технология.

Что такое микросервисная архитектура

Микросервисная архитектура — распространенный подход к разработке программного обеспечения, когда приложение разбивается на небольшие автономные компоненты (микросервисы) с четко определенными интерфейсами. Именно эта архитектура характерна для cloud-native приложений, которые сейчас популярны благодаря преимуществам, что открывают для бизнеса облачные среды.

Микросервисы vs Монолит

Прежде чем начать рассказ о микросервисах, стоит вспомнить другой тип приложений, который им чаще всего противопоставляют, — монолиты. Это приложения, построенные как единое целое, где вся логика по обработке запросов помещается внутрь одного процесса. Разумеется, монолиты могут иметь модульную структуру — содержать отдельные классы, функции, namespace (в зависимости от выбранного языка программирования). Но связи между этими модулями настолько сильны, что изменение каждого из них неизбежно отражается на работе приложения в целом.

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

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

Пример монолитной архитектуры

Мы видим, что бизнес-функции приложения очень разнообразны: работа с каталогом товаров и корзиной, обработка заказов, их оплата и отслеживание статуса, ведение пользователей и так далее. Но на уровне приложения все они объединены в один монолитный блок. При разворачивании код для различных функций находится на одном сервере. Чтобы масштабировать приложение, вам необходимо запустить несколько его экземпляров на различных физических серверах.

Недостатки такой схемы монолитной архитектуры очевидны:

Даже небольшое изменение для одной из бизнес-функций будет приводить к необходимости сборки и развертывания новой версии всего приложения.

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

Отказ одного модуля чаще всего сказывается на всей работе в целом в силу тесных связей внутри приложения.

Разработчик ограничен выбранным для приложения технологическим стеком. Хотя для ряда компонентов, возможно, было бы эффективно использовать иные технологии.

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

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

Любое изменение в базе данных будет сказываться на всем приложении и требовать значительных изменений кода.

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

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

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

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

Пример микросервисной архитектуры

Ключевые преимущества микросервисов по сравнению с монолитами

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

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

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

Можно подбирать различные наборы технологий, оптимальные для решения задач, стоящих перед отдельными сервисами.

При разработке микросервисов команды принято закреплять за конкретными бизнес-задачами (и сервисами, соответственно). Такие команды, как правило, показывают большую эффективность, а управлять ими легче.

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

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

Каждый микросервис, как правило, использует собственное хранилище данных — поэтому изменение модели данных в одном сервисе не влияет на работу остальных.

Недостатки микросервисной архитектуры: как с ними справиться

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

Распределенная система

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

Известны несколько путей решения этой проблемы:

Оба метода усложняют модель программирования и увеличивают требования к квалификации.

Усложнение процессов и повышение требований к команде

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

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

Необходимость поддержания согласованности приложения

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

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

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

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

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

Источник

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

Вступление

Чуть ли не каждый второй, кто впервые сталкивается с MSA (Micro Service Architecture), на первых порах восклицает: «Да я эти микросервисы еще …надцать лет назад». Отчасти они правы. И я тоже был из этой самой половины, и не понимал — почему такой шум?

В самом деле! Ведь MSA — это тоже про разработку софта. Какие здесь могут быть революции? Все методики знакомы. В некоторых местах можно даже удивиться: «А разве бывает по-другому»? Фанаты Agile и DevOps тоже скажут, что это всё наше, родное.

Но всё же прошу вас набраться терпения и продолжить читать дальше.

Что такое микросервисная архитектура (MSA)

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

Что такое микросервис (MS)

Понять суть микросервиса проще всего на сравнении, или даже противопоставлении его крупному приложению — монолиту. В отличии от MSA, я не буду давать определение микросервису, а перечислю его наиболее важные характеристики.

А дальше мы рассмотрим каждую из них подробнее.

Я выделил восемь свойств микросервиса:

Небольшой

Что такое «небольшой»? Такая малоинформативная формулировка! На самом деле, по-другому не скажешь. Каждый должен самостоятельно определиться с размером. Лучше всего на практике. В качестве индикативных оценок можно ориентироваться на рекомендации экспертов. Размер микровервиса должен быть таким, чтобы выполнялось одно из условий:

Независимый

Микросервисная архитектура — воплощение паттернов 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 непосредственно на интегрируемые компоненты: «умные конечные точки».

Здесь есть дилемма. Конечно бинарные протоколы гораздо эффективнее. Но, во-первых, появляются технологические ограничения. Во-вторых, на бинарных протоколах сложнее реализовывать шаблон Tolerant Reader, сохраняя эффективность. В-третьих, опять появляется зависимость провайдера и потребителей, поскольку они оперируют одними и теми же объектами и методами, то есть связаны по кодовой базе.

Другая отличительная черта взаимодействия микросервисов — синхронные вызовы не приветствуются. Рекомендуется использовать один синхронный вызов на один запрос пользователя, или вообще отказаться от синхронных вызовов.

И еще пара замечаний.

Design for failure для распределенной системы

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

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

Поэтому микросервисы могут вдруг перестать отвечать, могут начать отвечать медленнее, чем обычно. И каждый удаленный вызов должен это учитывать. Должен правильно обрабатывать разные варианты отказа, уметь ждать, уметь возвращаться к нормальной работе при восстановлении контрагента.

Дополнительный уровень сложности привносит событийная архитектура. А отладку такой системы — не одного микросервиса, а системы, где много потоков разнонаправленных неупорядоченных событий — даже трудно представить. И даже если каждый из микросервисов будет безупречен с точки зрения бизнес-логики, этого мало. По аналогии со спортом, «звёзды» не гарантируют звездную команду, ведь в команде важнее не «звезды», а слаженность всех её игроков.

И поскольку сложность таких систем очень высока, то проблему решают так.

Децентрализация данных

Каждому микросервису по своей базе данных!

Лозунг популиста на выборах.

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

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

В микросервисной архитектуре это решается гильотиной. Общей базы данных просто нет.

Помимо изолированности есть и побочные плюсы. Например, легче реализовать Polyglot Persistence, когда база подбирается под конкретные цели. Ничто не мешает делать это и без микросервисов, и так часто делают. Но всё же в одном случае это закон, в другом — исключение.

У этой медали есть оборотная сторона. Много баз, много контекстов, как их все согласовать? Старая техника распределенных транзакций сложна и обладает низкой скоростью. Возможно это иногда можно пережить. А вот необходимость синхронного взаимодействия нескольких микросервисов не может устраивать, и это не побороть.

Проблема решается нетрадиционно для монолита: отказом от постоянной согласованности данных. Добро пожаловать в мир Eventual consistency. На первых порах это вызывает волну «справедливого» гнева. Но если разобраться, то нужна ли повсеместно немедленная согласованность данных по окончании транзакции? При детальном рассмотрении значительную часть случаев можно отбросить. Где возможно, заменяют одну распределённую транзакцию серией локальных с компенсационными механизмами. Где-то мирятся с временной несогласованностью. А возможные ошибки либо обрабатывают за счет более сложной архитектуры, либо благодаря данным мониторинга. Если ничего не получается, то в особо экстремальных случаях всё же используют распределенные транзакции. Но это, с моей точки зрения, нарушение принципов MSA.

Монолит против микросервисов

Микросервисный подход несет довольно много проблем. Их найти не трудно и каждый может поупражняться.

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

Да, это действительно проблемы. Но команды, которые практикуют Agile и DevOps, уже знают решение. Поэтому начинать путь к микросервисной архитектуре стоит с внедрения этих практик.

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

Тогда зачем? Если у вас нет проблем с вашим «монолитом», то не надо их искать.

Но если проблемы есть, то посмотрите на плюсы MSA, и возможно она спасет вас.

Разбиение на независимые компоненты даёт безусловные и неоспоримые преимущества: легкое понимание контекста, гибкость развития, управления и масштабирования. Независимость и небольшой размер дают и неожиданные плюсы с точки зрения инфраструктуры. Вам теперь не нужна монструозная машина за 100500 долларов. Микросервисы можно устанавливать на обычные дешевые машинки. И окажется, что даже все вместе они будут стоить на порядок меньше, но работать эффективнее той самой супермашины, на которую у вас в организации, наверняка, молятся и сдувают с неё пылинки.

Здесь уместен другой лозунг от популиста. Хотя, как и предыдущий, он вполне серьезен.

Каждому микросервису по своему серверу!

Продолжим агитировать за микросервисы. Посмотрим на лидеров IT-индустрии: Amazon, Netflix, Google и другие показывают впечатляющие результаты. Их гибкость и скорость вывода новых продуктов поражают. Поэтому игра точно стоит свеч! Здесь уместно вспомнить, что в упомянутых организациях команд «уровня бог» не одна и не две. Им сложности микросервисной архитектуры вполне по зубам. И если предложить создать монолит, то они и его сделают так, что он будет сверкать путеводной звездой.

А, например, Amazon вполне себе работал на монолите, уже будучи гигантом и имея миллиардные обороты. Сайт газеты Guardian до сих пор, а возможно и навсегда, базируется на микросервисах вокруг монолита. Это говорит о том, что значительная часть задач успешно, а зачастую и легче, решается без привлечения микросервисов.

И всё же это не значит, что микросервисы не для вас. Не боги горшки обжигают. Но бросаться с головой в омут тоже не стоит. Для микросервисной архитектуры команда должна быть достаточно зрелой. Один из главных критериев: использует ли она Agile и DevOps? Команда должна быть грамотной. Это сложно формализовать, но всё же попробуйте трезво оценить возможности. Например, насколько команда продвинута в Reactive и Event-Driven Architecture? К тому же команда должна иметь подготовленную инфраструктуру для поддержки микросервисной системы.

Впрочем, достаточно. Просто попробуйте. Надеюсь, получится и понравится.

Источник