⚙️ 8 Шаблонов Проектирования Микросервисов ⚙️

1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.
Подробнее

2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.

3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.

4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.

5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.

6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.

7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.

8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.


⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.


Сохраните себе шпаргалку и используйте при проектировании архитектуры микросервисов, анализе своих проектов и подготовке к собеседованиям 🙌


Исходник: png | svg (анимация)

#АрхитектураGA

🔋 Схема микросервисной архитектуры - разбор проекта #GreenChargeGA 🔋

Вы уже знаете:
✔️ что такое микросервисы
✔️ как выделяют микросервисы
✔️ API Gateway
✔️ шаблоны проектирования микросервисов

Применим знания на практике и выделим микросервисы для системы зарядок электромобилей👇


⚙️ Управление пользователями
Регистрация аккаунтов владельцей электро-авто, подтверждение учетных записей по SMS, редактирование профилей.
Принцип:
+ независимая сущность
+ высокая нагрузка
+ DDD


⚙️ Программа лояльности
Бонусные карты пользователей, расчет кэшбека за оплату и начисление бонусов, для использования в счет оплаты будущих зарядок.
Принцип:
+ группа логически связанных функций
+ высокая нагрузка из-за связанных оплат
+ DDD


⚙️ Зарядные станции
Регистрация зарядных станций, настройка данных о них, получение информации о состоянии станции, отображение на карте, обновление цен на зарядку.
Принцип:
как пользователи.


⚙️ Управление ценами
Гибкая настройка цен для разных локаций, времён суток, динамическое ценообразование.
Принцип:
как пользователи.


⚙️ Контроль зарядки
Старт и остановка зарядки, расчёт времени и объёма потребления энергии, расчёт суммы к оплате.


⚙️ Платежи
Оплата зарядки - интеграция с платёжной системой для обработки банковских платежей картой, возвраты, генерация чеков. Авторизация карты на старте и автосписание средств по окончании зарядки.


⚙️ Очереди на зарядку
Бронирование места в очереди на станцию, управление ожиданием, снятие с очереди при неявке.


⚙️ Уведомления
Push-уведомления, email, SMS-уведомления.


⚙️ Тех. поддержка
Обработка чатов, передача обращений операторам, отображение в панели.


⚙️ Аналитика и отчеты
Отчёты о выручке, аналитика по станциям, загрузке, популярности, эффективности.


⚙️ Телеметрия
Сбор телеметрических данных с оборудования (энергия, температура и т.п.)


⚙️ API Gateway
Аутентификация запросов, кэш, и маршрутизация к соответствующим микросервисам.


+ API выберем,
+ с брокерами разберёмся 🤝


Схема прикреплена к посту ✅
Исследуем!

#АрхитектураGA

🔹 C4/Context - пример архитектуры для проекта #GreenChargeGA 🔹

Уровень Context в нотации C4 нужен, чтобы дать высокоуровневое представление о системе и ее окружении.

Он помогает понять что делает система, какие пользователи с ней взаимодействует, какие другие системы с ней связаны - интеграции.

Схема легко читается как бизнес-владельцами продукта, так и разработчиками.

👉 Что нужно показывать?

🔹 Основную систему – объект проектирования (например, интернет-магазин, банковское приложение).

🔹 Пользователей – кто взаимодействует с системой (клиенты, администраторы, партнеры).

🔹 Внешние системы – с чем интегрируется (платежные сервисы, справочники, ЭДО и другие).

🔹 Типы взаимодействий – основные потоки данных (например, клиент отправляет заказ в систему, система взаимодействует с банком).


👉 Что важно знать?

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

Мы не детализируем внутреннюю реализацию, а показываем глобальные границы и связи.

Это первый шаг проектирования архитектуры – помогает всем участникам проекта построить общее понимание системы.


👉 Пример для системы зарядки электромобилей - проект #GreenChargeGA

✔️ Основная система:
GreenChargeGA

✔️ Пользователи:
пользователи, которым нужно заряжать авто
сотрудники тех поддержки,
администраторы

✔️ Внешние системы:
ТБанк Интернет-эквайринг,
ТБанк Торговый эквайринг,
POS-Терминал для приема карт,
сканер QR-кодов,
датчики зарядной станции (энергия, температура и тп)
firebase (push)
unisender (sms/email)


Ни API, ни микросервисов, ни брокеров. Всё на верхнем уровне, чтобы осознать интеграции системы и пользователей. Ни более.
Сравните это со схемой проекта без нотации и увидите огромную разницу в количестве элементов!


Схема архитектуры в C4/Context прикреплена к посту 🙌


#АрхитектураGA