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 van de ene plaats naar de andere worden verplaatst, hetzij door de service-eigenaar, hetzij 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 voor 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 het 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 computer naar de andere worden verplaatst. Dit kan om verschillende redenen gebeuren, waaronder resourceverdeling, upgrades, failovers of uitschalen. Dit betekent dat service-eindpuntadressen veranderen wanneer de service naar knooppunten met verschillende IP-adressen wordt verplaatst en op verschillende poorten kan worden geopend als de service een dynamisch geselecteerde poort gebruikt.

Service Fabric biedt een detectie- en oplossingsservice met de naam Naamgevingsservice. De naamgevingsservice onderhoudt een tabel die benoemde service-exemplaren toegeeft 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. Alleen de eindpuntadressen kunnen veranderen wanneer services worden verplaatst. Dit is vergelijkbaar met websites met constante URL's, maar waar het IP-adres kan veranderen. En net als bij DNS op het web, waarmee website-URL's worden omgezet in IP-adressen, heeft Service Fabric een registrar die servicenamen toe wijst aan het eindpuntadres.

Het oplossen van en verbinding maken 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 op dat eindpunt wordt gebruikt.
• Opnieuw proberen: een verbindingspoging kan om verschillende redenen mislukken, bijvoorbeeld als de service is verplaatst sinds de laatste keer dat het eindpuntadres is omgezet. In dat geval moeten de voorgaande stappen voor het oplossen en verbinden opnieuw worden geprobeerd. Deze cyclus wordt herhaald totdat de verbinding tot stand is gebracht.

Verbinding maken met andere services

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

DNS-service

Omdat veel services, met name services in containers, een bestaande URL-naam kunnen hebben, is het erg handig om deze op te lossen met behulp van het standaard DNS-protocol (in plaats van het Naming Service-protocol), met name in lift-and-shift-scenario's voor toepassingen. Dit is precies wat de DNS-service doet. Hiermee kunt u DNS-namen toewijzen aan een servicenaam en dus eindpunt-IP-adressen omzetten.

Zoals 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 omgekeerde proxy adresseert services 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 verwerkt de stappen voor het oplossen, verbinden en opnieuw proberen die nodig zijn voor de ene service om te communiceren met een andere service met behulp van de naamgevingsservice. Met andere woorden, de naamgevingsservice wordt voor u verborgen wanneer u andere services aanroept door dit zo eenvoudig te maken als het aanroepen van een URL.

Zie het artikel Omgekeerde proxy in Azure Service Fabric voor meer informatie over het gebruik van de omgekeerde proxyservice.

Verbindingen van externe clients

Services die met elkaar in een cluster verbinding maken, hebben over het algemeen rechtstreeks toegang tot de eindpunten van andere services, omdat de knooppunten in een cluster zich in hetzelfde lokale netwerk bevinden. In sommige omgevingen kan een cluster zich echter achter een load balancer bevinden waarmee inkomend verkeer via een beperkte set poorten wordt gerouteerd. In dergelijke gevallen kunnen services nog steeds met elkaar communiceren en adressen omzetten met behulp van de naamgevingsservice, 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 de load balancer passeren. De load balancer stuurt automatisch binnenkomend verkeer op een bepaalde poort door naar een willekeurig knooppunt waarop dezelfde poort is geopend. De Azure Load Balancer weet alleen over poorten die zijn geopend op de knooppunten, 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 waarop de service wordt gehost. Als u meer dan één knooppunttype hebt, kunt u een plaatsingsbeperking voor de service instellen om ervoor te zorgen dat deze alleen wordt uitgevoerd op het knooppunttype waarvoor 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 op poort 80 door te sturen. Wanneer u een cluster maakt via de Azure Portal, wordt dit automatisch ingesteld voor elke aangepaste eindpuntpoort die is geconfigureerd.

   

4. De Azure Load Balancer gebruikt een test om te bepalen of verkeer naar een bepaald knooppunt moet worden verzonden. De test controleert periodiek een eindpunt op elk knooppunt om te bepalen of het knooppunt reageert. Als de test na een geconfigureerd aantal keren geen antwoord ontvangt, stopt de load balancer met het verzenden van verkeer naar dat knooppunt. Wanneer u een cluster maakt via de Azure Portal, wordt 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 op de test reageren. Zorg er daarom voor dat er services beschikbaar zijn op de knooppunten die op de test kunnen reageren.

Reliable Services: ingebouwde opties voor de communicatie-API

Het Reliable Services-framework wordt geleverd met verschillende vooraf gebouwde communicatieopties. De beslissing over welke het beste voor u werkt, 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 het communicatieframework, maar u iets snel aan de slag wilt laten gaan, is de ideale optie voor u externe communicatie, die sterk getypte externe procedureaanroepen voor Reliable Services en Reliable Actors mogelijk maakt. Dit is de eenvoudigste en snelste manier om aan de slag te gaan met servicecommunicatie. Externe service zorgt voor het oplossen van serviceadressen, verbinding, opnieuw proberen en foutafhandeling. Dit is beschikbaar voor zowel C#- als Java-toepassingen.
• HTTP: Voor taal-agnostische 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, inclusief ASP.NET web-API voor C#-toepassingen. Clients die zijn geschreven in C# kunnen gebruikmaken van de ICommunicationClient klassen en ServicePartitionClient , terwijl voor Java de CommunicationClient klassen en FabricServicePartitionClient gebruiken voor serviceomzetting, HTTP-verbindingen en lussen voor opnieuw proberen.
• WCF: Als u bestaande code hebt die WCF als uw communicatieframework gebruikt, kunt u de WcfCommunicationListener gebruiken voor de serverzijde en WcfCommunicationClient klassen en ServicePartitionClient voor de client. Dit is echter alleen beschikbaar voor C#-toepassingen op Windows-clusters. Zie dit artikel over op WCF gebaseerde implementatie van de communicatiestack voor meer informatie.

Aangepaste protocollen en andere communicatieframeworks gebruiken

Services kunnen elk protocol of framework gebruiken voor communicatie, of het nu gaat om een aangepast binair protocol via TCP-sockets, of het streamen van gebeurtenissen via Azure Event Hubs of Azure IoT Hub. Service Fabric biedt communicatie-API's waarop u uw communicatiestack kunt aansluiten, terwijl al het werk om te detecteren en verbinding te maken 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 of ga dieper in op het schrijven van een communicatielistener met behulp van web-API met OWIN self-host.