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

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

Знакомство с Service Fabric

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

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

Выбор шлюза API

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

Бесcтатусные службы

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

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

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

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

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

Экономия затрат и повышение доступности:

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

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

Служба Fabric Reliable Services позволяет легко создавать службы без отслеживания состояния и состояния. Дополнительные сведения см. в статье "Общие сведения о надежных службах".

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

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

Служба Fabric Надежные субъекты позволяют легко создавать виртуальные субъекты с отслеживанием состояния. Дополнительные сведения см. в статье "Надежные субъекты".

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

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

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

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

  • Посетите центр архитектуры Azure для получения руководств по проектированию микрослужб в Azure.

  • Посетите Get Started with Azure for Gaming для получения рекомендаций по дизайну использования Service Fabric в игровых службах.

  • Последнее обновление: