Co to są mikrousługi? Twoja następna architektura oprogramowania

Prawie każdy system komputerowy wykonuje wiele zadań przy użyciu współdzielonych zasobów, a jednym z pytań związanych z programowaniem komputerowym jest to, jak ściśle fragmenty kodu, które wykonują te zadania, powinny być ze sobą powiązane. Coraz popularniejszą odpowiedzią jest koncepcja mikrousługi - niewielkiego, dyskretnego fragmentu funkcjonalności, który współdziała z innymi mikrousługami w celu stworzenia większego systemu.

Chociaż podstawowa idea posiadania takich dyskretnych komponentów nie jest nowa, sposób implementacji mikrousług sprawia, że ​​stanowią one naturalną podstawę dla obu nowoczesnych aplikacji chmurowych. Mikrousługi są również zgodne z filozofią DevOps, która zachęca do szybkiego i ciągłego wdrażania nowych funkcji.

Co to są mikrousługi?

„Mikro” w mikrousługach oznacza, że ​​są to małe aplikacje. Czasami to prawda, ale lepszym sposobem myślenia o nich jest to, że powinny być tak duże, jak potrzeba, aby zrobić jedną konkretną rzecz lub rozwiązać konkretny problem. Ten problem powinien mieć charakter koncepcyjny, a nie techniczny. Jak to ujął Microsoft, „Mikrousługi powinny być projektowane pod kątem możliwości biznesowych, a nie warstw poziomych, takich jak dostęp do danych lub wiadomości”. Komunikują się z innymi mikrousługami i użytkownikami zewnętrznymi za pośrednictwem stosunkowo stabilnych interfejsów API, aby utworzyć większą aplikację.

W ten sposób wewnętrzna funkcjonalność poszczególnych mikrousług może zostać zmodyfikowana lub radykalnie zaktualizowana bez wpływu na resztę systemu. To z kolei wiąże się ze sposobem działania sklepów Devops: Jeśli określone funkcje większej aplikacji są podzielone na oddzielne, niezależnie działające fragmenty kodu, łatwiej jest żyć mantrą DevOps CI / CD (ciągła integracja i ciągłe dostarczanie) . Ponadto dobrze zdefiniowane interfejsy API ułatwiają automatyczne testowanie mikrousług.

Architektura mikrousług a architektura monolityczna

Często mówi się o mikrousługach w kontekście „architektury mikrousług ”. Ta fraza obejmuje nie tylko same mikrousługi, ale także komponenty do zarządzania i odnajdywania usług, a także bramę interfejsu API, która obsługuje komunikację między mikrousługami a światem zewnętrznym.

„Aplikacja monolityczna” jest przeciwieństwem tego, czym są mikrousługi. To retronim dla aplikacji, w której cały kod znajduje się w jednym dużym binarnym pliku wykonywalnym. Jak wyjaśnia TechTarget, monolityczna aplikacja jest trudniejsza do skalowania i trudniejsza do ulepszenia. Ale ponieważ jest zbudowana jako pojedyncza, spójna aplikacja, nie wymaga tak dużego zarządzania, jak architektura mikrousług.

Ograniczone pojęcia: jak zdefiniować mikrousługę

Wróćmy na chwilę do naszego wcześniejszego przykazania, że ​​mikrousługi powinny robić jedną konkretną rzecz. Łatwo powiedzieć, ale w praktyce funkcjonalność jest często przeplatana, a rysowanie podziałów jest trudniejsze, niż się wydaje. Analiza domeny i projektowanie oparte na domenie to podejścia teoretyczne, które pomogą Ci rozłożyć ogólne zadanie na poszczególne problemy, które może rozwiązać mikrousługa. W tym procesie, przedstawionym w pouczającej serii postów na blogu firmy Microsoft, tworzysz abstrakcyjny model swojej domeny biznesowej, a w trakcie tego procesu odkrywasz ograniczone konteksty , które grupują funkcje, które oddziałują ze światem w określony sposób.

Na przykład możesz mieć jeden ograniczony kontekst dla wysyłki, a drugi dla kont. Rzeczywisty obiekt fizyczny miałby oczywiście zarówno cenę, jak i miejsce, do którego musi się udać, ale ograniczone konteksty reprezentują określone sposoby, w jakie aplikacja myśli i współdziała z tymi obiektami. Każda mikrousługa powinna istnieć całkowicie w jednym ograniczonym kontekście, chociaż niektóre ograniczone konteksty mogą obejmować więcej niż jedną mikrousługę.

Mikrousługi a architektura zorientowana na usługi a usługi internetowe

W tym momencie, jeśli jesteś informatykiem, który pracuje w branży od jakiegoś czasu, możesz pomyśleć, że wiele z tych rzeczy brzmi znajomo. Pomysł, by małe, pojedyncze programy współpracowały ze sobą, może przypominać zarówno SOA (architektura zorientowana na usługi), jak i usługi sieciowe , dwa modne hasła z czasów Web 2.0 z pierwszej dekady XXI wieku. Chociaż w pewnym sensie pod słońcem naprawdę nie ma nic nowego, istnieją ważne różnice między tymi koncepcjami a mikrousługami. Datamation ma dobry podział różnic, ale oto krótka wersja:

  • W architekturze zorientowanej na usługi poszczególne komponenty są stosunkowo ściśle powiązane, często współużytkują zasoby, takie jak pamięć masowa, i komunikują się za pośrednictwem specjalistycznego oprogramowania zwanego korporacyjną magistralą pamięci masowej . Mikrousługi są bardziej niezależne, współdzielą mniej zasobów i komunikują się za pomocą lżejszych protokołów. Warto zauważyć, że mikrousługi wyrosły ze środowiska SOA i czasami są uważane za swego rodzaju SOA, czyli następcę koncepcji.
  • Usługa sieci Web to publicznie dostępny zestaw funkcji, do których inne aplikacje mogą uzyskać dostęp za pośrednictwem sieci Web; Prawdopodobnie najbardziej rozpowszechnionym przykładem są Mapy Google, które witryna restauracji mogłaby umieścić, aby zapewnić klientom wskazówki dojazdu. Jest to znacznie luźniejsze połączenie niż w architekturze mikrousług.

Komunikacja mikrousług

Często słyszanym powiedzeniem dotyczącym architektur mikrousług jest to, że powinny one zawierać „inteligentne punkty końcowe i głupie potoki”. Innymi słowy, mikrousługi powinny mieć na celu wykorzystanie podstawowych i dobrze znanych metod komunikacji, a nie złożonej i ścisłej integracji. Jak już wspomniano, jest to kolejna rzecz, która odróżnia mikrousługi od architektury SOA.

Ogólnie komunikacja między mikrousługami powinna być asynchroniczna , w tym sensie, że wątki kodu nie są blokowane w oczekiwaniu na odpowiedzi. (Nadal dobrze jest używać synchronicznych protokołów komunikacyjnych, takich jak HTTP, chociaż protokoły asynchroniczne, takie jak AMQP (Advanced Message Queuing Protocol), są również powszechne w architekturach mikrousług). Ten rodzaj luźnego powiązania sprawia, że ​​architektura mikrousług jest bardziej elastyczna w obliczu awarii poszczególnych elementów lub części sieci, co jest kluczową korzyścią.

Mikrousługi, Java i Spring Boot oraz Spring Cloud

Niektóre z pierwszych prac w mikrousługach pojawiły się w społeczności Java; Martin Fowler był jednym z pierwszych zwolenników. Na konferencji Java w Polsce w 2012 roku zaprezentowano jedną z najważniejszych wczesnych prezentacji na ten temat, zatytułowaną „Mikrousługi - Java, the Unix Way.” Zalecono stosowanie zasad, którymi kierowano się przy tworzeniu pierwszych aplikacji Unix w latach programy, które robią jedną rzecz i robią to dobrze. Pisz programy do współpracy ”) do programowania w języku Java.

W wyniku tej historii istnieje wiele struktur Java, które umożliwiają tworzenie mikrousług. Jednym z najpopularniejszych jest Spring Boot, który jest specjalnie zaprojektowany dla mikrousług; Boot jest rozszerzony o Spring Cloud, który jak sama nazwa wskazuje, pozwala wdrożyć te usługi również w chmurze. Pivotal Software, twórca Spring, ma dobry samouczek dotyczący rozpoczynania pracy z mikrousługami przy użyciu tych platform.

Mikrousługi i kontenery: Docker, Kubernetes i nie tylko

Podstawową technologią, która poszła najdalej w kierunku wprowadzenia mikrousług do głównego nurtu, są kontenery .  Kontener jest podobny do instancji maszyny wirtualnej, ale zamiast zawierać cały samodzielny system operacyjny, kontener jest po prostu izolowaną przestrzenią użytkownika, która wykorzystuje jądro systemu operacyjnego hosta, ale poza tym utrzymuje wykonywany w niej kod samodzielnie. Kontenery są znacznie mniejsze niż instancje maszyn wirtualnych i można je łatwo szybko wdrożyć lokalnie lub w chmurze, a także można je rozdzielać lub zmniejszać w celu dopasowania do zapotrzebowania i dostępnych zasobów.

Atrakcyjność kontenerów dla mikrousług powinna być oczywista: każda pojedyncza mikrousługa może działać we własnym kontenerze, co znacznie zmniejsza obciążenie związane z zarządzaniem usługami. Większość implementacji kontenerów ma uzupełniające się narzędzia do orkiestracji, które automatyzują wdrażanie, zarządzanie, skalowanie, tworzenie sieci i dostępność aplikacji opartych na kontenerach. To połączenie małych, łatwych do zbudowania mikrousług i łatwych do wdrożenia kontenerów umożliwia realizację filozofii DevOps. Istnieje kilka implementacji koncepcji kontenera, ale zdecydowanie najpopularniejszym jest Docker, który jest generalnie połączony z Kubernetesem jako platformą do orkiestracji.

Wiosna, choć popularna, jest związana z platformą Java. Z drugiej strony systemy oparte na kontenerach są poliglotami: każdy język programowania obsługiwany przez system operacyjny może działać w kontenerze, co zapewnia większą elastyczność programistom. Rzeczywiście, dużą zaletą mikrousług jest to, że każda indywidualna usługa może być napisana w dowolnym języku, który jest najbardziej sensowny lub z którym programiści są najbardziej zadowoleni. Rzeczywiście, usługa mogłaby zostać całkowicie przebudowana w nowym języku bez wpływu na system jako całość, o ile jej interfejsy API pozostają stabilne. DZone opublikował artykuł omawiający zalety i wady Spring Cloud vs. Kubernetes dla mikrousług. 

Wzorce projektowe mikrousług

Bez względu na to, jakiego języka używasz do tworzenia mikrousług, napotkasz problemy, które wcześniej napotkali inni programiści. Wzorce projektowe są sformalizowanymi, abstrakcyjnymi rozwiązaniami powtarzających się problemów w informatyce, a wiele z nich jest przeznaczonych specjalnie dla mikrousług. Devopedia ma świetną listę, która obejmuje:

  • Rejestr usług: do łączenia klientów z dostępnymi wystąpieniami mikrousług
  • Wyłącznik automatyczny: aby zapobiec wielokrotnemu wywoływaniu usług, które uległy awarii
  • Awaria: za zapewnienie alternatywy dla usługi, która uległa awarii
  • Sidecar: do dostarczania usług pomocniczych do głównego kontenera, takich jak logowanie, synchronizacja usług lub monitorowanie
  • Adapter: do standaryzacji lub normalizacji interfejsu pomiędzy głównym kontenerem a światem zewnętrznym
  • Ambasador: aby połączyć główny kontener ze światem zewnętrznym, na przykład w celu proxy połączeń hosta lokalnego z połączeniami zewnętrznymi

Mikrousługi i chmura : AWS i Azure

Jak wspomniano powyżej, jedną z zalet używania kontenerów jest to, że można je łatwo wdrożyć w chmurze, gdzie dostępne są elastyczne zasoby obliczeniowe, dzięki czemu można zmaksymalizować wydajność aplikacji. Jak możesz sobie wyobrazić, wszyscy główni dostawcy chmur publicznych chcą, abyś używał ich platform do uruchamiania aplikacji opartych na mikrousługach. Aby uzyskać więcej informacji, zapoznaj się z zasobami Amazon, Microsoft i Google.