Как спроектировать микросервисную систему, используя популярные паттерны: практический пример описания программной архитектуры типового интернет-магазина в диаграммах С4 на базе сервиса icepanel.io. Разбираемся с API Gateway, Database per Service, Shared database, CQRS и Saga.
Контекстная диаграмма проектируемой системы
Существует множество шаблонов (паттернов) построения микросервисной архитектуры, сгруппированных по точки зрения проектируемой системы. Например, декомпозиционные подходы для разделения монолита на микросервисы (по бизнес-задачам/возможностям, поддоменам, транзакциям и пр.), подходы к интеграции (шлюз API, агрегатор, цепочка микросервисов и т.д.), к хранению данных (Database per Service, Shared Database, CQRS, Event Sourcing, Saga) и к развертыванию (сине-зеленое, канареечное и т.п.). Каждая группа шаблонов сфокусирована на определенном вопросе, поэтому в рамках одной архитектуры может использоваться несколько паттернов, в т.ч. из одной категории. Как это работает, рассмотрим на моем традиционном демо-примере интернет-магазина из прошлой статьи.
Покупатель может просматривать товары и покупать их, делая заказы. Также покупателю доступны функции управления своими заказами (создать, изменить, отменить). За управление товарами и поставщиками отвечает Менеджер интернет-магазина, которому также доступен просмотр данных и аналитические операции по выполненным заказам. Оператор склада управляет упаковкой товаров в заказы. Стоимость доставки заказа к покупателю рассчитывается в зависимости от того, на каком складе найден товар, и как перевезти его в пункт сборки, используя внешние системы сторонних служб доставки. О каждом изменении статуса заказа (например, заказ принят, найден, подтвержден, собран, оплачен, отменен) система интернет-магазина уведомляет Покупателя и Менеджера, формируя уведомления и направляя их для фактической отправки во внешние системы отправки (TG, почтовый сервер и пр.). Оплата выполняется через обращение к внешней системе банковского шлюза.
Покажем контекстное окружение проектируемой системы на контекстной схеме С4, используя SaaS-продукт icepanel.io. Это веб-сервис, который предоставляет возможность построения архитектурных диаграмм в нотации C4, в т.ч. на бесплатном тарифе. Пользоваться сервисом довольно удобно. Например, мне понравилось, что можно сразу привязать технологию к проектируемой модели, выбран протокол связи, СУБД или фреймворк для разработки приложения. Также можно поделиться своей моделью с коллегами, расшарив публичную ссылку. Например, мой проект доступен по адресу https://s.icepanel.io/DaVgB9G4JAPZkP/uyiT.
Однако, у сервиса icepanel.io есть один, но очень существенный недостаток: он очень нагружает ЦП и GPU. Например, мой ноутбук с Windows 10 64 Pro на Intel 2.3 ГГц и 16 ГБ RAM начинает реветь, когда в любом браузере (Chrome, Firefox, IE) последней версии я работаю в этом приложении, даже просто просматривая созданную модель.
Дорогие читатели, пожалуйста, напишите мне в ТГ, были ли у вас подобная проблема с icepanel.io, поскольку по функциональным возможностям сервис замечательный, и хочется им пользоваться без разочарований.
Возвращаясь к рассматриваемому примеру, построим схему системного ландшафта или контекстную диаграмму (Context Level), где проектируемая система I-shop представлена в виде одного крупного блока, показывающего ее взаимодействие с внешними системами и пользователями. Внутреннее устройство системы с архитектурной точки зрения представляется на следующих уровнях (контейнеров и компонентов), что будет рассмотрено далее.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 мая, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
C4-диаграмма контейнеров
Следующий уровень C4 — уровень контейнеров (Container Level) показывает разделение системы на контейнеры: веб-серверы, приложения и базы данных. Обычно проектирование на этом уровне начинается с классической слоистой трехзвенной архитектуры клиент-сервер, где пользователи взаимодействуют с клиентским приложением (Frontend), за обработку бизнес-логики отвечает серверное приложение (Backend), а за хранение данных – базы и файловые хранилища. Однако, в случае микросервисной архитектуры хранилище данных может быть не одно, а несколько, т.к. Backend состоит из нескольких компонентов – микросервисов, каждый из которых может иметь свою собственную базу данных.
Выполним начальный этап проектирования, сделав аллокацию требований по элементам системы: разделим микросервисы по бизнес-задачам, покажем, какие СУБД каждый из них будет использовать.
| Задача | Сервис | Хранилище данных |
| Проверка прав на выполнение операций (запросов и команд) | Сервис Аутентификации и Авторизации | PostgreSQL |
| Посмотреть данные о заказах, товарах и поставщиках товары | Сервис Витрина | PostgreSQL и Redis как кэш для нее |
| Анализировать выполненные заказы | Сервис Заказов | MongoDB |
| Управлять активными заказами | Сервис Заказов | PostgreSQL |
| Управлять поставщиками | Сервис Склад | PostgreSQL |
| Управлять товарами | Сервис Склад | PostgreSQL |
| Управлять упаковкой товаров в заказ | Сервис Склад | PostgreSQL |
| Определить время и стоимость доставки | Сервис Доставка | Neo4j |
| Оплатить заказ | Сервис Оплаты | PostgreSQL |
| Отправить уведомление об изменении статуса заказа | Сервис Уведомлений | Apache Kafka |
Разумеется, выбор технологий должен основываться на подробном техническом задании, где полностью и точно специфицированы все функциональные и нефункциональные требования. Однако, в целях экономии времени этот вопрос остается за рамками текущей статьи. Например, PostgreSQL будет использоваться в качестве основного реляционного хранилища для хранения данных об активных заказах, товарах, поставщиках и пользователях (Покупатель, Менеджер). Обращаться к этой БД будет сервис Заказов, сервис Склад и Сервис Оплаты. Этот вариант использования соответствует паттерну Shared Database, когда одна и та же база данных используется несколькими микросервисами. Хотя такой способ интеграции приложений считается антипаттерном, он позволяет избежать распределенных транзакций, а также точно гарантирует соблюдений ACID-требований к транзакциям (атомарность, согласованность, изоляция и надежность). Для обеспечения безопасности, т.е. предотвращения ситуации, когда один сервис имеет доступ к данным другого сервиса, можно разграничить права доступа сервисов к данным через ролевые авторизации на таблицы или использовать материализованные представления.
Чтобы разгрузить основную базу, ночной ETL-процесс будет забирать из нее данные об уже выполненных заказах, преобразовывать их в JSON подобно тому, как я описывала здесь, и сохранять в документо-ориентированной базе MongoDB. Эти данные будет использовать Менеджер магазина для построения сводных аналитических отчетов. Также для разгрузки основной базы данных недавно просмотренные страницы каталога товаров будут кэшироваться в key-value хранилище Redis, которое работает очень быстро за счет примитивной модели представления данных и их использования оперативной памяти. Примеры работы с Redis я описывала здесь и здесь. Что касается Сервиса Уведомлений, данные для информирования пользователей он будет считывать прямо из Apache Kafka – распределенной платформы потоковой передачи событий, которая в данном кейсе будет выступать средством коммуникации микросервисов в рамках EDA-подхода (Event Driven Architecture). Об этом я рассказывала в прошлой статье.
Для определения времени и стоимости внутренних и внешних логистических операций Сервис Доставка будет строить графы и находить в них пути, используя графовую СУБД Neo4j. Таким образом, помимо паттерна Shared Database в проектируемой системе также используется шаблон Database per Service, где каждый микросервис имеет собственную базу данных. Все обозначенные хранилища данных будут являться контейнерами на схеме контейнеров в нотации C4, которая представляет собой декомпозицию ранее представленной контекстной диаграммы.
Также на схеме контейнеров видно, что клиентское приложение (Frontend) отправляет к серверному (Backend) запросы и команды. Это соответствует шаблону разделения ответственности запросов и команд (CQRS, Command Query Responsibility Segregation), где командами называются изменения (мутации) данных, т.е. операции их создания, изменения и удаления, а запросы означают выполнение операций чтения, что не изменяет данные. Поскольку у каждой системы есть преобладающие варианты использования, связанные именно с чтением данных или мутациями, например, OLAP или OLTP, шаблон CQRS позволяет обеспечить нужную производительность всей системы за счет физического разделения хранилищ данных. Запросы считывают данные из хранилища, оптимизированного для аналитических операций. Такое OLAP-хранилище реплицирует часть данных из основной OLTP-базы, где выполняются команды. Поскольку рабочие нагрузки чтения и записи обычно имеют разные требования к масштабированию, задержке и согласованности, CQRS хорошо дополняет ранее рассмотренный паттерн Database per Service.
В моем примере CQRS реализуется с использованием документо-ориентированной базы данных MongoDB, которая предназначена только для чтения в рамках анализа данных по уже выполненным заказам. Также можно реализовать CQRS для улучшения масштабируемости и производительности основного хранилища PostgreSQL, выделив мастер-БД, которая будет принимать команды и ее реплики, доступные только для чтения. Это также улучшает безопасность всей проектируемой системы.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 мая, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Структура микросервисной системы: диаграмма компонентов и паттерны микросервисной архитектуры
Наконец, переходим к самому интересному, т.е. самой структуре микросервисной системы, которая на предыдущем уровне контейнеров была показана в виде одного черного ящика Backend. Уровень компонентов (Component Level) отображает внутреннее устройство выбранного контейнера (в нашем случае это Backend), разделенное на компоненты. Компоненты представляют собой самостоятельные части системы, которые выполняют определенные функции, т.е микросервисы и то, что необходимо для их взаимодействия.
Помимо Apache Kafka, которая выполняет роль средства асинхронной интеграции микросервисов в событийно-ориентированной архитектуре, о чем я писала в прошлой статье, также на схеме компонентов появляется шлюз API (API Gateway). Это еще один паттерн микросервисной архитектуры, который фокусируется на вопросах интеграции. В моем примере шлюз API нужен для маршрутизации команд и запросов к соответствующему сервису. Например, выполнение команд на мутации данных требует аутентификации и проверки наличия прав на выполнение этой операции, за что отвечает Сервис Аутентификации и Авторизации. Аналогично, реализуя CQRS-подход, шлюз API может отправить запросы с клиентского приложения на чтение данных в сервис Витрина, а команды на мутации заказов – в Сервис Заказы. В качестве шлюза API можно использовать Nginx — мультиплатформенный веб-сервер и прокси-сервер, прописав маршруты в его конфигурациях, чтобы отправлять конкретный HTTP-запрос с клиентского приложения (Frontend) на соответствующую конечную точку нужного сервиса.
Наконец, Kafka реализует шаблон саги (Saga), который помогает обеспечить согласованность в распределенных приложениях и координирует транзакции между несколькими микросервисами. Несмотря на использование общей базы данных в рассматриваемом примере, согласно схеме бизнес-процесса результат поиска пути определяет изменение статуса заказа. Поэтому транзакция обработки заказа выполняется в нескольких базах данных и является распределенной. Это частая ситуация при применение паттерна Database per Service: микросервис публикует событие для каждой транзакции, и следующая транзакция инициируется по результатам этих событий.
Сага представляет собой последовательность локальных транзакций, каждая из которых обновляет отдельную базу данных и публикует сообщение или событие, запускающее следующую локальную транзакцию. Если локальная транзакция завершается неудачей из-за нарушения бизнес-правила, сага выполняет серию компенсирующих транзакций, которые отменяют изменения, внесенные предыдущими локальными транзакциями. Для реализации Saga используется хореографический или оркестрационный стиль коммуникации между сервисами, о чем я писала в прошлой статье. При хореографии каждая локальная транзакция публикует события домена, которые запускают локальные транзакции в других сервисах. В случае оркестрации оркестратор сообщает участникам, какие локальные транзакции следует выполнять. Оба варианта в архитектуре, управляемой событиями, можно реализовать с использованием Apache Kafka. Основной сложностью при этом будет проектирование потокового конвейера, определение топиков, их разделов и структуры данных полезной нагрузки. Можно сделать это в виде спецификации AsyncAPI, что покажу в следующий раз. Какие требования при этом надо специфицировать, читайте здесь.
Таким образом, в рамках одной системы можно использовать несколько архитектурных шаблонов, стилей и технологий. Выбор шаблона и технологии определяется требованиями к системе, рисками применения паттерна, его сильными и слабыми сторонами, уникальными для каждого конкретного случая. А выполнить такую работу по проектированию архитектуры ИС помогает довольно простая нотация C4 и довольно удобный (но не единственный) SaaS-продукт icepanel.io. Хотя можно использовать и любой другой инструмент графического проектирования.
В заключение отмечу, что проектирование архитектуры не ограничивается рассмотренными 3-мя диаграммами С4. Например, для улучшения масштабируемости и производительности системы часто используются балансировщики нагрузки к сервисам и базам данных, а также шардирование хранилищ, что показывается на схеме развертывания.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 мая, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Узнайте больше про архитектуру и интеграцию информационных систем на моих курсах в Школе прикладного бизнес-анализа на базе лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
