26 основных паттернов микросервисной разработки

Несмотря на достоинства микросервисов, при их внедрении можно столкнуться с множеством проблем.

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

Рассмотрим несколько основных паттернов, разделив их на условные группы в зависимости от решаемой задачи.

@golang_interview – вопросы с собеседований Golang

Паттерны декомпозиции на микросервисы

Этот блок шаблонов предлагает решения для декомпозиции, то есть разделения приложений на микросервисы.

1. Шаблон «Разбиение по бизнес-возможностям» (Decompose By Business Capability)Один из наиболее известных способов разбиения на микросервисы — это определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них. Бизнес-возможности представляют собой функции, которые будут доступны пользователям при работе с приложением.Паттерн Decompose By Business Capability. Пример создания микросервисов на основе бизнес-возможностей для интернет-магазина
2. Шаблон «Разбиение по поддоменам» (Decompose By Subdomain)При разбиении по бизнес-возможностям могут появиться так называемые «божественные классы» (God Classes) — сущности, которые будут общими для нескольких микросервисов. Как правило, их очень сложно разделить.Например, в приложении для интернет-магазина такой сущностью может стать заказ. В приведенном выше примере он используется сразу в нескольких сервисах: создание заказов (Orders Creation), доставка заказов (Orders Delivery), оповещения о заказах (Orders Alerts), предзаказы (Preorders).Чтобы избежать появления God Classes, можно использовать альтернативный шаблон разложения на микросервисы — разбиение по поддоменам. Он основан на концепциях предметно-ориентированного проектирования (Domain-Driven Design, DDD).DDD разбивает всю модель предметной области (домен) на поддомены. У каждого поддомена своя модель данных, область действия которой принято называть ограниченным контекстом (Bounded Context). Каждый микросервис будет разрабатываться внутри этого ограниченного контекста. Основная задача при использовании DDD-подхода — подобрать поддомены и границы между ними так, чтобы они были максимально независимы друг от друга.Если вернуться к примеру с интернет-магазином, то все, что связано с заказами, можно рассматривать в рамках поддомена «Заказы» (Orders Subdomain) и именно внутри этого поддомена создавать микросервис по управлению заказами (Orders Service). Таким образом, можно сократить число микросервисов по сравнению с декомпозицией на основе бизнес-возможностей. В нашем сильно упрощенном примере четыре микросервиса были преобразованы в один.Паттерн Decompose By Subdomain. Пример создания микросервисов на основе поддоменов для интернет-магазина: по сравнению с декомпозицией на основе бизнес-возможностей число микросервисов, так или иначе связанных с заказами, сокращено с 4 до 1

Паттерны рефакторинга для перехода на микросервисы

Эта группа шаблонов предназначена для организации взаимодействия с Legacy-приложениями и/или их постепенного перевода на микросервисную архитектуру.

1. Шаблон «Душитель» (Strangler)Рассмотренные выше способы разбиения на микросервисы хорошо подходят для новых приложений, создаваемых с нуля. Однако на практике часто возникает необходимость перевести на микросервисную архитектуру уже существующие монолитные приложения. Разложение монолита на микросервисы требует времени и не может быть выполнено за одну итерацию. Поэтому и был разработан паттерн Strangler, названный по аналогии с лианой, которая постепенно душит обвиваемое ею дерево.Этот шаблон означает миграцию монолитного приложения на микросервисную архитектуру путем постепенного переноса существующих функций в микросервисы. Настраивается маршрутизация запросов между устаревшим монолитом и микросервисами. Когда очередная функциональность переносится из монолита в микросервисы, фасад перехватывает клиентский запрос и направляет его к микросервисам. Новые функции при этом реализуются исключительно в микросервисах, минуя монолит. После переноса всех функций монолитное приложение полностью выводится из эксплуатации.Паттерн не рекомендуется использовать при небольших размерах монолита. В таком случае лучшим решением будет его единовременный перевод на микросервисную архитектуру, так как добавление фасада увеличивает задержки и затрудняет тестирование.Паттерн Strangler
2. Шаблон «Уровень защиты от повреждений» (Anti-Corruption Layer)При переводе Legacy-приложений на микросервисы рефакторинг некоторых подсистем может оказаться очень долгим либо вовсе невозможным. Но взаимодействовать с устаревшими подсистемами все равно нужно, несмотря на то, что в них, возможно, используются не самые современные технологии в части построения API, схем данных и так далее.Для таких случаев отлично подходит паттерн Anti-Corruption Layer. Он предназначен для изолирования различных подсистем путем размещения между ними дополнительного уровня, который может быть реализован как компонент приложения или независимая служба. Этот уровень связывает две подсистемы, позволяя им оставаться максимально независимыми друг от друга. Он содержит всю логику, необходимую для передачи данных в обе стороны: при взаимодействии с каждой из подсистем используется именно ее модель данных.Паттерн Anti-Corruption Layer

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

Этот блок шаблонов описывает возможные варианты взаимодействия микросервисов с базами данных.

1. Шаблон «База данных на сервис» (Database Per Service)Основная рекомендация при переходе на микросервисы — предоставить каждому сервису собственное хранилище данных, чтобы не было сильных зависимостей на уровне данных. При этом имеется в виду именно логическое разделение данных, то есть микросервисы могут совместно использовать одну и ту же физическую базу данных, но в ней они должны взаимодействовать с отдельной схемой, коллекцией или таблицей.Основанный на этих принципах паттерн Database Per Service повышает автономность микросервисов и уменьшает связь между командами, разрабатывающими отдельные сервисы.У паттерна есть и недостатки: усложняется обмен данными между сервисами и предоставление транзакционных гарантий ACID. Паттерн не стоит применять в небольших приложениях — он предназначен для крупномасштабных проектов с большим числом микросервисов, где каждой команде требуется полное владение ресурсами для повышения скорости разработки и лучшего масштабирования.Паттерн Database Per Service
   Паттерну Database Per Service часто противопоставляют другой шаблон — Shared Database («Разделяемая база данных»). По сути, он представляет собой антипаттерн и подразумевает использование одного хранилища данных несколькими микросервисами. Его допускается использовать на начальных стадиях миграции на микросервисную архитектуру или в очень небольших приложениях, разрабатываемых одной командой (2–3 микросервиса).
2. Шаблон «API-композиция» (API Composition)Этот шаблон является одним из возможных вариантов получения данных из нескольких сервисов после применения к ним паттерна Database Per Service. Он предлагает создать отдельное API, которое будет вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них результатов в памяти. Паттерн можно рассматривать как вариант использования другого шаблона — API Gateway, о котором мы поговорим ниже.API Composition — это самый простой способ получения данных из нескольких источников, но он может привести к неэффективному объединению больших наборов данных в памяти. Альтернативным решением является следующий шаблон CQRS.Паттерн API Composition
3. Шаблон «Разделение команд и запросов» (Command Query Responsibility Segregation, CQRS)Этот паттерн предлагает отделить изменение данных (Command) от чтения данных (Query). Шаблон CQRS имеет две формы: простую и расширенную.В простой форме для чтения и записи используются отдельные модели ORM (Object-Relational Mapping), но общее хранилище данных.Паттерн CQRS. Простая форма
   В расширенной форме используются разные хранилища данных, оптимизированные для записи и чтения данных. Данные копируются из хранилища для записи в хранилище для чтения асинхронно. В результате хранилище для чтения отстает от хранилища для записи, но в конечном итоге является согласованным. Расширенный CQRS часто используется совместно с паттерном Event Sourcing, речь о котором идет далее.Паттерн CQRS. Расширенная форма
   Паттерн CQRS обеспечивает высокую доступность данных, независимое масштабирование систем чтения/записи и более быстрое чтение данных в микросервисах, управляемых событиями. Однако его использование увеличивает сложность системы и приводит к слабой согласованности данных. Паттерн подходит для сложных систем, где для чтения данных требуется запрос в несколько хранилищ или операции чтения и записи имеют разную нагрузку.
4. Шаблон «Поиск событий» (Event Sourcing)Приложения с микросервисной архитектурой часто используют асинхронные методы связи: сообщения или события. Для обеспечения атомарности операций в таких системах рекомендуется применять шаблон Event Sourcing.В традиционных базах данных объект с текущим состоянием сохраняется напрямую. При использовании шаблона Event Sourcing вместо объектов сохраняются события, изменяющие их состояния. Итоговое состояние объекта можно получить путем повторной обработки серии событий, пришедших за определенное время. Различные службы могут воспроизводить события из хранилища событий, чтобы вычислить соответствующее состояние своих хранилищ данных. Для реализации хранилища событий обычно применяется шаблон CQRS.Паттерн рекомендуется использовать в высокомасштабируемых транзакционных системах, управляемых событиями. Он не подходит для простых приложений, где микросервисы могут синхронно обмениваться данными (например, через API).Паттерн Event Sourcing
5. Шаблон «Сага» (Saga)Этот паттерн предназначен для управления распределенными транзакциями в микросервисной архитектуре, где применение традиционного протокола двухфазной фиксации транзакций (Two-phase commit protocol, 2PC) становится трудноосуществимым.При использовании паттерна каждая локальная транзакция обновляет данные в хранилище в рамках одного микросервиса и публикует событие или сообщение, которые, в свою очередь, запускают следующую локальную транзакцию и так далее. Если локальная транзакция завершается с ошибкой, выполняется серия компенсирующих транзакций, которые отменяют изменения предыдущих транзакций.Для координации транзакций существует два основных способа:
   • Хореография. Децентрализованная координация, при которой каждый микросервис прослушивает события/сообщения другого микросервиса и решает, следует предпринять действие или нет.
   • Оркестровка. Централизованная координация, при которой отдельный компонент (оркестратор) сообщает микросервисам, какое действие необходимо выполнить далее.
   ⠀
   Использование шаблона обеспечивает согласованность транзакций в слабосвязанных распределенных системах, однако увеличивает сложность отладки. Saga отлично подходит для систем, управляемых событиями и/или использующих базы данных NoSQL без поддержки 2PC, но не рекомендуется при использовании баз данных SQL и в системах с циклическими зависимостями между сервисами.Паттерн Saga

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

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

1. Шаблон «API-шлюз» (API Gateway)Наиболее очевидный способ обращения к микросервисам — прямое обращение от клиента к сервису. И его вполне можно применять в небольших проектах. Однако в приложениях корпоративного масштаба с большим числом микросервисов рекомендуется использовать шаблон API Gateway.Этот паттерн основан на применении шлюза, который находится между клиентским приложением и микросервисами, обеспечивая единую точку входа для клиента.В зависимости от конкретной цели использования паттерна иногда выделяют следующие его разновидности:
   • Gateway Routing. Шлюз используется как обратный Proxy, перенаправляющий запросы клиента на соответствующий сервис.
   • Gateway Aggregation. Шлюз используется для разветвления клиентского запроса на несколько микросервисов и возвращения агрегированных ответов клиенту.
   • Gateway Offloading. Шлюз решает сквозные задачи, которые являются общими для сервисов: аутентификация, авторизация, SSL, ведение журналов и так далее.
   Применение паттерна сокращает число вызовов, обеспечивает независимость клиента от протоколов, используемых в сервисах: REST, AMQP, gRPC и так далее, обеспечивает централизованное управление сквозной функциональностью. Однако шлюз может стать единой точкой отказа, требует тщательного мониторинга и при отсутствии масштабирования бывает узким местом системы.Паттерн API Gateway
2. Шаблон «Бэкенды для фронтендов» (Backends for Frontends, BFF)Этот паттерн является вариантом реализации шаблона API Gateway. Он также обеспечивает дополнительный уровень между микросервисами и клиентами, но вместо одной точки входа вводит несколько шлюзов для каждого типа клиента: Web, Mobile, Desktop и так далее.С помощью паттерна можно добавить API, адаптированные к потребностям каждого клиента, избавившись от хранения большого количества ненужных настроек в одном месте. Но шаблон не стоит применять в тех случаях, когда разница в требованиях к API у разных типов клиентов незначительна либо приложение само по себе небольшое: это приведет лишь к дублированию кода и увеличению числа компонентов.Паттерн Backends for Frontends

Паттерны построения пользовательского интерфейса

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

1. Шаблон «Сборка пользовательского интерфейса на стороне клиента» (Client-Side UI Composition)При использовании этого шаблона разметка HTML создается и обновляется непосредственно в браузере. Каждый экран/страница пользовательского интерфейса разбивается на фрагменты, данные для которых получают различные микросервисы. Каждый такой фрагмент, по сути, представляет собой мини-приложение, которое может отображать и обновлять свою разметку независимо от остальной части страницы.Многие современные фреймворки, например AngularJS и ReactJS, помогают в реализации этого шаблона. Они используют принцип одностраничных приложений (Single-Page Application, SPA), позволяя обновлять отдельную область экрана, а не всю страницу целиком.Паттерн Client-Side UI Composition
2. Шаблон «Сборка фрагментов страниц на стороне сервера» (Server-Side Page Fragment Composition)При использовании этого шаблона сборка фрагментов пользовательского интерфейса происходит на сервере, а клиентская часть получает уже полностью собранную страницу, благодаря чему достигается более высокая скорость загрузки. Сборка обычно выполняется отдельной службой, которая находится между браузером и серверами приложений: Nginx, Varnish, CDN.Паттерн Server-Side Page Fragment Composition

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

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

Ключевым компонентом обнаружения микросервисов выступает реестр сервисов (Service Registry) — база данных с информа­цией о расположении сервисных экземпляров. Когда экземпляры запускаются и останавливаются, информация в реестре обновляется. Но взаимодействовать с реестром сервисов можно двумя путями, которые и легли в основу описанных ниже шаблонов.

1. Шаблон «Обнаружение сервисов на стороне клиента» (Client-Side Service Discovery)Первый способ обнаружения сервисов — на стороне клиента. В этом случае сервисы и их клиенты напрямую взаимодействуют с реестром. Последовательность шагов следующая:
   1. Экземпляр сервиса обращается к API реестра, чтобы зарегистри­ровать свое сетевое местоположение. Он также может предоставить URL-адрес для проверки своей работоспособности (Health Check), который будет использоваться для продления срока его регистрации в реестре.
   2. Клиент самостоятельно обращается к реестру сервисов, чтобы получить список экземпляров сервисов. Для улучшения производительности клиент может кэшировать экземпляры сервиса.
   3. Клиент использует алгоритм балансировки нагрузки, циклический или случайный, чтобы выбрать конкретный экземпляр сервиса и отправить ему запрос.
   Ключевое преимущество обнаружения сервисов на стороне клиента — его независимость от используемой платформы развертывания. Например, если часть ваших сервисов развернута на K8s, а остальные работают в устаревшей среде, то обнаружение на уровне приложения будет лучшим вариантом, так как серверное решение на базе Kubernetes не будет совместимо со всеми сервисами.К недостаткам подхода можно отнести необходимость использования различных клиентских библиотек для каждого языка программирования, а иногда и фреймворка. Кроме этого, на вашу команду ложится дополнительная нагрузка по настройке и обслуживанию реестра сервисов.Паттерн Client-Side Service Discovery
2. Шаблон «Обнаружение сервисов на стороне сервера» (Server-Side Service Discovery)Второй способ обнаружения сервисов — на стороне сервера. В этом случае за регистрацию, обнаружение сервисов и маршрутизацию запросов отвечает инфраструктура развертывания. Последовательность шагов следующая:
   1. Регистратор, который обычно является частью платформы развертывания, прописывает все экземпляры сервисов в реестре сервисов. По каждому экземпляру сохраняется DNS-имя и виртуальный IP-адрес (VIP).
   2. Вместо того чтобы обращаться к реестру напрямую, клиент делает запрос по DNS-имени сервиса. Запрос поступает в маршрутизатор, являющийся частью платформы развертывания.
   3. Маршрутизатор обращается к реестру сервисов для получения сетевого расположения экземпляров нужного сервиса.
   4. Маршрутизатор применяет балансировку нагрузки, чтобы выбрать конкретный экземпляр сервиса и отправить ему запрос.
   Все современные платформы развертывания, включая Docker, Kubernetes и другие, как правило, имеют встроенный реестр и механизмы обнаружения сервисов.Основное преимущество паттерна состоит в том, что всеми аспектами обнаружения сервисов занимается сама платформа. Дополнительный код на стороне клиента или сервисов не требуется. Благодаря этому достигается независимость от используемых в приложении языков программирования и фреймворков.Недостатком паттерна является невозможность его применения к сервисам, которые развернуты вне основной платформы, реализующей механизмы обнаружения. Несмо­тря на это ограничение, рекомендуется использовать обнаружение сервисов на стороне сервера всюду, где это осуществимо.Паттерн Server-Side Service Discovery

Паттерны развертывания микросервисов

Этот блок шаблонов описывает возможные варианты развертывания разработанных микросервисов.

1. Шаблон «Экземпляр сервиса на хост» (Service Instance Per Host)При переходе на микросервисную архитектуру рекомендуется проводить развертывание каждого экземпляра сервиса на собственном хосте (виртуальном или физическом). Паттерн Service Instance Per Host позволяет изолировать экземпляры сервисов друга от друга, избежать конфликтов версий и требований к ресурсам, максимально использовать ресурсы хоста, а также легче и быстрее проводить повторные развертывания. К недостаткам паттерна можно отнести потенциально менее эффективное использование ресурсов по сравнению с развертыванием нескольких экземпляров на хост.Иногда выделяют разновидности описанного шаблона, наиболее часто используемые на практике: «Экземпляр сервиса на виртуальную машину» (Service Instance Per VM) и «Экземпляр сервиса на контейнер» (Service Instance Per Container). При их использовании каждый экземпляр сервиса упаковывается и разворачивается в виде отдельной виртуальной машины либо контейнера соответственно.Паттерн Service Instance Per Host
2. Шаблон «Сине-зеленое развертывание» (Blue-Green Deployment)Паттерн позволяет выполнить развертывание новых версий сервисов максимально незаметно для пользователей, сократив время простоя до минимума. Это достигается за счет запуска двух идентичных производственных сред — условно синего и зеленого цвета. Предположим, что синий — это существующий активный экземпляр, а зеленый — это новая версия приложения, развернутая параллельно с ним.В любой момент времени только одна из сред является активной, и именно она обслуживает весь производственный трафик. После успешного развертывания новой версии — с прохождением всех тестов и так далее — трафик переключается на нее. В случае ошибок всегда можно вернуться к предыдущей версии.Паттерн Blue-Green Deployment

Паттерны повышения отказоустойчивости

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

1. Шаблон «Автоматический выключатель» (Circuit Breaker)При взаимодействии микросервисов не исключены ситуации, когда по какой-то причине один из сервисов перестает отвечать. Справиться с временными сбоями (медленное сетевое соединение, временная недоступность и так далее) помогают повторные вызовы. Однако при более серьезных сбоях, вызванных полным отказом сервиса, повторные вызовы будут лишь расходовать ресурсы.В таких случаях рекомендуется использовать шаблон Circuit Breaker. Микросервис будет запрашивать другой микросервис через Proxy-сервер. Он подсчитывает количество недавних сбоев и на основе него определяет, разрешать ли выполнение последующих вызовов или немедленно возвращать исключение.Proxy-сервер может находиться в трех состояниях:
   • Closed. Идет передача запросов между сервисами и подсчет количества сбоев. Если число сбоев за заданный интервал времени превышает пороговое значение, выключатель Proxy-сервера переводится в состояние Open.
   • Open. Запросы от исходного сервиса немедленно возвращаются с ошибкой. По истечении заданного тайм-аута выключатель переводится в состояние Half-Open.
   • Half-Open. Выключатель пропускает ограниченное количество запросов от исходного сервиса и подсчитывает число успешных запросов. Если необходимое количество достигнуто, выключатель переходит в состояние Closed, если нет — возвращается в статус Open.
   Использование шаблона повышает отказоустойчивость и предотвращает каскадные сбои, но требует тщательной настройки и мониторинга.Паттерн Circuit Breaker
2. Шаблон «Переборка» (Bulkhead)Свое название паттерн получил благодаря переборкам, используемым в судостроении: они защищают корабль от полного затопления в случае повреждения отдельных его частей. Так же и в архитектуре приложения: переборки изолируют элементы приложения в пулы, чтобы в случае сбоя одного из них остальные продолжали функционировать.Шаблон позволяет разделить ресурсы, чтобы гарантировать, что ресурсы, используемые для вызова одного сервиса, не влияют на ресурсы, используемые для вызова другого сервиса. Пример — использование отдельного пула соединений для каждого из нижестоящих сервисов.Вариант применения паттерна Bulkhead — разделение ресурсов, например пула соединений, между сервисами
   Еще один вариант использования шаблона — назначение каждому клиенту сервиса отдельного экземпляра сервиса. В таком случае, если один из клиентов сделает слишком много запросов, перегрузив свой экземпляр, другие клиенты смогут продолжить работу.Вариант применения паттерна Bulkhead — назначение каждому клиенту отдельного экземпляра сервиса
   Использование этого паттерна предотвращает каскадные сбои и изолирует критически важные ресурсы, но приводит к дополнительной сложности и менее эффективному использованию ресурсов.

Паттерны мониторинга микросервисов

Этот блок шаблонов охватывает возможные варианты построения мониторинга работы микросервисов.

1. Шаблон «Агрегация логов» (Log Aggregation)Хорошей практикой при разработке микросервисов считается ведение логов каждым экземпляром сервиса. Логи могут содержать ошибки, предупреждения, информационные и отладочные сообщения. Но с увеличением числа сервисов анализ логов, разнесенных по различным хостам, становится затруднительным.Паттерн Log Aggregation предлагает использовать централизованную службу ведения логов, которая будет собирать логи от каждого экземпляра сервиса. Это предоставит пользователям единую точку для поиска, анализа логов и настройки предупреждений, которые будут запускаться при появлении в них определенных сообщений.Паттерн Log Aggregation
2. Шаблон «Распределенная трассировка» (Distributed Tracing)В микросервисной архитектуре для выполнения клиентских запросов может потребоваться работа нескольких взаимосвязанных микросервисов. Каждый сервис обрабатывает запрос путем выполнения одной или нескольких операций, включая обращение к базе данных, публикацию сообщений и так далее. С увеличением числа сервисов становится все сложнее отследить место возникновения ошибок.Паттерн Distributed Tracing разработан для решения этой проблемы. Он предлагает назначать каждому внешнему запросу уникальный идентификатор (TraceId), который будет передаваться всем сервисам, участвующим в обработке запроса, и фиксироваться в журналах. Это позволит разработчикам видеть, как обрабатывается отдельный запрос, путем поиска в агрегированных журналах его внешнего идентификатора.Паттерн Distributed Tracing
3. Шаблон «Проверки здоровья» (Health Check)Иногда экземпляр сервиса, более не способный обрабатывать внешние запросы, остается доступен для других подсистем. Например, сервис может исчерпать пул соединений к базе данных — фактически он становится неработоспособным, но принимать внешние запросы по-прежнему в состоянии, хоть и без последующей корректной обработки. В таких случаях система мониторинга должна выдавать своевременное предупреждение, а балансировщик нагрузки, реестр служб и другие подсистемы не должны направлять запросы на отказавший экземпляр.Для решения этой задачи предназначен паттерн Health Check. Он предлагает определить для каждого сервиса конечную точку, которую можно использовать для проверки работоспособности, например /health. Этот API должен проверять статус хоста, подключение к другим сервисам, инфраструктуре и любую иную бизнес-логику. Клиент — служба мониторинга, реестр служб или балансировщик нагрузки — будет периодически обращаться к конечной точке для проверки работоспособности экземпляра сервиса.Паттерн Health Check

Прочие паттерны проектирования микросервисов

Здесь рассмотрим наиболее важные шаблоны из иных групп.

1. Шаблон «Посредник» («Посол», Ambassador)Приложениям и сервисам часто требуются общие функции, относящиеся к мониторингу, ведению журналов, настройкам безопасности, сетевым службам и так далее. Однако в микросервисной архитектуре отдельные сервисы могут быть построены с помощью различных языков и технологий — следовательно, они могут иметь свои зависимости и требовать определенных языковых библиотек. Паттерн Ambassador предлагает помещать клиентские фреймворки и библиотеки для решения периферийных задач внутрь вспомогательного сервиса, выступающего в роли Proxy между клиентским приложением или основным сервисом и прочими частями системы.Применение паттерна Ambassador позволяет:
   • Унифицировать обращение клиентских приложений к общим задачам независимо от используемого языка и фреймворка.
   • Решать периферийные задачи, не затрагивая основную функциональность, в том числе за счет передачи разработки отдельным специализированным командам. Это полезно, например, при необходимости централизованного управления сетевыми вызовами и функциями безопасности — во избежание дублирования сложного кода на каждом компоненте отдельно.
   • Добавлять новую функциональность в Legacy-приложения, которые тяжело поддаются рефакторингу.
   Так как добавление Proxy пусть и незначительно, но увеличивает сетевые задержки, шаблон Ambassador не рекомендуется использовать, когда время задержки критично. Также паттерн лучше не применять в случаях, когда можно обойтись стандартной клиентской библиотекой — например, если используется всего один язык или нет возможности выделить общие периферийные задачи.Развернуть Proxy можно как демон или службу. Если основной сервис является контейнерным, Proxy также разворачивается как отдельный контейнер на том же хосте, для этой цели используется другой паттерн — Sidecar.Паттерн Ambassador
2. Шаблон «Коляска» («Прицеп», Sidecar)Паттерн Sidecar предлагает помещать периферийные задачи, связанные с мониторингом, безопасностью, отказоустойчивостью и так далее, в отдельный компонент и развертывать его внутри собственного процесса или контейнера. Так обеспечивается однородный интерфейс для сервисов основного приложения, которые могут быть написаны на разных языках.Sidecar не обязательно является частью приложения, но связан с ним: для каждого экземпляра приложения рядом развертывается экземпляр Sidecar. Sidecar имеет тот же жизненный цикл, что и основное приложение.Преимуществами паттерна являются независимость вспомогательного компонента от платформы основного приложения, возможность их доступа к одним и тем же ресурсам, минимизация задержек из-за их близкого расположения и возможность независимого обновления. К недостаткам можно отнести накладные расходы на создание дополнительного компонента. Шаблон не рекомендуется использовать для небольших приложений, а также в тех случаях, когда можно обойтись библиотеками и стандартными механизмами расширений.Паттерн Sidecar
3. Шаблон «Тестирование контрактов, ориентированных на потребителя» (Consumer-Driven Contract Testing)Это один из стилей тестирования, который рекомендуют использовать в крупномасштабных проектах, где несколько команд работают над различными сервисами. Суть паттерна в том, что набор автоматизированных тестов для каждого сервиса (Provider Microservice) пишется разработчиками других сервисов (Consumer Microservice), вызывающих проверяемый сервис. Каждый такой набор тестов является контрактом, проверяющим, соответствует ли сервис провайдера ожиданиям потребителя. Сами тесты включают в себя запрос и ожидаемый ответ.Паттерн Consumer-Driven Contract Testing увеличивает автономность команд и позволяет своевременно обнаруживать изменения в сервисах, написанных другими командами. Но его применение может потребовать дополнительной работы по интеграции тестов, так как команды могут пользоваться различными инструментами тестирования.Паттерн Consumer-Driven Contract Testing
4. Шаблон «Внешняя конфигурация» (External Configuration)Практически все приложения во время работы используют разнообразные конфигурационные параметры: адреса служб, строки подключения к базам данных, учетные данные, пути к сертификатам и так далее. При этом параметры будут отличаться в зависимости от среды выполнения: Dev, Stage, Prod и так далее. Хранить конфигурации локально — в файлах, развертываемых вместе с приложением, — считается очень плохой практикой, особенно при переходе на микросервисы. Это приводит к серьезным рискам безопасности и требует повторного развертывания при каждом изменении конфигурационных параметров.Поэтому в приложениях корпоративного уровня рекомендуется использовать шаблон External Configuration, предлагающий хранить все конфигурации во внешнем хранилище. В качестве такого хранилища может выступать облачная служба хранения, база данных или другая система.В результате применения шаблона процесс сборки будет отделен от среды выполнения, а риски безопасности будут сведены к минимуму, так как конфигурации для производственной среды перестанут являться частью кодовой базы.Паттерн External Configuration

Почему важно применять шаблоны проектирования в микросервисной архитектуре

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

Вот лишь некоторые преимущества, которых можно достичь, используя паттерны проектирования микросервисов:

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

Источник