Общие сведения о Reliable Services

  • Статья

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

  • Модель программирования надежных служб для служб с отслеживанием состояния и без него.
  • Варианты выбора при написании надежной службы.
  • Некоторые сценарии и примеры использования надежных служб, а также способ их написания.

Надежные службы являются одной из моделей программирования, доступных в Service Fabric. Другая модель программирования — модель Reliable Actor, которая в дополнение к модели надежных служб, предоставляет исполняющую среду Virtual Actor. Дополнительные сведения о Reliable Actors см. в статье Общие сведения о надежных субъектах Service Fabric.

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

Что такое надежные службы

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

  • Доступ к API платформы Service Fabric. В отличие от служб Service Fabric, смоделированных в виде гостевых исполняемых файлов, надежные службы могут напрямую использовать API-интерфейсы платформы Service Fabric. Это позволяет службам:
    • Запрос к системе
    • Создание отчетов о работоспособности сущностей в кластере
    • Получение уведомлений об изменениях конфигурации и кода
    • Поиск других служб и обмен данными с ними
    • Использование надежных коллекций
    • Доступ ко многим другим возможностям высококлассной модели программирования на нескольких языках программирования.
  • Простая модель для выполнения собственного кода, которая похожа на другие привычные модели программирования: у создаваемого кода четко определенная точка входа и простой в управлении жизненный цикл.
  • Модель взаимодействия со службами Транспорт может быть любым, включая HTTP с веб-API, протоколы WebSocket, пользовательские протоколы TCP и т. п. Надежные службы позволяют использовать ряд отличных готовых вариантов или задействовать собственный.
  • Для служб с отслеживанием состояния модель программирования Reliable Services позволяет согласованно и надежно хранить состояние прямо в службе с помощью коллекций Reliable Collections. Reliable Collections — это простой набор классов коллекций с высокой доступностью и надежностью, которые будут знакомы всем, кто использовал коллекции C#. Обычно для надежного управления состоянием службам требовались внешние системы. Коллекции Reliable Collections обеспечивают хранение состояния вместе с вычислениями при таком же уровне доступности и надежности, как и в высокодоступных внешних хранилищах. Такая модель также сокращает задержку, потому что необходимые для работы данные состояния и вычисления хранятся рядом.

Отличие надежных служб

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

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

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

Жизненный цикл службы

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

  • CreateServiceReplicaListeners/CreateServiceInstanceListeners — в этом методе служба определяет стеки связи, которые собирается использовать. Стек связи, например веб-API, определяет одну или несколько конечных точек прослушивания для службы (способ доступа к ней клиентов), а также определяет взаимодействие поступающих сообщений с остальным кодом службы.
  • RunAsync — в этом методе выполняется бизнес-логика службы, а также запускаются все фоновые задачи, которые должны выполняться в течение всего времени существования службы. Предоставляемый токен отмены сигнализирует о моменте, когда работу следует остановить. Например, если служба должна извлекать сообщения из очереди Reliable Queue и обрабатывать их, это и будет местом выполнения соответствующей работы.

Если вы впервые узнали о Reliable Services, читайте статью дальше. Если вам необходимо подробное пошаговое руководство о жизненном цикле надежных служб, см. статью Жизненный цикл Reliable Services.

Примеры служб

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

Надежные службы без отслеживания состояния

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

Например, рассмотрим калькулятор — службу, которая не пользуется памятью и которая принимает все условия и операции для одновременного выполнения.

В этом случае метод RunAsync() (C#) или runAsync() (Java) службы может быть пустым, так как у службы нет необходимости в фоновой обработке задач. Когда создается служба калькулятора, она возвращает интерфейс ICommunicationListener (C#) или CommunicationListener (Java) (например, веб-API), который открывает конечную точку прослушивания на том или ином порту. Эта конечная точка подключается к различным вычислительным методам (например, Add(n1, n2)), которые определяют общедоступный API калькулятора.

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

Это простой пример, так как в службе калькулятора внутреннее состояние не сохраняется. Большинство служб без отслеживания состояния не являются таковыми в полной мере, так как они записывают свои состояния в какое-либо внешнее хранилище (например, веб-приложение, хранящее состояние сеанса в резервном хранилище или кэше, не является службой без отслеживания состояния).

Распространенным примером использования служб без отслеживания состояния в Service Fabric является внешний интерфейс, который позволяет пользоваться общедоступным интерфейсом API для веб-приложения. Затем внешняя служба обменивается данными со службами с отслеживанием состояния для выполнения запроса пользователя. В этом случае вызовы от клиентов направляются на известный порт, например с номером 80, который прослушивает служба без отслеживания состояния. Такая служба получает вызов и определяет, поступил ли он из надежного источника, а также устанавливает, для какой службы он предназначен. Затем служба без отслеживания состояния перенаправляет вызов на нужную секцию службы с отслеживанием состояния и ожидает ответа. При получении ответа служба без отслеживания состояния отвечает исходному клиенту. Примером такой службы является образец для начала работы с Service Fabric (C# / Java), а также другие образцы Service Fabric в этом репозитории.

Надежные службы с отслеживанием состояния

Служба с отслеживанием состояния — это служба, которой для надлежащего функционирования необходимо поддерживать часть состояния в согласованном виде. Рассмотрим службу, которая постоянно вычисляет скользящее среднее некоторых значений на основе получаемых обновлений. Для этого службе необходимо располагать текущим набором входящих запросов, которые требуется обработать, а также текущим средним значением. Любая служба, которая получает, обрабатывает и сохраняет информацию во внешнем хранилище (как это сегодня делается в хранилище BLOB-объектов или табличном хранилище Azure), является службой с отслеживанием состояния — она просто хранит свое состояние во внешнем хранилище состояний.

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

Допустим, нам нужно создать службу, которая обрабатывает изображения. Для этого служба принимает изображение и ряд преобразований, которые необходимо с ним выполнить. Эта служба возвращает прослушиватель связи (допустим, веб-API), который предоставляет такой API, как ConvertImage(Image i, IList<Conversion> conversions). Получив запрос, служба сохраняет его в IReliableQueue и возвращает клиенту идентификатор для отслеживания запроса.

В этой службе метод RunAsync() может быть более сложным. В методе RunAsync() этой службы существует цикл, который извлекает запросы из очереди IReliableQueue и выполняет запрошенные преобразования. Результаты сохраняются в IReliableDictionary. Когда клиент обращается к службе снова, он получает преобразованные изображения. Чтобы гарантировать, что даже в случае отказа изображение не будет утеряно, такая служба Reliable Service выполняет извлечение из очереди, преобразование и сохранение результата в одной транзакции. В таком случае сообщение удаляется из очереди и результаты сохраняются в словаре результатов только после завершения преобразований. Кроме того, служба может извлечь изображение из очереди и сразу же сохранить его в удаленном хранилище. Это уменьшает объем состояния, которым должна управлять служба, но увеличивает сложность, так как служба должна хранить необходимые метаданные для управления удаленным хранилищем. В обоих подходах при возникновении сбоя в процессе выполнения запрос остается в очереди, ожидая обработки.

Хотя эта служба похожа на обычную службу .NET, разница ее в том, что используемые структуры данных (IReliableQueue и IReliableDictionary) предоставляются платформой Service Fabric и для них обеспечивается высокая надежность, доступность и согласованность.

Когда следует использовать API надежных служб

Используйте API надежных служб, когда:

  • Необходима высокая доступность и надежность кода службы (и при необходимости состояния).
  • Необходимы гарантии выполнения транзакций между несколькими единицами состояния (например, заказами и позициями строки заказа).
  • Состояние приложения можно естественным образом моделировать в виде надежных словарей и очередей.
  • Код или состояние приложения должны иметь высокую доступность с низкой задержкой операций чтения и записи.
  • Приложению требуется контролировать параллелизм или степень детализации транзакционных операций по одной или нескольким надежным коллекциям.
  • Необходимо управлять обменом данными или контролировать схему секционирования службы.
  • Коду требуется среда выполнения, работающая в режиме свободного потока.
  • Приложению требуется динамически создавать или уничтожать словари Reliable Dictionary, очереди Reliable Queue или целые службы во время выполнения.
  • Вам нужно программным способом управлять функциями резервного копирования и восстановления, которые предоставляет платформа Service Fabric и которые относятся к вашей службе.
  • Приложению необходимо поддерживать историю изменений своих единиц состояния.
  • Вам нужно разработать свои настраиваемые поставщики состояний или использовать сторонние.

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