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

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

  • Статья

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

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

Reliable Services — это одна из моделей программирования, доступных в Service Fabric. Другой — это модель программирования Надежных субъектов , которая предоставляет платформу приложений виртуального субъекта на основе модели Reliable Services. Дополнительные сведения о надежных акторах см. в разделе «Общие сведения о надежных акторах Service Fabric».

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

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

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

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

Что делает надежные службы разными

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

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

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

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

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

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

Если вы впервые узнаёте о надёжных услугах, прочитайте дальше! Если вы ищете подробное пошаговое руководство по жизненному циклу надежных служб, ознакомьтесь с обзором жизненного цикла Надежных служб.

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

Давайте рассмотрим, как модель 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 отвечает за эти требования как для кода сервиса, так и для состояния сервиса.

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

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

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

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

Рассмотрите API Надежных служб, если:

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

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