[Перевод] Приложение на основе микросервисов на Azure
Azure Service Fabric
Начнем с готовой платформы микросервисов Azure Service Fabric. Она дает возможность разрабатывать и упаковывать надежные масштабируемые микросервисы в контейнерах и вне контейнеров, а также управлять ими. У платформы Service Fabric свыше 300 пользователей, в число которых входят такие компании, как BMW и Schneider Electric.
Кластеры Service Fabric можно подготовить к работе практически в любой среде, например, в общедоступной среде Azure, локальной среде, частном облаке или решении других поставщиков облачных служб. Общедоступная версия Service Fabric работает под управлением ОС Windows, но существует и версия для Linux, доступная для частного предварительного ознакомления. Перейдите по ссылке для получения дополнительных сведений о развертывании Service Fabric на базе Windows Server или Linux.
Помимо основных возможностей платформы, к числу которых относится быстрое развертывание, размещение служб, высокая надежность, высокая плотность, отчеты о работоспособности, скоординированные обновления и обнаружение конечных точек службы для любых типов приложений (Node.js, Java и тому подобное), в Service Fabric поддерживаются модели программирования для создания микросервисов с отслеживанием и без отслеживания состояния. В настоящее время модели программирования доступны для .NET в Windows и для Java в Linux.
Микросервисы Service Fabric с отслеживанием состояния, напротив, сохраняют состояние локально в вычислительных экземплярах. За счет этого снижаются задержки при чтении и записи, а также упрощается общая архитектура, поскольку перемещаемых компонентов становится меньше. Одна из основных целей Service Fabric состоит в том, чтобы поддерживать надежность и согласованность данных. Для этого применяется репликация.
Пример использования микросервисов
Решение для поточной передачи и кодирования TalkTalk изначально было создано по методике Lift and Shift в рамках предложения Azure «инфраструктура как услуга», поскольку так было проще всего перенести все приложение в облако. Тем не менее в условиях непрерывного и быстрого роста бизнеса и появления новых требований разработчики TalkTalk стали внедрять подход на основе микросервисов в некоторых частях своего приложения, используя Azure Service Fabric в качестве платформы.
За счет этого им удалось упростить развертывание служб, получить более гибкие возможности масштабирования каждой службы, а также исключить простои при обновлении отдельных служб. Приложение на основе микросервисов также хорошо интегрируется с Azure Media Services и Azure Batch.
На рисунке показана общая архитектура приложения на основе микросервисов и ход обработки запроса на кодирование в таком приложении.
Ниже приводится описание роли каждого микросервиса при обработке запроса:
Шаг 1. Клиент TalkTalk вызывает метод EncodeRequest, доступный для веб-API Activity посредством API управления Azure.
Шаг 2. Веб-API Activity без отслеживания состояния представляет собой прослушиватель на основе Open Web Interface для .NET (OWIN). В нем размещен контроллер API, предоставляющий возможность создавать новые запросы кодирования. Службы за пределами Service Fabric используют этот API для внешнего взаимодействия. Он получает вызовы от службы управления API.
Шаг 3. Микросервис Activity с отслеживанием состояния использует API надежной очереди в Service Fabric для входящей работы. Затем этот микросервис создает субъект действия, представляющий работу кодирования, которую необходимо выполнить.
Шаг 4. Микросервис ActivityActor представляет список рабочих элементов для отслеживания выполнения каждого шага и для создания субъектов действия каждого шага. Создаваемые субъекты отслеживают состояние, поэтому даже при сбоях данные не теряются за счет их репликации.
Шаг 5. Микросервис ActivityStepActor координирует этапы работы. Работа выполняется в других приложениях Service Fabric. Например, приложение для управления заданиями шифрования использует Azure Batch для выполнения настраиваемого шага шифрования, необходимого для абонентских приставок TalkTalk. Само приложение для управления заданиями шифрования содержит множество микросервисов и инкапсулирует необходимые взаимодействия Azure Batch. Субъект шага действия обменивается данными с соответствующими службами с помощью прокси-сервера служб, предоставляемого платформой Service Fabric.
Микросервис ActivityStep без отслеживания состояния предоставляет доступ к Service Communication Listener, поэтому другие службы Service Fabric, такие как приложение для управления заданиями Azure Media Services (AMS) (шаг 6) и приложение для управления заданиями шифрования (шаг 7), могут взаимодействовать с шагами действий. Такой принцип работы похож на обратные вызовы: например, когда служба Batch завершает работу, необходимо обратиться к ActivityStepActor для завершения или обновления этапа работы.
В ходе этого процесса напоминание о каждом субъекте используется для периодического сохранения состояния субъекта в DocumentDB. Это делается для двух целей: во-первых, чтобы предоставить возможность выполнения произвольных запросов, во-вторых, чтобы организовать защиту и резервное копирование данных вне платформы Service Fabric.
Подробное описание приложения TalkTalk на основе микросервисов доступно здесь.
Azure Container Service
Azure Container Service (ACS) — еще одна служба Azure, дающая возможность развертывать и запускать приложения на основе микросервисов. В число пользователей ACS входят компании Avanade, ESRi и CloudBees.
Основная функциональность ACS позволяет создать кластер для управления контейнерными нагрузками, применяя DC/OS или SWARM в качестве оркестратора. С точки зрения микросервисов вы отвечаете за выбор средств обнаружения и регистрации служб, обмена информацией, мониторинга и тому подобное. В этом также заключается основное отличие от платформы Service Fabric, возможности которой выходят за рамки кластера и оркестратора и включают интегрированные услуги, в том числе регистрацию и обнаружение служб, а также модели программирования.
Преимущества ACS
Начнем с очевидного: использование технологий программного обеспечения с открытым исходным кодом (OSS). Если учесть, что ACS использует Docker Swarm и Mesosphere DC/OS, то к вашим услугам все ресурсы сообщества OSS, доступные для этих двух технологий. Поскольку эти технологии доступны на рынке уже давно, вы с легкостью найдете пошаговые руководства, учебные материалы, фрагменты кода и даже готовые решения для практически любых сценариев.
Еще одно преимущество заключается в простоте настройки кластера и управления им с помощью Azure. Тем из вас, кому приходилось настраивать кластер DC/OS или Docker Swarm на «голом железе» или на виртуальных машинах, хорошо известно, что для этого требуется намного больше, чем просто подключить несколько машин друг к другу. Также нужно настроить различные дополнительные компоненты и службы, предоставить доступ к конечным точкам, связать агенты с подсистемой балансировки нагрузки и т. д. Чтобы автоматизировать настройку такого кластера, придется написать достаточно объемный сценарий. ACS упрощает настройку кластера за счет применения шаблонов и абстрагирования всех этапов настройки.
Впрочем, настройка кластера машин с оркестратором — это лишь полдела. После настройки и запуска кластера может потребоваться установить исправления на машины в составе этого кластера или обновить их до более поздней версии SWARM и DC/OS. Для таких задач обычно требуется тщательное планирование. В будущем ACS будет поддерживать полностью управляемую инфраструктуру, чтобы разработчики могли сосредоточиться только на рабочих нагрузках в кластере, не тратя время на задачи, связанные с управлением инфраструктурой.
Подготовить кластер к работе можно либо на портале Azure, либо автоматически с помощью шаблона диспетчера ресурсов Azure в рамках подхода «инфраструктура как услуга». Нужно будет предоставить только следующие значения:
- orchestratorProfile — оркестратор, который нужно использовать (DCOS или Swarm);
- masterProfile — количество главных узлов и префикс DNS;
- agentPoolProfiles — количество узлов агентов, размер узлов и префикс DNS;
- linuxProfile — имя пользователя и ключ SSH для подключения к узлам.
В приведенном ниже фрагменте показан код JSON шаблона диспетчера ресурсов Azure для ACS.
"resources”: [
{
"apiVersion”: "2016–03–30”,
"type”: "Microsoft.ContainerService/containerServices”,
"location”: "[resourceGroup().location]”,
"name”:”[concat(‘containerservice-’,resourceGroup().name)]”,
"properties”: {
"orchestratorProfile”: {
"orchestratorType”: "[variables(‘orchestratorType’)]”
},
"masterProfile”: {
"count”: "[variables(‘masterCount’)]”,
"dnsPrefix”: "[variables(‘mastersEndpointDNSNamePrefix’)]”
},
"agentPoolProfiles”: [
{
"name”: "agentpools”,
"count”: "[variables(‘agentCount’)]”,
"vmSize”: "[variables(‘agentVMSize’)]”,
"dnsPrefix”: "[variables(‘agentsEndpointDNSNamePrefix’)]”
}
],
"linuxProfile”: {
"adminUsername”: "[variables(‘adminUsername’)]”,
"ssh”: {
"publicKeys”: [
{
"keyData”: "[variables(‘sshRSAPublicKey’)]”
}
]
}
}
}
}В результате вы получаете полностью настроенный кластер DC/OS или Docker Swarm, в котором можно развертывать приложения. На рисунке показаны выходные данные полностью настроенного кластера ACS на основе DC/OS.
Помимо развертывания, служба ACS интегрируется с масштабируемыми наборами виртуальных машин (VMSS), которые будут поддерживать простое автоматическое масштабирование и установку исправлений для всего оркестратора и всей инфраструктуры. Как сказано выше, в ACS можно развертывать и запускать совершенно любые приложения на основе микросервисов. За счет этого при развертывании с помощью ACS достигается очень высокая гибкость возможностей. Для запуска приложений на основе микросервисов можно использовать любые решения под управлением DC/OS или Docker Swarm, которые вы стали бы использовать в других средах.
Рассмотрим пример приложения на основе микросервисов, где в качестве оркестратора используется DC/OS в службе контейнеров Azure. Flak.io — пример приложения для электронной коммерции, созданный специально для демонстрации возможностей микросервисов. Это приложение:
- использует разные технологии,
- соблюдает разные требования к масштабу и доступности для каждой службы,
- хранит данные отдельно для каждой службы,
- использует возможности регистрации и обнаружения служб DC/OS.
С точки зрения пользователя, это приложение позволяет просматривать товары в каталоге и покупать их.
Приложение состоит из четырех основных служб и службы интерфейса:
- Интерфейс реализован в виде AngularJS SPA, предоставляет целевую страницу для Flakio.
- Служба каталога отвечает за управление информацией о товарах.
- Служба заказов отвечает за обработку заказов. Следует отметить, что модель товаров, используемая в службе заказов, отличается от модели товаров в службе каталога, поскольку она относится к другому контексту.
- Служба рекомендаций подготавливает рекомендации, анализируя историческую информацию и данные реального времени.
- Служба уведомлений отвечает за отправку уведомлений по электронной почте, а также за хранение шаблонов электронных писем и управление ими.
На рисунке показана общая архитектура Flak.io.
Исходный код Flak.io доступен на GitHub.
Примечание. Проект Flak.io еще не закончен. Продолжается работа над хранением записей о событиях, созданием служб рекомендаций и уведомлений, но в целом это приложение позволит получить достаточно полное представление о проектировании и развертывании контейнерного приложения на основе микросервисов в ACS.
Итоги
В этой публикации мы рассмотрели два примера архитектур микросервисов: для Service Fabric и для службы контейнеров Azure. В целом Service Fabric можно рассматривать как готовое решение для создания приложений на основе микросервисов, в котором служба контейнеров Azure поможет быстро настроить кластер и управлять инфраструктурой, используя DC/OS или SWARM, чтобы разработчики могли полностью сосредоточиться на написании кода. После подготовки кластера ACS можно использовать любые удобные технологии для приложений на основе микросервисов, а также возможности постоянно растущих сообществ Docker и Mesoshpere.
Полезные мероприятия
Если вам мало статей и хотелось бы пообщаться удалённо или лично со мной или коллегами на тему создания микросервисных и других решений в Azure, приходите к нам на следующие меропрития.
- 11 апреля, вебинар. Новые подходы в облачной архитектуре: контейнеры и микросервисы (требуется регистрация)
- 19 апреля, Москва, митап. Микросервисы в Azure (требуется регистрация через meetup.com)
- 21–23 апреля, Москва, DevCon School. Современная архитектура (требуется регистрация)
Если вы дочитали до этого места и хотите на DevCon School: Современная архитектура, но у вас нет промо-кода, напишите мне лично сообщение с объяснением, зачем вы хотите туда попасть. У меня, как обычно, для читателей Habra есть несколько промо-кодов.
Полезные ссылки
- Начало работы с Service Fabric
- Service Fabric бесплатно с использованием кластеров Party Clusters
- Служба контейнеров Azure
- Развертывание и запуск приложений на основе микросервисов в ACS
Комментарии (7)
novoxudonoser
10 апреля 2017 в 20:31
–3↑
↓
Вот мне интересно, может ли случиться такая в мире радость что некрософт наконец таки закончит свой жизненный цикл?10 апреля 2017 в 21:13
0↑
↓
расскажите лучше про SNAT, про лимит в 160 портов, про другие оверхеды, с которым приходится сталкиваться, при запросах по локальной сети
stasus
10 апреля 2017 в 21:50
0↑
↓
Как мне кажется, 160 портов, это было несколько лет назад.
https://docs.microsoft.com/ru-ru/azure/load-balancer/load-balancer-outbound-connections
Хотя это не гарантируется, максимальное количество доступных SNAT-портов на сегодня составляет 64 511 (65 535 — 1024 привилегированных портов).
10 апреля 2017 в 22:39
0↑
↓
месяц еще не прошел, как саппорт подтвердил, что этот лимит действует все еще-
stasus
10 апреля 2017 в 23:06
0↑
↓
Хм. Это максимум. В доке по ссылке описываются, в том числе, разнообразное случаи, когда это может быть не так Если можно, опишите вашу задачу, где вы столкнулись с этим ограничением. Можно в личку.
10 апреля 2017 в 21:40
+1↑
↓
Картинки слишком мелкие-
stasus
10 апреля 2017 в 21:40
0↑
↓
Это перевод. Они взяты из исходного текста.
