Как выделить сервис из монолита и не перестроить всю систему
Крупная корпоративная система может нормально работать годами, но постепенно терять способность быстро меняться. Однажды команда обнаруживает, что готовое и протестированное обновление нельзя выпустить из-за незавершенной работы в другой части системы.
Меня зовут Алексей Постригайло, я старший партнер ИТ-интегратора "Энсайн". Больше 20 лет занимаюсь системной интеграцией и управлением проектами. Разберу, как мы отделили нагруженный сервис от монолитного портала, какие компромиссы приняли и почему не стали создавать для него отдельную базу данных.
Один портал и 2 разных сценария работы
Портал Департамента труда и социальной защиты населения Москвы использовали 2 большие группы.
Горожане искали информацию о социальных услугах. Сотрудники более 300 подведомственных учреждений работали с внутренними функциями и отчетностью.
Одним из ключевых публичных сервисов был "Социальный навигатор". Он представлял собой интерактивную карту с адресами организаций и доступными услугами.
К 2021 году в навигаторе было более 935 адресов по 225 услугам. Число обращений превысило 1,3 млн.
Портал активно развивался. Обновления требовались в среднем раз в 3 дня. Дополнительно появлялись срочные задачи с жесткими сроками.
Почему готовое обновление нельзя было выпустить
В определенный момент потребовалось доработать навигатор к заранее назначенной презентации. Изменение было готово и протестировано вовремя.
Параллельно команда развивала большую систему отчетности для подведомственных учреждений. Обе работы велись внутри одного проекта и затрагивали общие данные.
Навигатор и отчетность использовали информацию об организациях, услугах, районах и других связанных объектах. Изменения в структуре данных для отчетности уже находились в общей среде разработки.
В результате готовое обновление навигатора оказалось связано с незавершенной отчетностью. Выпустить только одну часть было нельзя. Вместе с ней в рабочую систему могли попасть сырые изменения второй подсистемы.
Почему обычные способы не помогали
Теоретически отдельные изменения можно было вручную переносить между ветками разработки. На практике это создавало дополнительные риски.
Компоненты использовали общие файлы и структуры данных. При выборочном переносе появлялись конфликты, нарушалась верстка, возникали ошибки, которые было сложно воспроизвести заранее.
Функциональные переключатели также не решали проблему. Изменения затрагивали структуру базы данных, поэтому их нельзя было безопасно скрыть обычным отключением функции.
Ситуацию усложнял порядок выпуска отчетности. С ней работали сотни организаций. Перед обновлением пользователей нужно было предупредить, попросить сохранить данные и выйти из системы. Работы часто переносились на вечер.
Срочные изменения навигатора были вынуждены ждать общего окна.
Решение: отделить сервис от общей скорости разработки
Мы предложили выделить "Социальный навигатор" в самостоятельный сервис на поддомене nav.dszn.ru.
Полностью переписывать портал не требовалось. Задача состояла в том, чтобы отделить уже работающий функционал и дать ему собственный цикл выпуска обновлений.
У решения было 3 причины.
Навигатор должен был развиваться быстрее внутренней отчетности. Его нагрузка росла вместе с количеством пользователей. Кроме того, интерактивная карта создавала дополнительную нагрузку на основной портал.
Выделение сервиса заняло около 3 месяцев.
Почему мы сохранили общую базу данных
Самостоятельный сервис не обязательно должен иметь собственную базу.
Навигатору требовалась только текущая информация. Он не создавал сложные пользовательские состояния и не должен был самостоятельно хранить полную историю изменений.
Поэтому основная база осталась внутри портала. Навигатор получал подготовленные данные через программный интерфейс в формате JSON.
Обновление можно было запустить вручную из панели управления либо выполнять по расписанию.
Такой подход позволил не создавать дополнительную инфраструктуру для хранения данных. Не понадобились отдельные резервные копии и репликация. Публичный сервис также не хранил локальную базу, что сокращало поверхность возможной атаки.
Это был сознательный компромисс. Навигатор оставался зависимым от источника данных, но его разработка и выпуск обновлений больше не зависели от других модулей портала.
Как изменился процесс обновления информации
Раньше значительная часть информации проходила через центральных администраторов.
После разделения системы появились личные кабинеты для более чем 300 подведомственных организаций. Каждое учреждение могло самостоятельно обновлять адреса, контакты и перечень услуг.
Изменения проходили модерацию. После подтверждения они попадали в навигатор.
В результате система состояла из 3 связанных приложений:
- Панель управления основного портала.
- Личные кабинеты учреждений.
- Публичный навигатор.
Двойной ввод данных исчез. Ответственность за первичное обновление информации перешла к тем, кто лучше всего знает ее текущее состояние.
Работа с большими файлами
Навигатор хранил только актуальную версию подготовленных данных.
При изменении структуры источника команда корректировала обработку JSON. Отдельные миграции внутри навигатора не требовались.
Файлы могли быть объемными, поэтому их обработку также пришлось оптимизировать. Для этого использовали легкий PHP-пакет с коллекциями и отложенными вычислениями.
Разработчики могли фильтровать, группировать и преобразовывать данные без большого количества ручных циклов. Это упростило код и уменьшило расход памяти.
Виджет для основного портала
После выделения сервиса появилась возможность сделать облегченную версию навигатора.
Интерактивную карту разместили внутри встраиваемого блока. Его можно было подключить к нужной странице без переноса всей логики обратно в основной портал.
Так навигатор продолжил работать на главной странице, хотя технически уже был самостоятельным сервисом.
Что изменилось после разделения
Главный результат - навигатор получил собственный цикл разработки.
Обновления больше не ждали готовности отчетности и других частей монолита. Команда отказалась от регулярных ручных переносов изменений между ветками. Риск повредить рабочую систему снизился.
Изменился и процесс управления информацией. Учреждения начали самостоятельно поддерживать свои данные, а центральные подразделения сохранили контроль через модерацию.
Основной портал перестал выполнять часть тяжелой работы, связанной с интерактивной картой.
Когда стоит применять такой подход
Сам по себе большой монолит еще не требует разделения.
Решение становится оправданным, когда одна часть системы:
- развивается в другом темпе;
- создает заметную нагрузку;
- регулярно блокируется соседними изменениями;
- имеет понятные границы и собственный пользовательский сценарий.
Полная перестройка в такой ситуации может оказаться слишком дорогой. Иногда достаточно отделить один сервис и сохранить общие данные там, где они уже управляются.
В этом проекте архитектурное изменение было ценно не количеством новых технологий. Оно устранило конкретную причину задержек и сделало развитие навигатора управляемым.
Здесь я обычно пишу про проекты, кейсы и ИТ-практику. А если хочется увидеть меня не только в рабочих текстах - приходите в мой тг https://t.me/alekseypostrigaylo. Там - сын, поездки, работа за кадром, личные наблюдения и попытка жить так, чтобы было что вспомнить.