Architektura usługi Service Fabric

Usługa Service Fabric jest oparta na podsystemach warstwowych. Te podsystemy umożliwiają pisanie aplikacji, które są:

• Wysoka dostępność
• Skalowalny
• Zarządzaniu
• Testować

Na poniższym diagramie przedstawiono główne podsystemy usługi Service Fabric.

W systemie rozproszonym kluczowa jest możliwość bezpiecznego komunikowania się między węzłami w klastrze. Podstawą stosu jest podsystem transportu, który zapewnia bezpieczną komunikację między węzłami. Powyżej podsystemu transportu znajduje się podsystem federacji, który klasteruje różne węzły do jednej jednostki (nazwanych klastrów), aby usługa Service Fabric mogła wykrywać błędy, wykonywać wybory lidera i zapewniać spójny routing. Podsystem niezawodności, warstwowy na podstawie podsystemu federacji, jest odpowiedzialny za niezawodność usług Service Fabric za pośrednictwem mechanizmów, takich jak replikacja, zarządzanie zasobami i tryb failover. Podsystem federacyjny stanowi również część podsystemu hostingu i aktywacji, który zarządza cyklem życia aplikacji w jednym węźle. Podsystem zarządzania zarządza cyklem życia aplikacji i usług. Podsystem testowania pomaga deweloperom aplikacji przetestować swoje usługi za pomocą symulowanych błędów przed wdrożeniem aplikacji i usług w środowiskach produkcyjnych i po ich wdrożeniu. Usługa Service Fabric umożliwia rozpoznawanie lokalizacji usług za pośrednictwem podsystemu komunikacji. Modele programowania aplikacji udostępniane deweloperom są nakładane na warstwy na tych podsystemach wraz z modelem aplikacji w celu włączenia narzędzi.

Podsystem transportu

Podsystem transportu implementuje kanał komunikacyjny datagramu punkt-punkt. Ten kanał jest używany do komunikacji w klastrach usługi Service Fabric i komunikacji między klastrem usługi Service Fabric a klientami. Obsługuje on wzorce komunikacji jednokierunkowej i żądań-odpowiedzi, które zapewniają podstawę implementacji emisji i multiemisji w warstwie federacyjnej. Podsystem transportu zabezpiecza komunikację przy użyciu certyfikatów X509 lub zabezpieczeń systemu Windows. Ten podsystem jest używany wewnętrznie przez usługę Service Fabric i nie jest bezpośrednio dostępny dla deweloperów na potrzeby programowania aplikacji.

Podsystem federacji

Aby poznać zestaw węzłów w systemie rozproszonym, należy mieć spójny widok systemu. Podsystem federacyjny używa pierwotnych komunikacji dostarczonych przez podsystem transportu i łączy różne węzły w jeden ujednolicony klaster, którego może poznać. Zapewnia on podstawowe systemy rozproszone wymagane przez inne podsystemy — wykrywanie błędów, wybór lidera i spójny routing. Podsystem federacji jest oparty na rozproszonych tabelach skrótów z 128-bitowym miejscem tokenu. Podsystem tworzy topologię pierścienia nad węzłami, a każdy węzeł w pierścieniu jest przydzielany podzestaw przestrzeni tokenu na własność. W przypadku wykrywania błędów warstwa używa mechanizmu dzierżawy opartego na biciu serca i arbitrażu. Podsystem federacji gwarantuje również za pomocą skomplikowanych protokołów sprzężenia i odlotu, które w dowolnym momencie istnieje tylko jeden właściciel tokenu. Zapewnia to wybory lidera i spójne gwarancje routingu.

Podsystem niezawodności

Podsystem niezawodności udostępnia mechanizm umożliwiający zapewnienie wysokiej dostępności usługi Service Fabric przy użyciu replikatora, Menedżera trybu failover i usługi Resource Balancer.

• Replikator zapewnia, że zmiany stanu repliki usługi podstawowej zostaną automatycznie zreplikowane do replik pomocniczych, zachowując spójność między replikami podstawowymi i pomocniczymi w zestawie replik usługi. Replikator jest odpowiedzialny za zarządzanie kworum wśród replik w zestawie replik. Wchodzi w interakcję z jednostką trybu failover, aby uzyskać listę operacji do replikacji, a agent rekonfiguracji zapewnia konfigurację zestawu replik. Ta konfiguracja wskazuje, które repliki należy replikować. Usługa Service Fabric udostępnia domyślny replikator o nazwie Fabric Replicator, który może być używany przez interfejs API modelu programowania w celu zapewnienia wysokiej dostępności i niezawodności stanu usługi.
• Menedżer trybu failover zapewnia, że po dodaniu lub usunięciu węzłów z klastra obciążenie jest automatycznie redystrybuowane w dostępnych węzłach. Jeśli węzeł w klastrze ulegnie awarii, klaster automatycznie ponownie skonfiguruje repliki usługi w celu zachowania dostępności.
• Usługa Resource Manager umieszcza repliki usług w domenach błędów w klastrze i zapewnia, że wszystkie jednostki trybu failover działają. Usługa Resource Manager równoważy również zasoby usługi w bazowej udostępnionej puli węzłów klastra w celu uzyskania optymalnego równomiernego rozkładu obciążenia.

Podsystem zarządzania

Podsystem zarządzania zapewnia kompleksowe zarządzanie usługą i cyklem życia aplikacji. Polecenia cmdlet programu PowerShell i administracyjne interfejsy API umożliwiają aprowizowanie, wdrażanie, stosowanie poprawek, uaktualnianie i anulowanie aprowizacji aplikacji bez utraty dostępności. Podsystem zarządzania wykonuje to za pośrednictwem następujących usług.

• Menedżer klastra: jest to usługa podstawowa, która współdziała z Menedżerem trybu failover z niezawodnością, aby umieścić aplikacje w węzłach na podstawie ograniczeń umieszczania usługi. Usługa Resource Manager w podsystemie trybu failover gwarantuje, że ograniczenia nigdy nie zostaną przerwane. Menedżer klastra zarządza cyklem życia aplikacji od aprowizacji do anulowania aprowizacji. Integruje się z menedżerem kondycji, aby zapewnić, że dostępność aplikacji nie zostanie utracona z perspektywy kondycji semantycznej podczas uaktualniania.
• Menedżer kondycji: ta usługa umożliwia monitorowanie kondycji aplikacji, usług i jednostek klastra. Jednostki klastra (takie jak węzły, partycje usługi i repliki) mogą zgłaszać informacje o kondycji, które są następnie agregowane do scentralizowanego magazynu kondycji. Te informacje o kondycji zawierają ogólną migawkę kondycji punktu w czasie usług i węzłów dystrybuowanych między wieloma węzłami w klastrze, umożliwiając wykonywanie wszelkich niezbędnych akcji naprawczych. Interfejsy API zapytań dotyczących kondycji umożliwiają wykonywanie zapytań dotyczących zdarzeń kondycji zgłoszonych w podsystemie kondycji. Interfejsy API zapytań dotyczących kondycji zwracają nieprzetworzone dane kondycji przechowywane w magazynie kondycji lub zagregowane, interpretowane dane kondycji dla określonej jednostki klastra.
• Magazyn obrazów: ta usługa zapewnia magazyn i dystrybucję plików binarnych aplikacji. Ta usługa udostępnia prosty rozproszony magazyn plików, z którego aplikacje są przekazywane i pobierane.

Podsystem hostingu

Menedżer klastra informuje podsystem hostingu (uruchomiony w każdym węźle), którymi usługami musi zarządzać dla określonego węzła. Podsystem hostingu zarządza następnie cyklem życia aplikacji w tym węźle. Współdziała z składnikami niezawodności i kondycji, aby zapewnić prawidłowe umieszczenie replik i ich kondycję.

Podsystem komunikacji

Ten podsystem zapewnia niezawodne komunikaty w ramach klastra i odnajdywania usługi za pośrednictwem usługi Naming. Usługa Nazewnictwa rozpoznaje nazwy usług w lokalizacji w klastrze i umożliwia użytkownikom zarządzanie nazwami i właściwościami usług. Za pomocą usługi Nazewnictwa klienci mogą bezpiecznie komunikować się z dowolnym węzłem w klastrze, aby rozpoznać nazwę usługi i pobrać metadane usługi. Korzystając z prostego interfejsu API klienta nazewnictwa, użytkownicy usługi Service Fabric mogą opracowywać usługi i klientów, którzy mogą rozpoznawać bieżącą lokalizację sieciową pomimo dynamizmu węzłów lub zmiany rozmiaru klastra.

Podsystem testowania

Testowanie to zestaw narzędzi przeznaczonych specjalnie do testowania usług opartych na usłudze Service Fabric. Narzędzia umożliwiają deweloperowi łatwe wywoływanie znaczących błędów i uruchamianie scenariuszy testowych w celu wykonania i zweryfikowania licznych stanów i przejść, które usługa będzie doświadczać przez cały okres istnienia, a wszystko to w kontrolowany i bezpieczny sposób. Możliwość testowania zapewnia również mechanizm uruchamiania dłuższych testów, które mogą iterować przez różne możliwe awarie bez utraty dostępności. Zapewnia to środowisko testowe w środowisku produkcyjnym.