Паттерны микросерверной разработки: рефакторинг

Паттерны рефакторинга предназначены для организации взаимодействия с программными Legacy-приложениями с постепенным их переводом на микросервисную архитектуру. Рассмотрим некоторые из таких шаблонов.

Strangler

Способы разбиения на микросервисы посредством композиции неплохо подходят для новых программных приложений, которые создаются с нуля. Но на практике нередко возникает необходимость в переводе на микросервисную архитектуру уже существующих монолитных приложений. К тому же, разложение монолита на микросервисы потребует времени, то есть этот процесс не выполнить за одну итерацию. Именно поэтому и разработали паттерн Strangler. Назван он не просто так -- тут проводится аналогия с лианой, которая медленно, постепенно и последовательно душит обвиваемое дерево.

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

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

Пример:

Anti-Corruption Layer

Когда осуществляется перевод Legacy-приложений на микросервисную архитектуру, рефакторинг в отношении некоторых подсистем может стать слишком долгим либо даже невозможным. Однако хочешь не хочешь, а взаимодействовать с устаревшими подсистемами надо все равно, причем несмотря на то, что в них, вероятнее всего, применяются не самые современные технологии относительно построения API, схем данных и пр.

В вышеописанной ситуации подойдет шаблон «Уровень защиты от повреждений». Он предназначается для изолирования различных подсистем посредством размещения между этими системами дополнительного уровня, который можно реализовать в качестве компонента программного приложения либо независимой службы. Данный уровень связывает 2 подсистемы и позволяет им оставаться, по сути, максимально независимыми друг от друга. При этом на данном уровне содержится вся логика, которая нужна для осуществления передачи данных в обе стороны, а при взаимодействии с каждой из этих подсистем применяется именно ее модель данных.

Пример реализации паттерна:

По материалам блога https://mcs.mail.ru/blog/.