В этой статье описывается, как использовать проектирование на основе домена (DDD) для переноса монолитного приложения в микрослужбы.
Монолитное приложение обычно представляет собой систему приложений, в которой все соответствующие модули упаковываются в единую развертываемую единицу выполнения. Например, это может быть веб-приложение Java (WAR), работающее в Tomcat или ASP. Приложение NET, работающее в службах IIS. Типичное монолитное приложение использует многоуровневую структуру с отдельными слоями для пользовательского интерфейса, логики приложения и доступа к данным.
Эти системы начинаются с малого, но со временем, как правило, растут в соответствии с потребностями бизнеса. В какой-то момент, когда добавляются новые функции, монолитное приложение может начать страдать от следующих проблем:
- Отдельные части системы нельзя масштабировать независимо друг от друга, так как они тесно связаны.
- Трудно поддерживать код из-за тесной связи и скрытых зависимостей.
- Тестирование становится сложнее, что повышает вероятность появления уязвимостей.
Эти проблемы могут стать препятствием на пути будущего роста и стабильности. Команды опасаются внесения изменений, особенно если исходные разработчики больше не работают над проектом, а проектные документы являются разреженными или устаревшими.
Несмотря на эти ограничения, монолитный дизайн может быть смыслом в качестве отправной точки для приложения. Монолиты часто являются самым быстрым путем к созданию подтверждения концепции или минимально жизнеспособного продукта. На ранних этапах разработки монолиты, как правило, являются:
- Проще в сборке, так как существует одна общая база кода.
- Проще в отладке, так как код выполняется в одном процессе и в одном пространстве памяти.
- Легче рассуждать о, потому что есть меньше движущихся частей.
Однако по мере усложняется приложение, эти преимущества могут исчезнуть. Крупные монолиты часто становятся все труднее создавать, отлаживать и обдумать. В какой-то момент проблемы перевешивают преимущества. Это момент, когда имеет смысл перенести приложение в архитектуру микрослужб. В отличие от монолитов, микрослужбы обычно являются децентрализованными, слабо связанных единицами выполнения. На следующей схеме показана типичная архитектура микрослужб:
Миграция монолита в микрослужбу требует значительного времени и средств, чтобы избежать сбоев или перерасходов. Чтобы обеспечить успешную миграцию, полезно понимать преимущества и проблемы, которые приносят микрослужбы. К преимуществам относятся:
- Службы могут развиваться независимо в зависимости от потребностей пользователей.
- Службы могут масштабироваться независимо в соответствии с потребностями пользователей.
- Со временем циклы разработки становятся быстрее, так как функции можно быстрее вывести на рынок.
- Службы изолированы и более терпимы к сбоям.
- Одна служба, которая завершается сбоем, не приведет к отключению всего приложения.
- Тестирование становится более последовательным и последовательным с использованием разработки на основе поведения.
Дополнительные сведения о преимуществах и проблемах микрослужб см. в статье Стиль архитектуры микрослужб.
Применение архитектуры на основе домена
Любая стратегия миграции должна позволить командам постепенно рефакторинговать приложение в небольшие службы, обеспечивая при этом непрерывность обслуживания для конечных пользователей. Ниже приведен общий подход.
- Прекратить добавление функциональных возможностей в монолит.
- Разделите внешний интерфейс от серверной части.
- Разложите и разделите монолит на ряд микрослужб.
Чтобы упростить эту декомпозицию, жизнеспособный подход к разработке программного обеспечения заключается в применении принципов проектирования на основе предметной области (DDD).
Разработка на основе предметной области (DDD) — это подход к разработке программного обеспечения, впервые представленный Эриком Эвансом. DDD требует хорошего понимания домена, для которого будет написано приложение. Знания, необходимые для создания приложения, находятся у людей, которые его понимают, — экспертов в области.
Подход DDD можно применить задним числом к существующему приложению, чтобы начать разложение приложения.
Начните с вездесущий язык, общий словарь, который используется всеми заинтересованными лицами.
Определите соответствующие модули в монолитном приложении и примените к ним общий словарь.
Определите модели предметной области монолитного приложения. Модель предметной области — это абстрактная модель предметной области бизнеса.
Определите ограниченные контексты для моделей. Ограниченный контекст — это граница в пределах домена, к которому применяется определенная модель предметной области. Применение явных границ с четко определенными моделями и обязанностями.
Ограниченные контексты, определенные на шаге 4, являются кандидатами для рефакторинга в небольшие микрослужбы. На следующей схеме показан существующий монолит с наложенными ограниченными контекстами:
Дополнительные сведения об использовании подхода DDD для архитектур микрослужб см. в статье Использование анализа предметной области для моделирования микрослужб.
Использование кода приклеивания (уровень защиты от повреждения)
Хотя эта исследовательская работа проводится для инвентаризации монолитного приложения, новые функциональные возможности можно добавить, применяя принципы DDD в качестве отдельных служб. "Приклеивание кода" позволяет монолитным приложениям выполнять прокси-вызовы к новой службе для получения новых функциональных возможностей.
Код клея (шаблон адаптера) эффективно выступает в качестве антивредоносного слоя, гарантируя, что новая служба не загрязнена моделями данных, необходимыми для монолитного приложения. Код привязки помогает посреднику между ними и гарантирует, что для обеспечения совместимости передаются только данные, необходимые новой службе.
В процессе рефакторинга команды могут выполнять инвентаризацию монолитного приложения и определять кандидатов для рефакторинга микрослужб, а также устанавливать новые функциональные возможности с новыми службами.
Дополнительные сведения о уровнях защиты от коррупции см. в разделе Шаблон антикоррупционного слоя.
Создание уровня презентации
Следующий шаг — отделить уровень представления от уровня серверной части. В традиционном n-уровневом приложении уровень приложения (бизнес) обычно представляет собой компоненты, которые являются основными для приложения и имеют логику предметной области. Эти грубо детализированные API взаимодействуют с уровнем доступа к данным для получения сохраненных данных из базы данных. Эти API устанавливают естественную границу уровня представления и помогают разделить уровень презентации на отдельное пространство приложения.
На следующей схеме показан уровень представления (пользовательский интерфейс), разделенный на уровни логики приложения и уровня доступа к данным.
На этой схеме также представлен другой уровень, шлюз API, который находится между уровнем представления и логикой приложения. Шлюз API — это фасадный слой, который предоставляет согласованный и унифицированный интерфейс для взаимодействия уровня представления, позволяя подчиненным службам развиваться независимо, не влияя на работу приложения. Шлюз API может использовать такую технологию, как Azure Управление API, и позволяет приложению взаимодействовать в режиме RESTful.
Уровень презентации можно разработать на любом языке или платформе, в рамках которого команда имеет опыт работы, например для одностраничного приложения или приложения MVC. Эти приложения взаимодействуют с микрослужбами через шлюз, используя стандартные HTTP-вызовы. Дополнительные сведения о шлюзах API см. в статье Использование шлюзов API в микрослужбах.
Начало вывода монолита из эксплуатации
На этом этапе команда может начать очистку монолитного приложения и медленно извлекать службы, созданные их ограниченными контекстами, в собственный набор микрослужб. Микрослужбы могут предоставлять интерфейс RESTful для взаимодействия уровня приложений с помощью шлюза API с помощью приклеиваемого кода для взаимодействия с монолитом в определенных обстоятельствах.
По мере того как вы продолжаете очищать монолит, в конечном итоге придет точка, когда он больше не должен существовать, и микрослужбы были успешно извлечены из монолита. На этом этапе антивредоносный слой (клейный код) можно безопасно удалить.
Этот подход является примером шаблона Strangler Fig и позволяет управлять декомпозицией монолита на набор микрослужб. Со временем, когда существующие функциональные возможности перемещаются в микрослужбы, монолит будет уменьшаться в размере и сложности, до такой степени, что он больше не существует.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально она была написана следующими участниками.
Основной автор:
- Лаван Наллайнатан | Старший архитектор облачных решений
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Дальнейшие действия
После разложения приложения на составляющие микрослужбы можно использовать современные средства оркестрации, такие как Azure DevOps , для управления жизненным циклом каждой службы. Дополнительные сведения см. в разделе CI/CD для архитектур микрослужб.