Verbinding maken en communiceren met services in Service Fabric

In Service Fabric wordt een service ergens in een Service Fabric-cluster uitgevoerd, meestal verdeeld over meerdere VM's. Het kan worden verplaatst van de ene plaats naar de andere, door de service-eigenaar of automatisch door Service Fabric. Services zijn niet statisch gekoppeld aan een bepaalde computer of een bepaald adres.

Een Service Fabric-toepassing bestaat over het algemeen uit veel verschillende services, waarbij elke service een gespecialiseerde taak uitvoert. Deze services kunnen met elkaar communiceren om een volledige functie te vormen, zoals het weergeven van verschillende onderdelen van een webtoepassing. Er zijn ook clienttoepassingen die verbinding maken met en communiceren met services. In dit document wordt beschreven hoe u communicatie met en tussen uw services in Service Fabric instelt.

Bekijk deze pagina voor een trainingsvideo die ook servicecommunicatie bespreekt:

Bring Your Own Protocol

Service Fabric helpt bij het beheren van de levenscyclus van uw services, maar neemt geen beslissingen over wat uw services doen. Dit omvat communicatie. Wanneer uw service wordt geopend door Service Fabric, is dat de mogelijkheid van uw service om een eindpunt in te stellen voor binnenkomende aanvragen, met behulp van het gewenste protocol of de communicatiestack. Uw service luistert op een normaal IP:poortadres met behulp van een adresseringsschema, zoals een URI. Meerdere service-exemplaren of replica's kunnen een hostproces delen. In dat geval moeten ze verschillende poorten gebruiken of een mechanisme voor delen van poorten gebruiken, zoals het http.sys kernelstuurprogramma in Windows. In beide gevallen moet elk service-exemplaar of elke replica in een hostproces uniek adresseerbaar zijn.

Servicedetectie en -oplossing

In een gedistribueerd systeem kunnen services na verloop van tijd van de ene machine naar de andere worden verplaatst. Dit kan om verschillende redenen gebeuren, waaronder resourceverdeling, upgrades, failovers of uitschalen. Dit betekent dat de adressen van service-eindpunten veranderen wanneer de service wordt verplaatst naar knooppunten met verschillende IP-adressen, en mogelijk worden geopend op verschillende poorten als de service een dynamisch geselecteerde poort gebruikt.

Service Fabric biedt een detectie- en oplossingsservice met de naam Naming Service. De Naamgevingsservice onderhoudt een tabel waarmee benoemde service-exemplaren worden toegewezen aan de eindpuntadressen waarop ze luisteren. Alle benoemde service-exemplaren in Service Fabric hebben unieke namen die worden weergegeven als URI's, "fabric:/MyApplication/MyService"bijvoorbeeld. De naam van de service verandert niet gedurende de levensduur van de service. Dit zijn alleen de eindpuntadressen die kunnen worden gewijzigd wanneer services worden verplaatst. Dit is vergelijkbaar met websites met constante URL's, maar waar het IP-adres kan veranderen. Service Fabric heeft een registrar die servicenamen toebedeelt aan het eindpuntadres, net als DNS op het web, waarmee website-URL's worden omgezet naar IP-adressen.

Het oplossen en verbinden met services omvat de volgende stappen die in een lus worden uitgevoerd:

• Oplossen: haal het eindpunt op dat een service heeft gepubliceerd vanuit de Naamgevingsservice.
• Verbinding maken: Maak verbinding met de service via het protocol dat wordt gebruikt op dat eindpunt.
• Opnieuw proberen: een verbindingspoging kan om verschillende redenen mislukken, bijvoorbeeld als de service is verplaatst sinds de laatste keer dat het eindpuntadres is opgelost. In dat geval moeten de voorgaande stappen voor het oplossen en verbinden opnieuw worden geprobeerd en wordt deze cyclus herhaald totdat de verbinding is geslaagd.

Verbinding maken met andere services

Services die verbinding maken met elkaar binnen een cluster, hebben doorgaans rechtstreeks toegang tot de eindpunten van andere services, omdat de knooppunten in een cluster zich in hetzelfde lokale netwerk bevinden. Service Fabric biedt extra services die gebruikmaken van de Naming Service om gemakkelijker verbinding te maken tussen services. Een DNS-service en een omgekeerde proxyservice.

DNS-service

Aangezien veel services, met name in containers geplaatste services, een bestaande URL-naam kunnen hebben, kan deze worden omgezet met behulp van het standaard-DNS-protocol (in plaats van het Naming Service-protocol) is zeer handig, met name in scenario's voor 'lift and shift' van toepassingen. Dit is precies wat de DNS-service doet. Hiermee kunt u DNS-namen toewijzen aan een servicenaam en daarom EINDPUNT-IP-adressen omzetten.

Zoals wordt weergegeven in het volgende diagram, wijst de DNS-service, die wordt uitgevoerd in het Service Fabric-cluster, DNS-namen toe aan servicenamen die vervolgens worden omgezet door de Naamgevingsservice om de eindpuntadressen te retourneren waarmee verbinding moet worden gemaakt. De DNS-naam voor de service wordt opgegeven op het moment van maken.

Zie het artikel DNS-service in Azure Service Fabric voor meer informatie over het gebruik van de DNS-service.

Omgekeerde proxyservice

De services voor omgekeerde proxyadressen in het cluster die HTTP-eindpunten beschikbaar maken, inclusief HTTPS. De omgekeerde proxy vereenvoudigt het aanroepen van andere services en hun methoden aanzienlijk door een specifieke URI-indeling te hebben en de oplossing af te handelen, verbinding te maken, stappen voor opnieuw proberen die nodig zijn om met een andere service te communiceren met behulp van de Naming Service. Met andere woorden, het verbergt de naamgevingsservice voor u bij het aanroepen van andere services door dit net zo eenvoudig te maken als het aanroepen van een URL.

Zie het artikel Reverse proxy in Azure Service Fabric voor meer informatie over het gebruik van de reverse proxy-service.

Verbindingen van externe clients

Services die verbinding maken met elkaar binnen een cluster, hebben doorgaans rechtstreeks toegang tot de eindpunten van andere services, omdat de knooppunten in een cluster zich in hetzelfde lokale netwerk bevinden. In sommige omgevingen bevindt een cluster zich echter achter een load balancer die inkomend verkeer routeert via een beperkte set poorten. In deze gevallen kunnen services nog steeds met elkaar communiceren en adressen oplossen met behulp van de Naming Service, maar er moeten extra stappen worden ondernomen om externe clients verbinding te laten maken met services.

Service Fabric in Azure

Een Service Fabric-cluster in Azure wordt achter een Azure Load Balancer geplaatst. Al het externe verkeer naar het cluster moet via de load balancer worden doorgegeven. De load balancer stuurt verkeer automatisch door op een bepaalde poort naar een willekeurig knooppunt dat dezelfde poort heeft geopend. De Azure Load Balancer weet alleen over poorten die zijn geopend op de knooppunten, maar weet niet over poorten die door afzonderlijke services worden geopend.

Als u bijvoorbeeld extern verkeer op poort 80 wilt accepteren, moeten de volgende zaken worden geconfigureerd:

1. Schrijf een service die luistert op poort 80. Configureer poort 80 in de ServiceManifest.xml van de service en open een listener in de service, bijvoorbeeld een zelf-hostende webserver.

   <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. Maak een Service Fabric-cluster in Azure en geef poort 80 op als een aangepaste eindpuntpoort voor het knooppunttype dat als host fungeert voor de service. Als u meer dan één knooppunttype hebt, kunt u een plaatsingsbeperking instellen voor de service om ervoor te zorgen dat deze alleen wordt uitgevoerd op het knooppunttype waarop de aangepaste eindpuntpoort is geopend.

   

3. Zodra het cluster is gemaakt, configureert u de Azure Load Balancer in de resourcegroep van het cluster om verkeer door te sturen op poort 80. Wanneer u een cluster maakt via Azure Portal, wordt dit automatisch ingesteld voor elke aangepaste eindpuntpoort die is geconfigureerd.

   

4. De Azure Load Balancer maakt gebruik van een test om te bepalen of verkeer wel of niet naar een bepaald knooppunt moet worden verzonden. De test controleert periodiek een eindpunt op elk knooppunt om te bepalen of het knooppunt al dan niet reageert. Als de test na een geconfigureerd aantal keren geen antwoord meer ontvangt, stopt de load balancer met het verzenden van verkeer naar dat knooppunt. Wanneer u een cluster maakt via Azure Portal, wordt er automatisch een test ingesteld voor elke aangepaste eindpuntpoort die is geconfigureerd.

   

Het is belangrijk om te onthouden dat de Azure Load Balancer en de test alleen weten over de knooppunten, niet de services die op de knooppunten worden uitgevoerd. De Azure Load Balancer verzendt altijd verkeer naar knooppunten die reageren op de test, dus zorg ervoor dat services beschikbaar zijn op de knooppunten die op de test kunnen reageren.

Reliable Services: ingebouwde communicatie-API-opties

Het Reliable Services-framework wordt geleverd met verschillende vooraf gebouwde communicatieopties. De beslissing over welke u het beste kunt gebruiken, is afhankelijk van de keuze van het programmeermodel, het communicatieframework en de programmeertaal waarin uw services zijn geschreven.

• Geen specifiek protocol: Als u geen specifieke keuze hebt voor communicatieframework, maar u snel iets wilt laten werken, is de ideale optie voor externe communicatie van services, waardoor sterk getypte externe procedures worden aangeroepen voor Reliable Services en Reliable Actors. Dit is de eenvoudigste en snelste manier om aan de slag te gaan met servicecommunicatie. Externe service verwerkt de oplossing van serviceadressen, verbindingen, opnieuw proberen en foutafhandeling. Dit is beschikbaar voor zowel C# als Java-toepassingen.
• HTTP: Voor taalagnostische communicatie biedt HTTP een industriestandaard keuze met hulpprogramma's en HTTP-servers die beschikbaar zijn in veel verschillende talen, allemaal ondersteund door Service Fabric. Services kunnen elke beschikbare HTTP-stack gebruiken, waaronder ASP.NET Web-API voor C#-toepassingen. Clients die zijn geschreven in C# kunnen gebruikmaken van de ICommunicationClient en ServicePartitionClient klassen, terwijl voor Java de CommunicationClient en FabricServicePartitionClient klassen worden gebruikt voor serviceomzetting, HTTP-verbindingen en lussen voor opnieuw proberen.
• WCF: Als u bestaande code hebt die GEBRUIKMAAKT van WCF als uw communicatieframework, kunt u de WcfCommunicationListener code voor de server en WcfCommunicationClient klassen ServicePartitionClient voor de client gebruiken. Dit is echter alleen beschikbaar voor C#-toepassingen op Windows-clusters. Zie dit artikel voor meer informatie over op WCF gebaseerde implementatie van de communicatiestack.

Aangepaste protocollen en andere communicatieframeworks gebruiken

Services kunnen elk protocol of framework voor communicatie gebruiken, ongeacht of het een aangepast binair protocol is via TCP-sockets of streaminggebeurtenissen via Azure Event Hubs of Azure IoT Hub. Service Fabric biedt communicatie-API's waarmee u uw communicatiestack kunt aansluiten, terwijl al het werk voor het detecteren en verbinden van u wordt geabstraheerd. Zie dit artikel over het Reliable Service-communicatiemodel voor meer informatie.

Volgende stappen

Meer informatie over de concepten en API's die beschikbaar zijn in het Reliable Services-communicatiemodel, en ga vervolgens snel aan de slag met externe communicatie van services of ga uitgebreider te werk om te leren hoe u een communicatielistener schrijft met behulp van web-API met OWIN self-host.