Udostępnij za pośrednictwem


Omówienie terminologii usługi Service Fabric

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. Usługa Service Fabric to kontener i orkiestrator 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. W tym artykule szczegółowo poznać terminologię używaną przez usługę Service Fabric do zrozumienia terminów używanych w dokumentacji.

Powiązane wideo szkoleniowe wymienione poniżej szczegółowo opisują aplikację, pakowanie, wdrażanie, abstrakcje 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 i zarządzane mikrousługi. 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ą cechy, takie jak właściwości umieszczania. Każda maszyna lub maszyna wirtualna ma usługę systemu Windows automatycznie uruchamianą po uruchomieniu, 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 formacie 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że być zarządzany niezależnie.

Usługa: Usługa wykonuje kompletną i autonomiczną funkcję i 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 kolejkowania, 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 na podstawie jednego typu aplikacji. Można 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:

  • Bezstanowy: 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, dla których chcesz rozłożyć stan na skalowalność. Określ również liczbę powtórzeń stanu między węzłami w celu uzyskania 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 w celu zachowania synchronizacji 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 Rekonfiguracja.

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 należy określić przy użyciu jego nazwy/wersji. Każde wystąpienie typu usługi ma przypisaną nazwę identyfikatora URI o zakresie w obszarze identyfikatora URI nazwanej aplikacji. Jeśli na przykład utworzysz usługę o nazwie "MyDatabase" w nazwie "MyNamedApp", identyfikator URI będzie wyglądać następująco: "fabric:/MyNamedApp/MyDatabase". W ramach 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 odwołują się do pliku typu ServiceManifest.xml usługi. Podczas tworzenia nazwanej usługi pakiet kodu jest kopiowany do węzła lub węzłów wybranych do uruchomienia nazwanej usługi. Następnie kod zostanie uruchomiony. Istnieją dwa typy plików wykonywalnych pakietu kodu:

  • Pliki wykonywalne gościa: pliki wykonywalne uruchamiane zgodnie z rzeczywistym działaniem w systemie operacyjnym hosta (Windows lub Linux). Te pliki wykonywalne nie łączą się ani nie odwołują się do żadnych plików środowiska uruchomieniowego usługi Service Fabric, 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, włączając funkcje 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 ładowania.

Pakiet danych: katalog dysku zawierający statyczne, tylko do odczytu pliki danych typu usługi, zazwyczaj zdjęcia, dźwięk i pliki wideo. Pliki w katalogu pakietu danych są przywołyne 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 do 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 typu usługi tylko do odczytu, zazwyczaj pliki tekstowe. Pliki w katalogu pakietu konfiguracji są przywołyne 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 zostanie uruchomiony i będzie mógł teraz uzyskać 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 abstrakcji podstawowego systemu operacyjnego z 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 kontenera konstrukcji systemu operacyjnego. 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 znaczną ilością 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 zakończy się niepowodzeniem, inne wystąpienia będą nadal działać normalnie, a następnie usługa Service Fabric tworzy nowe wystąpienie. Stanowe nazwane usługi zachowują swój stan w replikach, a każda partycja ma własny zestaw replik, więc stan jest synchronizowany. Jeśli replika nie powiedzie się, usługa Service Fabric utworzy 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 Naming Service 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óre rozpoznają bieżącą lokalizację sieci. Klienci uzyskują rzeczywisty adres IP i port komputera, na którym jest aktualnie 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ą wersjonowane pakiety aplikacji. 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, zapoznaj się z ustawieniem ImageStoreConnectionString.

Przeczytaj artykuł Deploy an application (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.
  • Organizuje uaktualnienia aplikacji i klastra.
  • Współdziała z innymi składnikami systemu.

Usługa Programu 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 naprawy jest używany w:

Modele wdrażania i aplikacji

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

Model macierzysty

Model aplikacji natywnej 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 umożliwiający tworzenie 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 używa modelu wątków opartych na kolei, dlatego najlepiej unikać kodu wywołującego innych aktorów lub usług, ponieważ pojedynczy 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 w systemie Windows Server 2016 wraz z obsługą trybu izolacji funkcji Hyper-V. W modelu aplikacji usługi Service Fabric kontener reprezentuje hosta aplikacji, w którym umieszczono wiele replik usług. Usługa Service Fabric może uruchamiać dowolne kontenery, a scenariusz jest podobny do scenariusza 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 można uruchamiać 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 oferuje 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: