Микросервисная архитектура или микросервисы – термин, введенный лидерами в области разработки программного обеспечения Мартином Фаулером и Джеймсом Льюисом в 2014 году. Это организационный метод разработки программного обеспечения, при котором приложение строится из модульных компонентов или независимых сервисов, взаимодействующих через четко определенные API (сокращ. от англ. программный интерфейс приложения). Каждый модуль поддерживает определенную задачу и использует простой, четко определенный интерфейс.

Как работают микросервисы?

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

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

Для чего используется микросервисная архитектура?

Обычно микросервисы используются для ускорения разработки приложений. Их также часто сравнивают с сервис-ориентированной архитектурой. У обоих одна и та же цель – разбить монолитное приложение на более мелкие компоненты, но у них разные подходы. Вот несколько примеров микросервисных архитектур:

Миграция сайта

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

Медиаконтент

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

Транзакции и счета

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

Обработка данных

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

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

Шлюзы API

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

Депозиция

Разработчики могут применять декомпозицию двумя основными способами:

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

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

Шаблон источника событий

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

Шаблон обнаружения службы

Существует два основных типа шаблонов обнаружения служб:

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

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

Шаблон агрегатора

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

- шлюз API разделяет запрос на несколько микросервисов и объединяет данные для отправки потребителю;

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

База данных или общие данные

Существует два основных подхода к архитектуре баз данных для микросервисов:

- База данных для каждой службы. При таком подходе у каждой микрослужбы есть собственная база данных, доступная только для этой службы. Доступ к ней возможен только через API микрослужбы.

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

Характеристика микросервисной архитектуры

Архитектура микросервисов состоит из отдельных компонентов и сервисов; их взаимосвязь и обмен данными создают функции законченного приложения. Типичные характеристики архитектуры микросервисов включают следующее:

Уникальность. Можно спроектировать и развернуть сервисы для выполнения определенной функции или удовлетворения конкретных требований.

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

Устойчивость. Услуги проектирования для обеспечения максимальной отказоустойчивости. Сбой одной службы не отключает все приложение.

API. Архитектура микросервисов в значительной степени зависит от API и шлюзов API для облегчения связи.

Разделение данных. В идеале каждая служба обращается к своей собственной базе данных или тому хранилища.

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

Использование микросервисной архитектуры при разработке приложений может быть очень полезным. Ниже представлены некоторые основные её преимущества:

1. Меньше времени на разработку

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

2. Независимое развертывание

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

3. Улучшенная изоляция сбоев

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

4. Смешанный технологический стек

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