Architektura usługi Service Fabric

Usługa Service Fabric jest zbudowana z podsystemami warstwowymi. Te podsystemy umożliwiają pisanie aplikacji, które są:

• Wysoka dostępność
• Skalowalność
• 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 w jedną jednostkę (nazwane klastry), aby usługa Service Fabric mogła wykrywać błędy, przeprowadzać 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 jest również oparty na podsystemie 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 testować swoje usługi za pomocą symulowanych błędów przed wdrożeniem aplikacji i usług w środowiskach produkcyjnych i po nim. Usługa Service Fabric umożliwia rozpoznawanie lokalizacji usług za pośrednictwem podsystemu komunikacyjnego. Modele programowania aplikacji widoczne dla deweloperów 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 ramach klastrów usługi Service Fabric i komunikacji między klastrem usługi Service Fabric a klientami. Obsługuje on wzorce komunikacji jednokierunkowej i odpowiedzi na żądanie, 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 dostępny bezpośrednio 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 elementów pierwotnych komunikacji dostarczanych przez podsystem transportu i łączy różne węzły w jednym ujednoliconym klastrze, którego może dotyczyć. Zapewnia podstawowe systemy rozproszone wymagane przez inne podsystemy — wykrywanie awarii, wybór lidera i spójny routing. Podsystem federacyjny jest oparty na rozproszonych tabelach skrótów z 128-bitowym miejscem tokenu. Podsystem tworzy topologię pierścienia nad węzłami, przy czym każdy węzeł w pierścieniu jest przydzielany podzestaw przestrzeni tokenu na własność. W przypadku wykrywania awarii warstwa używa mechanizmu dzierżawy opartego na biciu serca i arbitrażu. Podsystem federacji gwarantuje również poprzez skomplikowane protokoły sprzężenia i odlotu, które w dowolnym momencie istnieje tylko jeden właściciel tokenu. Zapewnia to wybór 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. Współdziała z jednostką trybu failover, aby uzyskać listę operacji do replikacji, a agent rekonfiguracji udostępnia go z konfiguracją zestawu replik. Ta konfiguracja wskazuje, które repliki należy replikować. Usługa Service Fabric udostępnia domyślny replikator o nazwie Replikator sieci szkieletowej, 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.
• Resource Manager umieszcza repliki usług między domenami awarii w klastrze i zapewnia, że wszystkie jednostki trybu failover działają. Resource Manager równoważy również zasoby usług w podstawowej puli współużytkowanej węzłów klastra w celu osiągnięcia optymalnego równomiernego rozkładu obciążenia.

Podsystem zarządzania

Podsystem zarządzania zapewnia kompleksowe zarządzanie usługami 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. 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 rozproszonych między wiele węzłów w klastrze, umożliwiając podjęcie wszelkich niezbędnych działań naprawczych. Interfejsy API zapytań dotyczących kondycji umożliwiają wykonywanie zapytań dotyczących zdarzeń kondycji zgłoszonych w podsystemie kondycji. Interfejsy API zapytań o kondycję 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 na 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 umieszczanie replik i ich kondycję.

Podsystem komunikacji

Ten podsystem zapewnia niezawodne komunikaty w ramach klastra i odnajdywania usług 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. Korzystając z 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 dynamiki węzła lub zmiany rozmiaru klastra.

Podsystem testowania

Testability 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 wykonywania i weryfikowania 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.