Моделирование приложения в Service Fabric

В этой статье представлен обзор модели приложения Azure Service Fabric и определение приложения и службы с помощью файлов манифеста.

Общие сведения о модели приложения

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

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

Классы (или типы) приложений и служб описываются с помощью XML-файлов (манифестов приложений и манифестов служб). Манифесты описывают приложения и службы и служат шаблонами, по которым приложения могут создаваться из хранилища образов кластера. Манифесты подробно рассматриваются в манифестах приложений и служб. Определение схемы для файлов ServiceManifest.xml и ApplicationManifest.xml устанавливается вместе с пакетом SDK и инструментами Service Fabric в C:\Program Files\Microsoft SDKs\Service Fabric\schemas\ServiceFabricServiceModel.xsd. XML-схема описана в документации схемы ServiceFabricServiceModel.xsd.

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

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

На следующей диаграмме отображается отношение между приложениями и экземплярами службы, разделами и репликами.

Подсказка

Макет приложений в кластере можно просмотреть с помощью средства Service Fabric Explorer, доступного в http://< yourclusteraddress>:19080/Explorer. Дополнительные сведения см. в статье Визуализация кластера с помощью Service Fabric Explorer.

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

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