Шаблоны проектирования

Шаблон разбиение на МС

• по бизнес возможностям
• по проблемным областям

Шаблоны взаимодействия

Приложение, основанное на микросервисной архитектуре, является распределенной системой. Важную роль в этой архитектуре играет межпроцессное взаимодействие (interprocess communication, IPC). Придется принять ряд архитектурных решений о том, как сервисы будут взаимодействовать друг с другом и с внешним миром.

Ответить на вопросы?

• Стиль взаимодействия. Какой механизм IPC следует использовать?
• Обнаружение. Каким образом клиент сервиса узнает его IP-адрес, чтобы, например, выполнить НТТР-запрос?
• Надежность. Как обеспечить надежное взаимодействие между сервисами с учетом того, что некоторые из них могут быть недоступны?
• Транзакционный обмен сообщениями. Как следует интегрировать отправку сообщений и публикацию событий с транзакциями баз данных, которые обновляют бизнес-информацию?
• Внешний API. Каким образом клиенты вашего приложения взаимодействуют c сервисами?

Шаблоны согласованности данных для реализации управления транзакциями

Для обеспечения слабой связанности каждый сервис должен иметь собственную базу данных. Но, такой подход чреват некоторыми существенными проблемами, как следствие традиционная методика с использованием распределенных транзакций (2PC) не подходит для современных приложений. Вместо этого согласованность данных следует обеспечивать с помощью шаблона «Повествование».

Возможно использовать шаблон объединения API, который обращается к API одного или нескольких сервисов и агрегирует результаты. В некоторых ситуациях приходится прибегать к командным запросам с разделением ответственности (command query responsibility segregation, CQRS), которые хранят одну или несколько копий данных и позволяют легко к ним обращаться.

Шаблоны развертывания сервисов

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

Для проектирования наблюдаемых сервисов

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

Шаблоны автоматического тестирования сервисов

• Тестирование контрактов с расчетом на потребителя — проверка того, что сервис отвечает ожиданиям клиентов.
• Тестирование контрактов на стороне потребителя — проверка того, что клиент может взаимодействовать с сервисом.
• Тестирование компонентов сервиса — тестирование сервиса в изоляции.

Шаблоны безопасности

Шаблон «Токен доступа» В микросервисной архитектуре аутентификацию пользователей обычно выполняет API-шлюз, который затем должен передать учетную информацию, например идентификатор и роли, вызываемому сервису. Часто для этого применяют токены доступа, такие как JWT (JSON Web token). API-шлюз передает токен сервисам, которые могут его проверить и извлечь из него информацию о пользователе.

Процесс разработки и доставки ПО

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