Имеется большая часть кодовой базы, в которой есть логика, которую требуется вынести...
Часть один
Выделяем в голове, какие части хотели бы вынести в микросервис(Dream Service). Важность рисования контура с чистого листа.
Затем уже смотрим в кодовую базу и находим эти части. Пока видим, что они раздроблены по разным местам в коде.
Dream Service видоизменяется, немного приземляется. Здесь важно, что меняется форма. Dream Service не кастрируется, он обтачивается об реальность, но ядро Dream Service остается, на этом этапе возможно лучше понимается, а что же в Dream Service является ядром.
Выделяем микрочасти и контуры на концах. Можно пока комментариями или в голове. Интересует внутренняя логика и связи с остальными модулями(точки контакта).
Здесь важен этап взятие этих частей (Изображение 1, части 1,8,9) себе:
понимание, для чего они делались
какие узкие места
где совсем непонятно, где все легко
Стать экскурсоводом по этим местам.
Часть два
Далее стараемся понять, как проходят потоки данных и в каких объемах. Возможно часть модулей мертвое или полуживое и лучше постараться сделать так, чтобы их количество уменьшилось.
Цель - уменьшение количества связей, уменьшение количества модулей, которые нужно вынести в отдельный контур.
Далее, когда в голове сложилась полная картинка или почти полная, то можно выносить физически логику в отдельную папку и сделать Loose Coupling с основной системой. Добавить логирование или метрики, убрать ненужные зависимости или схлопнуть их.
Потихоньку пытаясь двигать их, проверяя какой получается impact, где и что немного начинает деградировать. Деградация происходит из-за того, что части могут сильно корнями прирасти (здесь может быть аналогия с выкорчевыванием дерева или зуба).
Задача — добиться максимальной подвижности отделяемых модулей внутри системы как единого целого.
Часть три
Далее важно выделить входящие и исходящие потоки в наш отдельный новообразованный контур. Здесь уже идет работа с контуром как единого целого.
Выделяют входящий и исходящий интерфейс.Граница становится более выражденной. Контур более отделенным.
В таком логическом разделении система должна просуществовать какое-то время, чтобы понять, что действительно все вынесено, что при таком вынесении нет ошибок.
Параллельно можно так же внедрять более точный адаптер для логирования под новый контур.
Опять же вот этот логический контур должен быть отделен и взаимодействие с ним должно быть как-будто он уже в другом твердом контуре.
В конечном счете останется только выбрать нужны транспорт, у меня на картинке это GRPC в одну сторону, rabbitqm в другую.
Вместо интерфейса выбрать контракты на декларативном языке для описание схемы данных, например на Proto, JsonAPI, OpenAPI, AsyncAPI. То есть программные интерфейсы в конкретном языке программирования превращаются в Манифесты, Контракты или любые другие декларативные описания. И оба сервиса завивят от этого документа, а транспорт, service discovery это задача operation/infrastructure.
Перенос в другой твердый контур должен быть почти косметическим. Вопросом перестановки фигур на доске, а не просмотром приживется/не приживется, отделится/не отделится.
Дальнейшее изменение в схеме взаимодействия следует делать обратносовместимыми (например, через гарантию самих контрактов или обратно совместимых обновлений вручную). А очередность имплементации определяется обычно прямой зависимостью, то есть поставщик данных имплементирует фукционал первым для удобства.
Послесловие
Про степени свободы в новом твердом контуре:
появляется возможность независимо деплоить изменения внутри каждого контура
выбирать разные SLA, безопасность, инфраструктуру контуров, scale. Как следствие возможна потеря частичной работоспособности, а не полной.
выбирать более удобные языки имплементации логических контуров.
появляется более вырожденные части системы, взаимодействие которых подиктовано контрактами
удобно разделять: сервис под команду. Деление ответственности получается более гранулярным.
Про минусы:
Service Discovery. Появляется транспорт, а значит ошибки, связанные с недоставкой, недоступностью, разрыва канала связи. В зависимости от топологии сети/инфраструктуры те или или иные ошибки будут возникать чаще/реже.
Усложняется инфраструктура для деплоя: теперь несколько сервисов вместо одного, проложен транспорт между сервисами
Усложняется observability - нужно делать сквозные идентификаторы (Cross-Cutting) для трассировки запросов, дебага ошибок
Волатильность изменения взаимодействий между сервисами. Требуется большая проработка взаимодействия сервисов, четкого понимания, что и куда относить, чтобы сервисы не стали полностью зависимыми.
Решения разделение на микросервисы должно быть обусловлено
логически(по бизнес юнитам)
по зоне ответственности (должно быть определено достаточно ответственности под сервис)
по людям (хорошо бы сразу определить под какую команду он пойдет)
под практику (разделения в похожих областях).
Тут важно, чтобы сервис не стал
анимичным (очень мало ответственности)
невырожденным (контур отделенный, но несамостоятельный совсем)
чтобы он не был кроличьей норой, узким горлышком (несоответствие ответственности)
Иногда достаточно разделять код логически и поддерживать такую сепарацию на уровне невидимых границ. А сопротивление к “некорректным” изменениям искать на уровне движения рук.
Post Scriptum
Важность черчение контуров и обозначения границ иногда более тонко чем микросервисы. В данном примере в одном было важно, что два логических контура продолжительное время жили в одном твердом(=материальном) контуре.
Этапы:
Разделение взглядом → логическое разделение → физическое разделение(на уровне папок, адаптеров) → физическое два (на уровне разных микросервисов)
Зарождается все с невидимого. Затем сгустить, наиндуцировать, понять потоки. Смотреть как проходят данные, логировать, внедрять метрики, искать подтверждение в продакшене и у сотрудников(это про взгляд). Чем дольше мы будем взаимодействовать с системой, как-будто это у нас уже есть, тем лучше оно само разделится на то, что нам нужно. Способность видеть систему не тем, чем она является.
В фазах рождения (с первого по последний) физическое или старое логическое никогда не равно новому логическому. Умение жить, смотреть и чертить границы не так как написано, не так как до того смотрели на это, а по-новому. Умнее продолжительно жить с каждым из этапов перехода и пронести разделение до конца не растеряв истоки разделения.
Субъективный взгляд. Выработка взгляда. То, на что точно не ответит ИИ.