Масштабирование Azure сервисной ткани Услуги без гражданства

Question

Не могли бы вы дать мне лучшее представление о том, как мы можем масштабировать службы без состояния без разбиения на разделы?

Скажем, у нас есть 5 узлов в кластере, и у нас есть 5 экземпляров службы. При простом тестировании узел ведет себя как липкий, где все запросы, которые я отправляю, обслуживаются только одним узлом. В сценарии, когда у нас большой объем запросов, которые входят, могут использоваться другие экземпляры для обслуживания трафика. Как мы справляемся с такими масштабными ситуациями в сфере обслуживания?

Спасибо!

Answer 1

Обычно нет необходимости использовать разделение для лиц без услуг SF, поэтому следует избегать, что если вы можете:

more on SF partitioning, including why its not normally used for stateless services

Если вы используете ServiceProxy API, он будет поддерживать липкие соединения с заданным физическим узла в кластере. Если вы (скажем) разоблачаете конечные точки HTTP, у вас будет один для каждого физического экземпляра в кластере (это означает, что вы в конечном итоге будете разговаривать по одному за раз, если только вы вручную не перекроете их). Вы можете избежать этого:

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

2. Поместите балансировщик нагрузки перед вашим кластером и настройте весь трафик от ваших клиентов на узлы SF, которые будут перенаправлены через это. Балансировки нагрузки могут быть сконфигурирована для Round-Robin, семантика и т.д. стиля:

Azure Load Balancer

Azure Traffic Manager

Успехов!

Answer 2

Вы можете запросить запрос, используя обратный прокси-сервер, установленный на каждом узле. Использование https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverseproxy

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

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

Answer 3

Предполагается, что вы вызываете свои услуги из-за пределов кластера. Если да, ваша проблема не специфична для Service Fabric, это Azure VMSS + LB.

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

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

Это режим распределения по умолчанию (Hash-based). Вы должны также проверить правила маршрутизации в LB, чтобы проверить, является ли режим распространения Hash-based (5 tuple = ip + port), или если это Режим аффинации IP (только ip), в противном случае несколько соединений от одного и того же IP все равно будет привязан к одному узлу.

Источник: Azure Load Balaner Distribution Mode