Nawiązywanie połączenia z usługami i komunikowanie się z nimi w usłudze Service Fabric

W usłudze Service Fabric usługa działa gdzieś w klastrze usługi Service Fabric, zwykle dystrybuowana między wieloma maszynami wirtualnymi. Może zostać przeniesiony z jednego miejsca do innego przez właściciela usługi lub automatycznie przez usługę Service Fabric. Usługi nie są statycznie powiązane z określoną maszyną lub adresem.

Aplikacja usługi Service Fabric zwykle składa się z wielu różnych usług, w których każda usługa wykonuje wyspecjalizowane zadanie. Te usługi mogą komunikować się ze sobą w celu utworzenia pełnej funkcji, takiej jak renderowanie różnych części aplikacji internetowej. Istnieją również aplikacje klienckie, które łączą się z usługami i komunikują się z nimi. W tym dokumencie omówiono sposób konfigurowania komunikacji z usługami i między nimi w usłudze Service Fabric.

Sprawdź tę stronę, aby zapoznać się z filmem wideo szkoleniowym, który zawiera również omówienie komunikacji między usługami:

Korzystanie z własnego protokołu

Usługa Service Fabric pomaga zarządzać cyklem życia usług, ale nie podejmuje decyzji dotyczących tego, co robią usługi. Obejmuje to komunikację. Gdy usługa jest otwierana przez usługę Service Fabric, możesz skonfigurować punkt końcowy dla żądań przychodzących przy użyciu dowolnego żądanego stosu protokołu lub komunikacji. Usługa będzie nasłuchiwać normalnego adresu IP:port przy użyciu dowolnego schematu adresowania, takiego jak identyfikator URI. Wiele wystąpień usług lub replik może współużytkować proces hosta, w takim przypadku musi użyć różnych portów lub użyć mechanizmu udostępniania portów, takiego jak sterownik jądra http.sys w systemie Windows. W obu przypadkach każde wystąpienie usługi lub replika w procesie hosta muszą być unikatowo adresowalne.

Odnajdywanie i rozwiązywanie problemów z usługami

W systemie rozproszonym usługi mogą przechodzić z jednej maszyny do innej w czasie. Może się to zdarzyć z różnych powodów, takich jak równoważenie zasobów, uaktualnienia, tryb failover lub skalowanie w poziomie. Oznacza to, że adresy punktów końcowych usługi zmieniają się w miarę przenoszenia usługi do węzłów z różnymi adresami IP i mogą być otwierane na różnych portach, jeśli usługa używa dynamicznie wybranego portu.

Usługa Service Fabric udostępnia usługę odnajdywania i rozwiązywania nazywaną usługą nazewnictwa. Usługa Nazewnictwa obsługuje tabelę, która mapuje nazwane wystąpienia usługi na adresy punktów końcowych, na których nasłuchują. Wszystkie nazwane wystąpienia usługi w usłudze Service Fabric mają unikatowe nazwy reprezentowane jako identyfikatory URI, na przykład "fabric:/MyApplication/MyService". Nazwa usługi nie zmienia się w okresie istnienia usługi, ale tylko adresy punktów końcowych, które mogą ulec zmianie po przeniesieniu usług. Jest to analogiczne do witryn internetowych, które mają stałe adresy URL, ale gdzie adres IP może ulec zmianie. Podobnie jak system DNS w internecie, który rozpoznaje adresy URL witryn internetowych na adresy IP, usługa Service Fabric ma rejestratora mapowania nazw usług na adres punktu końcowego.

Rozwiązywanie i nawiązywanie połączenia z usługami obejmuje następujące kroki wykonywane w pętli:

• Rozwiąż: uzyskaj punkt końcowy opublikowany przez usługę z usługi Nazewnictwa.
• Połącz: połącz się z usługą za pośrednictwem dowolnego protokołu używanego w tym punkcie końcowym.
• Ponów próbę: Próba połączenia może zakończyć się niepowodzeniem z dowolnej liczby powodów, na przykład jeśli usługa została przeniesiona od czasu ostatniego rozwiązania adresu punktu końcowego. W takim przypadku należy ponowić poprzednie kroki rozwiązywania problemów i połączenia, a ten cykl będzie powtarzany do momentu pomyślnego nawiązania połączenia.

Nawiązywanie połączenia z innymi usługami

Usługi łączące się ze sobą wewnątrz klastra zazwyczaj mogą uzyskiwać bezpośredni dostęp do punktów końcowych innych usług, ponieważ węzły w klastrze znajdują się w tej samej sieci lokalnej. Aby ułatwić nawiązywanie połączenia między usługami, usługa Service Fabric udostępnia dodatkowe usługi korzystające z usługi Naming Service. Usługa DNS i usługa zwrotnego serwera proxy.

Usługa DNS

Ponieważ wiele usług, zwłaszcza usług konteneryzowanych, może mieć istniejącą nazwę adresu URL, możliwość ich rozpoznawania przy użyciu standardowego protokołu DNS (a nie protokołu usługi Naming Service) jest bardzo wygodna, szczególnie w scenariuszach "lift and shift" aplikacji. Jest to dokładnie to, co robi usługa DNS. Umożliwia mapowania nazw DNS na nazwę usługi, a tym samym rozpoznawanie adresów IP punktu końcowego.

Jak pokazano na poniższym diagramie, usługa DNS uruchomiona w klastrze usługi Service Fabric mapuje nazwy DNS na nazwy usług, które następnie są rozpoznawane przez usługę Naming Service, aby zwrócić adresy punktu końcowego do nawiązania połączenia. Nazwa DNS usługi jest udostępniana w momencie tworzenia.

Aby uzyskać więcej informacji na temat korzystania z usługi DNS, zobacz artykuł Usługa DNS w usłudze Azure Service Fabric .

Usługa zwrotnego serwera proxy

Zwrotny serwer proxy adresuje usługi w klastrze, które uwidacznia punkty końcowe HTTP, w tym HTTPS. Zwrotny serwer proxy znacznie upraszcza wywoływanie innych usług i ich metod przez użycie określonego formatu identyfikatora URI i obsługuje rozwiązywanie problemów, nawiązywanie połączenia, ponawianie kroków wymaganych przez jedną usługę do komunikowania się z inną przy użyciu usługi Nazewnictwa. Innymi słowy, usługa nazewnictwa ukrywa usługę nazewnictwa podczas wywoływania innych usług, co sprawia, że jest to tak proste, jak wywoływanie adresu URL.

Aby uzyskać więcej informacji na temat korzystania z usługi zwrotnego serwera proxy, zobacz Artykuł Reverse proxy in Azure Service Fabric (Zwrotny serwer proxy w usłudze Azure Service Fabric ).

Połączenia z klientów zewnętrznych

Usługi łączące się ze sobą wewnątrz klastra zazwyczaj mogą uzyskiwać bezpośredni dostęp do punktów końcowych innych usług, ponieważ węzły w klastrze znajdują się w tej samej sieci lokalnej. Jednak w niektórych środowiskach klaster może znajdować się za modułem równoważenia obciążenia, który kieruje ruch przychodzący przez ograniczony zestaw portów. W takich przypadkach usługi mogą nadal komunikować się ze sobą i rozpoznawać adresy przy użyciu usługi Naming Service, ale należy wykonać dodatkowe kroki, aby umożliwić klientom zewnętrznym łączenie się z usługami.

Usługa Service Fabric na platformie Azure

Klaster usługi Service Fabric na platformie Azure znajduje się za usługą Azure Load Balancer. Cały ruch zewnętrzny do klastra musi przechodzić przez moduł równoważenia obciążenia. Moduł równoważenia obciążenia automatycznie przekazuje ruch przychodzący na danym porcie do losowego węzła , który ma otwarty ten sam port. Usługa Azure Load Balancer wie tylko o otwartych portach w węzłach, ale nie wie o portach otwartych przez poszczególne usługi.

Aby na przykład akceptować ruch zewnętrzny na porcie 80, należy skonfigurować następujące elementy:

1. Napisz usługę, która nasłuchuje na porcie 80. Skonfiguruj port 80 w ServiceManifest.xml usługi i otwórz odbiornik w usłudze, na przykład własny serwer internetowy.

   <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. Utwórz klaster usługi Service Fabric na platformie Azure i określ port 80 jako niestandardowy port punktu końcowego dla typu węzła, który będzie hostować usługę. Jeśli masz więcej niż jeden typ węzła, możesz skonfigurować ograniczenie umieszczania w usłudze, aby upewnić się, że działa tylko w typie węzła, który ma otwarty niestandardowy port punktu końcowego.

   

3. Po utworzeniu klastra skonfiguruj usługę Azure Load Balancer w grupie zasobów klastra, aby przekazywać ruch na porcie 80. Podczas tworzenia klastra za pośrednictwem witryny Azure Portal jest ona konfigurowana automatycznie dla każdego skonfigurowanego niestandardowego portu punktu końcowego.

   

4. Usługa Azure Load Balancer używa sondy do określenia, czy ruch ma być wysyłany do określonego węzła. Sonda okresowo sprawdza punkt końcowy w każdym węźle, aby określić, czy węzeł odpowiada. Jeśli sonda nie otrzyma odpowiedzi po skonfigurowanej liczbie razy, moduł równoważenia obciążenia przestanie wysyłać ruch do tego węzła. Podczas tworzenia klastra za pośrednictwem witryny Azure Portal sonda jest automatycznie konfigurowana dla każdego skonfigurowanego niestandardowego portu punktu końcowego.

   

Należy pamiętać, że usługa Azure Load Balancer i sonda wiedzą tylko o węzłach, a nie o usługach uruchomionych w węzłach. Usługa Azure Load Balancer zawsze wysyła ruch do węzłów, które odpowiadają na sondę, dlatego należy zadbać o to, aby usługi były dostępne w węzłach, które mogą odpowiedzieć na sondę.

Reliable Services: wbudowane opcje interfejsu API komunikacji

Struktura Reliable Services jest dostarczana z kilkoma wstępnie utworzonymi opcjami komunikacji. Decyzja o tym, która będzie najlepsza dla Ciebie, zależy od wyboru modelu programowania, struktury komunikacyjnej i języka programowania, w którym są napisane usługi.

• Brak konkretnego protokołu: jeśli nie masz konkretnego wyboru struktury komunikacji, ale chcesz szybko uruchomić coś, idealną opcją jest komunikacja zdalna, która umożliwia silnie typizowane wywołania procedur zdalnych dla usług Reliable Services i Reliable Actors. Jest to najprostszy i najszybszy sposób na rozpoczęcie komunikacji z usługą. Komunikacja zdalna usługi obsługuje rozpoznawanie adresów usług, połączenia, ponawiania prób i obsługi błędów. Jest to dostępne zarówno dla aplikacji języka C#, jak i Java.
• HTTP: W przypadku komunikacji niezależnej od języka protokół HTTP udostępnia standard branżowy z narzędziami i serwerami HTTP dostępnymi w wielu różnych językach— wszystkie obsługiwane przez usługę Service Fabric. Usługi mogą używać dowolnego dostępnego stosu HTTP, w tym ASP.NET internetowego interfejsu API dla aplikacji języka C#. Klienci napisani w języku C# mogą korzystać z ICommunicationClient klas i, natomiast w przypadku języka Java użyj CommunicationClient klas i ServicePartitionClient FabricServicePartitionClient w celu rozpoznawania usług, połączeń HTTP i pętli ponawiania prób.
• WCF: Jeśli masz istniejący kod, który używa programu WCF jako struktury komunikacji, możesz użyć elementu WcfCommunicationListener dla serwera po stronie serwera i WcfCommunicationClient ServicePartitionClient klas dla klienta. Jest to jednak dostępne tylko dla aplikacji języka C# w klastrach opartych na systemie Windows. Aby uzyskać więcej informacji, zobacz ten artykuł dotyczący implementacji stosu komunikacyjnego opartego na programie WCF.

Używanie niestandardowych protokołów i innych struktur komunikacyjnych

Usługi mogą używać dowolnego protokołu lub struktury do komunikacji, niezależnie od tego, czy jest to niestandardowy protokół binarny za pośrednictwem gniazd TCP, czy zdarzeń przesyłania strumieniowego za pośrednictwem usługi Azure Event Hubs lub usługi Azure IoT Hub. Usługa Service Fabric udostępnia interfejsy API komunikacji, z którymi można podłączyć stos komunikacji, podczas gdy wszystkie prace nad odnajdywaniem i nawiązywaniem połączenia są abstrahowane od Ciebie. Aby uzyskać więcej informacji, zobacz ten artykuł na temat modelu komunikacji usługi Reliable Service.

Następne kroki

Dowiedz się więcej na temat pojęć i interfejsów API dostępnych w modelu komunikacji usług Reliable Services, a następnie szybko rozpocznij pracę z komunikacją zdalną usługi lub przejdź szczegółowo, aby dowiedzieć się, jak napisać odbiornik komunikacji przy użyciu internetowego interfejsu API z własnym hostem OWIN.