0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: микросервисы, декомпозиция, разработка, паттерны, рефакторинг</p>
1
<p>Теги: микросервисы, декомпозиция, разработка, паттерны, рефакторинг</p>
2
<p>Паттерны рефакторинга предназначены для организации взаимодействия с программными Legacy-приложениями с постепенным их переводом на микросервисную архитектуру. Рассмотрим некоторые из таких шаблонов.</p>
2
<p>Паттерны рефакторинга предназначены для организации взаимодействия с программными Legacy-приложениями с постепенным их переводом на микросервисную архитектуру. Рассмотрим некоторые из таких шаблонов.</p>
3
<h2>Strangler</h2>
3
<h2>Strangler</h2>
4
<p>Способы<a>разбиения на микросервисы посредством композиции</a>неплохо подходят для новых программных приложений, которые создаются с нуля. Но на практике нередко возникает необходимость в переводе на микросервисную архитектуру уже существующих монолитных приложений. К тому же, разложение монолита на микросервисы потребует времени, то есть этот процесс не выполнить за одну итерацию. Именно поэтому и разработали паттерн<strong>Strangler</strong>. Назван он не просто так -- тут проводится аналогия с лианой, которая медленно, постепенно и последовательно душит обвиваемое дерево.</p>
4
<p>Способы<a>разбиения на микросервисы посредством композиции</a>неплохо подходят для новых программных приложений, которые создаются с нуля. Но на практике нередко возникает необходимость в переводе на микросервисную архитектуру уже существующих монолитных приложений. К тому же, разложение монолита на микросервисы потребует времени, то есть этот процесс не выполнить за одну итерацию. Именно поэтому и разработали паттерн<strong>Strangler</strong>. Назван он не просто так -- тут проводится аналогия с лианой, которая медленно, постепенно и последовательно душит обвиваемое дерево.</p>
5
<p>То есть мы говорим о миграции монолита на микросервисную архитектуру посредством<strong>постепенного переноса в микросервисы существующих функций</strong>. При реализации поставленной задачи не обойтись без настройки маршрутизации запросов между микросервисами и устаревшим монолитом. При переносе очередной функциональности фасад перехватывает клиентский запрос, направляя его микросервисам. При этом новые функции реализуются исключительно в микросервисах. После того, как все функции перенесены, монолит полностью выводится из эксплуатации.</p>
5
<p>То есть мы говорим о миграции монолита на микросервисную архитектуру посредством<strong>постепенного переноса в микросервисы существующих функций</strong>. При реализации поставленной задачи не обойтись без настройки маршрутизации запросов между микросервисами и устаревшим монолитом. При переносе очередной функциональности фасад перехватывает клиентский запрос, направляя его микросервисам. При этом новые функции реализуются исключительно в микросервисах. После того, как все функции перенесены, монолит полностью выводится из эксплуатации.</p>
6
<p>При небольших размерах монолитного программного приложения данный паттерн использовать не рекомендуется -- тут уж лучше реализовать единовременный перевод на архитектуру микросервисов, ведь добавление фасада увеличит задержки и затруднит тестирование.</p>
6
<p>При небольших размерах монолитного программного приложения данный паттерн использовать не рекомендуется -- тут уж лучше реализовать единовременный перевод на архитектуру микросервисов, ведь добавление фасада увеличит задержки и затруднит тестирование.</p>
7
<p><em>Пример</em>:</p>
7
<p><em>Пример</em>:</p>
8
<h2>Anti-Corruption Layer</h2>
8
<h2>Anti-Corruption Layer</h2>
9
<p>Когда осуществляется перевод Legacy-приложений на микросервисную архитектуру, рефакторинг в отношении некоторых подсистем может стать слишком долгим либо даже невозможным. Однако хочешь не хочешь, а взаимодействовать с устаревшими подсистемами надо все равно, причем несмотря на то, что в них, вероятнее всего, применяются не самые современные технологии относительно построения API, схем данных и пр.</p>
9
<p>Когда осуществляется перевод Legacy-приложений на микросервисную архитектуру, рефакторинг в отношении некоторых подсистем может стать слишком долгим либо даже невозможным. Однако хочешь не хочешь, а взаимодействовать с устаревшими подсистемами надо все равно, причем несмотря на то, что в них, вероятнее всего, применяются не самые современные технологии относительно построения API, схем данных и пр.</p>
10
<p>В вышеописанной ситуации подойдет шаблон "<strong>Уровень защиты от повреждений</strong>". Он предназначается для изолирования различных подсистем посредством размещения между этими системами дополнительного уровня, который можно реализовать в качестве компонента программного приложения либо независимой службы. Данный уровень связывает 2 подсистемы и позволяет им оставаться, по сути, максимально независимыми друг от друга. При этом на данном уровне содержится вся логика, которая нужна для осуществления передачи данных в обе стороны, а при взаимодействии с каждой из этих подсистем применяется именно ее модель данных.</p>
10
<p>В вышеописанной ситуации подойдет шаблон "<strong>Уровень защиты от повреждений</strong>". Он предназначается для изолирования различных подсистем посредством размещения между этими системами дополнительного уровня, который можно реализовать в качестве компонента программного приложения либо независимой службы. Данный уровень связывает 2 подсистемы и позволяет им оставаться, по сути, максимально независимыми друг от друга. При этом на данном уровне содержится вся логика, которая нужна для осуществления передачи данных в обе стороны, а при взаимодействии с каждой из этих подсистем применяется именно ее модель данных.</p>
11
<p><em>Пример реализации паттерна</em>:</p>
11
<p><em>Пример реализации паттерна</em>:</p>
12
<p><em>По материалам блога https://mcs.mail.ru/blog/.</em></p>
12
<p><em>По материалам блога https://mcs.mail.ru/blog/.</em></p>
13
13