Как мы переносили интеграции с монолита на микросервис

В этой статье я делюсь нашим опытом выноса интеграций из монолита в микросервисную архитектуру: какие решения мы принимали, на что обращали внимание и где было сложнее всего. В моем случае монолитами были: CRM или ERP-системы.

Авторизация

В монолите авторизация была встроена в ядро. При выносе интеграции в отдельный сервис нужно было решить, как проверять, что запрос пришёл от доверенного источника. Мы выбрали протокол авторизации — OAuth 2.0, так как у нас уже был реализован единый сервис авторизации по типу Яндекс ID. Это позволило нам:

• не создавать новый механизм с нуля

• использовать существующую инфраструктуру

• быстро интегрировать авторизацию в новый микросервис

Проектирование интерфейса микросервиса

В монолите (CRM или ERP-система) настройки некоторых интеграций были расположены в разных разделах интерфейса. Это усложняло поддержку — чтобы изменить один параметр, пользователь должен был знать, где именно его искать. При переносе мы не могли просто скопировать этот хаос в новый интерфейс.

Нам нужно было:

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

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

Пример: В CRM-системе в нескольких разделах было упоминание названия внешнего сервиса, куда передавались данные: в названиях кнопок, статусов. Пришлось корректировать интерфейс монолита, не задев другие функции.

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

Пример: В CRM-системе имя отправителя для СМС можно было задать в различных разделах сервиса. Мы убрали эту возможность из всех разделов и вынесли ее в интерфейс микросервиса.

Проектирование базы данных микросервиса

Мы выявили в монолите все таблицы и поля, относящиеся к интеграции, и использовали их как основу для проектирования БД микросервиса. Логика связей между данными была сохранена.

Структура базы данных микросервиса:

• данные авторизации (ID, токены)

• данные интеграции (ID, настройки интеграции)

• данные, участвующие в обмене с внешним сервисом (например, данные товаров, выгружаемые из ERP в интернет-магазин)

Перенос и оптимизация текущих алгоритмов

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

Пример: В одной из интеграций раньше в рамках одной конкретной выгрузки разнородные данные отправлялись в разных итерациях. Для упрощения алгоритма мы объединили выгрузку в одну итерацию. Это помогло нам избежать потерю запросов и часть данных.

Доработка API монолита

В монолите часть данных ранее запрашивалась через прямые SQL-запросы. Мы не могли использовать тот же подход для микросервиса, так как это нарушало архитектуру. Поэтому мы доработали API монолита. Микросервис запрашивает и передает данные через API, а не через SQL. Это снизило связанность между сервисами и сделало систему более управляемой.

Развертывание микросервиса

Что мы сделали:

• настроили окружение для нового сервиса

• провели регрессионное тестирование на тестовых и прод контурах

• поэтапно переключили трафик с монолита на микросервис

Мы использовали подход с параллельной работой двух систем на время перехода, чтобы минимизировать риски.

Миграция

В монолите хранились данные интеграций. Нужно было перенести их в базу микросервиса, сохранив их целостность.

В зависимости от особенностей интеграций мы применяли два подхода.

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

Заключение

Если вы планируете переход интеграции с монолита на микросервисную архитектуру — не пытайтесь сделать всё идеально с первого раза. Начните с одного простого микросервиса, отработайте процесс, а затем масштабируйте.