GSP699

Wstęp

Jakie korzyści płyną z migracji aplikacji monolitowej do architektury mikroserwisów? Podzielenie aplikacji na mikroserwisy daje opisane poniżej korzyści, z których większość wywodzi się z faktu, że mikroserwisy są ze sobą luźno powiązane:

• Mikroserwisy można niezależnie testować i wdrażać. Im mniejsza jest jednostka wdrożenia, tym łatwiej ją wdrożyć.
• Mogą być implementowane w różnych językach i na różnych platformach. Dla poszczególnych mikroserwisów można wybrać najlepszą technologię na potrzeby konkretnego przypadku użycia.
• Mogą być zarządzane przez różne zespoły. Dzięki istnieniu granic między mikroserwisami łatwiej jest przydzielić zespół do 1 lub kilku mikroserwisów.
• Przejście na technologię mikroserwisów przyczynia się do rozluźnienia zależności między zespołami. Poszczególne zespoły muszą się zajmować tylko interfejsami API tych mikroserwisów, z którymi łączą je współzależności. Członkowie zespołów nie muszą wiedzieć, jak te mikroserwisy zostały zaimplementowane, jakie są ich cykle wydań itd.
• Prostsze jest też projektowanie reakcji na awarie. Dzięki istnieniu wyraźnych granic między usługami łatwiej można określić, jakie czynności należy wykonać w przypadku wyłączenia usługi.

W porównaniu z aplikacjami monolitowymi mikroserwisy mają też swoje wady. Oto kilka z nich:

• Aplikacja bazująca na mikroserwisach to sieć różnych usług, które często wchodzą ze sobą w nieoczekiwane interakcje, dlatego ogólna złożoność takiego systemu staje się coraz większa.
• Inaczej niż w przypadku aplikacji monolitowych, mikroserwisy komunikują się przez sieć. W pewnych okolicznościach może to powodować problemy z zabezpieczeniami. Istio rozwiązuje ten problem przez automatyczne szyfrowanie ruchu między mikroserwisami.
• Osiągnięcie takiego samego poziomu wydajności, jakim charakteryzują się aplikacje monolitowe, może okazać się trudne z powodu występowania opóźnień między usługami.
• Zachowanie całego systemu jest wynikiem nie tylko zachowania pojedynczej usługi, ale wielu z nich oraz występujących między nimi interakcji. Z tego powodu trudniej jest zrozumieć, w jaki sposób system zachowa się w środowisku produkcyjnym (jaka będzie jego dostrzegalność). Istio oferuje rozwiązanie także tego problemu.

W tym module wdrożysz istniejącą aplikację monolitową w klastrze Google Kubernetes Engine, a następnie podzielisz ją na mikroserwisy. Kubernetes to platforma umożliwiająca hostowanie, skalowanie i wdrażanie kontenerów oraz zarządzanie nimi. Kontenery to przenośny sposób pakowania i uruchamiania kodu. Są one szczególnie przydatne w modelu mikroserwisów, w którym poszczególne mikroserwisy działają we własnych kontenerach.

Schemat architektury naszych mikroserwisów

Zacznij od podzielenia monolitu kolejno na 3 mikroserwisy. Będą one nosiły nazwy Orders (Zamówienia), Products (Produkty) i Frontend. Za pomocą Cloud Build dla każdego z mikroserwisów utwórz obraz Dockera. Następnie wdróż i ujawnij te mikroserwisy w Google Kubernetes Engine (GKE) z usługą Kubernetes typu LoadBalancer. Wykonasz to zadanie dla każdej usługi z jednoczesną ich refaktoryzacją z monolitu. Podczas trwania tego procesu będą działały zarówno mikroserwisy, jak i monolit, aż do samego końca, kiedy monolit zostanie ostatecznie usunięty.

Czego się nauczysz

• Jak podzielić monolit na mikroserwisy

• Jak utworzyć klaster Google Kubernetes Engine

• Jak utworzyć obraz Dockera

• Jak wdrożyć obrazy Dockera w klastrach Kubernetes

Wymagania wstępne

• Konto Google Cloud Platform z dostępem administracyjnym do tworzenia projektów lub projekt z rolą właściciela projektu

• Podstawowa znajomość technologii Docker i Kubernetes