Przewodnik po mikrousługach Java. Część 2: Wdrożenie i testowanie

Tłumaczenie i adaptacja mikrousług Java: praktyczny przewodnik . Link do pierwszej części poradnika . Każdy program Java po stronie serwera, a zatem każda mikrousługa, to po prostu plik z rozszerzeniem .jar lub .war. Jest jedna wspaniała rzecz w ekosystemie Java, a raczej w JVM: wystarczy raz napisać kod Java, a będzie on działał na prawie każdym systemie operacyjnym, o ile nie skompilowałeś swojego kodu z nowszą wersją Java niż twoja docelowa wersja JVM. Warto to zrozumieć, zwłaszcza jeśli chodzi o tematy takie jak Docker, Kubernetes czy (bęben!) Chmura. Dlaczego? Przyjrzyjmy się różnym scenariuszom wdrażania.

Minimalistyczny przykład wdrożenia mikroserwisu Java

Kontynuujmy przykład banku. Mamy więc plik monobank.jar (monolith) i nasz nowo wyodrębniony plik Riskengine.jar (pierwsza mikrousługa sprawdzająca ryzyko). Załóżmy też, że obie aplikacje, jak każda inna aplikacja na świecie, potrzebują pliku .properties. W naszym przypadku będzie zawierał tylko adres URL bazy danych i dane uwierzytelniające. Minimalne wdrożenie może składać się z dwóch katalogów, które wyglądają mniej więcej tak: Pierwszy:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Drugi:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

To pozostawia otwarte pytanie: w jaki sposób pliki .properties i .jar dostaną się na serwer? Niestety odpowiedzi może być wiele.

Jak używać narzędzi do budowania, SSH i Ansible do wdrażania mikrousług Java

Nudne, ale nie mniej doskonałe porady dotyczące wdrażania mikrousług Java... Właściwie dokładnie tak, jak administratorzy systemów wdrażali dowolny program serwerowy Java w firmach przez ostatnie 20 lat. To jest mieszanka:

• Twoje ulubione narzędzie do budowania (Maven, Gradle)
• stary, dobry SSH/SCP do kopiowania plików .jars na serwery
• Skrypty Bash do zarządzania skryptami wdrożeniowymi i serwerami
• lub jeszcze lepiej: niektóre skrypty Ansible.

Oczywiście nie jest to odpowiednie dla innowatorów, którzy potrzebują „oddychającej” chmury, serwerów z automatycznym równoważeniem obciążenia i tak dalej. To naprawdę nudna stara szkoła. Jednak to działa!

Jak używać Dockera do wdrażania mikrousług Java

Wróćmy do słodkiej agonii wyboru. Kilka lat temu na scenę wkroczył Docker, a wraz z nim konteneryzacja. Jeśli nigdy z tym nie pracowałeś, oto krótki opis skierowany do użytkowników końcowych i programistów:

• Kontener (uproszczony) jest podobny do starej, dobrej maszyny wirtualnej, ale jest „lżejszy”. Jeśli nie masz pewności, co oznacza „łatwiej” w tym kontekście, sprawdź tę odpowiedź na Stackoverflow .
• Kontener gwarantuje własną przenośność. Oznacza to, że działa wszędzie. Brzmi znajomo, prawda?

Zabawne, że biorąc pod uwagę przenośność i kompatybilność wsteczną JVM, ta funkcja nie wydaje się być aż taką zaletą. Możesz po prostu pobrać plik JVM.zip na dowolne Raspberry Pi (lub nawet telefon komórkowy), rozpakować go i uruchomić dowolny plik .jar. Sytuacja zmienia się w językach takich jak PHP czy Python, gdzie niezgodności wersji lub ustawienia wdrożenia są bardziej złożone. Lub jeśli Twoja aplikacja Java zależy od wielu innych zainstalowanych usług (z poprawnymi numerami wersji): na przykład bazy danych Postgres lub magazynu wartości kluczy Redis. Zatem główną zaletą Dockera dla mikrousług Java, a dokładniej dla aplikacji Java, jest to, że: możliwość skonfigurowania ujednoliconych środowisk testowych lub integracyjnych przy użyciu narzędzi takich jak Testcontainers . Złożone rozwiązania są łatwiejsze w montażu. Weź oprogramowanie forum dyskusyjnego . Można go zainstalować za pomocą pojedynczego obrazu Dockera, a ten obraz zawiera wszystko, czego potrzebujesz, od oprogramowania Discourse napisanego w języku Ruby, przez bazę danych Postgres, Redis, aż po zlew kuchenny. Jeśli Twoje wdrożenia są podobne lub chcesz uruchomić ładną, małą bazę danych Oracle, wypróbuj Docker. Podsumowując, zamiast tylko patrzeć na plik .jar, możesz teraz:

• spakuj plik jar w obraz Dockera
• wypchnij ten obraz do prywatnego rejestru Dockera
• pobierz i uruchom ten obraz na platformie docelowej
• lub skopiuj obraz Dockera bezpośrednio do systemu produkcyjnego i uruchom go.

Jak używać Docker Swarm lub Kubernetes do wdrażania mikrousług Java

Załóżmy, że zdecydujesz się wypróbować Dockera. Za każdym razem, gdy wdrażasz mikrousługę Java, tworzony jest obraz platformy Docker, który zawiera plik .jar. Załóżmy, że masz kilka mikrousług Java i chcesz wdrożyć te usługi na kilku komputerach (w klastrze). Powstaje pytanie: jak zarządzać tym klastrem? Uruchamiać kontenery Docker, sprawdzać wydajność, wdrażać aktualizacje, skalować system (brrr)? Dwie możliwe odpowiedzi na to pytanie to Docker Swarm i Kubernetes. Opisywanie szczegółowo obu opcji spowodowałoby, że ten i tak już długi samouczek byłby zbyt długi, ale uważamy, że należy wspomnieć, że obie opcje ostatecznie polegają na pisaniu plików YAML (patrz historie wcięć Yaml ) w celu zarządzania klastrem. Jeśli chcesz wiedzieć, jakie odczucia to budzi w praktyce, wystarczy wpisać podobne zapytanie w wyszukiwarkę na Twitterze. Zatem proces wdrażania mikrousług Java wygląda teraz mniej więcej tak:

• Konfigurowanie i zarządzanie Docker Swarm/Kubernetes
• Wszystkie kroki dla Dockera (patrz wyżej)
• Pisz i wykonuj YAML, aż oczy będą krwawić, aż wszystko zacznie działać.

Jak testować mikrousługi Java

Załóżmy, że decydujesz się na wdrożenie mikrousług w środowisku produkcyjnym. Jak teraz przetestować integrację n-mikrousług podczas programowania? Jak sprawdzić, czy cały przepływ pracy działa, a nie tylko jego części? W praktyce można zastosować jedną z trzech metod:

1. Przy odrobinie pracy (jeśli używasz frameworków takich jak Spring Boot) możesz połączyć wszystkie swoje mikrousługi w jedną klasę programu uruchamiającego i załadować wszystkie mikrousługi przy użyciu jednej klasy Wrapper.java - w zależności od tego, czy masz wystarczającą ilość pamięci na komputerze, aby uruchom na nich wszystkie swoje mikrousługi.
2. Możesz skopiować ustawienia Docker Swarm lub Kubernetes lokalnie.
3. Po prostu nie uruchamiaj już testów integracyjnych lokalnie. Zamiast tego wdróż dedykowane środowisko DEV/TEST. Jest to coś, co faktycznie robi sporo zespołów, gdy ulegają trudom związanym z lokalnymi konfiguracjami mikrousług.

Dodatkowo oprócz mikrousług Java prawdopodobnie będziesz także potrzebował działającego brokera komunikatów (takiego jak ActiveMQ lub RabbitMQ), być może serwera poczty e-mail lub innego komponentu przesyłania wiadomości, którego mikrousługi Java potrzebują do komunikowania się między sobą. Prowadzi to do znacznego niedoszacowania złożoności po stronie DevOps. Spójrz na biblioteki testowe mikrousług, mogą złagodzić ten ból. W każdym razie ta złożoność prowadzi nas do ogólnych problemów mikrousług, o których teraz porozmawiamy. W końcowej części omówimy ogólne pytania dotyczące mikroserwisów Java.