Архитектура микрослужб

Само название предполагает, что архитектура микрослужб является подходом к созданию серверного приложения как набора малых служб, Это означает, что архитектура микрослужб главным образом ориентирована на серверную часть, несмотря на то, что этот подход также используется для внешнего интерфейса. где каждая служба выполняется в своем процессе и взаимодействует с остальными службами по таким протоколам, как HTTP/HTTPS, WebSockets или AMQP. Каждая микрослужба реализует специфические возможности в предметной области и свою бизнес-логику в рамках определенного ограниченного контекста, должна разрабатываться автономно и развертываться независимо. Наконец, у каждой микрослужбы должны быть соответствующие собственные модель данных и логика предметной области (владение и децентрализованное управление данными); для каждой микрослужбы могут применяться разные технологии хранилищ (SQL, NoSQL) и разные языки программирования.

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

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

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

Рис. 4-6. Монолитное развертывание в сравнении с подходом на основе микрослужб

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

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

Ниже перечислены важные аспекты успешного ввода системы на основе микрослужб в эксплуатацию:

• мониторинг и проверки работоспособности служб и инфраструктуры;

• масштабируемая инфраструктура служб (то есть облако и оркестраторы);

• проектирование и реализация безопасности на разных уровнях: проверка подлинности, авторизация, управление секретами, безопасный обмен данными и т. д.;

• быстрая поставка приложения, причем разными микрослужбами обычно занимаются разные команды;

• методики и инфраструктура DevOps и непрерывной интеграции и поставки.

Из этих аспектов только первые три рассматриваются в данном руководстве. Последние два, связанные с жизненным циклом приложения, описываются в дополнительной электронной книге Жизненный цикл контейнерного приложения Docker на основе платформы и средств Майкрософт.

Дополнительные ресурсы

• Марк Руссинович (Mark Russinovich). Микрослужбы: революция в сфере приложений, движимая облачными технологиями
  https://azure.microsoft.com/blog/microservices-an-application-revolution-powered-by-the-cloud/

• Мартин Фоулер (Martin Fowler). Микрослужбы
  https://www.martinfowler.com/articles/microservices.html

• Мартин Фоулер (Martin Fowler). Требования для микрослужб
  https://martinfowler.com/bliki/MicroservicePrerequisites.html

• Джимми Нилссон (Jimmy Nilsson). Фрагментирование облачных вычислений
  https://www.infoq.com/articles/CCC-Jimmy-Nilsson

• Сезар де ла Торре (Cesar de la Torre). Жизненный цикл контейнерного приложения Docker на основе платформы и средств Майкрософт (скачиваемая электронная книга)
  https://aka.ms/dockerlifecycleebook