Микросервисная архитектура и 10 наиболее важных шаблонов проектирования

Архитектура микросервисов, База данных на микросервисы, Источники событий, CQRS, Saga, BFF, API-шлюз, Душитель, Автоматический выключатель, Внешняя конфигурация, Тестирование контрактов, ориентированное на потребителя

Преодоление сложности больших программных систем всегда было сложной задачей с первых дней разработки программного обеспечения (1960-е годы). За прошедшие годы инженеры-программисты и архитекторы предприняли множество попыток справиться со сложностями программных систем: Модульность и сокрытие информации Дэвид Парнас (1972), Разделение проблем Эдсгер В. Дейкстра (1974) , Сервисно-ориентированная архитектура (1998).

Все они использовали старинную и проверенную технику для преодоления сложности большой системы: разделяй и властвуй. С 2010-х годов этих методов оказалось недостаточно для решения сложных задач веб-масштабирования или современных крупномасштабных корпоративных приложений. В результате архитекторы и инженеры разработали новый подход к преодолению сложности программных систем в наше время: микросервисная архитектура. Он также использует ту же старую технику «Разделяй и властвуй», хотя и по-новому.

Шаблоны проектирования программного обеспечения - это общие многократно используемые решения часто встречающейся проблемы в разработке программного обеспечения. Шаблоны проектирования помогают нам использовать общий словарь и использовать проверенное в боях решение вместо того, чтобы изобретать колесо. В предыдущей статье Эффективные микросервисы: 10 лучших практик я описал набор лучших практик для разработки эффективных микросервисов. Здесь я опишу набор шаблонов проектирования, которые помогут вам реализовать эти передовые практики. Если вы новичок в микросервисной архитектуре, не беспокойтесь, я познакомлю вас с микросервисной архитектурой.

Прочитав эту статью, вы узнаете:

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

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

Микросервисная архитектура

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

Что такое микросервисная архитектура. Существует множество определений микросервисной архитектуры. Вот мое определение:

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

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

Важные характеристики микросервисной архитектуры:

• Все приложение разделено на отдельные процессы, каждый из которых может содержать несколько внутренних модулей.
• В отличие от модульных монолитов или SOA, приложение микросервиса разделено вертикально (в соответствии с бизнес-возможностями или доменами)
• Граница микросервиса внешняя. В результате микросервисы взаимодействуют друг с другом через сетевые вызовы (RPC или сообщения).
• Поскольку микросервисы являются независимыми процессами, их можно развертывать независимо.
• Они общаются легко и не нуждаются в каком-либо интеллектуальном канале связи.

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

• Лучшее масштабирование разработки.
• Более высокая скорость разработки.
• Поддерживает итеративную или инкрементную модернизацию.
• Воспользуйтесь преимуществами современной экосистемы разработки программного обеспечения (облако, контейнеры, DevOps, бессерверная среда).
• Поддерживает горизонтальное масштабирование и гранулярное масштабирование.
• Он возлагает низкую когнитивную сложность на голову разработчика благодаря своему меньшему размеру.

Недостатки микросервисной архитектуры:

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

Когда использовать микросервисную архитектуру:

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

Шаблоны проектирования для микросервисной архитектуры

База данных на микросервис

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

Лучший подход - предоставить каждой микросервисе собственное хранилище данных, чтобы не было сильной связи между службами на уровне базы данных. Здесь я использую термин база данных, чтобы показать логическое разделение данных, т.е. микросервисы могут совместно использовать одну и ту же физическую базу данных, но они должны использовать отдельную схему / коллекцию / таблицу. Это также гарантирует, что микросервисы будут правильно разделены в соответствии с Domain-Driven-Design.

Плюсы

• Полное владение данными для службы.
• Слабая связь между командами, разрабатывающими сервисы.

Минусы

• Обмен данными между службами становится сложной задачей.
• Предоставление транзакционной гарантии ACID для всего приложения становится намного сложнее.
• Разложение базы данных Monolith на более мелкие части требует тщательного проектирования и является сложной задачей.

Когда использовать базу данных для микросервиса

• В крупномасштабных корпоративных приложениях.
• Когда команде требуется полное владение своими микросервисами для масштабирования и скорости разработки.

Когда не следует использовать базу данных на микросервисе

• В небольших приложениях.
• Если одна команда разработает все микросервисы.

Примеры использования технологий

Все базы данных SQL, NoSQL предлагают логическое разделение данных (например, отдельные таблицы, коллекции, схемы, базы данных).

Дополнительная информация

Поиск событий

В микросервисной архитектуре, особенно с базой данных на микросервис, микросервисы должны обмениваться данными. Для отказоустойчивых, высокомасштабируемых и отказоустойчивых систем они должны обмениваться данными асинхронно, обмениваясь событиями. В таком случае вы можете захотеть выполнить атомарные операции, например, обновить базу данных и отправить сообщение. Если у вас есть базы данных SQL и вы хотите иметь распределенные транзакции для большого объема данных, вы не можете использовать двухфазную блокировку (2PL), поскольку она не масштабируется. Если вы используете базы данных NoSQL и хотите иметь распределенную транзакцию, вы не можете использовать 2PL, поскольку многие базы данных NoSQL не поддерживают двухфазную блокировку.

В таких сценариях используйте архитектуру на основе событий с поиском событий. В традиционных базах данных бизнес-объект с текущим «состоянием» сохраняется напрямую. В Event Sourcing любое событие, изменяющее состояние, или другие важные события сохраняются вместо сущностей. Это означает, что изменения бизнес-объекта сохраняются в виде серии неизменяемых событий. Состояние бизнес-объекта вычитается путем повторной обработки всех событий этого бизнес-объекта в заданное время. Поскольку данные хранятся в виде серии событий, а не через прямые обновления в хранилищах данных, различные службы могут воспроизводить события из хранилища событий, чтобы вычислить соответствующее состояние своих соответствующих хранилищ данных.

Плюсы

• Обеспечьте атомарность высокомасштабируемым системам.
• Автоматическая история сущностей, включая функции путешествий во времени.
• Слабосвязанные микросервисы, управляемые событиями.

Минусы

• Чтение сущностей из хранилища событий становится сложной задачей и обычно требует дополнительного хранилища данных (шаблон CQRS).
• Общая сложность системы увеличивается и обычно требуется Domain-Driven Design.
• Система должна обрабатывать повторяющиеся события (идемпотентные) или отсутствующие события.
• Перенос схемы событий становится сложной задачей.

Когда использовать Event Sourcing

• Высоко масштабируемые транзакционные системы с базами данных SQL.
• Транзакционные системы с базами данных NoSQL.
• Высоко масштабируемая и устойчивая микросервисная архитектура.
• Типичные системы, управляемые сообщениями или событиями (системы электронной коммерции, бронирования и бронирования).

Когда не использовать Event Sourcing

• Слабо масштабируемые транзакционные системы с базами данных SQL.
• В простой микросервисной архитектуре, где микросервисы могут синхронно обмениваться данными (например, через API).

Примеры использования технологий

Магазин событий: EventStoreDB, Apache Kafka, Confluent Cloud, AWS Kinesis, Azure Event Hub, GCP Pub / Sub, Azure Cosmos DB, MongoDB. », Кассандра . Amazon DynamoDB,

Фреймворки: Lagom, Akka, Spring, akkatecture, Axon, Eventuate.

Дополнительная информация

Разделение ответственности за запросы команд (CQRS)

Если мы используем Event Sourcing, тогда чтение данных из Event Store становится затруднительным. Чтобы получить сущность из хранилища данных, нам нужно обработать все события сущности. Кроме того, иногда у нас разные требования к согласованности и пропускной способности для операций чтения и записи.

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

В своей простой форме для чтения и записи используются отдельные сущности или модели ORM, как показано ниже:

Это помогает обеспечить соблюдение принципа единой ответственности и разделения интересов, что приводит к более чистому дизайну.

В расширенной форме для операций чтения и записи используются разные хранилища данных. Расширенный CQRS используется с Event Sourcing. В зависимости от варианта использования используются разные типы хранилища данных записи и хранилища данных чтения. Хранилище данных записи - это «Система записей», то есть золотой источник всей системы.

Для приложений с интенсивным чтением или микросервисной архитектуры в качестве хранилища записи используется база данных OLTP (любая база данных SQL или NoSQL, предлагающая гарантию транзакции ACID) или платформа распределенного обмена сообщениями. Для приложений с интенсивной записью (высокая масштабируемость и пропускная способность записи) используется база данных с горизонтальной масштабируемой записью (глобальные базы данных общедоступного облака). Нормализованные данные сохраняются в хранилище данных записи.

База данных NoSQL, оптимизированная для поиска (например, Apache Solr, Elasticsearch) или чтения (хранилище данных Key-Value, хранилище данных документов), используется в качестве хранилища для чтения. Во многих случаях, когда требуется SQL-запрос, используются масштабируемые для чтения базы данных SQL. Денормализованные и оптимизированные данные сохраняются в хранилище для чтения.

Данные копируются из хранилища записи в хранилище чтения асинхронно. В результате хранилище чтения отстает от хранилища записи и является конечным согласованным.

Плюсы

• Более быстрое чтение данных в микросервисах, управляемых событиями.
• Высокая доступность данных.
• Системы чтения и записи могут масштабироваться независимо.

Минусы

• Хранилище данных чтения слабо согласовано (согласованность в конечном итоге)
• Общая сложность системы увеличивается. Консультации по грузовым перевозкам CQRS могут значительно поставить под угрозу весь проект.

Когда использовать CQRS

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

Когда не использовать CQRS

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

Примеры использования технологий

Магазин записи: EventStoreDB, Apache Kafka, Confluent Cloud, AWS Kinesis, Azure Event Hub, GCP Pub / Sub, Azure Cosmos DB, MongoDB. », Кассандра . Amazon DynamoDB

Читать магазин: Elastic Search, Solr, Cloud Spanner, Amazon Aurora, Azure Cosmos DB, Neo4j

Фреймворки: Lagom, Akka, Spring, akkatecture, Axon, Eventuate.

Дополнительная информация

Сага

Если вы используете микросервисную архитектуру с базой данных на микросервис, то управление согласованностью с помощью распределенных транзакций является сложной задачей. Вы не можете использовать традиционный протокол двухфазной фиксации, поскольку он либо не масштабируется (базы данных SQL), либо не поддерживается (многие базы данных NoSQL).

Вы можете использовать шаблон Saga для распределенных транзакций в микросервисной архитектуре. Saga - это старый шаблон, разработанный в 1987 году как концептуальная альтернатива длительным транзакциям базы данных в базах данных SQL. Но современный вариант этого шаблона отлично работает и для распределенной транзакции. Шаблон саги - это последовательность локальной транзакции, в которой каждая транзакция обновляет данные в хранилище данных в рамках одной микросервиса и публикует событие или сообщение. Первая транзакция в саге инициируется внешним запросом (событием или действием). После завершения локальной транзакции (данные сохраняются в хранилище данных, а сообщение или событие публикуются) опубликованное сообщение / событие запускает следующую локальную транзакцию в Saga.

Если локальная транзакция терпит неудачу, Saga выполняет серию компенсирующих транзакций, которые отменяют изменения предыдущих локальных транзакций.

В основном существует два варианта координации транзакций Saga:

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

Плюсы

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

Минусы

• Необходимо обрабатывать временные сбои и обеспечивать идемпотентность.
• Трудно отлаживать, и сложность растет по мере увеличения количества микросервисов.

Когда использовать Saga

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

Когда не использовать Saga

• Слабо масштабируемые транзакционные системы с базами данных SQL.
• В системах, где существует циклическая зависимость между услугами.

Примеры использования технологий

Аксон, Эвентуате, Нараяна

Дополнительная информация

Бэкэнды для фронтендов (BFF)

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

Backends for Frontends pattern может использоваться в сценариях, где каждый пользовательский интерфейс получает отдельный серверный модуль, настроенный для конкретного пользовательского интерфейса. Он также обеспечивает другие преимущества, например, выступает в качестве фасада для подчиненных микросервисов, тем самым уменьшая болтливую связь между пользовательским интерфейсом и подчиненными микросервисами. Кроме того, в сценарии с высокой степенью защиты, когда нижестоящие микросервисы развертываются в сети DMZ, BFF используются для обеспечения более высокой безопасности.

Плюсы

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

Минусы

• Дублирование кода у лучших друзей.
• Распространение BFF в случае использования многих других пользовательских интерфейсов (например, Smart TV, Web, Mobile, Desktop).
• Требуется тщательная разработка и реализация, поскольку BFF не должны содержать никакой бизнес-логики, а должны содержать только логику и поведение, специфичные для клиента.

Когда использовать серверные части для интерфейсов

• Если приложение имеет несколько пользовательских интерфейсов с разными требованиями к API.
• Если требуется дополнительный уровень между пользовательским интерфейсом и микросервисами нижестоящего уровня по соображениям безопасности.
• Если при разработке пользовательского интерфейса используются микро-интерфейсы.

Когда не следует использовать серверные части для интерфейсов

• Если у приложения несколько пользовательских интерфейсов, но они используют один и тот же API.
• Если основные микросервисы не развернуты в DMZ.

Примеры использования технологий

Его поддерживают любые серверные фреймворки (Node.js, Spring, Django, Laravel, Flask, Play, ...).

Дополнительная информация

API-шлюз

В архитектуре микросервисов пользовательский интерфейс обычно соединяется с несколькими микросервисами. Если микросервисы являются мелкозернистыми (FaaS), клиенту может потребоваться подключение к большому количеству микросервисов, что становится болтливым и сложным. Кроме того, сервисы, включая их API, могут развиваться. Крупные предприятия хотели бы иметь другие общие задачи (завершение SSL, аутентификация, авторизация, регулирование, ведение журнала и т. Д.).

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

Плюсы

• Предложите слабую связь между Frontend и Backend микросервисами.
• Уменьшите количество двусторонних вызовов между клиентом и микросервисами.
• Высокая безопасность за счет завершения SSL, аутентификации и авторизации.
• Централизованно управляемые сквозные задачи, например, ведение журнала и мониторинг, регулирование, балансировка нагрузки.

Минусы

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

Когда использовать API Gateway

• В сложной микросервисной архитектуре это почти обязательно.
• В крупных корпорациях API Gateway является обязательным для централизации безопасности и общих проблем.

Когда не следует использовать API Gateway

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

Примеры использования технологий

Amazon API Gateway, Azure API Management, Apigee, Kong, WSO2 API Manager

Дополнительная информация

Душитель

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

Одно из решений - использовать шаблон душителя. Шаблон душителя означает постепенную миграцию монолитного приложения на микросервисную архитектуру путем постепенной замены определенных функций новыми микросервисами. Кроме того, новые функции добавляются только в микросервисы, минуя устаревшее приложение Monolithic. Затем настраивается фасад (шлюз API) для маршрутизации запросов между устаревшим Monolith и микросервисами. После того, как функциональность перенесена с Monolith на микросервисы, Facade перехватывает клиентский запрос и направляет его к новым микросервисам. После переноса всех функций унаследованного монолита унаследованное приложение Monolithic «задушено», то есть выводится из эксплуатации.

Плюсы

• Безопасная миграция монолитного приложения на микросервисы.
• Миграция и разработка новой функциональности могут идти параллельно.
• Процесс миграции может иметь свой темп.

Минусы

• Совместное использование хранилища данных между существующим Monolith и новыми микросервисами становится сложной задачей.
• Добавление фасада (шлюза API) увеличит задержку системы.
• Сквозное тестирование становится трудным.

Когда использовать душитель

• Постепенная миграция большого серверного монолитного приложения на микросервисы.

Когда не использовать Strangler

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

Включение технологий

Фреймворки серверных приложений с API Gateway.

Дополнительная информация

Автоматический выключатель

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

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

Автоматический выключатель может находиться в следующих трех состояниях:

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

Плюсы

• Повышение отказоустойчивости и отказоустойчивости микросервисной архитектуры.
• Останавливает каскадную передачу сбоев другим микросервисам.

Минусы

• Нужна сложная обработка исключений.
• Регистрация и мониторинг.
• Должен поддерживать ручной сброс.

Когда использовать автоматический выключатель

• В тесно связанной микросервисной архитектуре, где микросервисы обмениваются данными синхронно.
• Если один микросервис зависит от нескольких других микросервисов.

Когда не использовать автоматический выключатель

• Слабо связанная микросервисная архитектура, управляемая событиями.
• Если микросервис не зависит от других микросервисов.

Включение технологий

API Gateway, Service Mesh, различные библиотеки автоматических выключателей (Hystrix, Reselience4J, Polly.

Дополнительная информация

Внешняя конфигурация

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

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

Плюсы

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

Минусы

• Нам нужно выбрать фреймворк, поддерживающий внешнюю конфигурацию.

Когда использовать внешнюю конфигурацию

• Любое серьезное производственное приложение должно использовать внешнюю конфигурацию.

Когда не следует использовать внешнюю конфигурацию

• В доказательство разработки концепции.

Включение технологий

Практически все современные фреймворки корпоративного уровня поддерживают внешнюю конфигурацию.

Дополнительная информация

Тестирование контрактов, ориентированных на потребителя

В микросервисной архитектуре существует множество микросервисов, которые часто разрабатываются отдельными группами. Эти микросервисы работают вместе для выполнения бизнес-требований (например, запроса клиента) и взаимодействуют друг с другом синхронно или асинхронно. Интеграционное тестирование микросервиса Потребителя - сложная задача. Обычно в таких сценариях используется TestDouble для более быстрого и дешевого запуска теста. Но TestDouble часто не представляет собой настоящий микросервис провайдера. Кроме того, если микросервис поставщика изменяет свой API или сообщение, TestDouble не может это подтвердить. Другой вариант - провести сквозное тестирование. Хотя сквозное тестирование является обязательным перед производством, оно хрупкое, медленное, дорогое и не может заменить интеграционное тестирование (Пирамида тестирования).

В этом нам может помочь тестирование контрактов, ориентированных на потребителя. Здесь группа владельцев Consumer Microservice пишет набор тестов, содержащий его Request и ожидаемый ответ (для синхронного взаимодействия) или ожидаемые сообщения (для асинхронного взаимодействия) для конкретного Provider Microservice. Эти наборы тестов называются явными контрактами. Для микросервиса провайдера все наборы тестов Контракта его Потребителей добавляются в его автоматизированный тест. Когда выполняется автоматический тест для конкретного микросервиса провайдера, он запускает свои собственные тесты и контракты и проверяет контракт. Таким образом, проверка контракта может помочь в автоматическом поддержании целостности микросервисной связи.

Плюсы

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

Минусы

• Требуется дополнительная работа по разработке и интеграции контрактных тестов в Provider Microservice, поскольку они могут использовать совершенно разные инструменты тестирования.
• Если проверка Контракта не соответствует реальному потреблению Услуг, это может привести к производственному сбою.

Когда использовать тестирование контрактов с учетом требований потребителей

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

Когда не следует использовать тестирование контрактов, ориентированных на потребителя

• Относительно более простые и небольшие приложения, в которых одна команда разрабатывает все микросервисы.
• Если микросервисы провайдера относительно стабильны и не находятся в активной разработке.

Включение технологий

Пакт, Почтальон, Контракт весеннего облака

Дополнительная информация

Заключение

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

Наиболее важным шаблоном проектирования в микросервисной архитектуре является База данных на микросервис. Реализация этого шаблона проектирования является сложной задачей и требует нескольких других тесно связанных шаблонов проектирования (Event Sourcing, CQRS, Saga). В типичных бизнес-приложениях с несколькими клиентами (Интернет, мобильные устройства, настольные компьютеры, интеллектуальные устройства) обмен данными между клиентом и микросервисами может быть частым и может потребовать централизованного управления с дополнительной безопасностью. В таких сценариях очень полезны шаблоны проектирования Backends for Frontend и API Gateway. Кроме того, шаблон Прерыватель цепи может значительно помочь в обработке сценариев ошибок в таких приложениях. Перенос устаревшего приложения Monolithic на микросервисы довольно сложно, и шаблон душитель может помочь в миграции. Тестирование контрактов, ориентированных на потребителя - это инструментальный шаблон для интеграционного тестирования микросервисов. В то же время Внешняя конфигурация является обязательным шаблоном при разработке любого современного приложения.

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

Похожие статьи