Udostępnij za pośrednictwem

Odporna komunikacja

Wskazówka

Ta zawartość jest fragmentem e-książki, Architektura Cloud Native .NET Applications for Azure, dostępnej w .NET Docs lub jako bezpłatny plik PDF do pobrania, który można czytać offline.

Pobierz plik PDF

Natywne aplikacje .NET dla chmury Azure - okładka miniatury eBooka.

W tej książce przyjęliśmy podejście architektury oparte na mikrousługach. Chociaż taka architektura zapewnia ważne korzyści, stanowi wiele wyzwań:

  • Komunikacja sieciowa poza procesem. Każda mikrousługa komunikuje się za pośrednictwem protokołu sieciowego, który wprowadza przeciążenie sieci, opóźnienia i błędy przejściowe.

  • Odnajdywanie usługi. Jak mikrousługi odnajdują i komunikują się ze sobą podczas uruchamiania w klastrze maszyn z własnymi adresami IP i portami?

  • Odporność. Jak zarządzać krótkotrwałymi awariami i utrzymać stabilność systemu?

  • Równoważenie obciążenia. W jaki sposób ruch przychodzący jest dystrybuowany w wielu wystąpieniach mikrousługi?

  • Bezpieczeństwo. W jaki sposób są wymuszane obawy dotyczące zabezpieczeń, takie jak szyfrowanie na poziomie transportu i zarządzanie certyfikatami?

  • Monitorowanie rozproszone. - Jak skorelować i przechwycić możliwość śledzenia i monitorowanie pojedynczego żądania w wielu mikrousługach zużywających wiele?

Możesz rozwiązać te problemy z różnymi bibliotekami i strukturami, ale implementacja może być kosztowna, złożona i czasochłonna. W końcu kwestie związane z infrastrukturą są powiązane z logiką biznesową.

Sieć usług

Lepszym podejściem jest rozwijająca się technologia zatytułowana Service Mesh. Siatka usług to konfigurowalna warstwa infrastruktury z wbudowanymi funkcjami do obsługi komunikacji z usługą i innymi wyzwaniami wymienionymi powyżej. Rozdziela te obawy, przenosząc je do serwera proxy usługi. Serwer proxy jest wdrażany w osobnym procesie ( nazywanym przyczepką), aby zapewnić izolację od kodu biznesowego. Jednak przyczepka jest połączona z usługą — jest tworzona wraz z nią i udostępnia swój cykl życia. Rysunek 6–7 przedstawia ten scenariusz.

Siatka serwisowa z samochodem bocznym

Rysunek 6–7. Siatka serwisowa z samochodem bocznym

Na poprzedniej ilustracji zwróć uwagę, jak serwer proxy przechwytuje komunikację między mikrousługami i klastrem oraz zarządza nią.

Siatka usług jest logicznie podzielona na dwa różne składniki: płaszczyznę danych i płaszczyznę sterowania. Rysunek 6–8 przedstawia te składniki i ich obowiązki.

Kontrolka siatki usług i płaszczyzna danych

Rysunek 6–8. Kontrolka siatki usług i płaszczyzna danych

Po skonfigurowaniu siatka usług jest wysoce funkcjonalna. Może pobrać odpowiednią pulę wystąpień z punktu końcowego odnajdywania usługi. Siatka może następnie wysłać żądanie do określonego wystąpienia, rejestrując opóźnienie i typ odpowiedzi wyniku. Siatka może wybrać wystąpienie, które najprawdopodobniej zwróci szybką odpowiedź na podstawie wielu czynników, w tym zaobserwowanego opóźnienia dla ostatnich żądań.

Jeśli wystąpienie nie odpowiada lub kończy się niepowodzeniem, siatka ponowi próbę żądania w innym wystąpieniu. Jeśli zwraca błędy, siatka spowoduje wykluczenie wystąpienia z puli równoważenia obciążenia i ich odtworzenie po jego usunięciu. Jeśli upłynął limit czasu żądania, siatka może zakończyć się niepowodzeniem, a następnie ponowić próbę żądania. Siatka przechwytuje i emituje metryki oraz rozproszone śledzenie do scentralizowanego systemu metryk.

Istio i Envoy

Chociaż obecnie istnieje kilka opcji siatki usług, Istio jest najbardziej popularne w momencie pisania tego tekstu. Istio to wspólne przedsięwzięcie firmy IBM, Google i Lyft. Jest to oferta typu open source, którą można zintegrować z nową lub istniejącą aplikacją rozproszoną. Technologia zapewnia spójne i kompletne rozwiązanie do zabezpieczania, łączenia i monitorowania mikrousług. Jego funkcje obejmują:

  • Zabezpieczanie komunikacji między usługami w klastrze przy użyciu silnego uwierzytelniania opartego na tożsamościach i autoryzacji.
  • Automatyczne równoważenie obciążenia dla ruchu HTTP, gRPC, WebSocket i TCP.
  • Szczegółowa kontrola zachowania ruchu przy użyciu zaawansowanych reguł routingu, ponownych prób, przełączeń w tryb failover i iniekcji błędów.
  • Podłączany interfejs API warstwy zasad i konfiguracji obsługujący kontrole dostępu, limity szybkości i limity przydziału.
  • Automatyczne metryki, dzienniki i ślady dla całego ruchu w klastrze, w tym ruch przychodzący i wychodzący klastra.

Kluczowym składnikiem implementacji istio jest usługa proxy zatytułowana Envoy proxy. Działa wraz z każdą usługą i zapewnia niezależną od platformy podstawę dla następujących funkcji:

  • Dynamiczne odnajdywanie usług.
  • Równoważenie obciążenia.
  • Kończenie żądań protokołu TLS.
  • Serwery proxy HTTP i gRPC.
  • Odporność wyłącznika.
  • Kontrole kondycji.
  • Aktualizacje stopniowe z wdrożeniami kanarowymi .

Jak wspomniano wcześniej, aplikacja Envoy jest wdrażana jako przyczepka do każdej mikrousługi w klastrze.

Integracja z usługą Azure Kubernetes Services

Chmura platformy Azure obejmuje platformę Istio i zapewnia bezpośrednią pomoc techniczną w ramach usług Azure Kubernetes Services. Poniższe linki mogą pomóc w rozpoczęciu pracy:

Źródła

PoprzedniNastępny