Переход к микросервисам

Необязательно переписывать всё сразу

Переход от монолита к микросервисам безопаснее выполнять постепенно. Сначала выбирают часть системы, у которой есть понятная граница и реальная причина для независимого развития, после чего отделяют её контракт и переносят ответственность поэтапно.

Step 1: Client -> Monolith
Step 2: Client -> Router -> Monolith
                         \-> New Service
Step 3: more traffic/features move out

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

Выделять стоит проблемную или ценную область

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

Сначала отделяем зависимости

До переноса в отдельный процесс полезно убрать прямой доступ к внутренним классам и данным будущего сервиса. Монолит должен обращаться к этой области через явный интерфейс. После этого локальную реализацию проще заменить сетевым вызовом, потому что потребители уже не зависят от её внутренностей.

На каждом шаге важно иметь понятный источник истины для данных и не допускать длительного периода, когда и монолит, и новый сервис независимо изменяют одну и ту же сущность.