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

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

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

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

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

  1. Некоторые компоненты X в монолитном приложении имели незадокументированную зависимость от компонента 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. Выравненная аффинность полезна только с состояниесознательными службами. Настройка двух служб с отслеживанием состояния для сопоставления гарантирует, что первичные компоненты этих служб помещаются на одни и те же узлы, что и друг друга. Это также приводит к тому, что каждая пара вторичных файлов для этих служб помещается на одни и те же узлы. Можно также настроить NonAlignedAffinity для служб с отслеживанием состояния, хотя это менее распространено. Для NonAlignedAffinity разные реплики двух служб с отслеживанием состояния будут выполняться на одних узлах, но их первичные элементы могут в конечном итоге быть на разных узлах.

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

Максимально возможное состояние

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

Цепочки против звезд

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

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

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

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

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

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