🛠 5 способов определения микросервисов 🛠
Микросервисы (МС) — это способ разбить большую систему на независимые, слабо связанные компоненты, каждый из которых отвечает за свою конкретную функцию и масштабируется отдельно.
Другими словами — это небольшие сервер-приложения с их собственными БД.
Ниже — примеры применения 5 ключевых подходов к декомпозиции сложной системы на микросервисы на примере проекта #GreenChargeGA по зарядке электромобилей.
-----------
1️⃣ По группам функций
Каждый МС объединяет логически связанные функции.
➕ Пользователи: регистрация, управление профилями пользователей
➕ Станции: управление зарядными станциями, их активностью, геолокацией для отражения на карте
➕ Бронирования: бронирование очереди на зарядку
➕ Биллинг: расчёт стоимости заправки, интеграция с платёжным провайдером, формирование чеков
➕ Уведомления: push/sms/email-уведомления о завершении заправки, подтверждении регистрации, коды для аутентификации
➕ Тех. поддержка: работа чат-ботов, обработка обращений пользователей
-----------
2️⃣ По доменам (DDD - Domain Driven Design)
Выделяем bounded contexts (ограниченные контексты) по предметным областям.
➕ Домен “Станции”
Управление статусом зарядки. Геолокация станций. Актуальные цены на зарядку.
➕ Домен “Пользователи”
Профили, регистрация, история сеансов.
➕ Домен “Платежи”
Интеграция с платежным провайдером, проведение платежей и формирование платежных документов, возвраты, отчеты о продажах.
-----------
3️⃣ По данным
Каждый МС управляет узким набором сущностей.
➕ Пользовательские сессии: аккаунты, авторизации, история входов
➕ Станции зарядки: локации, конфигурации, цены
➕ Сеансы зарядки: продолжительность, израсходованная энергия
➕ Платежи: чек, статус транзакции
➕ Обращения пользователей: запросы, ответы, статусы
-----------
4️⃣ По пользовательским сценариям
МС обслуживает конкретный Use Case.
➕ Поиск зарядной станции и бронирование места в очереди.
➕ Процесс зарядки: старт и авторизация банковской карты, обработка данных об израсходованной энергии и расчет итоговой стоимости, списание итоговой суммы за зарядку.
➕ Возврат средств.
-----------
5️⃣ По уровню нагрузки
Высоконагруженные и обычные части системы выделяются в отдельные сервисы со своими SLA и требованиями к масштабируемости.
➕ Поиск станции (много запросов по геолокации, особенно в «пиковые» часы).
➕ Сбор телеметрии (станция шлёт данные каждую 5 секунду, высокая частота).
➕ Обработка платежей (всплески нагрузки в моменты массовых зарядок).
-----------
Как видно из примеров, разные подходы могут приводить к одним и тем же микросервисам. На практике их часто используют совместно.
👉 Сочетайте методы декомпозиции и подробно фиксируйте принципы выбора микросервисов в рамках проекта — это поможет избежать неясностей и обеспечит гибкость при развитии проекта.
#АрхитектураGA
Микросервисы (МС) — это способ разбить большую систему на независимые, слабо связанные компоненты, каждый из которых отвечает за свою конкретную функцию и масштабируется отдельно.
Другими словами — это небольшие сервер-приложения с их собственными БД.
Ниже — примеры применения 5 ключевых подходов к декомпозиции сложной системы на микросервисы на примере проекта #GreenChargeGA по зарядке электромобилей.
-----------
1️⃣ По группам функций
Каждый МС объединяет логически связанные функции.
➕ Пользователи: регистрация, управление профилями пользователей
➕ Станции: управление зарядными станциями, их активностью, геолокацией для отражения на карте
➕ Бронирования: бронирование очереди на зарядку
➕ Биллинг: расчёт стоимости заправки, интеграция с платёжным провайдером, формирование чеков
➕ Уведомления: push/sms/email-уведомления о завершении заправки, подтверждении регистрации, коды для аутентификации
➕ Тех. поддержка: работа чат-ботов, обработка обращений пользователей
-----------
2️⃣ По доменам (DDD - Domain Driven Design)
Выделяем bounded contexts (ограниченные контексты) по предметным областям.
➕ Домен “Станции”
Управление статусом зарядки. Геолокация станций. Актуальные цены на зарядку.
➕ Домен “Пользователи”
Профили, регистрация, история сеансов.
➕ Домен “Платежи”
Интеграция с платежным провайдером, проведение платежей и формирование платежных документов, возвраты, отчеты о продажах.
-----------
3️⃣ По данным
Каждый МС управляет узким набором сущностей.
➕ Пользовательские сессии: аккаунты, авторизации, история входов
➕ Станции зарядки: локации, конфигурации, цены
➕ Сеансы зарядки: продолжительность, израсходованная энергия
➕ Платежи: чек, статус транзакции
➕ Обращения пользователей: запросы, ответы, статусы
-----------
4️⃣ По пользовательским сценариям
МС обслуживает конкретный Use Case.
➕ Поиск зарядной станции и бронирование места в очереди.
➕ Процесс зарядки: старт и авторизация банковской карты, обработка данных об израсходованной энергии и расчет итоговой стоимости, списание итоговой суммы за зарядку.
➕ Возврат средств.
-----------
5️⃣ По уровню нагрузки
Высоконагруженные и обычные части системы выделяются в отдельные сервисы со своими SLA и требованиями к масштабируемости.
➕ Поиск станции (много запросов по геолокации, особенно в «пиковые» часы).
➕ Сбор телеметрии (станция шлёт данные каждую 5 секунду, высокая частота).
➕ Обработка платежей (всплески нагрузки в моменты массовых зарядок).
-----------
Как видно из примеров, разные подходы могут приводить к одним и тем же микросервисам. На практике их часто используют совместно.
👉 Сочетайте методы декомпозиции и подробно фиксируйте принципы выбора микросервисов в рамках проекта — это поможет избежать неясностей и обеспечит гибкость при развитии проекта.
#АрхитектураGA