Поделиться через

Общие сведения о терминологии Service Fabric

  • Статья

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

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

Основные понятия для инфраструктуры

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

Узел — компьютер или виртуальная машина, которая входит в состав кластера. Каждому узлу назначается имя (строка). Узлы имеют свои характеристики, в частности свойства размещения. Каждый компьютер или виртуальная машина имеет автоматически запускаемую службу Windows FabricHost.exe. Она запускается после загрузки системы и запускает два исполняемых файла: Fabric.exe и FabricGateway.exe. Эти два файла формируют узел. В целях тестирования на одном компьютере или виртуальной машине можно разместить несколько узлов, запустив несколько экземпляров Fabric.exe и FabricGateway.exe.

Концепции приложения и службы

Собственное приложение Service Fabric: собственные приложения Service Fabric описаны в модели собственных приложений (приложения на основе XML и манифесты служб).

Концепции собственных приложений Service Fabric

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

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

Тип приложения — имя и версия, назначенные коллекции типов служб. Он определен в файле ApplicationManifest.xml и внедрен в каталоге пакета приложения. Затем этот каталог копируется в хранилище образов кластера Service Fabric. Из этого типа приложения в кластере можно создать именованное приложение.

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

Пакет приложения — каталог на диске, в котором хранится файл типа приложения ApplicationManifest.xml. В этом файле указаны ссылки на пакеты служб, типы которых определяют тип приложения. Файлы в каталоге пакета приложения копируются в хранилище образов кластера Service Fabric. Например, пакет почтового приложения может содержать ссылки на пакет службы очередей, пакет службы внешнего интерфейса и пакет службы базы данных.

Именованное приложение. После копирования пакета приложения в хранилище образов можно создать экземпляр приложения в пределах кластера. Создайте экземпляр при указании типа приложения пакета приложения, используя его имя или версию. Каждому экземпляру приложения этого типа назначается универсальный код ресурса (URI), который выглядит следующим образом: "fabric:/MyNamedApp". Из одного типа приложения в кластере можно создать несколько именованных приложений. Именованные приложения можно также создавать из разных типов приложений. Для каждого именованного приложения управление и контроль версий выполняются отдельно.

Тип службы — имя и версия, назначенные пакетам кода, пакетам данных и пакетам конфигураций службы. Тип службы определен в файле ServiceManifest.xml и внедрен в каталог пакета службы. Затем на каталог пакета службы ссылается файл пакета приложения ApplicationManifest.xml. Создав именованное приложение, вы можете создать в кластере именованную службу, используя для этого один из типов служб соответствующего типа приложения. Файл типа службы, ServiceManifest.xml, содержит ее описание.

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

Существует два типа служб.

  • Без отслеживания состояния. Служба без отслеживания состояния используется, когда устойчивое состояние службы хранится во внешней службе хранилища, например в службе хранилища Azure, Базе данных SQL Azure или Azure Cosmos DB. Службу без отслеживания состояния следует использовать, когда у службы нет постоянного хранилища. Примером может быть служба калькулятора: в службу передаются значения, служба выполняет вычисления с использованием этих значений и возвращает результат.
  • С отслеживанием состояния. Служба с отслеживанием состояния используется, когда нужно, чтобы платформа Service Fabric управляла состоянием службы через модели программирования Reliable Collections или Reliable Actors. При создании именованной службы укажите количество секций, на которые вы хотите распределить состояние (для масштабируемости). Укажите также, сколько раз следует реплицировать состояние между узлами (для обеспечения надежности). У каждой именованной службы есть одна первичная реплика и несколько вторичных. Изменение состояния именованной службы происходит при записи в первичную реплику. Затем Service Fabric реплицирует это состояние во все вторичные реплики, чтобы синхронизировать состояние. Service Fabric автоматически обнаруживает, когда происходит сбой первичной реплики, и повышает уровень существующей вторичной реплики до первичной. После этого Service Fabric создает новую вторичную реплику.

Реплики или экземпляры относятся к коду (и состоянию для служб с отслеживанием состояния) службы, которая развернута и запущена. Ознакомьтесь с разделом Реплики и экземпляры.

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

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

Именованная служба. Создав именованное приложение, можно создать в кластере экземпляр одной из его служб определенного типа. Укажите тип службы, используя его имя или версию. Каждому экземпляру службы определенного типа назначается код URI, частью которого будет URI именованного приложения. Например, если в именованном приложении MyNamedApp вы создадите именованную службу MyDatabase, то ее универсальный код ресурса (URI) будет выглядеть так: "fabric:/MyNamedApp/MyDatabase". В именованном приложении можно создать несколько именованных служб. У каждой именованной службы может быть своя схема секционирования и свое количество реплик или экземпляров.

Пакет кода — каталог на диске, в котором хранятся исполняемые файлы службы определенного типа (обычно файлы EXE или DLL). Ссылки на файлы из каталога пакетов кода указываются в файле ServiceManifest.xml для соответствующего типа службы. При создании именованной службы пакет кода копируется на один или несколько узлов, выбранных для запуска этой службы. Затем код запускается. Существует два типа исполняемых файлов для пакетов кода.

  • Гостевые исполняемые файлы — исполняемые файлы, выполняющиеся "как есть" в операционной системе сервера виртуальных машин (Windows или Linux). Эти исполняемые файлы никак не связаны с файлами среды выполнения Service Fabric, поэтому они не используют ни одну из моделей программирования Service Fabric. Эти исполняемые файлы не могут использовать некоторые возможности Service Fabric, в том числе службу именования для обнаружения конечных точек. Гостевые исполняемые файлы не могут сообщать о метриках нагрузки, относящихся к каждому экземпляру службы.
  • Исполняемые файлы узла службы — исполняемые файлы, использующие модели программирования Service Fabric. Они создают связи с файлами среды выполнения Service Fabric и позволяют использовать возможности Service Fabric. Например, экземпляр именованной службы может регистрировать конечные точки в службе именования Service Fabric и передавать показатели нагрузки.

Пакет данных — каталог на диске, в котором хранятся статические файлы данных службы определенного типа, предназначенные только для чтения (обычно фотографии, аудио и видео). Ссылки на файлы из каталога пакетов данных указываются в файле ServiceManifest.xml для соответствующего типа службы. При создании именованной службы пакет данных копируется на один или несколько узлов, выбранных для запуска этой службы. После этого начинается выполнение кода, и теперь у него имеется доступ к файлам данных.

Пакет конфигурации — каталог на диске, в котором хранятся статические файлы конфигурации службы определенного типа, предназначенные только для чтения (обычно текстовые файлы). Ссылки на файлы из каталога пакетов конфигураций указываются в файле ServiceManifest.xml для соответствующего типа службы. При создании именованной службы файлы из пакета конфигурации копируются на один или несколько узлов, выбранных для запуска этой службы. Затем начинается выполнение кода, и теперь у него имеется доступ к файлам конфигурации.

Контейнеры — по умолчанию Service Fabric развертывает и активирует службы как процессы. Service Fabric также позволяет развертывать службы в образах контейнеров. Контейнеры — это технология виртуализации, которая представляет базовую операционную систему в приложениях. Приложение, его среда выполнения, зависимости и системные библиотеки выполняются внутри контейнера. Контейнер имеет полный частный доступ к собственному изолированному представлению конструкций операционной системы. Service Fabric поддерживает контейнеры Docker и контейнеры Windows Server в Linux. Дополнительные сведения см. в статье Service Fabric и контейнеры (предварительная версия).

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

Дополнительные сведения см. в статье Секционирование служб Reliable Services в Service Fabric.

Системные службы

Существуют системные службы, которые создаются в каждом кластере и предоставляют возможности платформы Service Fabric.

Служба именования. У каждого кластера Service Fabric есть служба именования, которая разрешает имена службы в определенные расположения в кластере. Вы можете управлять именами и свойствами служб так же, как и служба доменных имен (DNS) для кластера. Используя службу именования для разрешения имени службы в ее расположение, клиенты могут безопасно обмениваться данными с любым узлом в кластере. Приложения перемещаются в кластере. Это может быть из-за сбоев, балансировки ресурсов или изменения размера кластера. Вы можете разрабатывать службы и клиенты, которые разрешают текущее сетевое расположение. Клиенты получают фактические IP-адрес и порт компьютера, на котором она запущена.

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

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

Дополнительные сведения о службе хранилища образов см. в разделе Общие сведения о параметре ImageStoreConnectionString.

Дополнительные сведения о развертывании приложений в службе хранилища образов см. в статье Развертывание и удаление приложений с помощью PowerShell.

Служба диспетчера отработки отказов. На каждом кластере Service Fabric имеется служба диспетчера отработки отказов, которая:

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

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

Модели развертывания и приложения

Чтобы развернуть свои службы, необходимо описать их запуск. Service Fabric поддерживает три разные модели развертывания.

Собственная модель

Собственная модель приложения предоставляет приложениям полный низкоуровневый доступ к Service Fabric. Приложения и службы определяются как зарегистрированные типы в XML-файлах манифеста.

Собственная модель поддерживает платформу Reliable Services и Reliable Actors, которая предоставляет доступ к интерфейсам API среды выполнения Service Fabric и интерфейсам API управления кластерами в средах C# и Java. Собственная модель также поддерживает произвольные контейнеры и исполняемые файлы.

Reliable Services — API для создания служб без отслеживания и с отслеживанием состояния. Служба с отслеживанием состояния хранит сведения о своем состоянии в коллекциях Reliable Collections (например, словарь или очередь). Кроме того, вы можете использовать разнообразные коммуникационные стеки (например, веб-API и Windows Communication Foundation (WCF)).

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

Также в Service Fabric можно выполнять существующие приложения:

Контейнеры. Service Fabric поддерживает развертывание контейнеров Docker в Linux и контейнеров Windows Server в Windows Server 2016, а также режим изоляции Hyper-V. В модели приложенияService Fabric контейнер представляет собой узел приложения, в котором размещается несколько реплик службы. В Service Fabric можно запускать все контейнеры. Сценарий аналогичен сценарию с готовым исполняемым файлом, при котором вы упаковываете существующее приложение внутри контейнера. Кроме того, внутри контейнеров можно выполнять службы Service Fabric.

Гостевые исполняемые файлы. В Azure Service Fabric можно запустить как службу приложение любого типа, в том числе приложения Node.js, Python, Java или C++. В Service Fabric такие типы служб называются гостевыми исполняемыми файлами и обрабатываются как службы без отслеживания состояния. Преимущества запуска гостевого исполняемого файла в кластере Service Fabric — высокий уровень доступности, мониторинг работоспособности, управление жизненным циклом приложений, высокая плотность и возможность обнаружения.

Дополнительные сведения см. в статье Общие сведения о модели программирования Service Fabric.

Docker Compose

Docker Compose является частью проекта Docker. Service Fabric предоставляет ограниченную поддержку развертывания приложений с помощью модели Docker Compose.

Среды

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

  • Azure Service Fabric: предложение кластера Azure Service Fabric. Он обеспечивает интеграцию Service Fabric и инфраструктуры Azure, а также обновление и управление конфигурацией кластеров Service Fabric.
  • Изолированная служба Service Fabric: набор инструментов для установки и настройки для развертывания кластеров Service Fabric в любой среде (в локальной среде или среде любого поставщика облачных служб). Эта служба управляется Azure.
  • Кластер разработки Service Fabric: предоставляет локальную среду разработки на основе Windows, Linux или Mac для разработки приложений Service Fabric.

Следующие шаги

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