Интеграция микросервисов. Обмен данных между ними, обеспечение целостности данных

1.

Интеграция микросервисов.
Обмен данных между ними,
обеспечение целостности данных.
ГРУППА РАЗРАБОТКИ «ЦЕЛЕВОГО БИЛЛИНГА» PYTHON
(Ирина Волкова, Арсений Леонтьев, Дмитрий Кошелев)

2.

Описание проблемы
Проблема:
связь между микросервисами не стабильна;
отсутствует возможность реструктуризации программного кода (по техническим, либо
экономическим причинам);
время от времени необходимо менять состояние интеграции - добавлять в нее новые
микросервисы или исключать уже существующие, делать закрытыми или доступными
различные типы данных.
Необходимо спроектировать решение, которое позволит на основе микросервисной
архитектуры, использовании шаблона CQRS и Kafka обеспечить настраиваемое (гибкое)
взаимодействие между микросервисами, имеющими одинаковую предметную область, не
подвергая их значительной модернизации, и с невысокими трудозатратами.

3.

Требования к решению
1. Не добавлять жестких связей между микросервисами;
2. Предусмотреть поддержку разных баз данных;
3. Предусмотреть фильтрацию референсов;
4. Избежать большого дублирования данных;
5. Добиться консистентности данных;
6. Простое, но гибкое (настраиваемое) решение в зависимости от изменений workflow.

4.

Модель сетевого взаимодействия (Prod)
Сегмент приложений
UI - клиентский
сервис ввода и
вывода информации
Внешняя сеть
Сегмент шины данных
Zookeeper
Kafka кластер
(интернет)
Keycloak
Workflow / ProcessEngines сервис
Любой внутренний
сервис биллинга
Сегмент данных
БД для
чтения (WF)
БД для
записи
DWH сервис
БД для
чтения (DWH)

5.

Модель компонентов и их взаимодействия
Process-Engines сервис
API
Repo’s
БД (WF)
Kafka Adapter
Zookeeper
Kafka Broker
Primary service Topic
Partition 1
Producers
1
Services
Consumers
Kafka Adapter
API
Consumers
Repo’s
3
Next service Topic
Partition 1
1
DTO
2
Изменяемый сервис биллинга
2
Services
3
Producers
Retry 1 service Topic
DTO
Partition 1
Зависимый сервис биллинга
БД
(dependent)
API
Kafka Adapter
Repo’s
Main
Consumer
Services
Retry
Consumer 1
DTO
Retry
Consumer n
1
2
3
Retry n service Topic
Partition 1
1
2
3
БД
DLQ
(mutable)
Partition 1
1
2
3
Answers Topic
Partition 1
1
2
3

6.

Описание решения Kafka
Retry topic (топик повтора).
1. Консюмер делает попытку потребить сообщение из топика.
2. Если попытка завершилась неудачей, продюсер внутри консьюмера публикует сообщение
в топик повтора и только после публикации консьюмер фиксирует смещение сообщения, чтобы
получить возможность продолжить работу с остальным потоком сообщений.
3. На топик повтора подписан консюмер повтора, у которого та же самая логика, что и у
предыдущего консюмера. Этот консюмер вводит короткую отсрочку между попытками
потребить сообщение. И если этот консюмер также не может удачно потребить сообщение, он
публикует сообщение в следующий топик повтора и только после публикации фиксирует
смещение сообщения.
4. Каждый следующий консьюмер повтора должен увеличивать отсрочку между попытками
потребить сообщение, что будет служить стратегией отката (backoff strategy). Когда сообщение
не удается обработать последнему консюмеру повтора, оно отправляется в очередь мертвых
сообщений (dead letter queue, DLQ), где его вручную сортирует тех. поддержка ПО.

7.

Описание решения Kafka
Разделение сообщений на исправимые и неисправимые ошибки.
Определение их критичности для системы.
1. Исправимая ошибка (recoverable errors) - ошибки, которые в итоге будут исправлены. Например:
если база данных будет временно недоступна, консюмер даст сбой, когда придет следующее
сообщение. Как только база данных снова станет доступна, тогда консюмер снова сможет
обрабатывать сообщение.
2. Неисправимые ошибки (non-recoverable errors) - ошибки, которые все равно будут случаться,
независимо от того, сколько раз мы попробуем повторно выполнить операцию. Например:
сообщение не поддающееся синтаксическому анализу (ошибки валидации данных).
Очередь повторов полезна только в случае исправимых ошибок. В случае неисправимых
ошибок – сообщение сразу необходимо отправлять в мертвую очередь и сообщать сервису
Workflow о неудачном запросе, отправив для этого сообщение в очередь ответов.
При этом сервис Workflow должен определить критичность ошибки. При некритичной ошибке
(например информация не была обновлена для сервиса отчетов) – сервис Workflow генерирует
через почтовый сервис заявку на ГЛ для исправления ситуации. При критичной ошибке (например
зависимый сервис не обновил данные активации сим-карты) – сервис Workflow начинает операцию
отката данных по заданному сценарию. Инициализация записи для отката происходит из ключа
партиции (partition key). Фиксировать работу продюсеров/консюмеров в каждом микросервисе –
необходимо в его БД.

8.

Описание решения CQRS
Применение шаблона CQRS в MSA поможет решить следующие проблемы:
1. Разделение слоев кода (+ к архитектуре). Т.е., благодаря этому разделению пользовательский
интерфейс и сервис отчетов практически не влияют на архитектуру предметной области,
сокращая время проектирования приложения за счет использования возможностей DDD.
2. Решение проблем сортировки и фильтрации референсов.
3. Данные для чтения будут хранятся в удобном виде для клиента (денормализованные данные,
индекс для полнотекстового поиска и т.д.).
4. Гибкая масштабируемостью, серверные ресурсы разделены под чтение и под запись.
5. Улучшенная безопасность данных (сервер для чтения не меняет состояние БД).
6. Низкие требования к ресурсам клиентской части, т.к. у клиента остаются только функции
отображения данных.