Edytuj

Udostępnij za pośrednictwem

Rozwiązania wielochmurowe ze strukturą bezserwerową

Azure Functions

W tym artykule opisano sposób współpracy zespołu microsoft Commercial Software Engineering (CSE) z globalnym sprzedawcą detalicznym w celu wdrożenia rozwiązania bezserwerowego o wysokiej dostępności na platformach w chmurze platformy Azure i Amazon Web Services (AWS) przy użyciu platformy bezserwerowej.

Architektura

Diagram przedstawiający architekturę bezserwerową z wieloma chmurami.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych

  • Aplikacja użytkownika może pochodzić z dowolnego źródła, które może zalogować się do chmury. W tej implementacji użytkownik loguje się do aplikacji bramy, która równoważy obciążenie żąda od 50 do 50 między chmurami platformy Azure i usług AWS.
  • Każda odpowiedź kieruje również przez bramę usługi API Manager, która następnie wysyła ją do aplikacji osoby żądającej.

Składniki

Struktura bezserwerowa

To rozwiązanie korzysta z platformy Bezserwerowej dostępnej w witrynie Serverless, Inc. Bezpłatna wersja platformy Bezserwerowej obejmuje interfejs wiersza polecenia, więcej wtyczek i ograniczonych usług monitorowania. Wersja Pro oferuje możliwości operacyjne w chmurach, takie jak ulepszone monitorowanie i alerty. Platforma obsługuje języki Node.js i Python oraz hosty usług AWS i Azure w chmurze.

Aby korzystać z platformy Azure z platformą Serverless Framework, potrzebne są następujące elementy:

  • Node.js do tworzenia pakietów mikrousług
  • Azure Functions, aby zapewnić funkcjonalność porównywalną z innymi platformami w chmurze
  • Platforma bezserwerowa do obsługi wdrażania i monitorowania w wielu chmurach
  • Biblioteka wielochmurowa bezserwerowa w celu zapewnienia znormalizowanych interfejsów API środowiska uruchomieniowego dla deweloperów
  • Wtyczka Azure Functions Bezserwerowa do obsługi wdrożenia w wielu chmurach. Ta wtyczka nie była początkowo zgodna z porównywalną wtyczką AWS Lambda i została rozszerzona dla tego projektu.

Na poniższej ilustracji przedstawiono potok przetwarzania. Warstwy oprogramowania pośredniczącego reprezentują wszelkie wymagane funkcje pośrednie przed dotarciem do programu obsługi.

Diagram przedstawiający potok przetwarzania wielochmurowego.

Niezależne od chmury interfejsy API

Implementacja bezserwerowa na każdej platformie obsługuje poszczególne funkcje jako mikrousługi, po jednym do każdego funkcjonalnego węzła maszyny wirtualnej i wykonuje przetwarzanie zgodnie z potrzebami. Każda funkcja lambda platformy AWS ma odpowiednią funkcję Azure Functions. Biblioteka wielochmurowa bezserwerowa tworzy analogiczne mikrousługi z chmury do niezależnego od chmury znormalizowanego interfejsu API REST, którego aplikacje klienckie mogą używać do interfejsu z jedną z tych platform. Ponieważ abstrakcyjna warstwa interfejsu API udostępnia kod adresowany do odpowiednich mikrousług dla każdej platformy, transakcje nie wymagają tłumaczenia. Interfejs niezależne od chmury umożliwia aplikacjom użytkowników interakcję z chmurą bez znajomości lub dbania o platformę w chmurze, do której uzyskuje dostęp.

Na poniższym diagramie przedstawiono tę koncepcję:

Diagram przedstawiający niezależną od chmury interfejs API.

Ciągła integracja/ciągłe wdrażanie za pomocą metodyki GitOps

Podstawowym zadaniem struktury bezserwerowej jest abstrakcja wszystkich kwestii związanych z infrastrukturą wdrażania aplikacji w chmurze. Korzystając z podejścia opartego na manifeście, platforma bezserwerowa może radzić sobie ze wszystkimi problemami z wdrażaniem, umożliwiając zautomatyzowanie wdrożenia zgodnie z potrzebami w celu obsługi metodyki GitOps.

Mimo że ten początkowy projekt używał wdrożeń ręcznych, realistyczne jest zaimplementowanie bezserwerowych kompilacji, testów i wdrożeń opartych na manifeście w chmurach lub w różnych chmurach. Ten proces może korzystać z przepływu pracy dewelopera GitOps: kompilowania z usługi Git, używania bram jakości do testowania i oceny oraz wypychania rozwiązań bezserwerowych do obu dostawców chmury. Wykonywanie wszystkich wdrożeń przy użyciu struktury bezserwerowej od początku projektu jest najbardziej efektywnym sposobem na kontynuowanie.

Menedżer interfejsów API

Usługa API Manager może być istniejącą lub niestandardową aplikacją. Usługa ApiGee™ API Manager w tej implementacji działała tylko jako router, aby zapewnić 50-50-50 równoważenia obciążenia transakcji do dwóch platform w chmurze i była niedostatecznie wykorzystywana dla jego możliwości.

Menedżer interfejsów API musi mieć następujące możliwości:

  • Być wdrażane wewnątrz lub na zewnątrz platformy w chmurze zgodnie z potrzebami
  • Kierowanie komunikatów do i z obu platform w chmurze
  • Rejestrowanie żądań ruchu w celu koordynowania ruchu asynchronicznego komunikatów
  • Przekazywanie żądań i odpowiedzi przy użyciu wspólnego interfejsu API REST z i do aplikacji użytkownika
  • Monitorowanie kondycji obu wdrożeń platformy bezserwerowej w chmurze w celu zweryfikowania ich możliwości odbierania żądań
  • Przeprowadzanie automatycznych kontroli kondycji i dostępności na każdej platformie w chmurze w celu obsługi routingu i wysokiej dostępności

Alternatywy

  • Inne języki, takie jak Python, mogą implementować rozwiązanie, o ile są one obsługiwane przez bezserwerowe implementacje platform w chmurze, AWS Lambda i Azure Functions w tym przypadku. W tym projekcie użyto Node.js do spakowania mikrousług, ponieważ klient był komfortowo z Node.js, a platformy AWS i Azure go obsługują.

  • Rozwiązanie może korzystać z dowolnej platformy w chmurze, która obsługuje platformę Bezserwerową, a nie tylko platformę Azure i platformę AWS. Obecnie platforma Bezserwerowa zgłasza zgodność z ośmioma różnymi dostawcami usług w chmurze. Jedynym zastrzeżeniem jest zapewnienie, że elementy, które obsługują architekturę wielochmurową lub jej odpowiednik, są dostępne na docelowych platformach w chmurze.

  • Menedżer interfejsów API w tej początkowej implementacji działał tylko jako router, aby zapewnić równoważenie obciążenia transakcji 50–50 do dwóch platform w chmurze. Usługa API Manager może uwzględniać inną logikę biznesową dla określonych scenariuszy.

Szczegóły scenariusza

W przypadku przetwarzania bezserwerowego dostawca usług w chmurze dynamicznie przydziela zasoby mikrousług do uruchamiania kodu i nalicza tylko opłaty za używane zasoby. Przetwarzanie bezserwerowe abstrahuje kod aplikacji od implementacji infrastruktury, wdrażania kodu i aspektów operacyjnych, takich jak planowanie i konserwacja.

Podobnie jak w przypadku innych usług, każdy dostawca usług w chmurze ma własną implementację bezserwerową i trudno jest klientom korzystać z innego dostawcy bez znacznego wpływu i kosztów operacyjnych. Potencjalni klienci mogą postrzegać tę sytuację jako osłabienie pozycji przetargowej i elastyczności. Blokada dostawcy jest jedną z największych przeszkód w wdrożeniu chmury przedsiębiorstwa.

Platforma bezserwerowa typu open source to uniwersalny interfejs chmury do opracowywania i wdrażania rozwiązań przetwarzania bezserwerowego u dostawców chmury. Open-sourcing i typowe interfejsy API dla funkcji bezserwerowych pomagają dostawcom, klientom i partnerom tworzyć rozwiązania między chmurami w celu uzyskania najlepszych usług. Struktura bezserwerowa zmniejsza bariery wdrażania chmury przez rozwiązywanie problemów z nadmiarowością dostawcy i dostawcy usług w chmurze. Klienci mogą optymalizować swoje rozwiązania na podstawie kosztów, elastyczności i innych zagadnień.

CsE i zespół produktu platformy Azure wspólnie ponownie napiszą bezserwerowy interfejs wiersza polecenia, aby obsługiwać nowe funkcje Azure Functions, takie jak Premium Functions, API Management i KeyVault. Bezserwerowy interfejs wiersza polecenia udostępnia teraz standardowy interfejs dla wdrożenia metodyki GitOps zarówno na platformie Azure, jak i w usługach AWS. Zespół opracował również bibliotekę wielochmurową bezserwerową, która udostępnia znormalizowany interfejs API środowiska uruchomieniowego do wdrażania aplikacji bezserwerowych zarówno na platformie AWS, jak i na platformie Azure.

Ten projekt zapewnia wysoką dostępność z trybem failover aktywny-aktywny między wieloma platformami w chmurze, w przeciwieństwie do trybu failover aktywne-pasywne . Jeśli usługa jednego dostawcy usług w chmurze stanie się w złej kondycji lub niedostępna, to rozwiązanie może przekierowywać żądania do innej platformy w chmurze.

Ten projekt spełnił następujące cele techniczne:

  • Tworzenie rozwiązania między branżami.
  • Biblioteka bezserwerowa z wieloma chmurami umożliwia obsługę niezależnego od chmury interfejsu API, który interfejsy z mikrousługami wszędzie tam, gdzie są wdrażane.
  • Obsługa przepływu pracy procesu ciągłej integracji/ciągłego wdrażania usługi GitOps na potrzeby programowania, testowania i wdrażania na wszystkich obsługiwanych platformach w chmurze.
  • Użyj dostępu opartego na interfejsie API za pośrednictwem uwierzytelnionej bramy w chmurze i równoważenia obciążenia między platformami w chmurze przy użyciu bramy jako routera.

Inne potencjalne korzyści wynikające z używania struktury bezserwerowej obejmują:

  • Zapobieganie lub zmniejszanie blokady dostawcy
  • 40–60+% redukcji kodu podczas programowania przy użyciu biblioteki bezserwerowej w wielu chmurach
  • Opracowywanie najlepszych rozwiązań, które łączą usługi różnych dostawców usług w chmurze
  • Eliminacja większości wymagań dotyczących złożoności platformy i infrastruktury oraz konserwacji
  • Łatwiejsze udostępnianie danych, porównanie wydajności i kosztów oraz możliwość korzystania z ofert specjalnych
  • Wysoka dostępność aktywna-aktywna

Potencjalne przypadki użycia

  • Pisanie aplikacji po stronie klienta dla wielu platform przy użyciu niezależnego od chmury interfejsu API z biblioteki wielochmurowej bezserwerowej.
  • Wdrażanie kolekcji funkcjonalnych mikrousług w bezserwerowej strukturze na wielu platformach w chmurze.
  • Używaj niezależnej od chmury aplikacji na platformach w chmurze bez znajomości lub dbania o platformę, która ją hostuje.

Zagadnienia do rozważenia

  • W tym artykule nie opisano rozwiązań zabezpieczeń, chociaż początkowe wdrożenie je obejmowało. Istnieje wiele możliwych rozwiązań zabezpieczeń, niektóre zależne od platformy, a ta struktura powinna pomieścić dowolne rozsądne rozwiązanie. Uwierzytelnianie użytkownika to minimalne zakładane zabezpieczenia.

  • Ponieważ trudno jest określić różnice między usługami AWS i ofertami funkcjonalnymi bezserwerowymi platformy Azure, wczesne wysiłki powinny skupić się na mapowaniu funkcji dostępnych na każdej platformie w chmurze i zidentyfikowaniu niezbędnych wymagań dotyczących transformacji. Dzięki tym informacjom możesz opracować niezależną od platformy interfejs API.

  • Korzystanie z rozwiązania open source może powodować ryzyko ze względu na długoterminową konserwację i wyzwania związane z obsługą dowolnego oprogramowania open source.

  • W bezpłatnej strukturze bezserwerowej monitorowanie jest ograniczone głównie do administracyjnego pulpitu nawigacyjnego. Monitorowanie jest dostępne w płatnej ofercie przedsiębiorstwa. Obecnie wtyczka Azure Functions Bezserwerowa nie zawiera aprowizuje możliwości obserwacji ani monitorowania i wymaga modyfikacji w celu zaimplementowania tych funkcji.

  • To rozwiązanie może służyć do porównywania wydajności i kosztów między platformami w chmurze, co umożliwia klientom bezproblemowe optymalizowanie użycia na różnych platformach w chmurze.

Wdrażanie tego scenariusza

Tradycyjne wdrożenie blue-green opracowuje i wdraża aplikację w dwóch oddzielnych, ale identycznych środowiskach, niebieskim i zielonym, zwiększając dostępność i zmniejszając ryzyko. Niebieskie środowisko jest zwykle środowiskiem produkcyjnym, które zwykle obsługuje ruch na żywo, a zielone środowisko jest wdrożeniem trybu failover zgodnie z potrzebami. Zazwyczaj potok ciągłej integracji/ciągłego wdrażania automatycznie wdraża zarówno niebieskie, jak i zielone środowiska na tej samej platformie w chmurze. Ta konfiguracja jest uznawana za konfigurację aktywne-pasywne .

W rozwiązaniu wielochmurowym wdrożenie blue-green jest implementowane na obu platformach w chmurze. W przypadku bezserwerowym dwa zduplikowane zestawy mikrousług są wdrażane dla każdej platformy w chmurze, jeden jako środowisko produkcyjne i drugi jako środowisko trybu failover. Ta aktywna-pasywna konfiguracja na każdej platformie w chmurze zmniejsza ryzyko, że ta platforma zostanie wyłączona, zwiększy jej dostępność i włączy aktywną dostępność w wielu chmurach o wysokiej dostępności.

Diagram przedstawiający wdrożenie aktywne-aktywne niebieskie-zielone.

Dodatkową zaletą wdrożenia niebieskiego zielonego jest możliwość korzystania z wdrożenia trybu failover na każdej platformie w chmurze jako środowiska testowego aktualizacji mikrousług przed udostępnieniem ich do wdrożenia produkcyjnego.

Następne kroki