Шаблоны проектирования декомпозиции микросервисов

Это четвертая публикация из серии об архитектуре микросервисов. Эта статья изначально опубликована на https://www.learncsdesign.com

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

Разложение важно по нескольким причинам:

Это облегчает разделение труда и обмен знаниями. С его помощью несколько человек (или групп) со специальными знаниями могут продуктивно работать вместе над приложением.
Он описывает, как взаимодействуют элементы программного обеспечения.

В рамках микросервисов существует два типа проектов.

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

Разложить по шаблону бизнес-возможностей

Одной из стратегий создания микросервисной архитектуры является декомпозиция на основе бизнес-возможностей. Как бизнес, вы делаете что-то, чтобы создавать ценность. Вот что такое бизнес-возможности. Например, в бизнесе электронной коммерции задействованы управление заказами, управление запасами, оплата, доставка и т. д.

Этот шаблон имеет следующие преимущества

Бизнес-возможности относительно стабильны, поэтому архитектура стабильна.
Команды разработчиков являются кросс-функциональными, автономными и организованы вокруг предоставления бизнес-ценности, а не технических функций.
Услуги слабо связаны и связны.

Разложить по шаблону поддомена

Подход доменно-ориентированного проектирования (DDD) — это способ создания сложных программных приложений, основанный на разработке объектно-ориентированной модели предметной области. DDD определяет отдельные модели домена для каждого поддомена. Каждый поддомен принадлежит домену. Определение поддоменов — это тот же процесс, что и определение бизнес-возможностей, то есть анализ бизнеса и определение областей знаний. Скорее всего, конечным результатом будут поддомены, привычные для бизнеса. Объем модели предметной области называется в DDD ограниченным контекстом. Ограниченные контексты включают артефакты кода, реализующие модель.

Поддомен можно классифицировать следующим образом

Ядро. Самое большое отличие для бизнеса и самая ценная часть приложения.
Поддержка – не отличительная черта, а связанная с тем, что предлагает компания. Обычно реализуется внутри компании или на стороне.
Универсальный — не относится к конкретному бизнесу и лучше всего реализуется с помощью готового программного обеспечения.

Этот шаблон имеет следующие преимущества

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

Проблемы при разложении монолитного приложения на микросервисы

При декомпозиции монолитных приложений могут возникнуть проблемы.

Сетевая задержка. В распределенной системе сетевая задержка является постоянной проблемой. Вы можете обнаружить, что конкретная декомпозиция на сервисы приводит к большому количеству циклов обмена данными между двумя сервисами.
Поддержание согласованности данных между службами. Каждая служба будет иметь свою собственную базу данных, поэтому поддерживать согласованность данных между службами будет сложно.
Бог-классы. Бог-классы — это объекты, которые контролируют слишком много других объектов в системе, вырастая за пределы логики и становясь классом, который делает все. Это класс, который централизует интеллект системы из-за его размера и сложности и использует информацию из других классов.

Узор душителя

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