Udostępnij za pośrednictwem

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ą one oba 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 nim. 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 rozważ 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 platformy Kubernetes i zarządza nią, wykonuje 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 usługa zarządzana oparta na rozwiązaniu Kubernetes, która abstrahuje od złożoności aranżacji 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 kolekcji Reliable Collections.

  • Inne opcje, takie jak Docker Enterprise Edition, mogą być uruchamiane w środowisku IaaS na platformie Azure. Szablony wdrażania można znaleźć w witrynie 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 lub innych zależności. Ułatwia to ich wdrażanie. 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ą lekkie 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 ucieczki nie wyczerpał 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ę odczytującą z kolejki i przetwarzającą 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ń usługi Azure Functions. Rozważ również usługę Azure Event Grid, która jest usługą routingu zdarzeń zarządzanych na platformie Azure.

Orkiestrator lub bezserwerowy?

Poniżej przedstawiono niektóre czynniki, które należy wziąć pod uwagę podczas wybierania między podejściem orkiestratora a podejściem bezserwerowym.

Zarządzanie aplikacją bezserwerową można łatwo zarządzać, ponieważ platforma zarządza wszystkimi zasobami obliczeniowymi. Podczas gdy orkiestrator abstrahuje niektóre aspekty 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 usługi Azure Functions. Aby zapoznać się z przykładem tego podejścia, zobacz 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ść. Usługa Azure Functions jest skalowana automatycznie 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ługi 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 usługi Azure Functions dla jednej usługi, a mianowicie usługi Historia dostarczania. Usługa Azure Functions była 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 kompleksowe opóźnienie operacji zainicjowanych przez użytkownika.

Następne kroki

Komunikacja między usługami