В этой статье я делюсь нашим опытом выноса интеграций из монолита в микросервисную архитектуру: какие решения мы принимали, на что обращали внимание и где было сложнее всего. В моем случае монолитами были: CRM или ERP-системы.
Авторизация
В монолите авторизация была встроена в ядро. При выносе интеграции в отдельный сервис нужно было решить, как проверять, что запрос пришёл от доверенного источника. Мы выбрали протокол авторизации - OAuth 2.0, так как у нас уже был реализован единый сервис авторизации по типу Яндекс ID. Это позволило нам:
не создавать новый механизм с нуля
использовать существующую инфраструктуру
быстро интегрировать авторизацию в новый микросервис
Проектирование интерфейса микросервиса
В монолите (CRM или ERP-система) настройки некоторых интеграций были расположены в разных разделах интерфейса. Это усложняло поддержку - чтобы изменить один параметр, пользователь должен был знать, где именно его искать. При переносе мы не могли просто скопировать этот хаос в новый интерфейс.
Нам нужно было:
Собрать всё воедино. Мы проанализировали, где именно в монолите хранятся настройки переносимой интеграции, и собрали их в единый список. Это помогло увидеть полную картину: какие параметры есть, какие из них обязательные, а какие - опциональные. На этом же этапе мы сопоставляли поля интерфейса с полями в базе данных: для каждого параметра определяли, в какую таблицу и в какой столбец он записывается.
При переносе некоторых интеграций на этом этапе выявлялось, что какие-то параметры не хранятся ни в базе данных, ни в кеше. В зависимости от особенностей интеграции принималось решение: сохранять эти данные в БД микросервиса или нет.
Скорректировать интерфейс монолита. Мы собрали все настройки, связанные с интеграцией, из разных разделов монолита и разместили их в интерфейсе микросервиса, переосмыслив логику их группировки.
Пример: В CRM-системе в нескольких разделах было упоминание названия внешнего сервиса, куда передавались данные: в названиях кнопок, статусов. Пришлось корректировать интерфейс монолита, не задев другие функции.
Спроектировать интерфейс микросервиса с нуля. Мы собрали все настройки, связанные с интеграцией, из разных разделов монолита и разместили их в интерфейсе микросервиса, переосмыслив логику их группировки.
Пример: В CRM-системе имя отправителя для СМС можно было задать в различных разделах сервиса. Мы убрали эту возможность из всех разделов и вынесли ее в интерфейс микросервиса.
Проектирование базы данных микросервиса
Мы выявили в монолите все таблицы и поля, относящиеся к интеграции, и использовали их как основу для проектирования БД микросервиса. Логика связей между данными была сохранена.
Структура базы данных микросервиса:
данные авторизации (ID, токены)
данные интеграции (ID, настройки интеграции)
данные, участвующие в обмене с внешним сервисом (например, данные товаров, выгружаемые из ERP в интернет-магазин)
Перенос и оптимизация текущих алгоритмов
Код интеграции в монолите работал, но был написан давно и не всегда оптимально. Мы могли просто скопировать его в микросервис, но это было бы ошибкой. Вместо копирования мы пересмотрели алгоритмы и оптимизировали их под новую архитектуру.
Пример: В одной из интеграций раньше в рамках одной конкретной выгрузки разнородные данные отправлялись в разных итерациях. Для упрощения алгоритма мы объединили выгрузку в одну итерацию. Это помогло нам избежать потерю запросов и часть данных.
Доработка API монолита
В монолите часть данных ранее запрашивалась через прямые SQL-запросы. Мы не могли использовать тот же подход для микросервиса, так как это нарушало архитектуру. Поэтому мы доработали API монолита. Микросервис запрашивает и передает данные через API, а не через SQL. Это снизило связанность между сервисами и сделало систему более управляемой.
Развертывание микросервиса
Что мы сделали:
настроили окружение для нового сервиса
провели регрессионное тестирование на тестовых и прод контурах
поэтапно переключили трафик с монолита на микросервис
Мы использовали подход с параллельной работой двух систем на время перехода, чтобы минимизировать риски.
Миграция
В монолите хранились данные интеграций. Нужно было перенести их в базу микросервиса, сохранив их целостность.
В зависимости от особенностей интеграций мы применяли два подхода.
Интеграция | Подход к миграции |
Интеграция А | Миграция данных из базы монолита в базу микросервиса |
Интеграция Б | Пользователи настраивали интеграцию заново в новом интерфейсе - миграция не потребовалась |
После успешного релиза и миграции данных в базе данных монолита необходимо удалить таблицы и поля для хранения данных интеграции, так как теперь все данные хранятся в базе микросервиса.
Заключение
Если вы планируете переход интеграции с монолита на микросервисную архитектуру - не пытайтесь сделать всё идеально с первого раза. Начните с одного простого микросервиса, отработайте процесс, а затем масштабируйте.