Контейнерные микрослужбы

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

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

Микрослужбы

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

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

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

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

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

Поэтому приложения микрослужб имеют множество преимуществ по сравнению с монолитными приложениями:

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

Однако решение на основе микрослужб также имеет потенциальные недостатки:

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

Контейнеризация

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

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

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

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

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

Основные понятия при создании и работе с контейнерами:

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

Приложение для ссылок eShop использует Docker для размещения четырех контейнерных микрослужб, как показано на схеме ниже.

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

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

Обмен данными между клиентами и микрослужбами

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

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

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

Взаимодействие между микрослужбами

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

Два распространенных подхода к обмену данными с микрослужбами — это взаимодействие REST на основе HTTP при запросе данных и упрощенное асинхронное обмен сообщениями при обмене обновлениями между несколькими микрослужбами.

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

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

С точки зрения приложения шина событий — это просто канал публикации подписки, предоставляемый через интерфейс. Однако способ реализации шины событий может отличаться. Например, реализация шины событий может использовать RabbitMQ, Служебная шина Azure или другие служебные автобусы, такие как NServiceBus и MassTransit. На схеме ниже показано, как используется шина событий в справочном приложении eShop.

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

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

Итоги

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

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