Csatlakozás és kommunikáció a Service Fabric szolgáltatásaival

A Service Fabricben egy szolgáltatás fut valahol egy Service Fabric-fürtben, amely általában több virtuális gép között van elosztva. A szolgáltatás tulajdonosa vagy a Service Fabric automatikusan áthelyezheti egyik helyről a másikra. A szolgáltatások nincsenek statikusan egy adott géphez vagy címhez kötve.

A Service Fabric-alkalmazások általában számos különböző szolgáltatásból állnak, ahol minden szolgáltatás speciális feladatot végez. Ezek a szolgáltatások kommunikálhatnak egymással egy teljes funkció kialakításához, például egy webalkalmazás különböző részeinek rendereléséhez. Vannak olyan ügyfélalkalmazások is, amelyek a szolgáltatásokhoz csatlakoznak és kommunikálnak. Ez a dokumentum azt ismerteti, hogyan állíthatja be a service fabricbeli és a szolgáltatások közötti kommunikációt.

Ezen az oldalon talál egy oktatóvideót, amely a szolgáltatás kommunikációját is ismerteti:

Saját protokoll használata

A Service Fabric segít a szolgáltatások életciklusának kezelésében, de nem hoz döntéseket a szolgáltatásokról. Ez magában foglalja a kommunikációt is. Amikor a Service Fabric megnyitja a szolgáltatást, a szolgáltatás így állíthat be végpontot a bejövő kérésekhez, bármilyen protokollt vagy kommunikációs vermet használva. A szolgáltatás egy normál IP:portcímet figyel bármilyen címzési sémával, például egy URI-vel. Több szolgáltatáspéldány vagy replika is megoszthat egy gazdagépfolyamatot, amely esetben vagy különböző portokat kell használniuk, vagy egy portmegosztási mechanizmust kell használniuk, például a Windows http.sys kernelillesztőjét. Mindkét esetben a gazdagépfolyamat minden szolgáltatáspéldányának vagy replikájának egyedileg címezhetőnek kell lennie.

Szolgáltatásfelderítés és -megoldás

Az elosztott rendszerekben a szolgáltatások idővel áttérhetnek egyik gépről a másikra. Ez számos okból történhet, például az erőforrás-kiosztás, a frissítések, a feladatátvételek vagy a vertikális felskálázás miatt. Ez azt jelenti, hogy a szolgáltatásvégpontok címe megváltozik, amikor a szolgáltatás különböző IP-címekkel rendelkező csomópontokra kerül, és különböző portokon nyílik meg, ha a szolgáltatás dinamikusan kiválasztott portot használ.

A Service Fabric egy elnevezési szolgáltatás nevű felderítési és megoldási szolgáltatást nyújt. Az elnevezési szolgáltatás egy táblát tart fenn, amely leképezi a nevesített szolgáltatáspéldányokat a figyelt végpontcímekre. A Service Fabricben minden nevesített szolgáltatáspéldány egyedi névvel rendelkezik, például "fabric:/MyApplication/MyService"URI-kként. A szolgáltatás neve nem változik a szolgáltatás élettartama során, csak a végpontcímek módosulhatnak a szolgáltatások áthelyezésekor. Ez hasonló az állandó URL-címmel rendelkező webhelyekhez, de az IP-cím megváltozhat. A webes DNS-hez hasonlóan, amely ip-címekre oldja fel a webhely URL-címeit, a Service Fabricnek van egy regisztrálója, amely leképezi a szolgáltatásneveket a végpont címére.

A szolgáltatások feloldásához és a szolgáltatásokhoz való csatlakozáshoz a következő lépések futnak egy hurokban:

• Megoldás: Kérje le azt a végpontot, amelyet egy szolgáltatás közzétett az elnevezési szolgáltatásból.
• Csatlakozás: Csatlakozzon a szolgáltatáshoz az adott végponton használt protokollon keresztül.
• Újrapróbálkozás: A csatlakozási kísérlet számos okból meghiúsulhat, például ha a szolgáltatás a végpont címének legutóbbi feloldása óta megváltozott. Ebben az esetben a fenti feloldási és csatlakozási lépéseket újra kell próbálkozni, és ezt a ciklust addig kell megismételni, amíg a kapcsolat sikeres nem lesz.

Csatlakozás más szolgáltatásokhoz

A fürtön belül egymáshoz csatlakozó szolgáltatások általában közvetlenül hozzáférhetnek más szolgáltatások végpontjaihoz, mert a fürt csomópontjai ugyanazon a helyi hálózaton találhatók. A szolgáltatások közötti könnyebb kapcsolódás érdekében a Service Fabric további szolgáltatásokat biztosít, amelyek az elnevezési szolgáltatást használják. EGY DNS-szolgáltatás és egy fordított proxyszolgáltatás.

DNS-szolgáltatás

Mivel számos szolgáltatás, különösen a tárolóalapú szolgáltatások, rendelkezhet egy meglévő URL-névvel, ezért a standard DNS-protokoll (és nem az elnevezési szolgáltatás protokollja) használatával történő megoldásuk nagyon kényelmes, különösen az "emelési és váltási" alkalmazások esetében. Pontosan ezt teszi a DNS-szolgáltatás. Lehetővé teszi a DNS-nevek szolgáltatásnévhez való leképezését, és ezáltal a végpont IP-címeinek feloldását.

Ahogy az alábbi ábrán is látható, a Service Fabric-fürtben futó DNS-szolgáltatás leképezi a DNS-neveket a szolgáltatásnevekre, amelyeket az elnevezési szolgáltatás felold a végpontcímek visszaadásához. A szolgáltatás DNS-neve a létrehozáskor van megadva.

A DNS-szolgáltatás használatáról további információt a DNS-szolgáltatás az Azure Service Fabricben című cikkben talál.

Fordított proxyszolgáltatás

A fordított proxy a http-végpontokat , köztük a HTTPS-t is elérhetővé tevő fürt szolgáltatásait kezeli. A fordított proxy jelentősen leegyszerűsíti a más szolgáltatások és metódusaik meghívását egy adott URI-formátummal, és kezeli a feloldási, kapcsolódási és újrapróbálkozási lépéseket, amelyek szükségesek ahhoz, hogy az egyik szolgáltatás kommunikáljon egy másikkal az elnevezési szolgáltatás használatával. Más szóval elrejti az elnevezési szolgáltatást ön elől, amikor más szolgáltatásokat hív meg úgy, hogy ezt olyan egyszerűvé teszi, mint egy URL-cím meghívása.

A fordított proxy szolgáltatás használatáról további információt a Fordított proxy az Azure Service Fabricben című cikkben talál.

Külső ügyfelek kapcsolatai

A fürtön belül egymáshoz csatlakozó szolgáltatások általában közvetlenül hozzáférhetnek más szolgáltatások végpontjaihoz, mert a fürt csomópontjai ugyanazon a helyi hálózaton találhatók. Egyes környezetekben azonban előfordulhat, hogy egy fürt egy terheléselosztó mögött van, amely korlátozott portokon keresztül irányítja a bejövő forgalmat. Ezekben az esetekben a szolgáltatások továbbra is kommunikálhatnak egymással, és feloldhatják a címeket az elnevezési szolgáltatással, de további lépéseket kell tenni annak érdekében, hogy a külső ügyfelek kapcsolódhassanak a szolgáltatásokhoz.

Service Fabric az Azure-ban

Az Azure-ban egy Service Fabric-fürt egy Azure Load Balancer mögé kerül. A fürt felé bejövő összes külső forgalomnak át kell haladnia a terheléselosztón. A terheléselosztó automatikusan továbbítja az adott porton bejövő forgalmat egy olyan véletlenszerű csomópontra , amelyen ugyanaz a port van megnyitva. A Azure Load Balancer csak a csomópontokon megnyitott portokról tud, az egyes szolgáltatások által megnyitott portokról nem.

Ha például a 80-as porton szeretne külső forgalmat fogadni, a következő dolgokat kell konfigurálni:

1. Írjon egy szolgáltatást, amely a 80-s porton figyel. Konfigurálja a 80-s portot a szolgáltatás ServiceManifest.xml, és nyisson meg egy figyelőt a szolgáltatásban, például egy saját üzemeltetésű webkiszolgálót.

   <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. Hozzon létre egy Service Fabric-fürtöt az Azure-ban, és adja meg a 80-as portot a szolgáltatást üzemeltető csomóponttípushoz tartozó egyéni végpontportként. Ha több csomóponttípussal rendelkezik, beállíthat egy elhelyezési kényszert a szolgáltatásra, hogy csak azon a csomóponttípuson fusson, amelyen meg van nyitva az egyéni végpont portja.

   

3. A fürt létrehozása után konfigurálja a Azure Load Balancer a fürt erőforráscsoportjában a forgalom továbbítására a 80-s porton. Amikor a Azure Portal keresztül hoz létre fürtöt, ez automatikusan be van állítva minden konfigurált egyéni végpontporthoz.

   

4. A Azure Load Balancer mintavétel segítségével állapítja meg, hogy egy adott csomópontra küld-e forgalmat. A mintavétel rendszeres időközönként ellenőrzi az egyes csomópontokon lévő végpontokat annak megállapításához, hogy a csomópont válaszol-e. Ha a mintavétel egy konfigurált szám után nem kap választ, a terheléselosztó nem küld forgalmat az adott csomópontra. Amikor a Azure Portal keresztül hoz létre fürtöt, a rendszer automatikusan beállít egy mintavételt minden konfigurált egyéni végpontporthoz.

   

Fontos megjegyezni, hogy a Azure Load Balancer és a mintavétel csak a csomópontokról tud, a csomópontokon futó szolgáltatásokról nem. A Azure Load Balancer mindig olyan csomópontokra küldi a forgalmat, amelyek válaszolnak a mintavételre, ezért ügyelni kell arra, hogy a mintavételre válaszoló csomópontokon elérhető szolgáltatások álljanak rendelkezésre.

Reliable Services: Beépített kommunikációs API-lehetőségek

A Reliable Services keretrendszer számos előre elkészített kommunikációs lehetőséggel rendelkezik. A programozási modell, a kommunikációs keretrendszer és a szolgáltatások által írt programozási nyelv kiválasztásától függ, hogy melyik fog a legjobban működni.

• Nincs konkrét protokoll: Ha nem rendelkezik egy adott kommunikációs keretrendszerrel, de gyorsan szeretne valamit üzembe helyezni, akkor az ideális megoldás a szolgáltatásátirányítás, amely lehetővé teszi a megbízható szolgáltatások és a reliable actors erősen típusú távoli eljáráshívásokat. Ez a legegyszerűbb és leggyorsabb módja a szolgáltatáskommunikáció használatának. A szolgáltatás-újraírás kezeli a szolgáltatáscímek feloldását, a kapcsolatot, az újrapróbálkozást és a hibakezelést. Ez C#- és Java-alkalmazásokhoz is elérhető.
• HTTP: A nyelv-agnosztikus kommunikációhoz a HTTP iparági szabványnak megfelelő választás, amely számos különböző nyelven elérhető eszközöket és HTTP-kiszolgálókat tartalmaz, mindezt a Service Fabric támogatja. A szolgáltatások bármilyen elérhető HTTP-vermet használhatnak, beleértve a C#-alkalmazásokhoz készült ASP.NET Webes API-t is. A C# nyelven írt ügyfelek használhatják a és az ICommunicationClient osztályokat, míg a Java esetében a és FabricServicePartitionClient az CommunicationClient osztályokat a szolgáltatásfeloldáshoz, a HTTP-kapcsolatokhoz és az újrapróbálkozási hurkokhoz.ServicePartitionClient
• WCF: Ha rendelkezik olyan kóddal, amely a WCF-et használja kommunikációs keretrendszerként, akkor használhatja a WcfCommunicationListener kiszolgálóoldalt és WcfCommunicationClientServicePartitionClient az osztályokat az ügyfélhez. Ez azonban csak Windows-alapú fürtökön futó C#-alkalmazásokhoz érhető el. További részletekért lásd ezt a cikket a kommunikációs verem WCF-alapú implementációjáról.

Egyéni protokollok és egyéb kommunikációs keretrendszerek használata

A szolgáltatások bármilyen protokollt vagy keretrendszert használhatnak a kommunikációhoz, legyen szó tcp-szoftvercsatornákon keresztüli egyéni bináris protokollról vagy Azure Event Hubs vagy Azure IoT Hub keresztüli streamelési eseményekről. A Service Fabric kommunikációs API-kat biztosít, amelyekbe csatlakoztathatja a kommunikációs vermet, míg a felderítendő és összekapcsolható összes munka elvont Öntől. További részletekért tekintse meg a Reliable Service kommunikációs modelljéről szóló cikket.

Következő lépések

Tudjon meg többet a Reliable Services kommunikációs modellben elérhető fogalmakról és API-król, majd gyorsan kezdje el a szolgáltatásáthelyezést , vagy alaposabban tájékozódjon arról, hogyan írhat kommunikációs figyelőt webes API-val az OWIN saját gazdagépével.