Подключение и взаимодействие со службами в Service Fabric

Статья
04/02/2025

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

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

Просмотрите эту страницу для обучающего видео, в котором также рассматриваются сведения об обмене данными о службе:

Принесите свой собственный протокол

Service Fabric помогает управлять жизненным циклом служб, но не принимает решения о том, что делают ваши службы. Это включает обмен данными. Когда ваша служба открывается с помощью Service Fabric, это её возможность настроить конечную точку для входящих запросов, используя любой протокол или стек связи. Ваша служба будет прослушивать обычный IP-адрес:порт с использованием любой схемы адресации, такой как URI. Несколько экземпляров служб или реплик могут совместно использовать процесс узла, в этом случае им потребуется использовать разные порты или использовать механизм общего доступа к портам, например драйвер ядра http.sys в Windows. В любом случае каждый экземпляр службы или реплика в хост-процессе должен иметь уникальный адрес.

Конечные точки службы

Обнаружение и разрешение сервисов

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

Распределение служб

Service Fabric предоставляет службу обнаружения и разрешения, называемую службой именования. Служба именования поддерживает таблицу, которая сопоставляет именованные экземпляры служб с адресами конечной точки, которые они прослушивают. Все именованные экземпляры служб в Service Fabric имеют уникальные имена, представленные как URI, например "fabric:/MyApplication/MyService". Имя службы не изменяется в течение всего времени существования службы, это только адреса конечной точки, которые могут изменяться при перемещении служб. Это аналогично веб-сайтам, которые имеют постоянные URL-адреса, но где IP-адрес может измениться. Аналогично DNS в Интернете, который разрешает URL-адреса веб-сайта IP-адресам, Service Fabric имеет регистратор, который сопоставляет имена служб с адресом конечной точки.

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

Разрешение и подключение к службам включает следующие шаги, выполняемые в цикле:

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

Подключение к другим службам

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

Служба DNS

Так как многие службы, особенно контейнерные службы, могут иметь существующее имя URL-адреса, что позволяет устранить их с помощью стандартного протокола DNS (а не протокола службы именования), особенно в сценариях "лифт и смена" приложения. Это именно то, что делает служба DNS. Он позволяет связывать DNS-имена с именем службы и, следовательно, обеспечивать разрешение IP-адресов конечной точки.

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

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

Дополнительные сведения об использовании службы DNS см. в статье о СЛУЖБЕ DNS в Azure Service Fabric .

Обратная прокси-служба

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

Схема, показывающая, как обратный прокси-сервер обращается к службам в кластере, которые предоставляют конечные точки HTTP, включая HTTPS.

Дополнительные сведения об использовании обратной прокси-службы см. в статье об обратном прокси-сервере в Azure Service Fabric .

Подключения от внешних клиентов

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

Service Fabric в Azure

Кластер Service Fabric в Azure размещается за Azure Load Balancer. Весь внешний трафик к кластеру должен проходить через подсистему балансировки нагрузки. Подсистема балансировки нагрузки автоматически перенаправит входящий трафик на заданный порт на случайный узел с тем же открытым портом. Azure Load Balancer знает только о портах, открытых на узлах, он не знает о портах, открытых отдельными службами.

Топология Azure Load Balancer и Service Fabric

Например, чтобы принять внешний трафик через порт 80, необходимо настроить следующие действия:

Напишите службу, которая прослушивает порт 80. Настройте порт 80 в ServiceManifest.xml службы и откройте прослушиватель в службе, например локальный веб-сервер.

<Resources>
    <Endpoints>
        <Endpoint Name="WebEndpoint" Protocol="http" Port="80" />
    </Endpoints>
</Resources>

    class HttpCommunicationListener : ICommunicationListener
    {
        ...

        public Task<string> OpenAsync(CancellationToken cancellationToken)
        {
            EndpointResourceDescription endpoint =
                serviceContext.CodePackageActivationContext.GetEndpoint("WebEndpoint");

            string uriPrefix = $"{endpoint.Protocol}://+:{endpoint.Port}/myapp/";

            this.httpListener = new HttpListener();
            this.httpListener.Prefixes.Add(uriPrefix);
            this.httpListener.Start();

            string publishUri = uriPrefix.Replace("+", FabricRuntime.GetNodeContext().IPAddressOrFQDN);
            return Task.FromResult(publishUri);
        }

        ...
    }

    class WebService : StatelessService
    {
        ...

        protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
        {
            return new[] { new ServiceInstanceListener(context => new HttpCommunicationListener(context))};
        }

        ...
    }

    class HttpCommunicationlistener implements CommunicationListener {
        ...

        @Override
        public CompletableFuture<String> openAsync(CancellationToken arg0) {
            EndpointResourceDescription endpoint =
                this.serviceContext.getCodePackageActivationContext().getEndpoint("WebEndpoint");
            try {
                HttpServer server = com.sun.net.httpserver.HttpServer.create(new InetSocketAddress(endpoint.getPort()), 0);
                server.start();

                String publishUri = String.format("http://%s:%d/",
                    this.serviceContext.getNodeContext().getIpAddressOrFQDN(), endpoint.getPort());
                return CompletableFuture.completedFuture(publishUri);
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
        }

        ...
    }

    class WebService extends StatelessService {
        ...

        @Override
        protected List<ServiceInstanceListener> createServiceInstanceListeners() {
            <ServiceInstanceListener> listeners = new ArrayList<ServiceInstanceListener>();
            listeners.add(new ServiceInstanceListener((context) -> new HttpCommunicationlistener(context)));
            return listeners;		
        }

        ...
    }

Создайте кластер Service Fabric в Azure и укажите порт 80 в качестве пользовательского порта конечной точки для типа узла, который будет размещать службу. Если у вас несколько типов узлов, можно настроить ограничение размещения службы, чтобы убедиться, что она выполняется только в типе узла с открытым пользовательским портом конечной точки.
После создания кластера настройте Azure Load Balancer в группе ресурсов кластера для пересылки трафика через порт 80. При создании кластера на портале Azure это настраивается автоматически для каждого настраиваемого порта конечной точки, настроенного.
Azure Load Balancer использует пробу для определения того, следует ли отправлять трафик на определенный узел. Проба периодически проверяет конечную точку на каждом узле, чтобы определить, отвечает ли узел. Если проба не сможет получить ответ после заданного количества раз, подсистема балансировки нагрузки перестает отправлять трафик на этот узел. При создании кластера через портал Azure для каждого порта конечной точки, который был настроен, автоматически настраивается проверочный элемент.

Важно помнить, что Azure Load Balancer и проба знают только о узлах, а не службах , работающих на узлах. Azure Load Balancer всегда отправляет трафик узлам, которые отвечают на пробу, поэтому необходимо обеспечить доступность служб на узлах, которые могут реагировать на пробу.

Надежные службы: встроенные параметры API обмена данными

Платформа Reliable Services поставляется с несколькими предварительно созданными параметрами связи. Решение о том, какой из них лучше всего подходит для вас, зависит от выбора модели программирования, платформы коммуникации и языка программирования, на котором написаны ваши службы.

Нет определенного протокола: Если у вас нет конкретного выбора платформы коммуникации, но вы хотите быстро что-то настроить и запустить, то идеальным вариантом для вас является удаленное взаимодействие служб, которое позволяет строго типизированные удаленные вызовы для надежных служб и надежных акторов. Это самый простой и быстрый способ начать работу со службой связи. Удалённое управление службами обрабатывает разрешение адресов, подключение, повторные попытки и обработку ошибок. Это доступно для приложений C# и Java.
HTTP: для взаимодействия, не зависящем от языка, HTTP предоставляет стандартный в отрасли выбор с инструментами и HTTP-серверами, доступными на многих разных языках, все поддерживаемые Service Fabric. Службы могут использовать любой стек HTTP, включая ASP.NET веб-API для приложений C#. Клиенты, написанные на C#, могут использовать классы ICommunicationClient и ServicePartitionClient, в то время как для Java следует использовать классы CommunicationClient и FabricServicePartitionClient для разрешения служб, HTTP-подключений и циклов повторных попыток.
WCF: Если у вас есть код, использующий WCF в качестве средства коммуникации, вы можете использовать WcfCommunicationListener для серверной стороны и классы WcfCommunicationClient и ServicePartitionClient для клиента. Однако это доступно только для приложений C# в кластерах на основе Windows. Дополнительные сведения см. в этой статье о реализации стека коммуникации на основе WCF.

Использование пользовательских протоколов и других платформ обмена данными

Службы могут использовать любой протокол или платформу для обмена данными, будь то пользовательский двоичный протокол через сокеты TCP или потоковая передача событий через Центры событий Azure или Центр Интернета вещей Azure. Service Fabric предоставляет API-интерфейсы связи, которые можно подключить к стеку коммуникации, а все действия по обнаружению и подключению абстрагируются от вас. Дополнительные сведения см. в этой статье о модели обмена данными с надежными службами .

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

Узнайте больше о понятиях и API, доступных в модели коммуникации Reliable Services, а затем быстро начните с удаленного управления службами или углубитесь в то, как написать слушатель связи с использованием веб-API с автономным размещением OWIN.

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