В этой статье описывается использование архитектуры на основе домена (DDD) для переноса монолитного приложения в микрослужбы.
Монолитное приложение обычно представляет собой систему приложений, в которой все соответствующие модули упаковываются в одну развертываемую единицу выполнения. Например, это может быть веб-приложение Java (WAR), работающее в Tomcat или ASP.Приложение NET, работающее в IIS. Типичное монолитное приложение использует многоуровневую структуру с отдельными слоями для пользовательского интерфейса, логики приложения и доступа к данным.
Эти системы начинаются с малого, но, как правило, растут с течением времени для удовлетворения бизнес-потребностей. В какой-то момент, когда добавляются новые функции, монолитное приложение может начать страдать от следующих проблем:
- Отдельные части системы нельзя масштабировать независимо, так как они тесно связаны.
- Трудно поддерживать код из-за жесткой связи и скрытых зависимостей.
- Тестирование становится сложнее, увеличив вероятность внедрения уязвимостей.
Эти проблемы могут стать препятствием для будущего роста и стабильности. Команды становятся осторожными в внесении изменений, особенно если исходные разработчики больше не работают над проектом и проектными документами являются разреженными или устаревшими.
Несмотря на эти ограничения, монолитная конструкция может быть смыслом в качестве отправной точки для приложения. Монолиты часто являются самым быстрым путем к созданию подтверждения концепции или минимального жизнеспособного продукта. На ранних этапах развития монолиты, как правило, будут:
- Проще создавать, так как существует одна общая база кода.
- Проще выполнить отладку, так как код выполняется в пределах одного процесса и пространства памяти.
- Проще подумать о том, потому что есть меньше движущихся частей.
Однако по мере того как приложение усложняется, эти преимущества могут исчезнуть. Крупные монолиты часто становятся постепенно сложнее создавать, отлаживать и причину. В какой-то момент проблемы перевешивают преимущества. Это точка, когда можно перенести приложение в архитектуру микрослужб. В отличие от монолитов, микрослужбы обычно децентрализованы, слабо связанные единицы выполнения. На следующей схеме показана стандартная архитектура микрослужб:
Миграция монолита в микрослужбу требует значительного времени и инвестиций, чтобы избежать сбоев или переполнений. Чтобы убедиться, что любая миграция успешна, хорошо понять как преимущества, так и проблемы, которые приносят микрослужбы. К преимуществам относятся:
- Службы могут развиваться независимо на основе потребностей пользователей.
- Службы могут масштабироваться независимо в соответствии с требованиями пользователей.
- С течением времени циклы разработки становятся быстрее, так как функции можно выпускать на рынок быстрее.
- Службы изолированы и более терпимы к сбоям.
- Одна служба, которая завершается сбоем, не приведет ко всему приложению.
- Тестирование становится более последовательным и последовательным, используя разработку на основе поведения.
Дополнительные сведения о преимуществах и проблемах микрослужб см . в стиле архитектуры микрослужб.
Применение архитектуры на основе домена
Любая стратегия миграции должна позволить командам постепенно рефакторингировать приложение в небольшие службы, обеспечивая непрерывность обслуживания конечным пользователям. Ниже приведен общий подход.
- Остановите добавление функций в монолит.
- Разделите внешний интерфейс с серверной части.
- Раскомпозировать и разделить монолит на ряд микрослужб.
Чтобы упростить эту декомпозицию, жизнеспособный подход к разработке программного обеспечения заключается в применении принципов разработки на основе домена (DDD).
Проектирование на основе домена (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 для архитектур микрослужб.