Omówienie terminologii usługi Service Fabric

  • Artykuł

Usługa Azure Service Fabric to platforma systemów rozproszonych ułatwiająca pakowanie i wdrażanie skalowalnych i niezawodnych mikrousług oraz zarządzanie nimi. Service Fabric to orkiestrator kontenerów i procesów, który umożliwia hostowanie klastrów w dowolnym miejscu: na platformie Azure, w lokalnym centrum danych lub u dowolnego dostawcy usług w chmurze. Możesz użyć dowolnej platformy do pisania usług i wybrać miejsce uruchamiania aplikacji z wielu opcji środowiska. Ten artykuł zawiera szczegółowe informacje na temat terminologii używanej przez usługę Service Fabric w celu zrozumienia terminów używanych w dokumentacji.

Powiązane wideo szkoleniowe wymienione poniżej szczegółowo opisują aplikację, pakowanie, wdrażanie, abstrakcję i terminologię używaną przez usługę Service Fabric:

Pojęcia dotyczące infrastruktury

Klaster: połączony z siecią zestaw maszyn wirtualnych lub fizycznych, w którym są wdrażane mikrousługi i zarządzane. Klastry mogą obejmować nawet tysiące maszyn.

Węzeł: maszyna lub maszyna wirtualna, która jest częścią klastra, jest nazywana węzłem. Każdy węzeł ma przypisaną nazwę węzła (ciąg). Węzły mają właściwości, takie jak właściwości umieszczania. Każda maszyna lub maszyna wirtualna ma automatycznie uruchamianą usługę systemu Windows, uruchamianą podczas rozruchu, FabricHost.exea następnie uruchamia dwie pliki wykonywalne: Fabric.exe i FabricGateway.exe. Te dwa pliki wykonywalne tworzą węzeł. W przypadku scenariuszy testowania można hostować wiele węzłów na jednej maszynie lub maszynie wirtualnej, uruchamiając wiele wystąpień Fabric.exe elementów i FabricGateway.exe.

Pojęcia dotyczące aplikacji i usług

Aplikacja natywna usługi Service Fabric: Aplikacje natywne usługi Service Fabric są opisywane przez natywny model aplikacji (oparte na języku XML i manifesty usługi).

Pojęcia dotyczące aplikacji natywnej usługi Service Fabric

Aplikacja: Aplikacja jest kolekcją usług składowych, które wykonują określoną funkcję lub funkcje. Cykl życia każdego wystąpienia aplikacji można zarządzać niezależnie.

Usługa: Usługa wykonuje kompletną i autonomiczną funkcję oraz może uruchamiać i uruchamiać niezależnie od innych usług. Usługa składa się z kodu, konfiguracji i danych. Dla każdej usługi kod składa się z plików binarnych wykonywalnych, konfiguracja składa się z ustawień usługi, które można załadować w czasie wykonywania, a dane składają się z dowolnych danych statycznych, które mają być używane przez usługę.

Typ aplikacji: nazwa/wersja przypisana do kolekcji typów usług. Jest on zdefiniowany w ApplicationManifest.xml pliku i osadzony w katalogu pakietów aplikacji. Katalog jest następnie kopiowany do magazynu obrazów klastra usługi Service Fabric. Następnie można utworzyć nazwaną aplikację na podstawie tego typu aplikacji w klastrze.

Aby uzyskać więcej informacji, przeczytaj artykuł Model aplikacji .

Pakiet aplikacji: katalog dysku zawierający plik typu ApplicationManifest.xml aplikacji. Odwołuje się do pakietów usług dla każdego typu usługi, który składa się na typ aplikacji. Pliki w katalogu pakietu aplikacji są kopiowane do magazynu obrazów klastra usługi Service Fabric. Na przykład pakiet aplikacji dla typu aplikacji poczty e-mail może zawierać odwołania do pakietu usługi kolejki, pakietu fronton-service i pakietu usługi bazy danych.

Nazwana aplikacja: po skopiowaniu pakietu aplikacji do magazynu obrazów należy utworzyć wystąpienie aplikacji w klastrze. Wystąpienie jest tworzone podczas określania typu aplikacji pakietu aplikacji przy użyciu jego nazwy lub wersji. Każde wystąpienie typu aplikacji ma przypisaną jednolitą nazwę identyfikatora zasobu (URI), która wygląda następująco: "fabric:/MyNamedApp". W klastrze można utworzyć wiele nazwanych aplikacji z jednego typu aplikacji. Możesz również tworzyć nazwane aplikacje z różnych typów aplikacji. Każda nazwana aplikacja jest zarządzana i wersjonowana niezależnie.

Typ usługi: nazwa/wersja przypisana do pakietów kodu usługi, pakietów danych i pakietów konfiguracji. Typ usługi jest zdefiniowany w ServiceManifest.xml pliku i osadzony w katalogu pakietu usługi. Katalog pakietu usługi jest następnie przywołyyny przez plik pakietu ApplicationManifest.xml aplikacji. W klastrze po utworzeniu nazwanej aplikacji można utworzyć nazwaną usługę na podstawie jednego z typów usług typu aplikacji. Plik typu ServiceManifest.xml usługi opisuje usługę.

Aby uzyskać więcej informacji, przeczytaj artykuł Model aplikacji .

Istnieją dwa typy usług:

  • Bezstanowe: użyj usługi bezstanowej, gdy stan trwały usługi jest przechowywany w zewnętrznej usłudze magazynu, takiej jak Azure Storage, Azure SQL Database lub Azure Cosmos DB. Użyj usługi bezstanowej, gdy usługa nie ma trwałego magazynu. Na przykład w przypadku usługi kalkulatora, w której wartości są przekazywane do usługi, wykonywane jest obliczenie, które używa tych wartości, a następnie zwracany jest wynik.
  • Stanowe: użyj usługi stanowej, jeśli chcesz, aby usługa Service Fabric zarządzała stanem usługi za pośrednictwem jej modeli programowania Reliable Collections lub Reliable Actors. Podczas tworzenia nazwanej usługi określ liczbę partycji, które mają zostać rozłożone na potrzeby skalowalności. Określ również, ile razy ma być replikowany stan między węzłami w celu zwiększenia niezawodności. Każda nazwana usługa ma jedną replikę podstawową i wiele replik pomocniczych. Stan nazwanej usługi można zmodyfikować podczas zapisywania w repliki podstawowej. Następnie usługa Service Fabric replikuje ten stan do wszystkich replik pomocniczych, aby zachować synchronizację stanu. Usługa Service Fabric automatycznie wykrywa awarię repliki podstawowej i promuje istniejącą replikę pomocniczą do repliki podstawowej. Następnie usługa Service Fabric tworzy nową replikę pomocniczą.

Repliki lub wystąpienia odnoszą się do kodu (i stanu dla usług stanowych) usługi wdrożonej i uruchomionej. Zobacz Repliki i wystąpienia.

Rekonfiguracja odnosi się do procesu każdej zmiany w zestawie replik usługi. Zobacz Reconfiguration (Ponowna konfiguracja).

Pakiet usługi: katalog dysku zawierający plik typu ServiceManifest.xml usługi. Ten plik odwołuje się do kodu, danych statycznych i pakietów konfiguracji dla typu usługi. Pliki w katalogu pakietu usługi są przywołyyzowane przez plik typu ApplicationManifest.xml aplikacji. Na przykład pakiet usługi może odwoływać się do kodu, danych statycznych i pakietów konfiguracji tworzących usługę bazy danych.

Nazwana usługa: po utworzeniu nazwanej aplikacji można utworzyć wystąpienie jednego z jego typów usług w klastrze. Typ usługi określa się przy użyciu jego nazwy/wersji. Każde wystąpienie typu usługi ma przypisaną nazwę identyfikatora URI o zakresie w zakresie identyfikatora URI nazwanej aplikacji. Jeśli na przykład utworzysz usługę o nazwie "MyDatabase" w aplikacji o nazwie "MyNamedApp", identyfikator URI będzie wyglądać następująco: "fabric:/MyNamedApp/MyDatabase". W obrębie nazwanej aplikacji można utworzyć kilka nazwanych usług. Każda nazwana usługa może mieć własny schemat partycji i liczbę wystąpień lub replik.

Pakiet kodu: katalog dysku zawierający pliki wykonywalne typu usługi, zazwyczaj pliki EXE/DLL. Pliki w katalogu pakietu kodu są przywołyyzowane przez plik typu ServiceManifest.xml usługi. Podczas tworzenia nazwanej usługi pakiet kodu jest kopiowany do węzła lub węzłów wybranych w celu uruchomienia nazwanej usługi. Następnie kod zaczyna działać. Istnieją dwa typy plików wykonywalnych pakietu kodu:

  • Pliki wykonywalne gościa: pliki wykonywalne uruchamiane jako w systemie operacyjnym hosta (Windows lub Linux). Te pliki wykonywalne nie łączą się z żadnymi plikami środowiska uruchomieniowego usługi Service Fabric ani nie odwołują się do nich, dlatego nie używają żadnych modeli programowania usługi Service Fabric. Te pliki wykonywalne nie mogą używać niektórych funkcji usługi Service Fabric, takich jak usługa nazewnictwa na potrzeby odnajdywania punktów końcowych. Pliki wykonywalne gościa nie mogą zgłaszać metryk obciążenia specyficznych dla każdego wystąpienia usługi.
  • Pliki wykonywalne hosta usługi: pliki wykonywalne korzystające z modeli programowania usługi Service Fabric przez łączenie z plikami środowiska uruchomieniowego usługi Service Fabric, co umożliwia korzystanie z funkcji usługi Service Fabric. Na przykład nazwane wystąpienie usługi może rejestrować punkty końcowe w usłudze Service Fabric nazewnictwa, a także zgłaszać metryki obciążenia.

Pakiet danych: katalog dysku, który zawiera statyczne pliki danych typu usługi, tylko do odczytu, zazwyczaj zdjęcia, dźwięk i pliki wideo. Pliki w katalogu pakietu danych są przywołyzowane przez plik typu ServiceManifest.xml usługi. Podczas tworzenia nazwanej usługi pakiet danych jest kopiowany do węzła lub węzłów wybranych w celu uruchomienia nazwanej usługi. Kod zaczyna działać i może teraz uzyskiwać dostęp do plików danych.

Pakiet konfiguracji: katalog dysku zawierający statyczne pliki konfiguracji tylko do odczytu typu usługi, zazwyczaj pliki tekstowe. Pliki w katalogu pakietu konfiguracji są przywołyyzowane przez plik typu ServiceManifest.xml usługi. Podczas tworzenia nazwanej usługi pliki w pakiecie konfiguracji są kopiowane do co najmniej jednego węzła wybranego do uruchomienia nazwanej usługi. Następnie kod zaczyna działać i może teraz uzyskiwać dostęp do plików konfiguracji.

Kontenery: domyślnie usługa Service Fabric wdraża i aktywuje usługi jako procesy. Usługa Service Fabric może również wdrażać usługi w obrazach kontenerów. Kontenery to technologia wirtualizacji, która abstrahuje podstawowy system operacyjny od aplikacji. Aplikacja i jej środowisko uruchomieniowe, zależności i biblioteki systemowe działają wewnątrz kontenera. Kontener ma pełny, prywatny dostęp do własnego izolowanego widoku konstrukcji systemu operacyjnego kontenera. Usługa Service Fabric obsługuje kontenery systemu Windows Server i kontenery platformy Docker w systemie Linux. Aby uzyskać więcej informacji, przeczytaj Service Fabric i kontenery.

Schemat partycji: podczas tworzenia nazwanej usługi należy określić schemat partycji. Usługi ze znacznymi ilościami stanu dzielą dane między partycje, co rozkłada stan między węzły klastra. Dzieląc dane między partycje, stan nazwanej usługi może być skalowany. W ramach partycji bezstanowe nazwane usługi mają wystąpienia, natomiast stanowe nazwane usługi mają repliki. Zazwyczaj bezstanowe nazwane usługi mają tylko jedną partycję, ponieważ nie mają stanu wewnętrznego. Wystąpienia partycji zapewniają dostępność. Jeśli jedno wystąpienie ulegnie awarii, inne wystąpienia nadal działają normalnie, a następnie usługa Service Fabric tworzy nowe wystąpienie. Stanowe nazwane usługi zachowują swój stan w ramach replik, a każda partycja ma własny zestaw replik, dzięki czemu stan jest synchronizowany. Jeśli replika nie powiedzie się, usługa Service Fabric skompiluje nową replikę z istniejących replik.

Aby uzyskać więcej informacji, przeczytaj artykuł Partition Service Fabric reliable services (Partycjonowanie usług Reliable Services w usłudze Service Fabric ).

Usługi systemowe

Istnieją usługi systemowe tworzone w każdym klastrze, które zapewniają możliwości platformy usługi Service Fabric.

Usługa nazewnictwa: każdy klaster usługi Service Fabric ma usługę Nazewnictwa, która rozpoznaje nazwy usług w lokalizacji w klastrze. Zarządzasz nazwami i właściwościami usług, takimi jak internetowy system nazw domen (DNS) dla klastra. Klienci bezpiecznie komunikują się z dowolnym węzłem w klastrze przy użyciu usługi Nazewnictwa w celu rozpoznania nazwy usługi i jej lokalizacji. Aplikacje są przenoszone w klastrze. Może to być na przykład spowodowane awariami, równoważeniem zasobów lub zmianą rozmiaru klastra. Możesz opracowywać usługi i klientów, którzy rozpoznają bieżącą lokalizację sieci. Klienci uzyskują rzeczywisty adres IP maszyny i port, w którym jest obecnie uruchomiony.

Przeczytaj Artykuł Komunikacja z usługami , aby uzyskać więcej informacji na temat interfejsów API komunikacji klienta i usługi, które współpracują z usługą Nazewnictwa.

Usługa magazynu obrazów: każdy klaster usługi Service Fabric ma usługę Magazynu obrazów, w której są wdrażane, przechowywane są pakiety aplikacji w wersji. Skopiuj pakiet aplikacji do magazynu obrazów, a następnie zarejestruj typ aplikacji zawarty w tym pakiecie aplikacji. Po zainicjowaniu obsługi administracyjnej typu aplikacji należy utworzyć na jej podstawie nazwę. Po usunięciu wszystkich nazwanych aplikacji można wyrejestrować typ aplikacji z usługi Image Store.

Aby uzyskać więcej informacji na temat usługi Image Store, przeczytaj artykuł Understand the ImageStoreConnectionString setting (Informacje o ustawieniu ImageStoreConnectionString ).

Przeczytaj artykuł Wdrażanie aplikacji, aby uzyskać więcej informacji na temat wdrażania aplikacji w usłudze Image Store.

Usługa Menedżera trybu failover: każdy klaster usługi Service Fabric ma usługę Menedżera trybu failover, która jest odpowiedzialna za następujące akcje:

  • Wykonuje funkcje związane z wysoką dostępnością i spójnością usług.
  • Orkiestruje uaktualnienia aplikacji i klastra.
  • Współdziała z innymi składnikami systemu.

Usługa Repair Manager: jest to opcjonalna usługa systemowa, która umożliwia wykonywanie akcji naprawy w klastrze w sposób bezpieczny, automatyzowalny i przezroczysty. Menedżer napraw jest używany w:

Modele wdrażania i aplikacji

Aby wdrożyć usługi, musisz opisać sposób ich działania. Usługa Service Fabric obsługuje trzy różne modele wdrażania:

Model macierzysty

Natywny model aplikacji zapewnia aplikacjom pełny dostęp niskiego poziomu do usługi Service Fabric. Aplikacje i usługi są definiowane jako zarejestrowane typy w plikach manifestu XML.

Model macierzysty obsługuje struktury Reliable Services i Reliable Actors, które zapewniają dostęp do interfejsów API środowiska uruchomieniowego usługi Service Fabric i interfejsów API zarządzania klastrami w językach C# i Java. Model macierzysty obsługuje również dowolne kontenery i pliki wykonywalne.

Reliable Services: interfejs API umożliwiający tworzenie usług bezstanowych i stanowych. Usługi stanowe przechowują swój stan w elementach Reliable Collections, takich jak słownik lub kolejka. Możesz również podłączyć różne stosy komunikacyjne, takie jak internetowy interfejs API i program Windows Communication Foundation (WCF).

Reliable Actors: interfejs API do tworzenia obiektów bezstanowych i stanowych za pomocą modelu programowania wirtualnego aktora. Ten model jest przydatny, gdy masz wiele niezależnych jednostek obliczeniowych lub stanu. Ten model korzysta z modelu wątków opartych na kolei, dlatego najlepiej jest unikać kodu wywołującego innych aktorów lub usług, ponieważ dany aktor nie może przetwarzać innych żądań przychodzących do momentu zakończenia wszystkich żądań wychodzących.

Możesz również uruchamiać istniejące aplikacje w usłudze Service Fabric:

Kontenery: usługa Service Fabric obsługuje wdrażanie kontenerów platformy Docker w kontenerach systemu Linux i Windows Server na Windows Server 2016 oraz obsługę trybu izolacji funkcji Hyper-V. W modelu aplikacji usługi Service Fabric kontener reprezentuje hosta aplikacji, w którym umieszcza się wiele replik usługi. Usługa Service Fabric może uruchamiać dowolne kontenery, a scenariusz jest podobny do scenariusza pliku wykonywalnego gościa, w którym pakujesz istniejącą aplikację wewnątrz kontenera. Ponadto można również uruchamiać usługi Service Fabric wewnątrz kontenerów .

Pliki wykonywalne gościa: w usłudze Azure Service Fabric jako usługa można uruchomić dowolny typ kodu, na przykład Node.js, Python, Java lub C++. Usługa Service Fabric określa tego typu usługi jako pliki wykonywalne gościa, które są traktowane jako usługi bezstanowe. Zalety uruchamiania pliku wykonywalnego gościa w klastrze usługi Service Fabric obejmują wysoką dostępność, monitorowanie kondycji, zarządzanie cyklem życia aplikacji, wysoką gęstość i możliwość odnajdywania.

Aby uzyskać więcej informacji, przeczytaj artykuł Wybieranie modelu programowania dla usługi .

Docker Compose

Docker Compose jest częścią projektu platformy Docker. Usługa Service Fabric zapewnia ograniczoną obsługę wdrażania aplikacji przy użyciu modelu docker Compose.

Środowiska

Service Fabric to technologia platformy typu open source oparta na kilku różnych usługach i produktach. Firma Microsoft udostępnia następujące opcje:

  • Azure Service Fabric: oferta klastra hostowanego na platformie Azure usługi Service Fabric. Zapewnia integrację między usługą Service Fabric i infrastrukturą platformy Azure, a także zarządzanie uaktualnianiem i konfiguracją klastrów usługi Service Fabric.
  • Autonomiczna usługa Service Fabric: zestaw narzędzi instalacji i konfiguracji do wdrażania klastrów usługi Service Fabric w dowolnym miejscu (lokalnie lub u dowolnego dostawcy usług w chmurze). Niezarządzane przez platformę Azure.
  • Klaster deweloperów usługi Service Fabric: zapewnia lokalne środowisko programistyczne w systemie Windows, Linux lub Mac na potrzeby tworzenia aplikacji usługi Service Fabric.

Następne kroki

Aby dowiedzieć się więcej o usłudze Service Fabric: