Připojení a komunikace se službami v Service Fabric

Článek
08/25/2024

V Service Fabric běží služba někde v clusteru Service Fabric, obvykle distribuovaná napříč několika virtuálními počítači. Je možné ho přesunout z jednoho místa do jiného, buď vlastníkem služby, nebo automaticky service Fabric. Služby nejsou staticky svázané s konkrétním počítačem nebo adresou.

Aplikace Service Fabric se obvykle skládá z mnoha různých služeb, kde každá služba provádí specializovanou úlohu. Tyto služby můžou vzájemně komunikovat, aby vytvořily úplnou funkci, například vykreslování různých částí webové aplikace. Existují také klientské aplikace, které se připojují ke službám a komunikují s ní. Tento dokument popisuje, jak nastavit komunikaci se službami Service Fabric a mezi těmito službami.

Na této stránce najdete školicí video, které se zabývá také komunikací služby:

Používání vlastního protokolu

Service Fabric pomáhá spravovat životní cyklus vašich služeb, ale nerozhoduje o tom, co vaše služby dělají. To zahrnuje komunikaci. Když service otevírá Service Fabric, je to možnost nastavit koncový bod pro příchozí požadavky pomocí libovolného protokolu nebo zásobníku komunikace. Vaše služba bude naslouchat na normální ADRESE IP:port pomocí libovolného schématu adresování, jako je identifikátor URI. V takovém případě může hostitelský proces sdílet více instancí služby nebo replik, v takovém případě budou muset buď použít jiné porty, nebo použít mechanismus sdílení portů, například ovladač jádra http.sys ve Windows. V obou případech musí být každá instance služby nebo replika v hostitelském procesu jedinečně adresovatelná.

koncové body služby

Zjišťování a řešení služeb

V distribuovaném systému se služby můžou v průběhu času přesouvat z jednoho počítače do jiného. K tomu může dojít z různých důvodů, včetně vyrovnávání prostředků, upgradů, převzetí služeb při selhání nebo horizontálního navýšení kapacity. To znamená, že se adresy koncových bodů služby mění při přesunu služby na uzly s různými IP adresami a můžou se otevřít na různých portech, pokud služba používá dynamicky vybraný port.

Distribuce služeb

Service Fabric poskytuje službu zjišťování a překladu, která se nazývá Služba pojmenování. Služba pojmenování udržuje tabulku, která mapuje pojmenované instance služby na adresy koncového bodu, na které naslouchají. Všechny pojmenované instance služby v Service Fabric mají jedinečné názvy reprezentované jako identifikátory URI, "fabric:/MyApplication/MyService"například . Název služby se po celou dobu životnosti služby nezmění, jedná se pouze o adresy koncových bodů, které se můžou při přesunu služeb změnit. Je to podobné webům, které mají konstantní adresy URL, ale kde se ip adresa může změnit. Podobně jako DNS na webu, který překládá adresy URL webů na IP adresy, má Service Fabric registrátora, který mapuje názvy služeb na adresu koncového bodu.

Diagram znázorňující, že Service Fabric má registrátora, který mapuje názvy služeb na adresu koncového bodu.

Řešení a připojení ke službám zahrnuje následující kroky, které se spustí ve smyčce:

Řešení: Získejte koncový bod, který služba publikovala ze služby pojmenování.
Připojení: Připojte se ke službě přes jakýkoli protokol, který v daném koncovém bodu používá.
Opakování: Pokus o připojení může selhat z libovolného počtu důvodů, například pokud se služba přesunula od posledního vyřešení adresy koncového bodu. V takovém případě je potřeba zopakovat předchozí kroky řešení a připojení a tento cyklus se opakuje, dokud se připojení nepodaří.

Připojení k jiným službám

Služby, které se vzájemně připojují uvnitř clusteru, mají obecně přímý přístup ke koncovým bodům jiných služeb, protože uzly v clusteru jsou ve stejné místní síti. Kvůli snadnějšímu připojení mezi službami poskytuje Service Fabric další služby, které používají službu pojmenování. Služba DNS a služba reverzního proxy serveru.

Služba DNS

Vzhledem k tomu, že mnoho služeb, zejména kontejnerizovaných služeb, může mít existující název adresy URL, takže je možné je přeložit pomocí standardního protokolu DNS (místo protokolu Naming Service), je velmi pohodlný, zejména ve scénářích "lift and shift" aplikace. Přesně to dělá služba DNS. Umožňuje mapování názvů DNS na název služby a překlad IP adres koncových bodů.

Jak je znázorněno v následujícím diagramu, služba DNS spuštěná v clusteru Service Fabric mapuje názvy DNS na názvy služeb, které pak služba pojmenování přeloží, aby vrátila adresy koncových bodů pro připojení. Název DNS pro službu se poskytuje při vytváření.

Diagram znázorňující, jak služba DNS při spuštění v clusteru Service Fabric mapuje názvy DNS na názvy služeb, které pak služba pojmenování přeloží, aby vrátila adresy koncových bodů pro připojení.

Další podrobnosti o používání služby DNS najdete v článku o službě DNS v Azure Service Fabric .

Reverzní proxy služba

Reverzní proxy adresy služby v clusteru, které zpřístupňují koncové body HTTP, včetně PROTOKOLU HTTPS. Reverzní proxy server výrazně zjednodušuje volání jiných služeb a jejich metod tím, že má určitý formát identifikátoru URI a zpracovává překlad, připojení, kroky opakování vyžadované pro komunikaci jedné služby pomocí služby pojmenování. Jinými slovy, skryje službu pojmenování před vámi při volání jiných služeb tak jednoduché jako volání adresy URL.

Diagram znázorňující, jak služby reverzního proxy serveru adresují v clusteru, které zpřístupňují koncové body HTTP včetně PROTOKOLU HTTPS

Další podrobnosti o tom, jak používat službu reverzního proxy serveru, najdete v článku o reverzním proxy serveru v Azure Service Fabric .

Připojení z externích klientů

Služby, které se vzájemně připojují uvnitř clusteru, mají obecně přímý přístup ke koncovým bodům jiných služeb, protože uzly v clusteru jsou ve stejné místní síti. V některých prostředích ale může být cluster za nástrojem pro vyrovnávání zatížení, který směruje příchozí provoz přes omezenou sadu portů. V těchto případech můžou služby vzájemně komunikovat a řešit adresy pomocí služby pojmenování, ale je potřeba provést další kroky, aby se externí klienti mohli připojit ke službám.

Service Fabric v Azure

Cluster Service Fabric v Azure se nachází za Nástrojem pro vyrovnávání zatížení Azure. Veškerý externí provoz do clusteru musí projít nástrojem pro vyrovnávání zatížení. Nástroj pro vyrovnávání zatížení automaticky přesměruje příchozí provoz na daném portu do náhodného uzlu , který má otevřený stejný port. Azure Load Balancer ví jenom o portech otevřených na uzlech, ale neví o portech otevřených jednotlivými službami.

Topologie Azure Load Balanceru a Service Fabric

Pokud například chcete přijímat externí provoz na portu 80, musí být nakonfigurované následující věci:

Napište službu, která naslouchá na portu 80. Nakonfigurujte port 80 v ServiceManifest.xml služby a otevřete v této službě naslouchací proces, například na místním webovém serveru.

<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;		
        }

        ...
    }

Vytvořte cluster Service Fabric v Azure a jako vlastní port koncového bodu zadejte port 80 pro typ uzlu, který bude službu hostovat. Pokud máte více než jeden typ uzlu, můžete ve službě nastavit omezení umístění, aby se zajistilo, že běží jenom na typu uzlu, který má otevřený port vlastního koncového bodu.
Po vytvoření clusteru nakonfigurujte Azure Load Balancer ve skupině prostředků clusteru tak, aby předával provoz na portu 80. Při vytváření clusteru prostřednictvím webu Azure Portal se toto nastavení nastaví automaticky pro každý nakonfigurovaný port vlastního koncového bodu.
Azure Load Balancer používá sondu k určení, jestli má odesílat provoz do určitého uzlu nebo ne. Sonda pravidelně kontroluje koncový bod na každém uzlu a zjišťuje, jestli uzel reaguje nebo ne. Pokud sonda po nakonfigurovaném počtu nedorazí odpověď, nástroj pro vyrovnávání zatížení přestane odesílat provoz do tohoto uzlu. Při vytváření clusteru prostřednictvím webu Azure Portal se pro každý nakonfigurovaný port vlastního koncového bodu automaticky nastaví sonda.

Je důležité si uvědomit, že Azure Load Balancer a sonda znají pouze uzly, ne služby spuštěné na uzlech. Azure Load Balancer vždy odesílá provoz do uzlů, které reagují na sondu, takže je potřeba zajistit dostupnost služeb na uzlech, které jsou schopné reagovat na sondu.

Reliable Services: Integrované možnosti rozhraní API pro komunikaci

Architektura Reliable Services se dodává s několika předem připravenými možnostmi komunikace. Rozhodnutí o tom, který z nich bude pro vás nejvhodnější, závisí na výběru programovacího modelu, komunikačního rozhraní a programovacího jazyka, ve kterém jsou vaše služby napsané.

Žádný konkrétní protokol: Pokud nemáte určitou volbu komunikační architektury, ale chcete něco rychle zprovoznět, je ideální možností vzdálené komunikace služby, která umožňuje volání spolehlivých služeb a Reliable Actors se silnými typy procedur. Jedná se o nejjednodušší a nejrychlejší způsob, jak začít se službou komunikovat. Vzdálené komunikace služby zpracovává překlad adres služeb, připojení, opakování a zpracování chyb. Tato možnost je k dispozici pro aplikace jazyka C# i Java.
HTTP: Pro komunikaci nezávislou na jazyce poskytuje http standardní volbu s nástroji a servery HTTP dostupnými v mnoha různých jazycích, které podporuje Service Fabric. Služby můžou používat libovolný dostupný zásobník HTTP, včetně ASP.NET webového rozhraní API pro aplikace jazyka C#. Klienti napsaní v jazyce C# můžou využívat třídy ICommunicationClient a ServicePartitionClient třídy, zatímco pro Javu používají CommunicationClient třídy FabricServicePartitionClient pro překlad služeb, připojení HTTP a smyčky opakování.
WCF: Pokud máte existující kód, který jako komunikační architekturu používá WCF, můžete použít WcfCommunicationListener pro straně serveru a WcfCommunicationClient ServicePartitionClient třídy klienta. Tato možnost je však k dispozici pouze pro aplikace jazyka C# v clusterech založených na Windows. Další podrobnosti najdete v tomto článku o implementaci komunikačního zásobníku založeného na WCF.

Použití vlastních protokolů a dalších komunikačních architektur

Služby můžou pro komunikaci používat jakýkoli protokol nebo architekturu, ať už jde o vlastní binární protokol přes sokety TCP, nebo streamované události prostřednictvím služby Azure Event Hubs nebo Azure IoT Hubu. Service Fabric poskytuje komunikační rozhraní API, ke kterým můžete připojit komunikační zásobník, zatímco veškerá práce ke zjišťování a připojení se od vás abstrahuje. Další podrobnosti najdete v tomto článku o modelu komunikace Reliable Service.

Další kroky

Přečtěte si další informace o konceptech a rozhraních API dostupných v modelu komunikace Reliable Services a začněte rychle komunikovat se službou nebo se podrobně naučíte psát naslouchací proces komunikace pomocí webového rozhraní API s vlastním hostitelem OWIN.

Sdílet prostřednictvím