Edytuj

Architektura mikrousług na platformie Azure Service Fabric

Azure API Management
Azure Key Vault
Azure Monitor
Azure Pipelines
Azure Service Fabric

Ta architektura referencyjna przedstawia architekturę mikrousług wdrożona w usłudze Azure Service Fabric. Przedstawia podstawową konfigurację klastra, która może być punktem wyjścia dla większości wdrożeń.

GitHub logo Implementacja referencyjna tej architektury jest dostępna w witrynie GitHub.

Architektura

Diagram that shows the Service Fabric reference architecture.

Pobierz plik programu Visio z tą architekturą.

Uwaga

Ten artykuł koncentruje się na modelu programowania usług Reliable Services dla usługi Service Fabric. Wdrażanie kontenerów i zarządzanie nimi przy użyciu usługi Service Fabric wykracza poza zakres tego artykułu.

Przepływ pracy

Niniejsza architektura zawiera następujące składniki. Aby zapoznać się z innymi terminami, zobacz Omówienie terminologii usługi Service Fabric.

  • Klaster usługi Service Fabric. Klaster to połączony z siecią zestaw maszyn wirtualnych, w którym wdrażasz mikrousługi i zarządzasz nimi.

  • Zestawy skalowania maszyn wirtualnych. Zestawy skalowania maszyn wirtualnych umożliwiają tworzenie grupy identycznych, z równoważeniem obciążenia i automatyczne skalowanie maszyn wirtualnych oraz zarządzanie nimi. Te zasoby obliczeniowe zapewniają również domeny błędów i uaktualnień.

  • Węzły. Węzły to maszyny wirtualne należące do klastra usługi Service Fabric.

  • Typy węzłów. Typ węzła reprezentuje zestaw skalowania maszyn wirtualnych, który wdraża kolekcję węzłów. Klaster usługi Service Fabric ma co najmniej jeden typ węzła.

    W klastrze, który ma wiele typów węzłów, jeden musi być zadeklarowany jako typ węzła podstawowego. Podstawowy typ węzła w klastrze uruchamia usługi systemowe usługi Service Fabric. Te usługi zapewniają możliwości platformy usługi Service Fabric. Typ węzła podstawowego działa również jako węzły inicjujące , które są węzłami, które utrzymują dostępność bazowego klastra.

    Skonfiguruj dodatkowe typy węzłów do uruchamiania usług.

  • Usługi. Usługa wykonuje funkcję autonomiczną, która może uruchamiać i uruchamiać niezależnie od innych usług. Wystąpienia usług są wdrażane w węzłach w klastrze. Istnieją dwie odmiany usług w usłudze Service Fabric:

    • Usługa bezstanowa. Usługa bezstanowa nie utrzymuje stanu w ramach usługi. Jeśli wymagana jest trwałość stanu, stan jest zapisywany i pobierany z magazynu zewnętrznego, takiego jak usługa Azure Cosmos DB.
    • Usługa stanowa. Stan usługi jest przechowywany w samej usłudze. Większość usług stanowych implementuje to za pośrednictwem kolekcji Reliable Collections w usłudze Service Fabric.

  • Service Fabric Explorer. Service Fabric Explorer to narzędzie typu open source do sprawdzania klastrów usługi Service Fabric i zarządzania nimi.

  • Azure Pipelines. Usługa Azure Pipelines jest częścią usług Azure DevOps Services i uruchamia zautomatyzowane kompilacje, testy i wdrożenia. Możesz również używać rozwiązań ciągłej integracji i ciągłego dostarczania (CI/CD), takich jak Jenkins.

  • Azure Monitor. Usługa Azure Monitor zbiera i przechowuje metryki i dzienniki, w tym metryki platformy dla usług platformy Azure w telemetrii rozwiązania i aplikacji. Te dane służą do monitorowania aplikacji, konfigurowania alertów i pulpitów nawigacyjnych oraz przeprowadzania analizy głównej przyczyny awarii. Usługa Azure Monitor integruje się z usługą Service Fabric w celu zbierania metryk z kontrolerów, węzłów i kontenerów oraz dzienników kontenerów i węzłów.

  • Azure Key Vault. Usługa Key Vault umożliwia przechowywanie wpisów tajnych aplikacji używanych przez mikrousługi, takich jak parametry połączenia.

  • Azure API Management. W tej architekturze usługa API Management działa jako brama interfejsu API, która akceptuje żądania od klientów i kieruje je do usług.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych dotyczących poprawy jakości obciążenia.

Uwagi dotyczące projektowania

Ta architektura referencyjna koncentruje się na architekturach mikrousług. Mikrousługa jest małą, niezależnie wersjonowaną jednostką kodu. Można go odnaleźć za pośrednictwem mechanizmów odnajdywania usług i może komunikować się z innymi usługami za pośrednictwem interfejsów API. Każda usługa jest niezależna i powinna implementować jedną funkcję biznesową. Aby uzyskać więcej informacji na temat sposobu dekompilowania domeny aplikacji do mikrousług, zobacz Używanie analizy domeny do modelowania mikrousług.

Usługa Service Fabric zapewnia infrastrukturę do wydajnego kompilowania, wdrażania i uaktualniania mikrousług. Udostępnia również opcje skalowania automatycznego, zarządzania stanem, monitorowania kondycji i ponownego uruchamiania usług w przypadku awarii.

Usługa Service Fabric jest zgodna z modelem aplikacji, w którym aplikacja jest kolekcją mikrousług. Aplikacja jest opisana w pliku manifestu aplikacji. Ten plik definiuje typy usług, które zawiera aplikacja, wraz ze wskaźnikami do niezależnych pakietów usług.

Pakiet aplikacji zwykle zawiera również parametry, które służą jako przesłonięcia dla niektórych ustawień używanych przez usługi. Każdy pakiet usług zawiera plik manifestu opisujący pliki fizyczne i foldery niezbędne do uruchomienia tej usługi, w tym pliki binarne, pliki konfiguracji i dane tylko do odczytu. Usługi i aplikacje są niezależnie wersjonowane i możliwe do dostosowania.

Opcjonalnie manifest aplikacji może opisywać usługi, które są automatycznie aprowidowane po utworzeniu wystąpienia aplikacji. Są to usługi domyślne. W tym przypadku manifest aplikacji opisuje również sposób tworzenia tych usług. Te informacje obejmują nazwę usługi, liczbę wystąpień, zasady zabezpieczeń lub izolacji oraz ograniczenia umieszczania.

Uwaga

Unikaj korzystania z usług domyślnych, jeśli chcesz kontrolować okres istnienia usług. Usługi domyślne są tworzone podczas tworzenia aplikacji i działają tak długo, jak aplikacja jest uruchomiona.

Aby uzyskać więcej informacji, zobacz Więc chcesz dowiedzieć się więcej o usłudze Service Fabric?.

Model pakowania aplikacji do usługi

Zestaw mikrousług polega na tym, że każda usługa może być wdrażana niezależnie. W usłudze Service Fabric, jeśli pogrupujesz wszystkie usługi w jeden pakiet aplikacji, a jedna usługa nie zostanie uaktualniona, całe uaktualnienie aplikacji zostanie wycofane. Wycofanie uniemożliwia uaktualnianie innej usługi.

Z tego powodu w architekturze mikrousług zalecamy używanie wielu pakietów aplikacji. Umieść jeden lub więcej ściśle powiązanych typów usług w jeden typ aplikacji. Na przykład umieść typy usług w tym samym typie aplikacji, jeśli twój zespół jest odpowiedzialny za zestaw usług, które mają jeden z następujących atrybutów:

  • Są one uruchamiane przez ten sam czas i muszą być aktualizowane w tym samym czasie.
  • Mają ten sam cykl życia.
  • Współużytkują zasoby, takie jak zależności lub konfiguracja.

Modele programowania usługi Service Fabric

Po dodaniu mikrousługi do aplikacji usługi Service Fabric zdecyduj, czy ma stan, czy dane, które muszą być udostępniane o wysokiej dostępności i niezawodności. Jeśli tak, może przechowywać dane zewnętrznie lub czy dane są zawarte w ramach usługi? Wybierz usługę bezstanową, jeśli nie musisz przechowywać danych lub chcesz przechowywać dane w magazynie zewnętrznym. Rozważ wybranie usługi stanowej, jeśli ma zastosowanie jedna z następujących instrukcji:

  • Chcesz zachować stan lub dane w ramach usługi. Na przykład musisz, aby dane znajdowały się w pamięci blisko kodu.
  • Nie można tolerować zależności od magazynu zewnętrznego.

Jeśli masz istniejący kod, który chcesz uruchomić w usłudze Service Fabric, możesz uruchomić go jako plik wykonywalny gościa: dowolny plik wykonywalny uruchamiany jako usługa. Alternatywnie możesz spakować plik wykonywalny w kontenerze zawierającym wszystkie zależności potrzebne do wdrożenia.

Usługa Service Fabric modeluje kontenery i pliki wykonywalne gościa jako usługi bezstanowe. Aby uzyskać wskazówki dotyczące wybierania modelu, zobacz Omówienie modelu programowania usługi Service Fabric.

Odpowiadasz za utrzymanie środowiska, w którym jest uruchamiany plik wykonywalny gościa. Załóżmy na przykład, że plik wykonywalny gościa wymaga języka Python. Jeśli plik wykonywalny nie jest samodzielny, musisz upewnić się, że wymagana wersja języka Python jest wstępnie zainstalowana w środowisku. Usługa Service Fabric nie zarządza środowiskiem. Platforma Azure oferuje wiele mechanizmów konfigurowania środowiska, w tym niestandardowych obrazów maszyn wirtualnych i rozszerzeń.

Aby uzyskać dostęp do pliku wykonywalnego gościa za pośrednictwem zwrotnego serwera proxy, upewnij się, że atrybut został dodany UriScheme do Endpoint elementu w manifeście usługi pliku wykonywalnego gościa.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Jeśli usługa ma dodatkowe trasy, określ trasy w PathSuffix wartości . Wartość nie powinna być poprzedzona prefiksem ani sufiksem ukośnika (/). Innym sposobem jest dodanie trasy w nazwie usługi.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Aby uzyskać więcej informacji, zobacz:

Brama interfejsu API

Brama interfejsu API (ruch przychodzący) znajduje się między klientami zewnętrznymi a mikrousługami. Działa jako zwrotny serwer proxy, rozsyłanie żądań od klientów do mikrousług. Może również wykonywać zadania krzyżowe, takie jak uwierzytelnianie, kończenie żądań SSL i ograniczanie szybkości.

Zalecamy usługę Azure API Management dla większości scenariuszy, ale Traefik jest popularną alternatywą typu open source. Obie opcje technologii są zintegrowane z usługą Service Fabric.

  • Usługa API Management. Uwidacznia publiczny adres IP i kieruje ruch do usług. Działa w dedykowanej podsieci w tej samej sieci wirtualnej co klaster usługi Service Fabric.

    Usługa API Management może uzyskiwać dostęp do usług w typie węzła uwidacznianym za pośrednictwem modułu równoważenia obciążenia z prywatnym adresem IP. Ta opcja jest dostępna tylko w warstwach Premium i Developer usługi API Management. W przypadku obciążeń produkcyjnych użyj warstwy Premium. Informacje o cenach są opisane w cenniku usługi API Management.

    Aby uzyskać więcej informacji, zobacz Service Fabric with Azure API Management overview (Omówienie usługi Service Fabric z usługą Azure API Management).

  • Traefik. Obsługuje funkcje, takie jak routing, śledzenie, dzienniki i metryki. Traefik działa jako usługa bezstanowa w klastrze usługi Service Fabric. Przechowywanie wersji usługi może być obsługiwane za pośrednictwem routingu.

    Aby uzyskać informacje na temat sposobu konfigurowania traefik dla ruchu przychodzącego usługi i jako zwrotnego serwera proxy w klastrze, zobacz Dostawca usługi Azure Service Fabric w witrynie internetowej Traefik. Aby uzyskać więcej informacji na temat korzystania z rozwiązania Traefik z usługą Service Fabric, zobacz wpis w blogu Intelligent routing on Service Fabric with Traefik (Inteligentne routing w usłudze Service Fabric za pomocą traefika).

Traefik, w przeciwieństwie do usługi Azure API Management, nie ma funkcji rozpoznawania partycji usługi stanowej (z więcej niż jedną partycją), do której jest kierowane żądanie. Aby uzyskać więcej informacji, zobacz Dodawanie elementu matcher do partycjonowania usług.

Inne opcje zarządzania interfejsami API obejmują aplikacja systemu Azure Gateway i Azure Front Door. Te usługi można używać w połączeniu z usługą API Management do wykonywania zadań, takich jak routing, kończenie żądań SSL i zapora.

Komunikacja między usługami

Aby ułatwić komunikację między usługami, należy wziąć pod uwagę następujące zalecenia:

  • Protokół komunikacyjny. W architekturze mikrousług usługi muszą komunikować się ze sobą z minimalnym sprzężeniem w czasie wykonywania. Aby umożliwić komunikację niezależną od języka, protokół HTTP jest standardem branżowym z szeroką gamą narzędzi i serwerów HTTP, które są dostępne w różnych językach. Usługa Service Fabric obsługuje wszystkie te narzędzia i serwery.

    W przypadku większości obciążeń zalecamy używanie protokołu HTTP zamiast komunikacji zdalnie usługi wbudowanej w usługę Service Fabric.

  • Odnajdywanie usługi. Aby komunikować się z innymi usługami w klastrze, usługa kliencka musi rozpoznać bieżącą lokalizację usługi docelowej. W usłudze Service Fabric usługi mogą być przenoszone między węzłami i powodować dynamiczne zmienianie punktów końcowych usługi.

    Aby uniknąć połączeń z nieaktualnymi punktami końcowymi, możesz użyć usługi nazewnictwa w usłudze Service Fabric, aby pobrać zaktualizowane informacje o punkcie końcowym. Jednak usługa Service Fabric udostępnia również wbudowaną usługę zwrotnego serwera proxy, która abstrakcji usługi nazewnictwa. Zalecamy tę opcję odnajdywania usług jako punktu odniesienia dla większości scenariuszy, ponieważ łatwiej jest używać i stosować prostszy kod.

Inne opcje komunikacji międzyusługowej to:

  • Traefik na potrzeby zaawansowanego routingu.
  • System DNS w scenariuszach zgodności, w których usługa oczekuje użycia systemu DNS.
  • Klasa TCommunicationClient Klasy ServicePartitionClient<>, która buforuje punkty końcowe usługi. Może to zapewnić lepszą wydajność, ponieważ wywołania przechodzą bezpośrednio między usługami bez pośredników lub protokołów niestandardowych.

Skalowalność

Usługa Service Fabric obsługuje skalowanie tych jednostek klastra:

  • Skalowanie liczby węzłów dla każdego typu węzła
  • Skalowanie usług

Ta sekcja koncentruje się na skalowaniu automatycznym. Możesz wybrać ręczne skalowanie w sytuacjach, w których jest to odpowiednie. Na przykład interwencja ręczna może być wymagana do ustawienia liczby wystąpień.

Początkowa konfiguracja klastra pod kątem skalowalności

Podczas tworzenia klastra usługi Service Fabric należy aprowizować typy węzłów na podstawie wymagań dotyczących zabezpieczeń i skalowalności. Każdy typ węzła jest mapowany na zestaw skalowania maszyn wirtualnych i można go skalować niezależnie.

  • Utwórz typ węzła dla każdej grupy usług, które mają różne wymagania dotyczące skalowalności lub zasobów. Rozpocznij od aprowizowania typu węzła (który staje się typem węzła podstawowego) dla usług systemowych usługi Service Fabric. Utwórz oddzielne typy węzłów, aby uruchamiać usługi publiczne lub frontonu. Utwórz inne typy węzłów zgodnie z potrzebami dla zaplecza i prywatnych lub izolowanych usług. Określ ograniczenia umieszczania, aby usługi zostały wdrożone tylko w zamierzonych typach węzłów.
  • Określ warstwę trwałości dla każdego typu węzła. Warstwa trwałości reprezentuje zdolność usługi Service Fabric do wywierania wpływu na aktualizacje i operacje konserwacji w zestawach skalowania maszyn wirtualnych. W przypadku obciążeń produkcyjnych wybierz warstwę Silver lub większą trwałość. Aby uzyskać informacje o każdej warstwie, zobacz Właściwości trwałości klastra.
  • Jeśli używasz warstwy trwałości Brązowa, niektóre operacje wymagają ręcznych kroków. Typy węzłów z warstwą trwałości Brązowa wymagają dodatkowych kroków podczas skalowania w poziomie. Aby uzyskać więcej informacji na temat operacji skalowania, zobacz ten przewodnik.

Skalowanie węzłów

Usługa Service Fabric obsługuje skalowanie automatyczne na potrzeby skalowania w poziomie i skalowania w poziomie. Każdy typ węzła można skonfigurować na potrzeby skalowania automatycznego niezależnie.

Każdy typ węzła może mieć maksymalnie 100 węzłów. Zacznij od mniejszego zestawu węzłów i dodaj więcej węzłów w zależności od obciążenia. Jeśli potrzebujesz więcej niż 100 węzłów w typie węzła, musisz dodać więcej typów węzłów. Aby uzyskać szczegółowe informacje, zobacz Zagadnienia dotyczące planowania pojemności klastra usługi Service Fabric. Zestaw skalowania maszyn wirtualnych nie jest skalowany natychmiast, dlatego należy wziąć pod uwagę ten czynnik podczas konfigurowania reguł skalowania automatycznego.

Aby obsługiwać automatyczne skalowanie, skonfiguruj typ węzła tak, aby miał warstwę trwałości Silver lub Gold. Ta konfiguracja zapewnia opóźnienie skalowania do momentu zakończenia przenoszenia usług przez usługę Service Fabric. Zapewnia również, że zestawy skalowania maszyn wirtualnych informują usługę Service Fabric o usunięciu maszyn wirtualnych, a nie tylko tymczasowo.

Aby uzyskać więcej informacji na temat skalowania na poziomie węzła lub klastra, zobacz Skalowanie klastrów usługi Azure Service Fabric.

Skalowanie usług

Usługi bezstanowe i stanowe stosują różne podejścia do skalowania.

W przypadku usługi bezstanowej (skalowanie automatyczne):

  • Użyj wyzwalacza średniego obciążenia partycji. Ten wyzwalacz określa, kiedy usługa jest skalowana w poziomie lub w poziomie na podstawie wartości progowej obciążenia określonej w zasadach skalowania. Można również ustawić częstotliwość sprawdzania wyzwalacza. Zobacz Średni wyzwalacz obciążenia partycji ze skalowaniem opartym na wystąpieniach. Takie podejście umożliwia skalowanie w górę do liczby dostępnych węzłów.
  • Ustaw InstanceCount wartość -1 w manifeście usługi, który informuje usługę Service Fabric o uruchomieniu wystąpienia usługi w każdym węźle. Takie podejście umożliwia usłudze dynamiczne skalowanie w miarę skalowania klastra. Wraz ze zmianą liczby węzłów w klastrze usługa Service Fabric automatycznie tworzy i usuwa wystąpienia usługi w celu dopasowania.

Uwaga

W niektórych przypadkach możesz ręcznie skalować usługę. Jeśli na przykład masz usługę odczytującą z usługi Azure Event Hubs, możesz chcieć odczytać wystąpienie dedykowane z każdej partycji centrum zdarzeń. Dzięki temu można uniknąć współbieżnego dostępu do partycji.

W przypadku usługi stanowej skalowanie jest kontrolowane przez liczbę partycji, rozmiar każdej partycji oraz liczbę partycji lub replik uruchomionych na maszynie:

  • Jeśli tworzysz usługi partycjonowane, upewnij się, że każdy węzeł otrzymuje odpowiednie repliki do równomiernego rozkładu obciążenia bez powodowania rywalizacji o zasoby. Jeśli dodasz więcej węzłów, usługa Service Fabric domyślnie dystrybuuje obciążenia na nowe maszyny. Jeśli na przykład istnieją 5 węzłów i 10 partycji, usługa Service Fabric domyślnie umieści dwie repliki podstawowe na każdym węźle. W przypadku skalowania węzłów w poziomie można osiągnąć większą wydajność, ponieważ praca jest równomiernie rozłożona na więcej zasobów.

    Aby uzyskać informacje na temat scenariuszy korzystających z tej strategii, zobacz Skalowanie w usłudze Service Fabric.

  • Dodawanie lub usuwanie partycji nie jest dobrze obsługiwane. Inną opcją, która jest często używana do skalowania, jest dynamiczne tworzenie lub usuwanie usług lub całych wystąpień aplikacji. Przykład tego wzorca został opisany w temacie Skalowanie przez utworzenie lub usunięcie nowych nazwanych usług.

Aby uzyskać więcej informacji, zobacz:

Używanie metryk do równoważenia obciążenia

W zależności od sposobu projektowania partycji mogą istnieć węzły z replikami, które uzyskują większy ruch niż inne. Aby uniknąć takiej sytuacji, należy podzielić stan usługi na partycje, tak aby był dystrybuowany na wszystkich partycjach. Użyj schematu partycjonowania zakresu z dobrym algorytmem skrótu. Zobacz Wprowadzenie do partycjonowania.

Usługa Service Fabric używa metryk, aby wiedzieć, jak umieszczać i równoważyć usługi w klastrze. Możesz określić domyślne obciążenie dla każdej metryki skojarzonej z usługą podczas tworzenia tej usługi. Następnie usługa Service Fabric bierze to pod uwagę podczas umieszczania usługi lub gdy usługa musi przenieść (na przykład podczas uaktualnień), aby zrównoważyć węzły w klastrze.

Początkowo określone domyślne obciążenie usługi nie zmieni się w okresie istnienia usługi. Aby przechwycić zmieniające się metryki dla usługi, zalecamy monitorowanie usługi, a następnie dynamiczne raportowanie obciążenia. Takie podejście umożliwia usłudze Service Fabric dostosowanie alokacji na podstawie zgłoszonego obciążenia w danym momencie. Użyj metody IServicePartition.ReportLoad, aby zgłosić metryki niestandardowe. Aby uzyskać więcej informacji, zobacz Ładowanie dynamiczne.

Dostępność

Umieść usługi w typie węzła innym niż typ węzła podstawowego. Usługi systemowe usługi Service Fabric są zawsze wdrażane w podstawowym typie węzła. Jeśli usługi są wdrażane w typie węzła podstawowego, mogą konkurować z (i zakłócać) usługi systemowe dla zasobów. Jeśli typ węzła ma hostować usługi stanowe, upewnij się, że istnieją co najmniej pięć wystąpień węzłów i że wybrano warstwę trwałości Silver lub Gold.

Rozważ ograniczenie zasobów usług. Zobacz Mechanizm nadzoru nad zasobami.

Oto typowe zagadnienia:

  • Nie mieszaj usług zarządzanych przez zasób i usług, które nie są zasobami zarządzanymi w tym samym typie węzła. Usługi, które nie podlegają, mogą zużywać zbyt wiele zasobów i wpływać na zarządzane usługi. Określ ograniczenia umieszczania, aby upewnić się, że tego typu usługi nie działają w tym samym zestawie węzłów. (Jest to przykład Wzorzec grodziowy).
  • Określ rdzenie procesora CPU i pamięć do zarezerwowania dla wystąpienia usługi. Aby uzyskać informacje o użyciu i ograniczeniach zasad ładu zasobów, zobacz Zarządzanie zasobami.

Aby uniknąć pojedynczego punktu awarii (SPOF), upewnij się, że każde wystąpienie docelowe usługi lub liczba replik jest większa niż jeden. Największa liczba, której można użyć jako wystąpienia usługi lub liczby replik, jest równa liczbie węzłów, które ograniczają usługę.

Upewnij się, że każda usługa stanowa ma co najmniej dwie aktywne repliki pomocnicze. Zalecamy pięć replik dla obciążeń produkcyjnych.

Aby uzyskać więcej informacji, zobacz Dostępność usług Service Fabric.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

Oto kilka kluczowych punktów zabezpieczania aplikacji w usłudze Service Fabric.

Sieć wirtualna

Rozważ zdefiniowanie granic podsieci dla każdego zestawu skalowania maszyn wirtualnych w celu kontrolowania przepływu komunikacji. Każdy typ węzła ma własny zestaw skalowania maszyn wirtualnych w podsieci w sieci wirtualnej klastra usługi Service Fabric. Sieciowe grupy zabezpieczeń można dodać do podsieci, aby zezwolić na ruch sieciowy lub go odrzucić. Na przykład w przypadku typów węzłów frontonu i zaplecza można dodać sieciową grupę zabezpieczeń do podsieci zaplecza w celu akceptowania ruchu przychodzącego tylko z podsieci frontonu.

Podczas wywoływania zewnętrznych usług platformy Azure z klastra użyj punktów końcowych usługi sieci wirtualnej, jeśli usługa platformy Azure ją obsługuje. Użycie punktu końcowego usługi zabezpiecza usługę tylko w sieci wirtualnej klastra.

Jeśli na przykład używasz usługi Azure Cosmos DB do przechowywania danych, skonfiguruj konto usługi Azure Cosmos DB z punktem końcowym usługi, aby zezwolić na dostęp tylko z określonej podsieci. Zobacz Uzyskiwanie dostępu do zasobów usługi Azure Cosmos DB z sieci wirtualnych.

Punkty końcowe i komunikacja międzyusługowa

Nie twórz niezabezpieczonego klastra usługi Service Fabric. Jeśli klaster uwidacznia punkty końcowe zarządzania publicznym Internetem, użytkownicy anonimowi mogą się z nim łączyć. Niezabezpieczone klastry nie są obsługiwane w przypadku obciążeń produkcyjnych. Zobacz Scenariusze zabezpieczeń klastra usługi Service Fabric.

Aby zabezpieczyć komunikację międzyusługową:

  • Rozważ włączenie punktów końcowych HTTPS w usługach internetowych ASP.NET Core lub Java.
  • Ustanów bezpieczne połączenie między zwrotnym serwerem proxy i usługami. Aby uzyskać szczegółowe informacje, zobacz Połączenie do bezpiecznej usługi.

Jeśli używasz bramy interfejsu API, możesz odciążyć uwierzytelnianie do bramy. Upewnij się, że poszczególne usługi nie mogą być dostępne bezpośrednio (bez bramy interfejsu API), chyba że zostaną wprowadzone dodatkowe zabezpieczenia w celu uwierzytelnienia komunikatów.

Nie ujawniaj publicznego zwrotnego serwera proxy usługi Service Fabric. Dzięki temu wszystkie usługi, które uwidaczniają punkty końcowe HTTP, mogą być adresowalne spoza klastra. Spowoduje to wprowadzenie luk w zabezpieczeniach i potencjalnie uwidacznia dodatkowe informacje poza klastrem niepotrzebnie. Jeśli chcesz publicznie uzyskać dostęp do usługi, użyj bramy interfejsu API. Sekcja bramy interfejsu API w dalszej części tego artykułu zawiera informacje o niektórych opcjach.

Pulpit zdalny jest przydatny do diagnostyki i rozwiązywania problemów, ale pamiętaj, aby go zamknąć. Pozostawienie go otwarte powoduje dziurę bezpieczeństwa.

Wpisy tajne i certyfikaty

Przechowywanie wpisów tajnych, takich jak parametry połączenia do magazynów danych, w magazynie kluczy. Magazyn kluczy musi znajdować się w tym samym regionie co zestaw skalowania maszyn wirtualnych. Aby użyć magazynu kluczy:

  1. Uwierzytelnij dostęp usługi do magazynu kluczy.

    Włącz tożsamość zarządzaną w zestawie skalowania maszyn wirtualnych hostujących usługę.

  2. Przechowywanie wpisów tajnych w magazynie kluczy.

    Dodaj wpisy tajne w formacie, który można przetłumaczyć na parę klucz/wartość. Użyj na przykład nazwy CosmosDB--AuthKey. Po skompilacji konfiguracji podwójny łącznik (--) jest konwertowany na dwukropek (:).

  3. Uzyskaj dostęp do tych wpisów tajnych w usłudze.

    Dodaj identyfikator URI magazynu kluczy w pliku app Ustawienia.json. W usłudze dodaj dostawcę konfiguracji, który odczytuje z magazynu kluczy, skompiluje konfigurację i uzyskuje dostęp do wpisu tajnego z wbudowanej konfiguracji.

Oto przykład, w którym usługa Przepływu pracy przechowuje wpis tajny w magazynie kluczy w formacie CosmosDB--Database.

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

Aby uzyskać dostęp do wpisu tajnego, określ nazwę wpisu tajnego w wbudowanej konfiguracji.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

Nie używaj certyfikatów klienta do uzyskiwania dostępu do narzędzia Service Fabric Explorer. Zamiast tego użyj identyfikatora Entra firmy Microsoft. Zobacz Usługi platformy Azure, które obsługują uwierzytelnianie firmy Microsoft Entra.

Nie używaj certyfikatów z podpisem własnym do środowiska produkcyjnego.

Ochrona danych magazynowanych

Jeśli dyski danych są dołączone do zestawów skalowania maszyn wirtualnych klastra usługi Service Fabric i usług zapisują dane na tych dyskach, należy zaszyfrować dyski. Aby uzyskać więcej informacji, zobacz Szyfrowanie dysków systemu operacyjnego i dołączonych dysków danych w zestawie skalowania maszyn wirtualnych za pomocą programu Azure PowerShell (wersja zapoznawcza).

Aby uzyskać więcej informacji na temat zabezpieczania usługi Service Fabric, zobacz:

Odporność

Aby odzyskać sprawność po awariach i zachować w pełni działający stan, aplikacja musi zaimplementować pewne wzorce odporności. Oto kilka typowych wzorców:

  • Ponów próbę: aby obsłużyć błędy, które powinny być przejściowe, takie jak zasoby, które są tymczasowo niedostępne.
  • Wyłącznik: aby rozwiązać problemy, które mogą trwać dłużej.
  • Grodzi: aby odizolować zasoby dla każdej usługi.

Ta implementacja referencyjna używa usługi Polly, opcji typu open source, aby zaimplementować wszystkie te wzorce.

Monitorowanie

Przed zapoznaniem się z opcjami monitorowania zalecamy przeczytanie tego artykułu na temat diagnozowania typowych scenariuszy za pomocą usługi Service Fabric. Możesz myśleć o monitorowaniu danych w tych zestawach:

Są to dwie główne opcje analizowania tych danych:

  • Szczegółowe dane dotyczące aplikacji
  • Log Analytics

Za pomocą usługi Azure Monitor można skonfigurować pulpity nawigacyjne do monitorowania i wysyłać alerty do operatorów. Niektóre narzędzia do monitorowania innych firm są również zintegrowane z usługą Service Fabric, taką jak Dynatrace. Aby uzyskać szczegółowe informacje, zobacz Azure Service Fabric monitoring partners (Partnerzy monitorowania usługi Azure Service Fabric).

Metryki i dzienniki aplikacji

Dane telemetryczne aplikacji umożliwiają monitorowanie kondycji usługi i identyfikowanie problemów. Aby dodać ślady i zdarzenia w usłudze:

Szczegółowe informacje aplikacji udostępnia wiele wbudowanych danych telemetrycznych: żądania, ślady, zdarzenia, wyjątki, metryki, zależności. Jeśli twoja usługa uwidacznia punkty końcowe HTTP, włącz Szczegółowe informacje aplikacji, wywołując metodę UseApplicationInsights rozszerzenia Microsoft.AspNetCore.Hosting.IWebHostBuilder. Aby uzyskać informacje na temat instrumentowania usługi dla usługi Application Szczegółowe informacje, zobacz następujące artykuły:

Aby wyświetlić ślady i dzienniki zdarzeń, użyj funkcji Application Szczegółowe informacje jako jednego z ujść na potrzeby rejestrowania strukturalnego. Skonfiguruj Szczegółowe informacje aplikacji przy użyciu klucza instrumentacji, wywołując metodę AddApplicationInsights rozszerzenia. W tym przykładzie klucz instrumentacji jest przechowywany jako wpis tajny w magazynie kluczy.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

Jeśli usługa nie uwidacznia punktów końcowych HTTP, musisz napisać rozszerzenie niestandardowe wysyłające ślady do usługi Application Szczegółowe informacje. Aby zapoznać się z przykładem, zobacz usługę Workflow w implementacji referencyjnej.

usługi ASP.NET Core używają interfejsu ILogger do rejestrowania aplikacji. Aby udostępnić te dzienniki aplikacji w usłudze Azure Monitor, wyślij ILogger zdarzenia do usługi Application Szczegółowe informacje. Szczegółowe informacje aplikacji może dodawać właściwości korelacji do ILogger zdarzeń, co jest przydatne do wizualizowania śledzenia rozproszonego.

Aby uzyskać więcej informacji, zobacz:

Dane kondycji i zdarzeń usługi Service Fabric

Dane telemetryczne usługi Service Fabric obejmują metryki kondycji i zdarzenia dotyczące operacji i wydajności klastra usługi Service Fabric oraz jego jednostek: jego węzły, aplikacje, usługi, partycje i repliki. Dane dotyczące kondycji i zdarzeń mogą pochodzić z:

  • EventStore. Ta stanowa usługa systemowa zbiera zdarzenia związane z klastrem i jego jednostkami. Usługa Service Fabric używa usługi EventStore do zapisywania zdarzeń usługi Service Fabric w celu udostępnienia informacji o klastrze na potrzeby aktualizacji stanu, rozwiązywania problemów i monitorowania. Magazyn zdarzeń może również korelować zdarzenia z różnych jednostek w danym momencie, aby zidentyfikować problemy w klastrze. Usługa uwidacznia te zdarzenia za pośrednictwem interfejsu API REST.

    Aby uzyskać informacje o sposobie wykonywania zapytań dotyczących interfejsów API magazynu zdarzeń, zobacz Query EventStore APIs for cluster events (Wykonywanie zapytań o interfejsy API magazynu zdarzeń dla zdarzeń klastra). Zdarzenia można wyświetlić z usługi EventStore w usłudze Log Analytics, konfigurując klaster przy użyciu rozszerzenia Diagnostyka Azure dla systemu Windows (WAD).

  • Magazyn kondycji. Ta stanowa usługa udostępnia migawkę bieżącej kondycji klastra. Agreguje wszystkie dane kondycji zgłaszane przez jednostki w hierarchii. Dane są wizualizowane w narzędziu Service Fabric Explorer. HealthStore monitoruje również uaktualnienia aplikacji. Zapytania dotyczące kondycji można używać w programie PowerShell, aplikacji .NET lub interfejsach API REST. Zobacz Wprowadzenie do monitorowania kondycji usługi Service Fabric.

  • Niestandardowe raporty dotyczące kondycji. Rozważ zaimplementowanie wewnętrznych usług watchdog, które mogą okresowo zgłaszać niestandardowe dane o kondycji, takie jak uszkodzone stany uruchomionych usług. Raporty dotyczące kondycji można odczytać w narzędziu Service Fabric Explorer.

Metryki i dzienniki infrastruktury

Metryki infrastruktury ułatwiają zrozumienie alokacji zasobów w klastrze. Poniżej przedstawiono główne opcje zbierania tych informacji:

  • WAD. Zbieranie dzienników i metryk na poziomie węzła w systemie Windows. Wad można użyć, konfigurując rozszerzenie IaaSDiagnostics maszyny wirtualnej na dowolnym zestawie skalowania maszyn wirtualnych zamapowanym na typ węzła w celu zbierania zdarzeń diagnostycznych. Te zdarzenia mogą obejmować dzienniki zdarzeń systemu Windows, liczniki wydajności, system ETW/manifest i zdarzenia operacyjne oraz dzienniki niestandardowe.
  • Agent usługi Log Analytics. Skonfiguruj rozszerzenie microsoftMonitoringAgent maszyny wirtualnej w celu wysyłania dzienników zdarzeń systemu Windows, liczników wydajności i dzienników niestandardowych do usługi Log Analytics.

Istnieją pewne nakładające się typy metryk zebranych za pomocą powyższych mechanizmów, takich jak liczniki wydajności. W przypadku nakładania się na siebie zalecamy użycie agenta usługi Log Analytics. Ponieważ agent usługi Log Analytics nie korzysta z usługi Azure Storage, opóźnienie jest niskie. Ponadto liczniki wydajności w usłudze IaaSDiagnostics nie mogą być łatwo przekazywane do usługi Log Analytics.

Diagram that shows infrastructure monitoring in Service Fabric.

Aby uzyskać informacje na temat używania rozszerzeń maszyn wirtualnych, zobacz Rozszerzenia i funkcje maszyn wirtualnych platformy Azure.

Aby wyświetlić dane, skonfiguruj usługę Log Analytics, aby wyświetlić dane zebrane za pośrednictwem wad. Aby uzyskać informacje o sposobie konfigurowania usługi Log Analytics pod kątem odczytywania zdarzeń z konta magazynu, zobacz Konfigurowanie usługi Log Analytics dla klastra.

Można również wyświetlić dzienniki wydajności i dane telemetryczne związane z klastrem usługi Service Fabric, obciążeniami, ruchem sieciowym, oczekującymi aktualizacjami i nie tylko. Zobacz Monitorowanie wydajności za pomocą usługi Log Analytics.

Rozwiązanie Service Map w usłudze Log Analytics zawiera informacje na temat topologii klastra (czyli procesów uruchomionych w każdym węźle). Wyślij dane na koncie magazynu do Szczegółowe informacje aplikacji. Może wystąpić pewne opóźnienie podczas pobierania danych do Szczegółowe informacje aplikacji. Jeśli chcesz zobaczyć dane w czasie rzeczywistym, rozważ skonfigurowanie usługi Event Hubs przy użyciu ujścia i kanałów. Aby uzyskać więcej informacji, zobacz Agregacja i zbieranie zdarzeń przy użyciu wad.

Metryki usług zależnych

  • Mapa aplikacji w usłudze Application Szczegółowe informacje udostępnia topologię aplikacji przy użyciu wywołań zależności HTTP między usługami z zainstalowanym zestawem SDK usługi Application Szczegółowe informacje.
  • Usługa Service Map w usłudze Log Analytics zawiera informacje o ruchu przychodzącym i wychodzącym z i do usług zewnętrznych. Usługa Service Map integruje się z innymi rozwiązaniami, takimi jak aktualizacje lub zabezpieczenia.
  • Niestandardowe watchdogi mogą zgłaszać warunki błędów w usługach zewnętrznych. Na przykład usługa może dostarczyć raport o kondycji błędu, jeśli nie może uzyskać dostępu do zewnętrznej usługi lub magazynu danych (Azure Cosmos DB).

Śledzenie rozproszone

W architekturze mikrousług kilka usług często uczestniczy w wykonaniu zadania. Dane telemetryczne z każdej z tych usług są skorelowane za pośrednictwem pól kontekstu (takich jak identyfikator operacji i identyfikator żądania) w rozproszonym śladzie.

Korzystając z mapy aplikacji w Szczegółowe informacje aplikacji, można utworzyć widok rozproszonych operacji logicznych i zwizualizować cały graf usługi aplikacji. Możesz również użyć diagnostyki transakcji w usłudze Application Szczegółowe informacje, aby skorelować dane telemetryczne po stronie serwera. Aby uzyskać więcej informacji, zobacz Ujednolicona diagnostyka transakcji między składnikami.

Ważne jest również skorelowanie zadań, które są wysyłane asynchronicznie przy użyciu kolejki. Aby uzyskać szczegółowe informacje na temat wysyłania danych telemetrycznych korelacji w komunikacie kolejki, zobacz Instrumentacja kolejki.

Aby uzyskać więcej informacji, zobacz:

Alerty i pulpity nawigacyjne

Usługa Application Szczegółowe informacje i Log Analytics obsługują rozbudowany język zapytań (język zapytań Kusto), który umożliwia pobieranie i analizowanie danych dziennika. Użyj zapytań, aby utworzyć zestawy danych i zwizualizować je na pulpitach nawigacyjnych diagnostyki.

Alerty usługi Azure Monitor umożliwiają powiadamianie administratorów systemu o wystąpieniu określonych warunków w określonych zasobach. Na przykład powiadomienie może być wiadomością e-mail, funkcją platformy Azure lub elementem webhook. Aby uzyskać więcej informacji, zobacz Alerty w usłudze Azure Monitor.

Reguły alertów przeszukiwania dzienników umożliwiają definiowanie i uruchamianie zapytania Kusto względem obszaru roboczego usługi Log Analytics w regularnych odstępach czasu. Alert jest tworzony, jeśli wynik zapytania jest zgodny z określonym warunkiem.

Optymalizacja kosztów

Koszty możesz szacować za pomocą kalkulatora cen platformy Azure. Inne zagadnienia zostały opisane w filarze optymalizacji kosztów platformy Microsoft Azure Well-Architected Framework.

Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę w przypadku niektórych usług używanych w tej architekturze.

Azure Service Fabric

Opłaty są naliczane za wystąpienia obliczeniowe, magazyn, zasoby sieciowe i adresy IP wybrane podczas tworzenia klastra usługi Service Fabric. Za usługę Service Fabric są naliczane opłaty za wdrożenie.

Zestawy skalowania maszyn wirtualnych

W tej architekturze mikrousługi są wdrażane w węzłach, które są zestawami skalowania maszyn wirtualnych. Opłaty są naliczane za maszyny wirtualne platformy Azure wdrożone w ramach klastra i podstawowych zasobów infrastruktury, takich jak magazyn i sieć. Nie ma żadnych opłat przyrostowych dla samych zestawów skalowania maszyn wirtualnych.

Usługa Azure API Management

Usługa Azure API Management to brama do kierowania żądań od klientów do usług w klastrze.

Dostępne są różne opcje cenowe. Opcja Zużycie jest naliczana na zasadzie płatności za użycie i obejmuje składnik bramy. Na podstawie obciążenia wybierz opcję opisaną w cenniku usługi API Management.

Szczegółowe dane dotyczące aplikacji

Za pomocą Szczegółowe informacje aplikacji można zbierać dane telemetryczne dla wszystkich usług oraz wyświetlać ślady i dzienniki zdarzeń w sposób ustrukturyzowany. Ceny usługi Application Szczegółowe informacje to model płatności zgodnie z rzeczywistym użyciem oparty na pozyskanym woluminie danych i opcjach przechowywania danych. Aby uzyskać więcej informacji, zobacz Zarządzanie użyciem i kosztami aplikacji Szczegółowe informacje.

Azure Monitor

W przypadku usługi Azure Monitor Log Analytics opłaty są naliczane za pozyskiwanie i przechowywanie danych. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Monitor.

Azure Key Vault

Usługa Azure Key Vault służy do przechowywania klucza instrumentacji dla usługi Application Szczegółowe informacje jako wpisu tajnego. Platforma Azure oferuje usługę Key Vault w dwóch warstwach usług. Jeśli nie potrzebujesz kluczy chronionych przez moduł HSM, wybierz warstwę Standardowa. Aby uzyskać informacje o funkcjach w każdej warstwie, zobacz Cennik usługi Key Vault.

Azure DevOps Services

Ta architektura referencyjna używa usługi Azure Pipelines do wdrożenia. Usługa Azure Pipelines umożliwia bezpłatne zadanie hostowane przez firmę Microsoft z 1800 minutami miesięcznie w przypadku ciągłej integracji/ciągłego wdrażania i jedno zadanie hostowane samodzielnie z nieograniczoną liczbą minut miesięcznie. Dodatkowe zadania mają opłaty. Aby uzyskać więcej informacji, zobacz Cennik usług Azure DevOps Services.

Aby zapoznać się z zagadnieniami dotyczącymi metodyki DevOps w architekturze mikrousług, zobacz Ciągła integracja/ciągłe wdrażanie dla mikrousług.

Aby dowiedzieć się, jak wdrożyć aplikację kontenera przy użyciu ciągłej integracji/ciągłego wdrażania w klastrze usługi Service Fabric, zobacz ten samouczek.

Wdrażanie tego scenariusza

Aby wdrożyć implementację referencyjną dla tej architektury, wykonaj kroki opisane w repozytorium GitHub.

Następne kroki