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

Проблемы микросервисов

• Согласованность данных. Когда курьер принимает заказ, информация о заказе и курьере должна быть синхронизирована в нескольких микросервисах. Без правильного подхода к согласованности данных могут возникнуть расхождения и ошибки.
• Масштабируемость. По мере роста числа заказов и курьеров система должна уметь эффективно масштабироваться, чтобы обрабатывать больше данных и запросов. Неправильное проектирование может привести к узким местам и ухудшить производительность.
• Надёжность. Система должна оставаться работоспособной, даже если в отдельных компонентах произошли сбои. Нужны механизмы для восстановления и устойчивости к ошибкам.
• Простота поддержки. Чем больше микросервисов, тем труднее поддерживать систему. Чтобы упростить поддержку, нужно разработать чёткую документацию и стандартизировать подходы к разработке и развёртыванию.

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

Уровни паттернов проектирования микросервисов

1. Паттерны уровня приложений — application patterns.
2. Паттерны уровня инфраструктуры приложений — application infrastructures patterns.
3. Паттерны уровня инфраструктуры — infrastructures patterns.

1. Паттерны уровня приложений

• Database per Service,
• Service per Team,
• Event Sourcing.

Database per Service

• Courier Service — микросервис для управления курьерами,
• Order Service — микросервис для управления заказами,
• Location Service — микросервис для отслеживания местоположения курьеров.

Service per Team

• команда A отвечает за разработку микросервиса управления курьерами,
• команда B — за микросервис управления заказами,
• команда C — за микросервис отслеживания местоположения курьеров.

Event Sourcing

2. Паттерны уровня инфраструктуры приложений

• Distributed Tracing,
• Audit Logging.

Distributed Tracing

• Пользователь (User) отправляет запрос на создание заказа через API Gateway.
• API Gateway перенаправляет запрос в Order Service для обработки заказа.
• Order Service назначает курьера через Courier Service.
• Courier Service взаимодействует с Location Service для отслеживания местоположения курьера.

Audit Logging

• Курьер (Courier) выполняет действие — например, принимает или завершает заказ.
• Каждое действие генерирует событие, которое записывается в журнал аудита (AuditLog).
• Журнал аудита фиксирует идентификатор курьера, тип действия, время и исполнителя.

3. Паттерны уровня инфраструктуры

• Service Discovery,
• Service Mesh,
• Service Registry.

Service Discovery

• Каждый микросервис регистрируется в сервисе обнаружения — Discovery Server.
• Когда Courier Service нужно взаимодействовать с Order Service, он запрашивает информацию у Discovery Server и находит его.
• Когда Order Service нужно взаимодействовать с Location Service, он запрашивает информацию у Discovery Server и точно так же находит его.

Service Mesh

• Микросервисы Courier Service, Order Service и Location Service взаимодействуют через Envoy Proxy. Он является частью Service Mesh.
• Каждый запрос от микросервисов сначала проходит через Envoy Proxy.
• Envoy Proxy управляет маршрутизацией, безопасностью и наблюдаемостью всех микросервисов.
• Когда Courier Service хочет взаимодействовать с Order Service, запрос направляется через Envoy Proxy, который управляет маршрутом и политиками безопасности. Order Service тоже взаимодействует с Location Service через Envoy Proxy.

Service Registry

• Каждый микросервис регистрируется в реестре сервисов — Registry Server.
• Когда любому из микросервисов нужно взаимодействовать с другим микросервисом, он запрашивает информацию у Registry Server.

Общий свод ключевых паттернов проектирования микросервисов

Документирование применения паттернов

Зачем документировать архитектурные решения

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

Методики и инструменты для документирования

• Markdown — простая и удобная разметка для создания текстовой документации.
• PlantUML — инструмент для создания диаграмм, который можно интегрировать с Markdown и другими форматами документации.
• MkDocs — статический генератор сайтов, который позволяет создавать красивую и структурированную документацию из файлов Markdown.
• Confluence или аналогичные инструменты — платформы для совместного создания и хранения документации.

Пример документации паттернов для проекта CourierTrack

• Courier Service использует Courier Database (PostgreSQL) для хранения информации о курьерах.
• Order Service использует Order Database (MongoDB) для управления заказами.
• Location Service использует Location Database (Redis) для отслеживания местоположения курьеров.

@startuml
package "Courier Service" {
  [Courier Database]
}

package "Order Service" {
  [Order Database]
}

package "Location Service" {
  [Location Database]
}

[Courier Service] --> [Courier Database]
[Order Service] --> [Order Database]
[Location Service] --> [Location Database]
@enduml 

@startuml
package "Team A" {
  [Courier Service]
}

package "Team B" {
  [Order Service]
}

package "Team C" {
  [Location Service]
}
@enduml 

@startuml
entity Courier {
  * id : UUID
  * name : String
  * status : String
}

entity Event {
  * id : UUID
  * type : String
  * timestamp : Date
  * data : JSON
}

entity Order {
  * id : UUID
  * courierId : UUID
  * status : String
  * deliveryTime : Date
}

Courier --> Event : generates
Event --> Order : affects
@enduml 

Итоги

• на уровне приложений — Database per Service, Service per Team и Event Sourcing,
• на уровне инфраструктуры приложений — Distributed Tracing и Audit Logging,
• на уровне инфраструктуры — Service Discovery, Service Mesh и Service Registry.