Архитектура Service Fabric

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

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

На следующей схеме показаны основные подсистемы Service Fabric.

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

Транспортная подсистема

Транспортная подсистема реализована на модели обмена данными по каналу "точка-точка". Этот канал используется для обмена данными в пределах кластера Service Fabric и между кластером Service Fabric и клиентами. Поддерживается как односторонняя модель обмена данными, так и модель на основе схемы "запрос — ответ". Это позволяет внедрять технологии широковещательной и многоканальной трансляции на уровне федерации. Транспортная подсистема обеспечивает безопасность при обмене данными за счет использования сертификатов X509 или средств безопасности Windows. Эта подсистема используется в рамках Service Fabric. При программировании приложений она недоступна напрямую для разработчиков.

Подсистема федерации

Чтобы рассуждать о наборе узлов в распределенной системе, нам потребуется сформировать целостное представление обо всей системе. Подсистема федерации использует составные элементы обмена данными, предоставляемые транспортной подсистемой, и объединяет различные узлы в единый унифицированный кластер. Это обеспечивает составные элементы распределенной системы, которые требуются другим подсистемам: обнаружение сбоев, выбор лидера и постоянная маршрутизация. Подсистема федерации основана на распределенных хэш-таблицах с 128-разрядным пространством маркера. Она создает кольцевую топологию на узлах, где каждому узлу в кольце выделяется подмножество пространства маркера для владельца. Для обнаружения ошибок этот уровень использует механизм аренды, основанный на сердцебиении и разрешении конфликтов. Кроме того, подсистема федерации при помощи сложных протоколов присоединения и отсоединения гарантирует, что в конкретный момент существует только один владелец. Это позволяет выбирать лидера и обеспечивать согласованную маршрутизацию.

Подсистема надежности

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

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

Подсистема управления

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

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

Подсистема хостинга

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

Подсистема связи

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

Подсистема тестирования

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