Mikroserwisy w akcji. Отсутствует
binarnych i procesów wspierających
Kontenery standaryzują tworzenie pakietów aplikacji oraz interfejs środowiska wykonawczego i zapewniają niezmienność zarówno środowiska operacyjnego, jak i kodu. To sprawia, że są potężnymi cegiełkami do budowania na wyższym poziomie. Korzystając z nich, można zdefiniować i wyodrębnić pełne środowisko wykonawcze dowolnej usługi.
Mimo że dostępnych jest wiele implementacji kontenerów (a koncepcja ta istnieje także poza Linuksem, jak np. jails w FreeBSD czy zones w systemie Solaris), to najbardziej dojrzałym i przystępnym narzędziem, spośród tych, których używaliśmy do tej pory, jest Docker. Użyjemy go w dalszej części tej książki.
IMPLEMENTACJA STRUMIENI CIĄGŁEGO DOSTARCZANIA
Ciągłe dostarczanie to praktyka, w której programiści tworzą oprogramowanie, jakie mogą niezawodnie dostarczać do produkcji w dowolnym momencie. Wyobraźmy sobie linię produkcyjną w fabryce – aby nieprzerwanie dostarczać oprogramowanie, budujemy podobny strumień, pobierający zatwierdzony kod i wdrażający go do produkcji. Na rysunku 1.10 pokazano prosty strumień. Każdy etap strumienia dostarcza zespołowi programistycznemu informacje zwrotne na temat poprawności kodu.
Wcześniej wspomnieliśmy, że mikroserwisy są idealnym narzędziem do ciągłego dostarczania, ponieważ ich mały rozmiar oznacza, że można je szybko budować i wydawać niezależnie. Jednak ciągłe dostarczanie nie wynika automatycznie z tworzenia mikroserwisów. Aby zapewnić ciągłe dostarczanie oprogramowania, musimy skupić się na dwóch celach:
■ budowanie zbioru walidacji, które musi przejść nasze oprogramowanie; na każdym etapie procesu wdrażania powinniśmy móc udowodnić poprawność naszego kodu;
■ automatyzacja strumienia dostarczającego kod od momentu zatwierdzenia (commit) do produkcji.
Zbudowanie sprawdzonego, poprawnego strumienia wdrażania pozwoli programistom pracować bezpiecznie oraz w tempie, w jakim będą mogli iteracyjnie rozwijać usługi. Taki strumień jest powtarzalnym i niezawodnym procesem dostarczania nowych funkcjonalności. W idealnej sytuacji powinniśmy móc zestandaryzować walidacje i kroki w strumieniu i używać ich dla wielu usług, bardziej znacząco zmniejszając koszt wdrażania nowych usług.
Ciągłe dostarczanie zmniejsza również ryzyko związane z wdrażaniem oprogramowania, ponieważ zarówno jakość tworzonego oprogramowania, jak i sprawność zespołu w zakresie dostarczania zmian są większe. Z perspektywy produktu może to oznaczać, że możemy pracować w prostszy sposób – szybko sprawdzając własne założenia i je powtarzając.
Rysunek 1.10. Wysokopoziomowy strumień wdrażania dla mikroserwisu
UWAGA W części 3 zbudujemy strumień ciągłego wdrażania za pomocą funkcjonalności Pipeline dostępnego bezpłatnie narzędzia integracyjnego Jenkins; przeanalizujemy także różne wzorce wdrażania, takie jak kanarkowe i niebieskozielone.
1.3.3. Obserwowanie mikroserwisów
W tym punkcie omówimy przejrzystość i obserwowalność. Podczas produkcji musimy wiedzieć, co się dzieje. Znaczenie tego jest dwojakie:
■ chcemy aktywnie identyfikować i modyfikować krytyczne elementy w systemie;
■ potrzebujemy rozumieć, jak zachowuje się system.
Dokładne monitorowanie jest znacznie trudniejsze w przypadku aplikacji mikroserwisowej, ponieważ pojedyncze transakcje mogą obejmować wiele różnych usług; technicznie heterogeniczne usługi mogą generować dane w niedających się pogodzić formatach, a całkowita objętość danych operacyjnych będzie prawdopodobnie znacznie większa niż w pojedynczej aplikacji monolitycznej. Ale jeśli potrafimy zrozumieć, jak działa nasz system i monitorować to dokładnie, to mimo tej złożoności będziemy w stanie dokonać w nim skutecznych zmian.
IDENTYFIKACJA I MODYFIKOWANIE POTENCJALNIE KRYTYCZNYCH ELEMENTÓW SYSTEMU
Systemy ulegają awarii niezależnie od tego, czy zostały popełnione błędy, wystąpiły błędy środowiska wykonawczego, awarie sieci, problemy ze sprzętem. Z biegiem czasu koszty eliminacji nieznanych pomyłek i błędów stają się wyższe niż koszty szybkiego i skutecznego reagowania w momencie ich wystąpienia.
Systemy monitorowania i ostrzegania pozwalają diagnozować problemy i określać przyczyny awarii. Warto mieć zautomatyzowane mechanizmy reagujące na alarmy, które będą tworzyć nowe instancje kontenerów w różnych centrach danych lub reagować na problemy z obciążeniem, zwiększając liczbę uruchomionych wystąpień usługi.
Aby zminimalizować konsekwencje tych awarii i zapobiec ich kaskadowaniu w całym systemie, musimy móc projektować zależności między usługami w sposób, który pozwoli na częściową degradację. Awaria jednej usługi nie powinna zdestabilizować całej aplikacji. Ważne jest, aby zastanowić się nad możliwymi punktami awarii w swojej aplikacji, mieć na uwadze to, że awaria kiedyś nastąpi i odpowiednio się do niej przygotować.
ZROZUMIENIE ZACHOWANIA SETEK USŁUG
Aby zrozumieć zachowanie swoich usług, należy nadawać priorytet przejrzystości w ich projektowaniu i wdrażaniu. Gromadzenie dzienników i danych oraz ujednolicanie ich w celach analitycznych i ostrzegawczych pozwala zbudować pojedyncze źródło prawdy, do którego można się odwoływać podczas monitorowania i badania zachowania systemu.
Jak wspomniano w punkcie 1.3.2, możemy standaryzować i upraszczać wszystko oprócz unikalnej zdolności, którą oferuje każda usługa. Potraktujmy tę usługę jako cebulę. W środku tej cebuli mamy unikalne zdolności biznesowe oferowane przez tę usługę. W otoczeniu tego znajdują się inne instrumenty: wskaźniki biznesowe, dzienniki aplikacji, dane operacyjne i wskaźniki infrastrukturalne, które umożliwiają obserwowanie tej zdolności biznesowej. Za pośrednictwem tych warstw można prześledzić każde żądanie do systemu. Następnie dane zebrane z tych warstw można przesłać do operacyjnego centrum danych w celu analizy i alarmowania. Zostało to zilustrowane na rysunku 1.11.
UWAGA W części 4 omówimy, jak zbudować system monitorowania mikroserwisów, zbierać odpowiednie dane i je wykorzystywać, aby stworzyć żywy model dla złożonej aplikacji mikroserwisowej.
Rysunek 1.11. Mikroserwis oferujący zdolność biznesową otoczony warstwami instrumentariów, przez które są do niego przekazywane żądania i jego odpowiedzi wraz z danymi zebranymi z procesu kierowanymi do operacyjnego centrum danych
1.4. Odpowiedzialna i operacyjnie świadoma kultura inżynieryjna
Błędem byłoby badanie technicznej natury mikroserwisów w oderwaniu od tego, jak zespół inżynierów pracuje nad ich rozwojem. Budowanie aplikacji z małych, niezależnych usług drastycznie zmienia sposób, w jaki firma funkcjonuje w zakresie inżynierii, więc kierowanie kulturą i priorytetami naszego zespołu będzie istotnym czynnikiem warunkującym pomyślne dostarczenie aplikacji mikroserwisowej.
Oddzielenie przyczyny i skutku może być trudne w firmach, które pomyślnie zastosowały mikroserwisy. Czy rozwój ziarnistych usług był logicznym rezultatem ich struktury organizacyjnej i zachowania zespołów? Czy też ta struktura i zachowanie wynikają z ich doświadczeń budowania ziarnistych usług?
Odpowiedzi na oba pytania są twierdzące. Długo działający system to nie tylko zbiór oczekiwanych, zaprojektowanych i zbudowanych funkcjonalności. Odzwierciedla on także preferencje, opinie i cele twórców oraz operatorów. W pewnym stopniu wyraża to prawo Conwaya:
organizacje,