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

V Service Fabric se služba spouští někde v clusteru Service Fabric, obvykle distribuovaná mezi více virtuálních počítačů. Můžete ho přesunout z jednoho místa na jiné, a to buď vlastníkem služby, nebo automaticky službou Service Fabric. Služby nejsou staticky svázány s konkrétním počítačem nebo adresou.

Aplikace Service Fabric se obecně skládá z mnoha různých služeb, kde každá služba provádí speciální úlohu. Tyto služby spolu můžou komunikovat, aby vytvořily kompletní 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í se službami. Tento dokument popisuje, jak nastavit komunikaci se službami a mezi službami v Service Fabric.

Na této stránce najdete školicí video, které se věnuje také komunikaci služeb:

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 i komunikaci. Když službu otevře Service Fabric, má vaše služba možnost nastavit koncový bod pro příchozí požadavky pomocí libovolného požadovaného protokolu nebo komunikačního zásobníku. Vaše služba bude naslouchat na normální IP:portové adrese pomocí libovolného schématu adresování, například identifikátoru URI. Hostitelský proces může sdílet více instancí služeb nebo replik. V takovém případě budou muset buď používat jiné porty, nebo mechanismus sdílení portů, jako je 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é.

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 na jiný. 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í s přesunem 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.

Service Fabric poskytuje službu zjišťování a řešení problémů s názvem Služba vytváření názvů. Služba pojmenování udržuje tabulku, která mapuje pojmenované instance služby na adresy koncových bodů, 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 v průběhu životnosti služby nemění, při přesunu služeb se můžou změnit jenom adresy koncových bodů. To je obdobou webů, které mají konstantní adresy URL, ale ip adresa se může změnit. Podobně jako DNS na webu, který překládá adresy URL webu na IP adresy, má Service Fabric 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 spuštěné ve smyčce:

• Řešení: Získejte koncový bod, který služba publikovala, ze služby vytváření názvů.
• Připojit: Připojte se ke službě přes libovolný protokol, který používá na daném koncovém bodu.
• Opakovat: Pokus o připojení může selhat z mnoha důvodů, například pokud se služba od posledního překladu adresy koncového bodu přesunula. V takovém případě je potřeba zopakovat předchozí kroky řešení a připojení a tento cyklus se opakuje, dokud připojení nebude úspěšné.

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. Service Fabric poskytuje další služby, které používají službu Pojmenování, aby bylo snazší se připojovat mezi službami. Služba DNS a reverzní proxy služba.

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, je možnost jejich překladu pomocí standardního protokolu DNS (místo protokolu služby Naming Service) velmi pohodlná, zejména ve scénářích aplikací typu "lift and shift". Přesně to dělá služba DNS. Umožňuje namapovat názvy DNS na název služby, a proto přeložit IP adresy koncových bodů.

Jak je znázorněno na 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 přeloží služba Pojmenování, aby vrátila adresy koncových bodů, ke kterým se chcete připojit. Název DNS pro službu se poskytuje v okamžiku vytvoření.

Další podrobnosti o tom, jak používat službu DNS, najdete v článku Služba DNS v Azure Service Fabric .

Reverzní proxy služba

Reverzní proxy adresuje služby v clusteru, které zpřístupňují koncové body HTTP, včetně protokolu HTTPS. Reverzní proxy server výrazně zjednodušuje volání dalších služeb a jejich metod tím, že má specifický formát identifikátoru URI a zpracovává kroky překladu, připojení a opakování, které jsou potřeba pro komunikaci jedné služby s jinou službou pomocí služby Pojmenování. Jinými slovy, při volání jiných služeb před vámi skryje službu pojmenování tím, že to bude stejně jednoduché jako volání adresy URL.

Další podrobnosti o tom, jak používat službu reverzního proxy serveru, najdete v článku Reverzní proxy server 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 dál komunikovat mezi sebou a překládat adresy pomocí služby pojmenování, ale je potřeba provést další kroky, které externím klientům umožní připojení ke službám.

Service Fabric v Azure

Cluster Service Fabric v Azure je umístěný za Azure Load Balancer. Veškerý externí provoz do clusteru musí procházet 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á stejný otevřený port. Azure Load Balancer ví pouze o portech otevřených na uzlech, neví o portech otevřených jednotlivými službami.

Například aby bylo možné přijímat externí provoz na portu 80, musí být nakonfigurovány následující věci:

1. Napište službu, která naslouchá na portu 80. Nakonfigurujte port 80 v ServiceManifest.xml služby a otevřete ve službě naslouchací proces, například webový server v místním prostředí.

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

2. Vytvořte cluster Service Fabric v Azure a zadejte port 80 jako port vlastního koncového bodu pro typ uzlu, který bude hostovat službu. Pokud máte více než jeden typ uzlu, můžete pro službu nastavit omezení umístění , aby se zajistilo, že bude spuštěná jenom na typu uzlu, který má otevřený port vlastního koncového bodu.

   

3. 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 Azure Portal se toto nastavení automaticky nastaví pro každý nakonfigurovaný port vlastního koncového bodu.

   

4. Azure Load Balancer používá sondu k určení, jestli se má nebo nemá odesílat provoz do určitého uzlu. Sonda pravidelně kontroluje koncový bod na každém uzlu a zjišťuje, jestli uzel reaguje. Pokud sonda neobdrží odpověď po nakonfigurovaných kolikrát, nástroj pro vyrovnávání zatížení přestane posílat provoz do tohoto uzlu. Při vytváření clusteru prostřednictvím 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 vědí pouze o uzlech, nikoli o službách spuštěných na uzlech. Azure Load Balancer bude vždy posílat provoz do uzlů, které reagují na sondu, proto je potřeba pečlivě zajistit, aby na uzlech byly dostupné služby, které jsou schopné na sondu reagovat.

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

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

• Žádný konkrétní protokol: Pokud nemáte konkrétní komunikační architekturu, ale chcete něco rychle zprovoznění, je pro vás ideální možností vzdálená komunikace služby, která umožňuje volání vzdálených procedur se silnými typy pro Reliable Services a Reliable Actors. Jedná se o nejjednodušší a nejrychlejší způsob, jak začít s komunikací služby. Vzdálené komunikace služby zpracovává překlad adres služby, připojení, opakování a zpracování chyb. Je k dispozici pro aplikace v jazyce 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é service Fabric podporuje. 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# mohou využívat ICommunicationClient třídy aServicePartitionClient, zatímco pro Javu používají CommunicationClient třídy a pro překlad služeb, připojení HTTP a smyčky opakování.FabricServicePartitionClient
• WCF: Pokud máte existující kód, který jako komunikační architekturu používá WCF, můžete použít WcfCommunicationListener třídy na straně serveru a WcfCommunicationClientServicePartitionClient třídy pro klienta. Tato možnost je ale dostupná jenom pro aplikace v jazyce C# v clusterech se systémem Windows. Další podrobnosti najdete v tomto článku o implementaci komunikačního zásobníku založeného na technologii WCF.

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

Služby můžou ke komunikaci používat libovolný protokol nebo architekturu, ať už se jedná o vlastní binární protokol přes sokety TCP, nebo streamování událostí prostřednictvím Azure Event Hubs nebo Azure IoT Hub. Service Fabric poskytuje komunikační rozhraní API, do kterého můžete připojit komunikační zásobník, zatímco veškerá práce na zjišťování a připojení je od vás abstrahovaná. 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, která jsou k dispozici v modelu komunikace Reliable Services, a pak můžete rychle začít se vzdálenou komunikací služby nebo se podrobněji seznámit s tím, jak napsat naslouchací proces komunikace pomocí webového rozhraní API s vlastním hostitelem OWIN.