Сценарии тестирования платформы Service Fabric: обмен данными между службами

  • Статья

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

Обмен данными между службами — критически важная точка интеграции приложения, так как каждая служба предоставляет удаленный API-интерфейс для других служб. Работа с набором границ API, включающая ввод-вывод данных, обычно требует тщательного подхода с интенсивным тестированием и проверкой.

При объединении этих границ служб другом в распределенной системе следует ответить на ряд вопросов.

  • Транспортный протокол. Вы будете использовать протокол HTTP для улучшения взаимодействия или пользовательский двоичный протокол, чтобы обеспечить максимальную пропускную способность?
  • Обработка ошибок. Как будут обрабатываться постоянные и временные ошибки? Что произойдет, когда служба переместится на другой узел?
  • Время ожидания и задержка. Как каждый слой службы будет обрабатывать задержку через стек для пользователя в многоуровневых приложениях?

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

Подготовка служб к перемещению

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

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

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

Для бесперебойной работы системы важно правильно обрабатывать такие сценарии. Чтобы сделать это, помните следующее.

  • Каждая служба, к которой можно подключиться, имеет адрес для прослушивания (например, HTTP или WebSockets). При перемещении экземпляра или раздела службы меняется адрес соответствующей конечной точки (Перемещается на другой узел с другим IP-адресом.) Если вы используете встроенные компоненты связи, они будут автоматически обрабатывать повторно разрешающиеся адреса служб.
  • Может наблюдаться временное увеличение задержки, так как экземпляр службы снова запускает свой прослушиватель. Это зависит от того, насколько быстро служба открывает прослушиватель после перемещения экземпляра службы.
  • При открытии службы на новом узле все существующие подключения потребуется закрыть и открыть заново. Нормальное завершение работы (или перезапуск узла) предоставляет достаточно времени для нормального завершения работы существующих подключений.

Тестирование. Перемещение экземпляров службы

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

  1. Переместите первичную реплику службы с отслеживанием состояния.

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

    
PS > Move-ServiceFabricPrimaryReplica -PartitionId 6faa4ffa-521a-44e9-8351-dfca0f7e0466 -ServiceName fabric:/MyApplication/MyService

  2. Остановите работу узла.

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

    Узел можно остановить с помощью следующего командлета PowerShell Stop-ServiceFabricNode :

    
PS > Stop-ServiceFabricNode -NodeName Node_1

Поддержание доступности службы

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

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

Тестирование. Недоступность операции записи

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

Потерю кворума можно вызвать с помощью командлета PowerShell Invoke-ServiceFabricPartitionQuorumLoss :


PS > Invoke-ServiceFabricPartitionQuorumLoss -ServiceName fabric:/Myapplication/MyService -QuorumLossMode QuorumReplicas -QuorumLossDurationInSeconds 20

В этом примере мы задаем для параметра QuorumLossMode значение QuorumReplicas, чтобы указать, что нам нужно вызвать потерю кворума без отключения всех реплик. Таким образом выполнение операций чтения по-прежнему возможно. Чтобы протестировать сценарий, при котором недоступен весь раздел, для этого параметра можно задать значение AllReplicas.

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

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

Дополнительные сведения о сценариях подсистемы тестирования