Ansluta och kommunicera med tjänster i Service Fabric

I Service Fabric körs en tjänst någonstans i ett Service Fabric-kluster, som vanligtvis distribueras över flera virtuella datorer. Den kan flyttas från en plats till en annan, antingen av tjänstens ägare eller automatiskt av Service Fabric. Tjänsterna är inte statiskt knutna till en viss dator eller adress.

Ett Service Fabric-program består vanligtvis av många olika tjänster, där varje tjänst utför en specialiserad uppgift. Dessa tjänster kan kommunicera med varandra för att bilda en fullständig funktion, till exempel att återge olika delar av ett webbprogram. Det finns också klientprogram som ansluter till och kommunicerar med tjänster. I det här dokumentet beskrivs hur du konfigurerar kommunikation med och mellan dina tjänster i Service Fabric.

På den här sidan finns en träningsvideo som även beskriver tjänstkommunikation:

Bring Your Own Protocol

Service Fabric hjälper till att hantera livscykeln för dina tjänster, men fattar inga beslut om vad dina tjänster gör. Detta inkluderar kommunikation. När tjänsten öppnas av Service Fabric är det din tjänsts möjlighet att konfigurera en slutpunkt för inkommande begäranden med hjälp av vilket protokoll eller vilken kommunikationsstack du vill. Tjänsten lyssnar på en normal IP:portadress med hjälp av alla adresseringsscheman, till exempel en URI. Flera tjänstinstanser eller repliker kan dela en värdprocess, i vilket fall de antingen behöver använda olika portar eller använda en mekanism för portdelning, till exempel http.sys kerneldrivrutin i Windows. I båda fallen måste varje tjänstinstans eller replik i en värdprocess vara unikt adresserbar.

Tjänstidentifiering och lösning

I ett distribuerat system kan tjänster flyttas från en dator till en annan över tid. Detta kan inträffa av olika orsaker, till exempel resursutjämning, uppgraderingar, redundans eller utskalning. Det innebär att tjänstslutpunktsadresserna ändras när tjänsten flyttas till noder med olika IP-adresser och kan öppnas på olika portar om tjänsten använder en dynamiskt vald port.

Service Fabric tillhandahåller en identifierings- och lösningstjänst som kallas namngivningstjänsten. Namngivningstjänsten har en tabell som mappar namngivna tjänstinstanser till de slutpunktsadresser som de lyssnar på. Alla namngivna tjänstinstanser i Service Fabric har unika namn som representeras som URI:er, "fabric:/MyApplication/MyService"till exempel . Namnet på tjänsten ändras inte under tjänstens livslängd. Det är bara slutpunktsadresserna som kan ändras när tjänsterna flyttas. Detta motsvarar webbplatser som har konstanta URL:er men där IP-adressen kan ändras. Och på samma sätt som DNS på webben, som löser webbplats-URL:er till IP-adresser, har Service Fabric en registrator som mappar tjänstnamn till deras slutpunktsadress.

Att lösa och ansluta till tjänster omfattar följande steg som körs i en loop:

• Lös: Hämta slutpunkten som en tjänst har publicerat från namngivningstjänsten.
• Anslut: Anslut till tjänsten via det protokoll som används på den slutpunkten.
• Försök igen: Ett anslutningsförsök kan misslyckas av flera orsaker, till exempel om tjänsten har flyttats sedan den senaste gången slutpunktsadressen löstes. I så fall måste du försöka utföra de föregående stegen för att lösa och ansluta igen, och den här cykeln upprepas tills anslutningen lyckas.

Ansluta till andra tjänster

Tjänster som ansluter till varandra i ett kluster kan vanligtvis komma åt slutpunkterna för andra tjänster direkt eftersom noderna i ett kluster finns i samma lokala nätverk. För att göra det enklare att ansluta mellan tjänster tillhandahåller Service Fabric ytterligare tjänster som använder namngivningstjänsten. En DNS-tjänst och en omvänd proxytjänst.

DNS-tjänst

Eftersom många tjänster, särskilt containerbaserade tjänster, kan ha ett befintligt URL-namn är det mycket praktiskt att kunna lösa dem med hjälp av DNS-standardprotokollet (i stället för protokollet Naming Service), särskilt i "lift and shift"-scenarier för program. Det här är precis vad DNS-tjänsten gör. Det gör att du kan mappa DNS-namn till ett tjänstnamn och därmed matcha slutpunkts-IP-adresser.

Som du ser i följande diagram mappar DNS-tjänsten, som körs i Service Fabric-klustret, DNS-namn till tjänstnamn som sedan matchas av namngivningstjänsten för att returnera slutpunktsadresserna att ansluta till. DNS-namnet för tjänsten tillhandahålls när den skapas.

Mer information om hur du använder DNS-tjänsten finns i artikeln DNS-tjänst i Azure Service Fabric .

Omvänd proxytjänst

Omvänd proxy adresserar tjänster i klustret som exponerar HTTP-slutpunkter, inklusive HTTPS. Den omvända proxyn förenklar avsevärt anropet av andra tjänster och deras metoder genom att ha ett specifikt URI-format och hanterar de åtgärder för att lösa, ansluta och försöka igen som krävs för att en tjänst ska kunna kommunicera med en annan med hjälp av namngivningstjänsten. Med andra ord döljer den namngivningstjänsten från dig när du anropar andra tjänster genom att göra det så enkelt som att anropa en URL.

Mer information om hur du använder omvänd proxytjänst finns i artikeln Omvänd proxy i Azure Service Fabric .

Anslutningar från externa klienter

Tjänster som ansluter till varandra i ett kluster kan vanligtvis komma åt slutpunkterna för andra tjänster direkt eftersom noderna i ett kluster finns i samma lokala nätverk. I vissa miljöer kan dock ett kluster finnas bakom en lastbalanserare som dirigerar inkommande trafik via en begränsad uppsättning portar. I dessa fall kan tjänster fortfarande kommunicera med varandra och lösa adresser med hjälp av namngivningstjänsten, men extra åtgärder måste vidtas för att tillåta externa klienter att ansluta till tjänster.

Service Fabric i Azure

Ett Service Fabric-kluster i Azure placeras bakom en Azure Load Balancer. All extern trafik till klustret måste passera lastbalanseraren. Lastbalanseraren vidarebefordrar automatiskt inkommande trafik på en viss port till en slumpmässig nod som har samma port öppen. Den Azure Load Balancer bara känner till portar som är öppna på noderna känner den inte till portar som öppnas av enskilda tjänster.

För att till exempel acceptera extern trafik på port 80 måste följande saker konfigureras:

1. Skriv en tjänst som lyssnar på port 80. Konfigurera port 80 i tjänstens ServiceManifest.xml och öppna en lyssnare i tjänsten, till exempel en webbserver med egen värd.

   <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. Skapa ett Service Fabric-kluster i Azure och ange port 80 som en anpassad slutpunktsport för den nodtyp som ska vara värd för tjänsten. Om du har fler än en nodtyp kan du konfigurera en placeringsbegränsning för tjänsten så att den endast körs på den nodtyp som har den anpassade slutpunktsporten öppen.

   

3. När klustret har skapats konfigurerar du Azure Load Balancer i klustrets resursgrupp för att vidarebefordra trafik på port 80. När du skapar ett kluster via Azure Portal konfigureras detta automatiskt för varje anpassad slutpunktsport som har konfigurerats.

   

4. Azure Load Balancer använder en avsökning för att avgöra om trafik ska skickas till en viss nod eller inte. Avsökningen kontrollerar regelbundet en slutpunkt på varje nod för att avgöra om noden svarar eller inte. Om avsökningen inte kan ta emot ett svar efter ett konfigurerat antal gånger slutar lastbalanseraren att skicka trafik till den noden. När du skapar ett kluster via Azure Portal konfigureras en avsökning automatiskt för varje anpassad slutpunktsport som har konfigurerats.

   

Det är viktigt att komma ihåg att Azure Load Balancer och avsökningen bara känner till noderna, inte de tjänster som körs på noderna. Azure Load Balancer skickar alltid trafik till noder som svarar på avsökningen. Därför måste du se till att tjänsterna är tillgängliga på noderna som kan svara på avsökningen.

Reliable Services: Inbyggda alternativ för kommunikations-API

Reliable Services-ramverket levereras med flera fördefinierade kommunikationsalternativ. Beslutet om vilket som fungerar bäst för dig beror på valet av programmeringsmodell, kommunikationsramverk och det programmeringsspråk som dina tjänster är skrivna i.

• Inget specifikt protokoll: Om du inte har ett visst kommunikationsramverk, men vill få igång något snabbt, är det perfekta alternativet för dig tjänstkommunikation, vilket möjliggör starkt typifierade fjärrproceduranrop för Reliable Services och Reliable Actors. Det här är det enklaste och snabbaste sättet att komma igång med tjänstkommunikation. Tjänstens fjärrkommunikation hanterar lösning av tjänstadresser, anslutning, återförsök och felhantering. Detta är tillgängligt för både C# och Java-program.
• HTTP: För språkagnostisk kommunikation tillhandahåller HTTP ett branschstandardval med verktyg och HTTP-servrar som är tillgängliga på många olika språk, som alla stöds av Service Fabric. Tjänster kan använda valfri HTTP-stack, inklusive ASP.NET webb-API för C#-program. Klienter som skrivits i C# kan utnyttja klasserna ICommunicationClient och ServicePartitionClient medan för Java använder CommunicationClient du klasserna och FabricServicePartitionClientför tjänstmatchning, HTTP-anslutningar och återförsöksloopar.
• WCF: Om du har befintlig kod som använder WCF som kommunikationsramverk kan du använda WcfCommunicationListener för serversidan och WcfCommunicationClient och ServicePartitionClient klasserna för klienten. Detta är dock endast tillgängligt för C#-program i Windows-baserade kluster. Mer information finns i den här artikeln om WCF-baserad implementering av kommunikationsstacken.

Använda anpassade protokoll och andra kommunikationsramverk

Tjänster kan använda valfritt protokoll eller ramverk för kommunikation, oavsett om det är ett anpassat binärt protokoll över TCP-sockets eller strömmande händelser via Azure Event Hubs eller Azure IoT Hub. Service Fabric tillhandahåller kommunikations-API:er som du kan ansluta din kommunikationsstack till, medan allt arbete för att identifiera och ansluta abstraheras från dig. Mer information finns i den här artikeln om reliable service-kommunikationsmodellen .

Nästa steg

Läs mer om de begrepp och API:er som är tillgängliga i reliable services-kommunikationsmodellen och kom sedan igång snabbt med tjänstkommunikation eller gå in på djupet för att lära dig hur du skriver en kommunikationslyssnare med hjälp av webb-API med OWIN-självvärd.