Wybieranie opcji obliczeń platformy Azure dla mikrousług

  • Artykuł

Termin obliczenia dotyczy modelu hostingu zasobów obliczeniowych używanych do uruchamiania aplikacji. W przypadku architektury mikrousług dwa podejścia są szczególnie popularne:

  • Orkiestrator usługi, który zarządza usługami działającymi na dedykowanych węzłach (maszynach wirtualnych).
  • Architektura bezserwerowa korzystająca z funkcji jako usługi (FaaS).

Chociaż nie są to jedyne opcje, są to sprawdzone podejścia do tworzenia mikrousług. Aplikacja może zawierać oba podejścia.

Orkiestratory usług

Orkiestrator obsługuje zadania związane z wdrażaniem zestawu usług i zarządzaniem nimi. Te zadania obejmują umieszczanie usług w węzłach, monitorowanie kondycji usług, ponowne uruchamianie usług w złej kondycji, równoważenie obciążenia ruchu sieciowego między wystąpieniami usług, odnajdywanie usług, skalowanie liczby wystąpień usługi i stosowanie aktualizacji konfiguracji. Popularne orkiestratory to Kubernetes, Service Fabric, DC/OS i Docker Swarm.

Na platformie Azure należy wziąć pod uwagę następujące opcje:

  • Azure Kubernetes Service (AKS) to usługa zarządzana platformy Kubernetes. Usługa AKS aprowizuje platformę Kubernetes i uwidacznia punkty końcowe interfejsu API Kubernetes, ale hostuje płaszczyznę sterowania Kubernetes i zarządza nią, przeprowadza automatyczne uaktualnienia, automatyczne stosowanie poprawek, skalowanie automatyczne i inne zadania zarządzania. Usługę AKS można traktować jako "interfejsy API Kubernetes jako usługę".

  • Azure Container Apps to zarządzana usługa oparta na platformie Kubernetes, która tworzy abstrakcję złożoności orkiestracji kontenerów i innych zadań zarządzania. Usługa Container Apps upraszcza wdrażanie konteneryzowanych aplikacji i mikrousług oraz zarządzanie nimi w środowisku bezserwerowym, zapewniając jednocześnie funkcje platformy Kubernetes.

  • Service Fabric to platforma systemów rozproszonych do tworzenia pakietów, wdrażania mikrousług i zarządzania nimi. Mikrousługi można wdrażać w usłudze Service Fabric jako kontenery, jako pliki wykonywalne binarne lub jako usługi Reliable Services. Korzystając z modelu programowania usług Reliable Services, usługi mogą bezpośrednio używać interfejsów API programowania usługi Service Fabric do wykonywania zapytań dotyczących systemu, raportowania kondycji, odbierania powiadomień o zmianach konfiguracji i kodu oraz odnajdywania innych usług. Kluczową różnicą w usłudze Service Fabric jest skupienie się na tworzeniu usług stanowych przy użyciu niezawodnych kolekcji.

  • Inne opcje, takie jak docker Enterprise Edition, mogą być uruchamiane w środowisku IaaS na platformie Azure. Szablony wdrażania można znaleźć na Azure Marketplace.

Kontenery

Czasami ludzie mówią o kontenerach i mikrousługach tak, jakby były takie same. Chociaż nie jest to prawdą — nie potrzebujesz kontenerów do tworzenia mikrousług — kontenery mają pewne korzyści, które są szczególnie istotne dla mikrousług, takich jak:

  • Przenośność. Obraz kontenera to autonomiczny pakiet, który działa bez konieczności instalowania bibliotek ani innych zależności. Dzięki temu można je łatwo wdrożyć. Kontenery można uruchamiać i zatrzymywać szybko, aby można było uruchamiać nowe wystąpienia w celu obsługi większej liczby obciążeń lub odzyskiwania po awariach węzłów.

  • Gęstość. Kontenery są uproszczone w porównaniu z uruchamianiem maszyny wirtualnej, ponieważ współużytkują zasoby systemu operacyjnego. Dzięki temu można spakować wiele kontenerów na jeden węzeł, co jest szczególnie przydatne, gdy aplikacja składa się z wielu małych usług.

  • Izolacja zasobów. Możesz ograniczyć ilość pamięci i procesora CPU dostępnego dla kontenera, co może pomóc w zapewnieniu, że proces uciekający nie wyczerpuje zasobów hosta. Aby uzyskać więcej informacji, zobacz wzorzec grodziowy .

Bezserwerowe (funkcje jako usługa)

Architektura bezserwerowa nie umożliwia zarządzania maszynami wirtualnymi ani infrastrukturą sieci wirtualnej. Zamiast tego wdrażasz kod i usługa hostingu obsługuje umieszczanie tego kodu na maszynie wirtualnej i wykonywanie go. Takie podejście ma tendencję do faworyzowania małych szczegółowych funkcji, które są koordynowane przy użyciu wyzwalaczy opartych na zdarzeniach. Na przykład komunikat umieszczany w kolejce może wyzwolić funkcję, która odczytuje z kolejki i przetwarza komunikat.

Azure Functions to bezserwerowa usługa obliczeniowa, która obsługuje różne wyzwalacze funkcji, w tym żądania HTTP, kolejki usługi Service Bus i zdarzenia usługi Event Hubs. Aby uzyskać pełną listę, zobacz pojęcia dotyczące wyzwalaczy i powiązań Azure Functions. Rozważ również Azure Event Grid, która jest usługą routingu zdarzeń zarządzanych na platformie Azure.

Orkiestrator czy bezserwerowy?

Poniżej przedstawiono niektóre czynniki, które należy wziąć pod uwagę podczas wybierania podejścia orkiestratora i podejścia bezserwerowego.

Zarządzania Aplikacja bezserwerowa jest łatwa do zarządzania, ponieważ platforma zarządza wszystkimi zasobami obliczeniowymi. Chociaż orkiestrator tworzy abstrakcję niektórych aspektów zarządzania klastrem i konfigurowania go, nie ukrywa całkowicie bazowych maszyn wirtualnych. W przypadku orkiestratora należy zastanowić się nad problemami, takimi jak równoważenie obciążenia, użycie procesora CPU i pamięci oraz sieć.

Elastyczność i kontrola. Orkiestrator zapewnia dużą kontrolę nad konfigurowaniem usług i klastrem oraz zarządzaniem nimi. Kompromis jest dodatkową złożonością. W przypadku architektury bezserwerowej można zrezygnować z pewnego stopnia kontroli, ponieważ te szczegóły są abstrakcyjne.

Przenośność. Wszystkie orkiestratory wymienione tutaj (Kubernetes, DC/OS, Docker Swarm i Service Fabric) mogą działać lokalnie lub w wielu chmurach publicznych.

Integracja aplikacji. Tworzenie złożonej aplikacji przy użyciu architektury bezserwerowej może być trudne ze względu na konieczność koordynowania, wdrażania i zarządzania wieloma małymi niezależnymi funkcjami. Jedną z opcji na platformie Azure jest użycie usługi Azure Logic Apps do koordynowania zestawu Azure Functions. Przykład tego podejścia można znaleźć w temacie Create a function that integrates with Azure Logic Apps (Tworzenie funkcji zintegrowanej z usługą Azure Logic Apps).

Koszt. W przypadku orkiestratora płacisz za maszyny wirtualne uruchomione w klastrze. W przypadku aplikacji bezserwerowej płacisz tylko za rzeczywiste zużyte zasoby obliczeniowe. W obu przypadkach należy uwzględnić koszt wszelkich dodatkowych usług, takich jak magazyn, bazy danych i usługi obsługi komunikatów.

Skalowalność. Azure Functions automatycznie skaluje się w celu spełnienia zapotrzebowania na podstawie liczby zdarzeń przychodzących. Za pomocą orkiestratora można skalować w poziomie, zwiększając liczbę wystąpień usług uruchomionych w klastrze. Można również skalować, dodając dodatkowe maszyny wirtualne do klastra.

Nasza implementacja referencyjna korzysta głównie z platformy Kubernetes, ale używaliśmy Azure Functions dla jednej usługi, a mianowicie usługi Historia dostarczania. Azure Functions był dobrym rozwiązaniem dla tej konkretnej usługi, ponieważ jest to obciążenie sterowane zdarzeniami. Używając wyzwalacza usługi Event Hubs w celu wywołania funkcji, usługa potrzebowała minimalnej ilości kodu. Ponadto usługa Historia dostarczania nie jest częścią głównego przepływu pracy, dlatego uruchomienie go poza klastrem Kubernetes nie ma wpływu na całkowite opóźnienie operacji zainicjowanych przez użytkownika.

Następne kroki

Komunikacja między usługami