Настройка и использование сходства служб в Service Fabric

  • Статья

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

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

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

  1. У компонента Х в монолитном приложении была незадокументированная зависимость от компонента Y, а теперь вы разделили эти компоненты на отдельные службы. Эти службы выполняются на разных узлах кластера, и из-за этого связь между ними нарушена.
  2. Эти компоненты взаимодействуют через локальные именованные каналы, общую память или файлы на диске. На текущий момент возможность записи в общий ресурс необходима им для обеспечения производительности. Возможно, позже эта жесткая зависимость будет устранена.
  3. Все работает, но оказывается, что эти два компонента выдают слишком много данных или слишком чувствительны к уровню производительности. С их переносом в отдельные службы общая производительность приложения резко упала или увеличилась задержка. В результате приложение в целом не удовлетворяет требованиям.

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

Что делать? Попробуйте включить сходство.

Настройка сходства

Для настройки сходства необходимо определить отношения сопоставления между двумя отдельными службами. Это все равно, что указать одной службе на другую и сказать: "Эта служба может работать только тогда, когда та служба работает". Иногда сходство называют родительско-дочерними отношениями (где вы указываете ребенку на родителя). В результате применения сходства реплики или экземпляры одной службы помещаются на те же узлы, что и реплики и экземпляры другой службы.

ServiceCorrelationDescription affinityDescription = new ServiceCorrelationDescription();
affinityDescription.Scheme = ServiceCorrelationScheme.Affinity;
affinityDescription.ServiceName = new Uri("fabric:/otherApplication/parentService");
serviceDescription.Correlations.Add(affinityDescription);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Примечание

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

  • Можно обратить отношения (сделать так, чтобы родительские службы parentService1 и parentService2 указывали на текущую дочернюю службу).
  • Можно назначить одну из родительских служб центром в соответствии с соглашением и настроить все службы таким образом, чтобы они указывали на эту службу.

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

Различные параметры сходства

Сопоставление представляет одна из нескольких возможных схем корреляции, которая имеет два различных режима. Наиболее распространенный режим сопоставления — NonAlignedAffinity. В режиме NonAlignedAffinity реплики или экземпляры разных служб помещаются в одни и те же узлы. Другой режим — AlignedAffinity. Он применяется только для служб с отслеживанием состояния. Сопоставление двух служб с отслеживанием состояния в режиме AlignedAffinity гарантирует, что первичные реплики одной службы будут размещаться на тех же узлах, что и первичные реплики другой службы. И там же будет размещаться каждая пара вторичных реплик этих служб. Сопоставление в режиме NonAlignedAffinity также можно настроить для служб с отслеживанием состояния (хотя это встречается реже). В режиме NonAlignedAffinity разные реплики двух служб с отслеживанием состояния будут выполняться на одних и тех же узлах, но их первичные реплики могут оказаться на разных узлах.

Режимы сходства и их эффекты

Требуемое состояние не гарантируется

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

Цепочки и звезды

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

Цепочки и звезды в контексте отношений сходства

Также следует помнить, что на сегодняшний день отношения сопоставления являются направленными по умолчанию. Это означает, что правило сходства определяет только размещение дочерней службы вместе с родительской. Оно не гарантирует, что родительская служба будет размещена вместе с дочерней. Таким образом, если имеется нарушение сходства и для устранения нарушения по какой-либо причине нецелесообразно переместить дочерний элемент в родительский узел, то, даже если перемещение родительского элемента к дочернему узлу исправит нарушение, родительский элемент не будет перемещен к дочернему узлу. Настройка для конфигурации MoveParentToFixAffinityViolation значения true позволит удалить направленность. Также важно отметить, что отношение сходства не может быть применено идеально или мгновенно, так как жизненные циклы разных служб отличаются, и их сбои и перемещения могут осуществляться независимо. Например, для родительской службы может быть выполнена отработка отказа на другой узел из-за того, что она была аварийно завершена. Диспетчер кластерных ресурсов и диспетчер отказоустойчивости сначала выполняют отработку отказа, так как высший приоритет имеет обеспечение работоспособности, согласованности и доступности служб. После выполнения отработки отказа отношение сходства будет нарушено, но диспетчер кластерных ресурсов не определит этого, пока не заметит, что дочерняя служба не размещена вместе с родительской. Такие проверки выполняются периодически. Дополнительные сведения о том, как диспетчер кластерных ресурсов оценивает ограничения, доступны в этой статье. А в этой статье подробнее описывается настройка периодичности, с которой данные ограничения оцениваются.

Поддержка секционирования

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

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