Моделирование приложения в структуре службы
В этой статье приведен обзор модели приложений Azure Service Fabric и описывается, как определить приложение и службу с помощью файлов манифеста.
Сведения о модели приложения
Приложение представляет собой коллекцию составляющих его служб, которые выполняют определенные функции. Служба выполняет завершенную и отдельную функцию и может запускаться и работать независимо от других служб. Она состоит из кода, конфигурации и данных. Для каждой службы код состоит из исполняемых двоичных файлов, конфигурация состоит из параметров службы, которые могут быть загружены во время выполнения, а данные состоят из произвольных статических данных, которые должны обрабатываться рассматриваемой службой. Каждый компонент в этой иерархической модели приложения может иметь свою версию и обновляться независимо.
Тип приложения представляет собой отнесение приложения к определенной категории и состоит из пакета типов служб. Тип службы представляет собой отнесение службы к определенной категории, которая может обладать различными параметрами и конфигурациями, однако ее основная функция не изменяется. Экземпляры службы представляют собой различные вариации конфигурации служб, принадлежащих к одному типу.
Классы (или типы) приложений и служб описываются с помощью XML-файлов (манифесты приложений и служб). Манифесты описывают приложения и службы. Это шаблоны, по которым создаются экземпляры приложений из хранилища образов кластера. См. дополнительные сведения о манифестах приложений и служб. Определение схемы для файла ServiceManifest.xml и ApplicationManifest.xml устанавливается с пакетом SDK и средствами для Service Fabric по адресу C:\Program Files\Microsoft SDKs\Service Fabric\schemas\ServiceFabricServiceModel.xsd. См. документацию по схеме ServiceFabricServiceModel.xsd.
Код для различных экземпляров приложений выполняется в виде отдельных процессов, даже если они размещены на одном узле Service Fabric. Кроме того, возможно независимое управление жизненным циклом (например, обновление). На следующей диаграмме показано, что типы приложений состоят из типов служб, которые, в свою очередь, состоят из кода, конфигурации и пакетов данных. Чтобы упростить схему, показаны только пакеты кода, конфигурации или данных для ServiceType4, хотя каждый тип службы будет включать некоторые или все из этих типов пакетов.
В кластере может работать один или несколько экземпляров службы определенного типа. Например, в экземплярах служб с отслеживанием состояния или в репликах достигается высокий уровень доступности за счет репликации состояния между репликами, размещенными на разных узлах кластера. Репликация обеспечивает избыточность, необходимую для обеспечения доступности службы, даже когда на одном из узлов кластера происходит сбой. При использовании разделенной службы выполняется дальнейшее разделение ее состояния (а также алгоритмов доступа к этому состоянию) на всех узлах кластера.
На следующей диаграмме отображается отношение между приложениями и экземплярами службы, разделами и репликами.
Совет
Просмотреть структуру приложений в кластере можно с помощью обозревателя Service Fabric, доступного по адресу http://<адрес_кластера>:19080/Explorer. Дополнительные сведения см. в статье Визуализация кластера с помощью обозревателя Service Fabric.
Дальнейшие действия
- Дополнительные сведения об обновлениях приложений.
- Дополнительные сведения о состоянии, секционирование и доступности служб.
- Узнайте, как приложения и службы определяются в манифестах приложений и служб.
- В описаниимоделей размещения рассматривается связь между репликами (или экземплярами) развернутой службы и процессом размещения службы.