Odporna komunikacja
Napiwek
Ta zawartość jest fragmentem książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
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?
Zabezpieczenia. 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ą.
Siatka 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.
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.
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:
