Почему стратегия разделения службы сервисной фабрики связана с разделом, а не со службой?

Question

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

https://stackoverflow.com/a/38562986/4787510

Я сделал несколько небольших изменений в этом, поэтому вот мой код:

private readonly FabricClient m_fabricClient

public async Task RefreshEndpointList()
{
        var appList = await m_fabricClient.QueryManager.GetApplicationListAsync();
        var app = appList.Single(x => x.ApplicationName.ToString().Contains("<MyFabricDeploymentName>"));

        // Go through all running services
        foreach (var service in await m_fabricClient.QueryManager.GetServiceListAsync(app.ApplicationName))
        {
            var partitions = await m_fabricClient.QueryManager.GetPartitionListAsync(service.ServiceName);

            // Go through all partitions
            foreach (var partition in partitions)
            {
                // Check what kind of service we have - depending on that the resolver figures out the endpoints.
                // E.g. Singleton is easy as it is just one endpoint, otherwise we need some load balancing later on
                ServicePartitionKey key;
                switch (partition.PartitionInformation.Kind)
                {
                    case ServicePartitionKind.Singleton:
                        key = ServicePartitionKey.Singleton;
                        break;
                    case ServicePartitionKind.Int64Range:
                        var longKey = (Int64RangePartitionInformation)partition.PartitionInformation;
                        key = new ServicePartitionKey(longKey.LowKey);
                        break;
                    case ServicePartitionKind.Named:
                        var namedKey = (NamedPartitionInformation)partition.PartitionInformation;
                        key = new ServicePartitionKey(namedKey.Name);
                        break;
                    default:
                        throw new ArgumentOutOfRangeException($"Can't resolve partition kind for partition with id {partition.PartitionInformation.Id}");
                }

                var resolvedServicePartition = await ServicePartitionResolver.GetDefault().ResolveAsync(service.ServiceName, key, CancellationToken.None);

                m_endpointCache.PutItem(service.ServiceTypeName, new ServiceDetail(service.ServiceTypeName, service.ServiceKind, ServicePartitionKind.Int64Range, resolvedServicePartition.Endpoints));
            }
        }
    }
}

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

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

Кластер Service Fabric -> Приложение Service Fabric (например, myApp_Fabric) -> Услуги (например, служба внешнего интерфейса, микросервис изображения профиля, службы внутреннего интерфейса)

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

IХотя я не совсем уверен, правильно ли я понял разницу между узлами / разделами / репликами.

Однако вернемся к моему замешательству и актуальному вопросу:

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

Итак, почему стратегия разделения не связана напрямую со службой?

Answer 1

Представьте, что ваш сервис похож на пиццу, когда вы запрашиваете пиццу, вы запрашиваете вкус пиццы (тип услуги), вы обычно не указываете, как вы хотите нарезать эту пиццу (то есть: 8 штук), как правило,пиццерия справится с этим, и некоторые из них могут быть нарезаны на 4, 8 или более в зависимости от размера пиццы.

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

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

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

По этой аналогии мы можем видеть сравнение как:

• Аромат = Тип сервиса
• Пицца = Сервис
• Размер и способ нарезки = Схема разбиения
• Срез = Разделение
• Коробка = Узел
• Количество пицц = Реплики

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

Answer 2

Что касается сервисов в Service Fabric, существует два типа: сервисы с сохранением состояния и сервисы без сохранения состояния.

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

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

<Service Name="Processing">
    <StatefulService ServiceTypeName="ProcessingType" TargetReplicaSetSize="3" MinReplicaSetSize="3">
        <UniformInt64Partition PartitionCount="26" LowKey="0" HighKey="25" />
    </StatefulService>
</Service>

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

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

В случае отсутствия состоянияслужб, будет только один раздел (одноэлементный раздел), поэтому число фактических экземпляров равно 1 * 3 (количество реплик) = 3. (3 реплики - это только пример. В большинстве случаев установлено количество экземпляров службы без сохранения состояния).до -1, что означает 1 экземпляр для каждого узла в кластере.)

Еще одна вещь: в вашем коде у вас есть строка комментария в фрагменте кода итерации разделов:

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

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

Вы, вероятно, уже прочитали документы .Если нет, я предлагаю также прочитать его.

Обращаясь к вашим комментариям:

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

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

Но, сервисные экземпляры могут.Если служба имеет размер реплики, скажем, 3, будет 3 экземпляра, обслуживающих этот раздел.Но только 1 является первичным экземпляром, считывающим и записывающим данные, которые реплицируются во вторичные экземпляры.