Масштабирование в Service Fabric

Статья
2025-04-02

Azure Service Fabric упрощает создание масштабируемых приложений путем управления службами, секциями и репликами на узлах кластера. Выполнение нескольких рабочих нагрузок на одном оборудовании обеспечивает максимальное использование ресурсов, но также обеспечивает гибкость с точки зрения масштабирования рабочих нагрузок. В этом видео канала 9 описывается, как создавать масштабируемые приложения микрослужб:

Масштабирование в Service Fabric выполняется несколькими разными способами.

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

Масштабирование путем создания или удаления экземпляров службы без отслеживания состояния

Один из самых простых способов масштабирования в Service Fabric работает с беззащитными службами. При создании службы без отслеживания состояния вы получите возможность определить InstanceCount. InstanceCount определяет, сколько исполняемых копий кода этой службы создается при запуске службы. Предположим, что в кластере есть 100 узлов. Предположим также, что создается служба с параметром InstanceCount равным 10. Во время выполнения эти 10 запущенных копий кода могут оказаться слишком занятыми (или не могут быть достаточно заняты). Одним из способов масштабирования этой рабочей нагрузки является изменение количества экземпляров. Например, некоторый фрагмент кода мониторинга или управления может изменить существующее количество экземпляров на 50 или 5, в зависимости от того, требуется ли масштабирование в зависимости от нагрузки.

C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell.

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

Использование динамического числа экземпляров

Специально для служб без отслеживания состояния Service Fabric предлагает автоматический способ изменения количества экземпляров. Это позволяет службе динамически масштабироваться с количеством доступных узлов. Способ выбрать это поведение — задать число экземпляров = -1. InstanceCount = -1 — это инструкция Service Fabric, которая означает: "Запустить эту бездеятельную службу на всех узлах". Если количество узлов изменяется, Service Fabric автоматически изменяет количество экземпляров, чтобы убедиться, что служба выполняется на всех допустимых узлах.

C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell.

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

Масштабирование путем создания или удаления новых именованных служб

Именованный экземпляр службы — это конкретный экземпляр типа службы (см. жизненный цикл приложения Service Fabric) в одном именованном экземпляре приложения в кластере.

Новые именованные экземпляры служб можно создавать (или удалять), так как службы становятся более или менее занятыми. Это позволяет распределять запросы по нескольким экземплярам служб, обычно позволяя уменьшить нагрузку на существующие службы. При создании служб диспетчер кластерных ресурсов Service Fabric размещает службы в кластере распределённым образом. Точные решения управляются метриками в кластере и другими правилами размещения. Службы могут создаваться различными способами, но наиболее распространенными являются административные действия, такие как кто-то вызывает New-ServiceFabricService, или посредством вызова кода CreateServiceAsync. CreateServiceAsync можно вызывать даже из других служб, работающих в кластере.

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

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

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

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

Масштабирование путем создания или удаления новых именованных экземпляров приложений

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

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

Новый экземпляр приложения предназначен для клиента, код которого должен выполняться в определенных параметрах удостоверения или безопасности.
- Service Fabric позволяет определять различные пакеты кода для выполнения с определенными идентификациями. Чтобы запустить один и тот же пакет кода под разными учетными записями, активации должны происходить в разных экземплярах приложения. Рассмотрим ситуацию, когда рабочие нагрузки существующего клиента уже развернуты. Они могут работать под определенным удостоверением, чтобы отслеживать и контролировать доступ к другим ресурсам, например, базам данных на удаленных серверах или другим системам. В этом случае, когда регистрируется новый клиент, вы, вероятно, не захотите активировать их код в том же контексте (пространстве процессов). Хотя это возможно, такой подход затрудняет выполнение кода службы в контексте определенной личности. Обычно требуется больше безопасности, изоляции и кода управления удостоверениями. Вместо использования разных именованных экземпляров служб в одном экземпляре приложения и, следовательно, в одном пространстве обработки можно использовать разные именованные экземпляры приложений Service Fabric. Это упрощает определение различных контекстов идентичности.
Новый экземпляр приложения также служит средством настройки
- По умолчанию все именованные экземпляры службы определенного типа службы в экземпляре приложения будут выполняться в одном процессе на определенном узле. Это означает, что хотя вы можете настроить каждый экземпляр службы по-разному, но сделать это сложно. Службы должны иметь какой-то маркер, который они используют для поиска конфигурации в пакете конфигурации. Обычно это просто имя службы. Это работает хорошо, но оно связывает конфигурацию с именами отдельных именованных экземпляров служб в этом экземпляре приложения. Это может быть запутано и трудно управлять, так как конфигурация обычно является артефактом времени разработки с определенными значениями экземпляра приложения. Создание дополнительных служб всегда означает больше обновлений приложений, чтобы изменить сведения в пакетах конфигурации или развернуть новые, чтобы новые службы могли искать конкретные сведения. Часто проще создать новый именованный экземпляр приложения. Затем можно использовать параметры приложения для задания любой конфигурации, необходимой для служб. Таким образом, все службы, созданные в этом именованном экземпляре приложения, могут наследовать определенные параметры конфигурации. Например, вместо одного файла конфигурации с параметрами и настройками для каждого клиента, таких как секреты или ограничения ресурсов клиента, вместо этого у каждого клиента будет другой экземпляр приложения с переопределенными параметрами.
Новое приложение служит границей обновления
- В Service Fabric разные именованные экземпляры приложений служат границами для обновления. Обновление одного именованного экземпляра приложения не повлияет на код, выполняемый другим именованным экземпляром приложения. В разных приложениях будут работать разные версии одного и того же кода на одном узле. Это может быть фактором, когда необходимо принять решение о масштабировании, так как вы можете выбрать, должен ли новый код выполнять те же обновления, что и другая служба. Например, предположим, что вызов поступает в службу диспетчера, которая отвечает за масштабирование рабочих нагрузок конкретного клиента путем динамического создания и удаления служб. Однако в этом случае вызов предназначен для рабочей нагрузки, связанной с новым клиентом. Большинство клиентов предпочитают быть изолированными друг от друга не только по причинам безопасности и конфигурации, перечисленным ранее, но и потому что это обеспечивает большую гибкость с точки зрения выполнения определенных версий программного обеспечения и выбора времени их обновления. Вы также можете создать новый экземпляр приложения и создать там службу для того, чтобы дополнительно разделить объём ваших служб, к которым будет применяться любое одно обновление. Отдельные экземпляры приложений обеспечивают большую степень детализации при обновлении приложений, а также позволяют проводить A/B тестирование и развертывание Blue/Green.
Существующий экземпляр приложения заполнен
- В Service Fabric емкость приложения — это концепция, которую можно использовать для управления объемом ресурсов, доступных для конкретных экземпляров приложений. Например, можно принять решение о создании другого экземпляра для масштабирования данной службы. Однако этот экземпляр приложения не имеет емкости для определенной метрики. Если этот конкретный клиент или рабочая нагрузка по-прежнему должны предоставляться больше ресурсов, можно либо увеличить существующую емкость для этого приложения, либо создать новое приложение.

Масштабирование на уровне раздела

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

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

Макет раздела с тремя узлами

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

Макет раздела с четырьмя узлами

Масштабирование с помощью Диспетчера кластерных ресурсов Service Fabric и метрик

Метрики — это то, как службы выражают потребление ресурсов в Service Fabric. Использование метрик дает диспетчеру кластерных ресурсов возможность переорганизовать и оптимизировать макет кластера. Например, в кластере может быть много ресурсов, но они могут не быть выделены службам, которые в настоящее время выполняют работу. Использование метрик позволяет диспетчеру кластерных ресурсов переорганизовать кластер, чтобы обеспечить доступ служб к доступным ресурсам.

Масштабирование путем добавления и удаления узлов из кластера

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

Дополнительные сведения см. в статье о масштабировании кластера.

Выбор платформы

Из-за различий в реализации между операционными системами, выбор использования Service Fabric с Windows или Linux может быть важной частью масштабирования приложения. Одним из потенциальных барьеров является то, как выполняется поэтапная рубка леса. Service Fabric в Windows использует драйвер ядра для журнала, который общий для всех машин и используется совместно репликами служб с отслеживанием состояния. Этот журнал весит около 8 ГБ. С другой стороны, в Linux используется промежуточный журнал 256 МБ для каждой реплики, что делает его менее идеальным для приложений, которые хотят максимально увеличить количество реплик облегченных служб, работающих на определенном узле. Эти различия во временных требованиях к хранилищу могут оказать влияние на выбор платформы для развертывания кластера Service Fabric.

Собираем всё воедино

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

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

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

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

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

Этот шаблон динамического создания имеет множество преимуществ:

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

Дальнейшие действия

Дополнительные сведения о концепциях Service Fabric см. в следующих статьях: