Рекомендации по проектированию приложений Azure Service Fabric

  • Статья

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

Познакомьтесь с Service Fabric

Руководство по разработке приложений

Ознакомьтесь с общей архитектурой приложений Service Fabric и их особенностями проектирования.

Выберите шлюз API

Используйте службу шлюза API, которая обменивается данными с внутренними службами, которые затем можно масштабировать. Наиболее распространенные службы шлюза API:

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

Мы рекомендуем всегда начинать с создания служб без сохранения состояния с помощью Надежных служб и хранения состояния в базе данных Azure, Azure Cosmos DB или хранилище Azure. Внешнее состояние — более знакомый подход для большинства разработчиков. Этот подход также позволяет вам воспользоваться возможностями запросов в магазине.

Когда использовать сервисы с отслеживанием состояния

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

Определитесь со сроками хранения данных:

  • Кэшированные данные. Используйте кэширование, когда возникает проблема с задержкой до внешних хранилищ. Используйте службу с отслеживанием состояния в качестве собственного кэша данных или рассмотрите возможность использования распределенного кэша SoCreate Service Fabric с открытым исходным кодом. В этом случае вам не нужно беспокоиться, если вы потеряете все данные в кэше.
  • Данные с привязкой ко времени. В этом сценарии вам необходимо хранить данные близко к вычислениям в течение некоторого периода времени для задержки, но вы можете позволить себе потерять данные в случае аварии. Например, во многих решениях IoT данные должны быть близки к вычислению, например, когда вычисляется средняя температура за последние несколько дней, но если эти данные потеряны, конкретные записанные точки данных не так важны. Кроме того, в этом сценарии вы обычно не заботитесь о резервном копировании отдельных точек данных. Вы выполняете резервное копирование только вычисленных средних значений, которые периодически записываются во внешнее хранилище.
  • Долгосрочные данные. Надежные коллекции могут хранить ваши данные постоянно. Но в этом случае вам необходимо подготовиться к аварийному восстановлению, включая настройку политик периодического резервного копирования для ваших кластеров. По сути, вы настраиваете, что произойдет, если ваш кластер будет разрушен в результате аварии, где вам потребуется создать новый кластер, и как развернуть новые экземпляры приложений и восстановить их из последней резервной копии.

Сэкономьте и улучшите доступность:

  • Вы можете сократить расходы, используя службы с отслеживанием состояния, потому что вы не несете затрат на доступ к данным и транзакции из удаленного хранилища, а также потому, что вам не нужно использовать другую службу, например Кэш Azure для Redis.
  • Использование сервисов с отслеживанием состояния в первую очередь для хранения, а не для вычислений, стоит дорого, и мы не рекомендуем это делать. Думайте о сервисах с отслеживанием состояния как о вычислениях с дешевым локальным хранилищем.
  • Удалив зависимости от других сервисов, вы можете повысить доступность своих сервисов. Управление состоянием с помощью высокой доступности в кластере изолирует вас от других проблем, связанных с простоями служб или задержками.

Как работать с Надежными службами

Надежные службы Service Fabric позволяют легко создавать службы без отслеживания состояния и без отслеживания состояния. Для получения дополнительной информации см. Введение в Reliable Services.

  • Всегда учитывайте токен отмены в методе RunAsync() для служб без отслеживания состояния и с отслеживанием состояния и в методе ChangeRole() для служб с отслеживанием состояния. Если вы этого не сделаете, Service Fabric не знает, можно ли закрыть вашу службу. Например, если вы не соблюдаете токен отмены, время обновления приложения может значительно увеличиться.
  • Открывайте и закрывайте прослушиватели связи своевременно и соблюдайте токены отмены.
  • Никогда не смешивайте код синхронизации с асинхронным кодом. Например, не используйте .GetAwaiter().GetResult() в своих асинхронных вызовах. Используйте async на всем протяжении стека вызовов.

Как работать с надежными субъектами

Надежные субъекты Service Fabric позволяют легко создавать виртуальные субъектов с отслеживанием состояния. Для получения дополнительной информации см. Введение в Надежные субъекты.

  • Серьезно подумайте об использовании обмена сообщениями pub/sub между вашими актерами для масштабирования вашего приложения. Инструменты, которые предоставляют эту службу, включают SoCreate Service Fabric Pub/Sub с открытым исходным кодом и Служебную шину Azure.
  • Сделайте состояние актера как можно более детальным.
  • Надлежащее управление жизненным циклом субъекта. Удалите субъекты, если вы больше не собираетесь их использовать. Удаление ненужных субъектов особенно важно, когда вы используете провайдер изменчивого состояния, потому что все состояние хранится в памяти.
  • Из-за пошагового параллелизма субъекты лучше использовать как независимые объекты. Не создавайте графы синхронных вызовов методов с несколькими субъектами (каждый из которых, скорее всего, станет отдельным сетевым вызовом) или создайте запросы с циклическими субъектами. Это существенно повлияет на производительность и масштаб.
  • Не смешивайте код синхронизации с асинхронным кодом. Последовательно используйте async, чтобы предотвратить проблемы с производительностью.
  • Не звоните актерам надолго. Длительные вызовы будут блокировать другие вызовы одного и того же субъекта из-за параллелизма, основанной на последующей блокировке.
  • Если вы взаимодействуете с другими службами с помощью удаленного взаимодействия Service Fabric и создаете ServiceProxyFactory, создайте фабрику на уровне службы-субъекта, а не на уровне субъекта.

Диагностика приложения

Будьте внимательны при добавлении регистрации приложений в сервисных вызовах. Это поможет вам диагностировать сценарии, в которых службы звонят друг другу. Например, когда A вызывает B, C вызывает D, вызов может закончиться неудачей в любом месте. Если у вас недостаточно журналов, сбои трудно диагностировать. Если службы регистрируют слишком много сообщений из-за объемов вызовов, не забудьте, по крайней мере, регистрировать ошибки и предупреждения.

Руководство по проектированию в Azure