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

W usłudze Service Fabric usługa jest uruchamiana gdzieś w klastrze usługi Service Fabric, zwykle dystrybuowana na wielu maszynach wirtualnych. Może zostać przeniesiony z jednego miejsca do drugiego 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 zazwyczaj 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 wideo szkoleniowego, w których omówiono również komunikację z usługami:

Korzystanie z własnego protokołu

Usługa Service Fabric ułatwia zarządzanie cyklem życia usług, ale nie podejmuje decyzji dotyczących tego, co robią usługi. Obejmuje to komunikację. Po otwarciu usługi przez usługę Service Fabric jest to możliwość skonfigurowania punktu końcowego dla żądań przychodzących przy użyciu dowolnego protokołu lub stosu komunikacyjnego. 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 będą musieli 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 rozpoznawania o nazwie Usługa nazewnictwa. Usługa Naming Service przechowuje tabelę, która mapuje nazwane wystąpienia usługi na adresy punktów końcowych, na których nasłuchiwanie. 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. Jest to 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 problemów i nawiązywanie połączenia z usługami obejmuje następujące kroki wykonywane w pętli:

• Rozwiązanie: 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 i nawiązywania 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ą w klastrze 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 Nazewnictwa. 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, będąc w stanie rozwiązać te problemy przy użyciu standardowego protokołu DNS (zamiast protokołu Naming Service), jest bardzo wygodne, 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 punktów końcowych.

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 w celu 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 .

Odwrotna usługa 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 Naming Service. Innymi słowy usługa Naming Service ukrywa usługę nazewnictwa podczas wywoływania innych usług, wykonując 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 od klientów zewnętrznych

Usługi łączące się ze sobą w klastrze 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 jest umieszczony za 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. 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 jest ono uruchamiane tylko w typie węzła z otwartym niestandardowym portem punktu końcowego.

   

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

   

4. 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 Azure Portal sonda jest automatycznie konfigurowana dla każdego skonfigurowanego niestandardowego portu punktu końcowego.

   

Należy pamiętać, że Azure Load Balancer i sonda wiedzą tylko o węzłach, a nie o usługach uruchomionych w węzłach. 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ą reagować 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 z nich będzie działać najlepiej, zależy od wyboru modelu programowania, struktury komunikacyjnej i języka programowania napisanego w usługach.

• Brak określonego protokołu: Jeśli nie masz określonego wyboru struktury komunikacji, ale chcesz szybko uruchomić coś, to idealną opcją jest komunikacja zdalna usługi, 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 rozpoczęcia komunikacji z usługami. 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 zapewnia standardowy wybór branżowy z narzędziami i serwerami HTTP dostępnymi w wielu różnych językach, które są 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 klas iServicePartitionClient, natomiast w przypadku języka Java użyj CommunicationClient klas i FabricServicePartitionClient na potrzeby rozpoznawania usług, połączeń HTTP i pętli ponawiania prób.ICommunicationClient
• WCF: jeśli masz istniejący kod, który używa programu WCF jako struktury komunikacji, możesz użyć elementu WcfCommunicationListener dla klasy i WcfCommunicationClientServicePartitionClient po stronie serwera 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ł na temat implementacji opartej na programie WCF stosu komunikacyjnego.

Używanie protokołów niestandardowych 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 zdarzenia przesyłania strumieniowego za pośrednictwem Azure Event Hubs lub Azure IoT Hub. Usługa Service Fabric udostępnia interfejsy API komunikacji, z którymi można podłączyć stos komunikacji, podczas gdy cała praca nad odnajdywaniem i łączeniem jest abstrahowana 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.