Шаблоны микросервисной архитектуры. Часть 1. Шаблоны декомпозиции

31 марта 2023 г. <цитата>

Еще в августе 2008 года в Netflix произошел серьезный сбой из-за серьезного повреждения базы данных, из-за которого они не могли отправлять DVD клиентам в течение трех дней. После этого они решили отказаться от единой точки отказа, которая могла масштабироваться только вертикально, и перейти к компонентам, которые могли масштабироваться горизонтально и были высокодоступными [1].

О чем эта статья?

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

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

Что такое микросервисная архитектура?

Микрослужбы – это архитектурный и организационный подход к разработке программного обеспечения, при котором программное обеспечение состоит из небольших независимых служб, взаимодействующих через четко определенные API [2]. По сути, подход микросервисная архитектура стал популярным при создании программных систем, особенно в современных веб-приложения.

Основные преимущества микросервисной архитектуры

• Масштабируемость. Одним из наиболее значимых преимуществ микросервисной архитектуры является ее масштабируемость. Каждый микросервис можно масштабировать независимо, что позволяет приложению справляться с более значительной нагрузкой, не влияя на производительность других сервисов.
• Гибкость. Микросервисы сильно развязаны, что означает, что каждый сервис можно разрабатывать, развертывать и обновлять независимо от других сервисов. Кроме того, высокий уровень разделения упрощает введение новых функций и обновление существующих, не затрагивая всю систему.
• Отказоустойчивость. Микросервисы спроектированы так, чтобы быть отказоустойчивыми (где отказоустойчивость достигается за счет избыточности и механизмов автоматического перехода на другой ресурс). система.
• Неоднородность технологий. Архитектура микрослужб позволяет использовать разные технологии для каждой службы, поэтому вы можете выбрать лучшую технологию для конкретной задачи или службы. Это может привести к повышению производительности, масштабируемости и гибкости.
• Непрерывная доставка. Архитектура микросервисов поддерживает непрерывную доставку, что позволяет выпускать обновления и новые функции быстрее и чаще, не затрагивая всю систему.

Однако в этом подходе есть некоторые проблемы

Несмотря на то, что микросервисы предлагают много преимуществ, они также сопряжены с рядом проблем:

• Границы сервисов. Определение и определение границ каждого микросервиса может быть сложной задачей, так как могут быть разные способы разделения приложения на микросервисы, и правильное определение границ имеет решающее значение для успеха система.
• Обнаружение служб. Одной из основных задач архитектуры микрослужб является обнаружение служб, то есть процесс поиска и взаимодействия с другими службами. По мере роста числа служб отслеживание всех служб и их местонахождений может стать сложной задачей.
• Консистентность данных. Архитектура микрослужб может привести к проблемам согласованности данных, поскольку каждая служба управляет своими данными. Поддержание согласованности между несколькими службами может быть сложной задачей, и вы должны убедиться, что данные непротиворечивы и актуальны во всех службах.
• Безопасность. Архитектура микрослужб может создавать дополнительные проблемы безопасности, поскольку вам необходимо защищать каждую службу по отдельности. Он включает аутентификацию, авторизацию и безопасную связь между ними.
• Управление транзакциями. Управление транзакциями, охватывающими несколько сервисов, может быть сложным в микросервисной архитектуре, поскольку каждый сервис управляет своими данными и транзакциями. Обеспечить согласованность транзакций и возможность их восстановления в различных службах может быть сложно.
• Тестирование. Тестирование микросервисов может быть проблематичным. Вам необходимо убедиться, что вы можете тестировать каждую службу независимо и что вы можете протестировать всю систему, чтобы убедиться в ее правильном функционировании.

Как мы можем преодолеть эти сложные проблемы?

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

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

Шаблоны декомпозиции

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

1. Декомпозиция по бизнес-возможностям

Описание

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

Этот шаблон лучше использовать, если:

Вот некоторые ситуации, в которых декомпозиция бизнес-возможностей может быть уместна:

• Ваша команда имеет достаточно знаний о бизнес-подразделениях вашей организации, и у вас есть профильные эксперты (SME) для каждого бизнес-подразделения [4].
• Приложение имеет большое количество взаимосвязанных функций или процессов, или когда эти функции или процессы могут часто меняться. Разбивая приложение на более мелкие, более специализированные сервисы, команды разработчиков могут быстрее и проще выполнять итерации и экспериментировать, а также более эффективно реагировать на изменяющиеся бизнес-требования и рыночные условия.
• Предположим, что в вашей организации есть несколько бизнес-подразделений или отделов с разными функциональными областями и рабочими процессами. В этом случае декомпозиция бизнес-возможностей может помочь привести архитектуру вашего приложения в соответствие с этими возможностями, упростив разработку и развертывание новых функций и сервисов.

Преимущества

• Согласование с бизнесом. Организуя микросервисы с учетом бизнес-возможностей, упрощается согласование разработки программного обеспечения с бизнес-целями и задачами. В результате также упрощается приоритизация усилий по разработке и гарантируется, что в первую очередь рассматриваются наиболее важные бизнес-возможности [5].
• Межфункциональные команды. Этот шаблон поощряет создание многофункциональных команд, ориентированных на определенные бизнес-возможности. А это, в свою очередь, может помочь устранить разрозненность между разными отделами и гарантировать, что все работают для достижения общей цели.
• Улучшение взаимодействия с пользователем. Сосредоточив внимание на определенных бизнес-возможностях, микросервисы можно оптимизировать для конкретных потребностей конечных пользователей. Это может улучшить взаимодействие с пользователем и повысить его удовлетворенность.

Давайте посмотрим на пример

Давайте рассмотрим гипотетическую платформу здравоохранения, которая предоставляет различные услуги, такие как ведение пациентов, планирование встреч, управление электронными медицинскими записями (EMR), выставление счетов и обработка платежей, а также услуги телемедицины. Чтобы разложить эти бизнес-возможности на микрослужбы, мы можем назначить одну отдельную бизнес-возможность и ее данные отдельной микрослужбе, которую можно разрабатывать, развертывать и масштабировать независимо друг от друга.

Вот архитектурная схема, иллюстрирующая эту декомпозицию.

На рисунке 1 мы видим, как можно разбить платформу здравоохранения на микросервисы в зависимости от бизнес-возможностей:

• Управление пациентами. Этот микросервис управляет записями пациентов, такими как демографические данные, история болезни и страховая информация.
• Планирование встреч. Эта микрослужба отвечает за планирование встреч с пациентами, отправку напоминаний пациентам и управление процессом записи на прием.
• Управление электронными медицинскими записями (EMR). Этот микросервис управляет медицинскими записями пациентов в электронном виде, включая результаты лабораторных исследований, исследования изображений и другие медицинские данные.
• Выставление счетов и обработка платежей. Этот микросервис формирует счета пациентов, обрабатывает платежи и управляет страховыми случаями.
• Телемедицина. Этот микросервис предоставляет пациентам удаленные консультации и услуги телемедицины, позволяя им удаленно консультироваться с врачами.

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

Возможные проблемы и проблемы

:::предупреждение * Сложность определения бизнес-возможностей. Определение и определение подходящих бизнес-возможностей для использования в качестве основы для микросервисов с правильными границами может быть сложным и трудоемким процессом. * Тесная связь между микросервисами. Если бизнес-возможности четко не определены или они частично совпадают, между микросервисами может быть высокая степень связанности. Высокая степень связанности микросервисов может затруднить изменение или замену отдельных сервисов, не затрагивая систему в целом, увеличивая риск простоя или другие проблемы. * Сложность координации микросервисов. Координация различных микросервисов, задействованных в бизнес-функциях, может быть сложной, особенно если бизнес-функции включают несколько шагов или взаимодействие с внешними системами.

:::

2. Разложение по транзакциям

Описание

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

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

Этот шаблон лучше использовать, если:

Этот шаблон может быть разумным в следующих сценариях:

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

Преимущества

• Пониженная сложность. Группируя компоненты, участвующие в транзакции, в одну микрослужбу, этот шаблон помогает упростить координацию транзакций между несколькими службами. Это может упростить разработку, тестирование и обслуживание системы.
• Минимальные проблемы с двухэтапной фиксацией. В этом шаблоне каждая транзакция принадлежит отдельной микрослужбе, что помогает избежать проблем с двухэтапной фиксацией. Тогда это может привести к созданию более надежной и отказоустойчивой системы.
• Уменьшение задержки. Благодаря группировке компонентов в одном микросервисе этот шаблон может уменьшить задержку, возникающую при координации транзакций между несколькими службами. Тогда это может привести к более быстрому времени отклика и лучшему взаимодействию с пользователем.
• Лучшее согласование с потребностями бизнеса. Разбивая систему на основе транзакций, этот шаблон может помочь лучше согласовать микросервисную архитектуру с конкретными потребностями бизнеса организации. Тогда это может привести к более эффективной и действенной системе.

Давайте посмотрим пример

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

Вот архитектурная схема, иллюстрирующая эту декомпозицию.

На Рисунке 2 мы видим, как платформа электронной коммерции может быть разложена по транзакциям на микросервисы, которые могут быть частью этой системы:

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

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

Возможные проблемы и проблемы

:::предупреждение * Возможность создания монолита. При использовании шаблона декомпозиции транзакций можно объединить несколько модулей в один микросервис. Это, в свою очередь, может создать монолитную архитектуру, что противоречит принципам микросервисов. Чтобы избежать этого, важно, чтобы каждый микросервис был сосредоточен на одной бизнес-области [7]. * Увеличение стоимости и сложности. Если одна микрослужба выполняет несколько функций, а не разделяет их на отдельные микрослужбы, стоимость и сложность этой микрослужбы могут возрасти. Это, в свою очередь, может привести к увеличению времени разработки и увеличению эксплуатационных расходов. Чтобы избежать этого, важно тщательно продумать область действия каждой микрослужбы. * Несовместимые версии. При развертывании микрослужб возможно случайное развертывание разных версий одной и той же микрослужбы для одного и того же бизнес-домена. Это, в свою очередь, может привести к непоследовательному поведению и потенциальным ошибкам в системе. Чтобы избежать этого, важно тщательно управлять процессами управления версиями и развертывания.

:::

3. Разбивка по субдоменам

Описание

Декомпозиция микросервисов по субдоменам – это процесс разбиения монолитной системы на более мелкие независимые микросервисы на основе соответствующих субдоменов, определяемых проектом, управляемым доменом (DDD). DDD относится к проблемному пространству приложения — бизнесу — как домену, состоящему из нескольких поддоменов [8]. Объем модели каждой подобласти называется ограниченным контекстом, вокруг которого разрабатываются микросервисы. Этот шаблон подходит для монолитных систем с четкими границами между поддоменами и позволяет переупаковывать существующие модули в виде микросервисов без значительного переписывания кода. Благодаря разбиению монолитной системы на микрослужбы на основе субдоменов каждая микрослужба имеет собственную модель, которая обеспечивает большую гибкость, масштабируемость и удобство обслуживания.

Этот шаблон лучше использовать, если:

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

Вот несколько сценариев, в которых этот шаблон хорошо подходит:

• Большие сложные приложения. Декомпозиция микросервисов по субдоменам особенно полезна для приложений с большим объемом бизнес-логики, с несколькими рабочими процессами, моделями данных и взаимозависимыми правилами. Разбивка приложения на поддомены упрощает управление кодовой базой и ее обслуживание, а также ускоряет разработку и развертывание.
• Гибкая разработка. Микросервисная архитектура хорошо подходит для гибких методологий разработки, поскольку позволяет разработчикам работать над небольшими независимыми сервисами, которые можно разрабатывать и развертывать быстрее. Такой подход может сократить время выхода на рынок, снизить затраты на разработку и повысить общее качество программного обеспечения.
• Масштабируемость. Разбивая приложение на более мелкие независимые службы, становится проще масштабировать каждую службу независимо от других. Такой подход может повысить общую масштабируемость и производительность приложения, поскольку каждую службу можно оптимизировать и масштабировать по мере необходимости.
• Гибкость. Декомпозиция микросервисов по субдоменам позволяет разработчикам вносить изменения в определенные области функциональности, не затрагивая другие части приложения. Такой подход может повысить общую гибкость и динамичность приложения, позволяя ему быстрее адаптироваться к изменяющимся бизнес-требованиям.

Преимущества

• Улучшенная масштабируемость и предсказуемость. Этот шаблон обеспечивает лучшую масштабируемость и предсказуемость за счет разбиения монолитной системы на более мелкие независимые микросервисы. Микросервисы можно увеличивать или уменьшать по мере необходимости, а сбои или сбои в одном микросервисе не повлияют на остальную часть системы. Это может привести к более стабильной и надежной системе, способной справляться с изменениями спроса и моделей использования [9].
• Слабосвязанная архитектура. Этот шаблон обеспечивает слабосвязанную архитектуру, что означает, что микрослужбы предназначены для работы независимо друг от друга. Это, в свою очередь, дает множество преимуществ, в том числе:
• Масштабируемость. Отдельные микрослужбы можно увеличивать или уменьшать независимо друг от друга, что обеспечивает большую гибкость и экономичность.
• Отказоустойчивость. Сбои или сбои в одной микрослужбе не повлияют на остальную часть системы, что снижает риск простоя или потери данных.
• Удобство обслуживания. Можно вносить изменения или обновления в отдельные микрослужбы, не затрагивая остальную часть системы, что упрощает и ускоряет обслуживание и обновления.
• Расширяемость: новые микросервисы можно добавлять или удалять, не затрагивая остальную часть системы, что обеспечивает большую гибкость для будущих разработок.
• Прозрачность местоположения. Микросервисы можно развертывать в разных местах, что упрощает развертывание сервисов ближе к пользователям или источникам данных.
• Независимость от протокола. Микросервисы могут обмениваться данными по разным протоколам, что упрощает интеграцию с существующими системами.
• Независимость от времени. Микросервисы можно разрабатывать и развертывать независимо друг от друга, что позволяет разным командам работать над разными сервисами, не влияя друг на друга.

Давайте посмотрим пример

Давайте рассмотрим монолитное страховое приложение, позволяющее клиентам приобретать страховку через Интернет. Чтобы реализовать это приложение с использованием микросервисной архитектуры, мы могли бы использовать шаблон декомпозиции поддоменов, чтобы разбить систему на более мелкие, более управляемые микросервисы, каждый из которых принадлежит определенному поддомену. Вот архитектурная диаграмма, иллюстрирующая эту декомпозицию [10].

На Рисунке 3 мы видим, как приложение страхового монолита было декомпозировано по бизнес-возможностям на четыре службы: продажи, клиент, комплаенс и маркетинг. Затем служба продаж была дополнительно разделена на субдомены закупок и претензий, а субдомен маркетинга — на субдомены кампаний, аналитики и отчетов.

Вот краткий обзор микросервисов, созданных в каждом поддомене:

• Служба закупок: занимается покупкой страховых полисов.
• Служба претензий: обрабатывает страховые претензии.
• Служба поддержки клиентов: управляет информацией о клиентах и ​​взаимодействием с ними.
• Служба соответствия: обеспечивает соответствие нормативным требованиям и управляет рисками.
• Служба кампаний: управление маркетинговыми кампаниями.
• Служба аналитики: отслеживание и анализ маркетинговых данных.
• Служба отчетов: создает отчеты об эффективности маркетинга.

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

Возможные проблемы и проблемы

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

:::

Заключение

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

Об авторе

Зуфар Сунагатов — опытный старший инженер-программист, увлеченный проектированием современных программных систем. Он решительно выступает за микросервисную архитектуру и много работал со сложными распределенными системами с использованием различных шаблонов проектирования в крупных компаниях электронной коммерции, финансовых технологий и страховых компаниях. Зуфар является активным участником сообщества разработчиков программного обеспечения и регулярно делится своими знаниями и опытом на своем канале Telegram ZufarExplainedIT и LinkedIn, где он объясняет алгоритмы и решения задач проектирования систем, а также подходы, которые были хорошо приняты сообществом.

Ссылки

1. https://networknuts.net/netflix-aws-case-study/
2. https://en.wikipedia.org/wiki/Microservices
3. https://learning.oreilly.com/library/view/microservices-patterns
4. https://docs.aws.amazon .com/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html
5. https://microservices.io/patterns/decomposition/decompose-by-business-capability .html
6. https://www.youtube.com/watch?v=IHhM6OmUoFI
7. https://docs.aws.amazon.com /prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html
8. https://microservices.io/patterns/decomposition/decompose-by-subdomain.html
9. https://www.tutorialspoint.com/microservices_design_patterns/microservices_design_patterns_decompose_by_subdomain.htm
10. https://docs.aws.amazon.com /prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html

---

Оригинал