Mikrousługi i architektura mikrousług
Poznaj wady i zalety mikrousług oraz dowiedz się, co odróżnia je od rozwiązań monolitycznych.
Jeszcze niedawno preferowaną metodą tworzenia aplikacji było stosowanie architektury monolitycznej, stanowiącej pojedynczą, autonomiczną jednostkę. To podejście było z powodzeniem wykorzystywane przez wielu twórców oprogramowania — do czasu, aż na przeszkodzie stanęła rosnąca złożoność aplikacji. Modyfikacja niewielkiej sekcji kodu w systemie monolitycznym wymaga ponownego przeprowadzenia kompilacji i testów całego systemu oraz wdrożenia zupełnie nowej wersji aplikacji.
Wtedy pojawiły się mikrousługi — podejście polegające na dzieleniu systemów oprogramowania na mniejsze jednostki, opracowywane i wdrażane w sposób autonomiczny. Do spopularyzowania architektury mikrousług przyczynił się ruch DevOps, który za cel stawia częste udostępnianie aktualizacji obejmujących nowe funkcje, poprawki błędów i usprawnienia zabezpieczeń. Wielu firmom otworzyło to drogę do opracowania na nowo dotychczas używanych aplikacji przy użyciu współczesnych języków programowania oraz zaktualizowanego zestawu rozwiązań technologicznych.
Mikrousługi to zbiór niewielkich jednostek, które umożliwiają ciągłe dostarczanie i wdrażanie dużych, złożonych aplikacji.
Czym są mikrousługi?
Architektura mikrousług, zwana również po prostu mikrousługami, to podejście do tworzenia aplikacji w formie szeregu niezależnie wdrażanych, zdecentralizowanych, autonomicznie opracowywanych usług. Te usługi są luźno powiązane, wdrażane niezależnie od siebie oraz łatwe w utrzymaniu. Aplikacja monolityczna jest tworzona jako pojedyncza, niepodzielna jednostka, natomiast w przypadku mikrousług jednostka ta jest podzielona na zbiór niezależnych elementów składających się na większą całość. Mikrousługi stanowią integralną część metodologii DevOps, ponieważ są one podstawą praktyk ciągłego dostarczania, które pozwalają zespołom szybko dostosowywać się do wymagań użytkowników.
Mikrousługa to usługa internetowa odpowiedzialna za jeden element logiki domeny. Na aplikację składa się wiele mikrousług, a każda z nich zapewnia jedną z funkcji domeny. Mikrousługi komunikują się ze sobą poprzez interfejsy API (np. REST lub gRPC), jednak nie wiedzą, co dzieje się wewnątrz innych usług. Taką harmonijną interakcję pomiędzy mikrousługami nazywamy architekturą mikrousług.
Dzięki architekturze mikrousług programiści mogą organizować się w mniejsze zespoły specjalizujące się w różnych usługach, korzystające z różnych rozwiązań technologicznych oraz przeprowadzające niezależne wdrożenia. Przykładowo system Jira jest obsługiwany przez wiele mikrousług, z których każda zapewnia określone możliwości, takie jak wyszukiwanie zgłoszeń, wyświetlanie ich szczegółów, komentowanie, zmienianie statusów i nie tylko.
Cechy mikrousług
Architektura mikrousług nie ma formalnej definicji, jednak istnieje kilka typowych wzorców lub cech, które warto znać.
Autonomiczne komponenty
Podstawowym blokiem konstrukcyjnym architektury mikrousług jest komponent. Może on być pakietem oprogramowania, usługą lub zasobem internetowym, aplikacją lub modułem zawierającym szereg powiązanych ze sobą funkcji. Martin Fowler wyjaśnia to jeszcze prościej: „Komponenty oprogramowania to coś, co można niezależnie wymieniać i ulepszać”.
W architekturze mikrousług każdy komponent można opracowywać, wdrażać, obsługiwać, zmieniać i wdrażać ponownie bez narażania działania innych usług czy integralności aplikacji.
Komponenty są używane wraz z innymi komponentami w celu zapewniania doświadczeń klientom lub korzyści firmie. Najczęściej są to usługi i biblioteki, jednak można również spotkać narzędzia interfejsu wiersza polecenia, aplikacje mobilne, moduły frontend, pipeline'y danych, modele uczenia maszynowego i wiele innych koncepcji możliwych do zastosowania w architekturze mikrousług.
Czyste interfejsy
Po przygotowaniu poszczególnych komponentów potrzebna jest rozbudowana logika, dzięki której będą one mogły się komunikować poprzez mechanizm, taki jak RPC, REST over HTTP lub system bazujący na zdarzeniach. Te mechanizmy mogą być synchroniczne lub asynchroniczne, a mikrousługi mogą korzystać z połączenia obu tych rodzajów.
Najważniejsze, aby każda mikrousługa zapewniała przejrzysty, intuicyjny kontrakt, który opisuje, w jaki sposób użytkownik może z niej korzystać. Zwykle służy do tego interfejs API publikowany wraz z usługą.
Odpowiedzialność za produkt
Filozofia metodologii DevOps — „odpowiadasz za to, co tworzysz” — podkreśla, że nie można zmienić architektury na opartą na mikrousługach, jeśli wcześniej nie rozważy się kwestii struktury zespołów. Metodologia DevOps łączy różne role funkcjonalne (programowanie, QA, inżynieria wydawania, eksploatacja) w jeden zespół, którego wspólnym celem jest opracowywanie wysokiej jakości oprogramowania. Praktyki DevOps, takie jak CI/CD, zautomatyzowane testowanie oraz flagi funkcji, przyspieszają wdrażanie oraz pozwalają zachować stabilność i bezpieczeństwo systemu. Co więcej, każdy zespół może kompilować i wdrażać mikrousługi, za które odpowiada, bez wpływu na inne zespoły.
Ewolucja chmury doprowadziła do uproszczenia kompilacji, wdrażania i obsługi mikrousług. Zespołom pomagają techniki automatyzacji infrastruktury, takie jak ciągła integracja, ciągłe dostarczanie i zautomatyzowane testowanie.
Porównanie architektury zorientowanej na usługi i mikrousług
Architektura zorientowana na usługi (SOA) i mikrousługi to dwa różne rodzaje architektury usług internetowych. Podobnie jak mikrousługi, również architektura zorientowana na usługi obejmuje wyspecjalizowane komponenty, które działają w sposób niezależny od siebie oraz nadają się do ponownego wykorzystania. Różnicą pomiędzy tymi dwoma rodzajami architektury jest biurokratyczna klasyfikacja typów usług.
Architektura zorientowana na usługi obejmuje cztery podstawowe typy usług:
- Business
- Enterprise
- Aplikacja
- Usługi infrastruktury
Te typy określają, za jaką domenę odpowiadają poszczególne usługi. Mikrousługi mają natomiast tylko dwa typy usług: funkcjonalne i infrastruktury.
Obie architektury współdzielą ten sam zestaw standardów na różnych poziomach firmy. Istnienie architektury mikrousług zależy od sukcesu wzorca SOA. Wzorzec architektury mikrousług jest więc podzbiorem architektury zorientowanej na usługi. Główny nacisk kładzie się tu na autonomię środowiska wykonawczego każdej usługi.
Korzyści płynące z mikrousług
Agility
Opracowywaniem usługi w ramach architektury mikrousług zajmują się zazwyczaj małe, niezależne zespoły, co ułatwia stosowanie praktyk Agile. Zespoły mogą pracować niezależnie i szybko, co skraca cykle prac programistycznych.
Elastyczne skalowanie
Ponieważ mikrousługi są z założenia rozproszone i mogą być wdrażane w klastrach, umożliwiają dynamiczne skalowanie w poziomie ponad granicami usług. Jeśli obciążenie danej mikrousługi osiągnie maksymalny poziom, można szybko wdrożyć nowe instancje tej usługi do powiązanego klastra, aby ułatwić obsługę zwiększonego zapotrzebowania.
Częste wydania
Jedną z głównych zalet mikrousług są częste i szybsze cykle wydawania. Mikrousługi stanowią kluczowy element ciągłej integracji i ciągłego dostarczania (CI/CD), umożliwiając zespołom eksperymentowanie z nowymi funkcjami i wycofywanie ich, jeśli coś pójdzie nie tak. Ułatwia to aktualizację kodu i przyspiesza wprowadzanie nowych funkcji na rynek.
Elastyczność technologii
Architektury mikrousług nie muszą się opierać na ustalonym podejściu z jednym łańcuchem narzędzi — zespoły mogą stosować takie narzędzia, jakie chcą.
Koncentracja na jakości
Podział aspektów biznesowych na niezależne mikrousługi oznacza, że zespół odpowiedzialny za daną usługę skupia się na dostarczeniu produktu wysokiej jakości.
Wysoka niezawodność
Dzięki wyodrębnieniu poszczególnych funkcji mikrousługi zmniejszają ryzyko awarii całej aplikacji lub bazy kodu podczas wydawania aktualizacji. Można w prosty sposób wyodrębniać i usuwać błędy i usterki w poszczególnych usługach. Możliwe jest wdrażanie zmian dotyczących tylko konkretnej usługi bez przerwy w działaniu całej aplikacji, dzięki czemu zwiększa się niezawodność.
Wyzwania związane z mikrousługami
Niekontrolowany rozwój
Rezygnacja z architektury monolitycznej na rzecz mikrousług oznacza zwiększenie stopnia złożoności. Pojawia się więcej usług w większej liczbie miejsc, a do tego pracuje nad nimi więcej zespołów. Z tego powodu trudno jest określić, jak poszczególne komponenty są ze sobą powiązane, kto jest właścicielem danego komponentu oprogramowania i jak uniknąć negatywnego wpływu na działanie zależnych komponentów. Brak zarządzania niekontrolowanym rozwojem skutkuje wolniejszym tempem prac programistycznych i gorszą wydajnością operacyjną. W miarę rozwoju systemu konieczny staje się doświadczony zespół operacyjny, który będzie zarządzać ponownymi wdrożeniami i częstymi zmianami architektury.
Brak wyraźnej odpowiedzialności
W przypadku architektury mikrousług nie zawsze jest jasne, kto odpowiada za co. Zespół DevOps może korzystać z połączenia interfejsów API, bibliotek komponentów, narzędzi do monitorowania oraz obrazów Docker pozwalających użytkownikom wdrożyć aplikację. Ważny jest wgląd w informacje o komponentach, łącznie z ich właścicielami, zasobami i zmieniającymi się zależnościami między komponentami. Konieczna jest precyzyjna komunikacja i koordynacja pomiędzy licznymi zespołami, aby każda osoba biorąca udział w pracach mogła z łatwością dotrzeć do wiedzy, która jest potrzebna do zrozumienia produktu.
Wykładniczy wzrost kosztów infrastruktury
Każda nowa mikrousługa dodana do wdrożenia produkcyjnego generuje własny koszt związany z zestawem testów, podręcznikami wdrażania, infrastrukturą hostingową, narzędziami do monitorowania i nie tylko.
Zwiększone obciążenie organizacyjne
Aby koordynować wprowadzanie aktualizacji i użycie interfejsów przez zespoły zajmujące się architekturą mikrousług, potrzebny jest dodatkowy poziom komunikacji i współpracy.
Debugowanie
Debugowanie aplikacji obejmującej wiele mikrousług, z których każda ma swój zestaw dzienników, może być nie lada wyzwaniem. Jeden proces biznesowy może działać na wielu komputerach w różnym czasie, co rodzi dodatkowe komplikacje.
Reagowanie na incydenty
Ważne jest, aby mieć dane umożliwiające odpowiadanie na incydenty związane z mikrousługami, np. kto korzysta z danej mikrousługi, gdzie i w jaki sposób została ona wdrożona oraz z kim należy się kontaktować w razie problemów.
Mikrousługi i DevOps: para idealna
Z uwagi na zwiększony stopień złożoności i zależności mikrousług praktyki DevOps dotyczące automatyzacji cyklu życia, wdrażania i monitorowania uznawane są za integralną część infrastruktury mikrousług. Właśnie dlatego mikrousługi często uważa się za pierwszy krok do wprowadzenia kultury DevOps, którego skutkami są:
- Automatyzacja
- Zwiększona skalowalność
- Możliwość zarządzania
- Agility
- Szybsze dostarczanie i wdrażanie
Najważniejsze technologie i narzędzia w przypadku architektury mikrousług
Kontenery, Docker i Kubernetes
Kontener to po prostu opakowanie aplikacji wraz z wszystkimi zależnościami, które umożliwia jej łatwe i spójne wdrażanie. Ponieważ kontenery nie potrzebują własnego systemu operacyjnego, są mniejsze i prostsze od tradycyjnych maszyn wirtualnych. Można je szybciej uruchamiać i wyłączać, dzięki czemu idealnie spełniają potrzeby mniejszych usług używanych w ramach architektury mikrousług.
Wraz ze wzrostem liczby usług i kontenerów pojawia się konieczność zarządzania dużymi grupami tych ostatnich. Docker to popularna platforma konteneryzacji i środowisko uruchomieniowe, które pomaga programistom kompilować, wdrażać i uruchamiać kontenery. Sam Docker nie wystarczy jednak do bezproblemowego uruchamiania kontenerów i zarządzania nimi na dużą skalę. Pomocny w takim przypadku jest Kubernetes oraz inne rozwiązania, takie jak Docker Swarm, Mesos czy HashiCorp Nomad.
Konteneryzacja i wdrażanie kontenerów to nowy model infrastruktury rozproszonej. Docker i Kubernetes opakowują usługę w kompletny kontener, który można szybko wdrożyć i wycofać. Te narzędzia infrastruktury stanowią uzupełnienie architektury mikrousług. Przy użyciu systemu zarządzania kontenerami można konteneryzować mikrousługi, z łatwością je wdrażać oraz zarządzać nimi.
Bramy interfejsów API
Poszczególne usługi w architekturze mikrousług komunikują się ze sobą poprzez odpowiednio zdefiniowane interfejsy API. Brama interfejsu API działa jak odwrotny serwer proxy: akceptuje wywołania interfejsu API, zbiera usługi w celu realizacji tych wywołań oraz zwraca wyniki. Bramy interfejsu API zapewniają abstrakcję na potrzeby pojedynczego punktu końcowego API, chociaż interfejsy API są obsługiwane przez wiele mikrousług. Bramy interfejsu API mogą również służyć do konsolidacji funkcji, takich jak ograniczanie przepustowości, monitorowanie, uwierzytelnianie, autoryzacja i przekierowywanie do odpowiedniej mikrousługi.
Obsługa komunikatów i strumieniowanie zdarzeń
Z uwagi na rozproszony charakter mikrousług zespoły potrzebują sposobu udostępniania informacji o zmianach stanu i innych zdarzeniach. Systemy obsługi komunikatów umożliwiają mikrousługom komunikację i przetwarzanie zdarzeń w ramach głównego interfejsu. Przykładowo wprowadzenie zmian na stronach Confluence powoduje wygenerowanie zdarzenia, które wyzwala ponowne indeksowanie na potrzeby wyszukiwania oraz wysłanie powiadomień do osób obserwujących stronę.
Rejestrowanie i monitorowanie
Mikrousługi utrudniają zidentyfikowanie problemu i jego rozwiązanie w wielu usługach. Ważne jest posiadanie narzędzi obserwacyjnych do rejestrowania, monitorowania i śledzenia. Pomagają one zrozumieć zachowanie mikrousług, zidentyfikować potencjalne problemy i rozwiązać te, które wystąpiły, oraz przeprowadzić debugowanie w przypadku awarii.
Ciągła integracja / ciągłe dostarczanie
Jedną z głównych zalet mikrousług są częste i szybsze cykle wydawania. Mikrousługi stanowią kluczowy element CI/CD, umożliwiając zespołom eksperymentowanie z nowymi funkcjami i wycofywanie ich, jeśli coś pójdzie nie tak. Ułatwia to aktualizację kodu i przyspiesza wprowadzanie nowych funkcji na rynek.
Portal dla programistów
Ponieważ architektury rozproszone z czasem stają się coraz bardziej złożone, dla programistów może się okazać przydatne narzędzie skupiające w jednym miejscu informacje o wynikach prac inżynierskich oraz współpracy zespołowej. Przykładem może być rozwiązanie Atlassian Compass, które zaprojektowano w celu zapanowania nad niekontrolowanym rozrostem mikrousług poprzez dostarczanie danych i analiz w łańcuchach narzędzi DevOps.
Przyszłość mikrousług
Konteneryzacja i wdrażanie kontenerów to obecnie popularny model infrastruktury rozproszonej. Takie narzędzia jak Docker i Kubernetes opakowują usługę w kompletny kontener, który można szybko wdrożyć i wycofać. Te nowe narzędzia infrastruktury stanowią uzupełnienie architektury mikrousług, ponieważ przy użyciu systemu zarządzania kontenerami możliwa jest konteneryzacja mikrousług, ich proste wdrażanie oraz zarządzanie nimi.
Wdrażanie mikrousług należy postrzegać raczej jako proces niż bezpośredni cel zespołu.
Rozpoczęcie na małą skalę może pomóc w zrozumieniu technicznych wymagań systemu rozproszonego oraz w skalowaniu poszczególnych komponentów. Potem w miarę zdobywania doświadczenia i wiedzy można stopniowo wyodrębniać więcej usług.
Zarządzanie mikrousługami za pomocą rozwiązania Compass
Podczas pracy z architekturą mikrousług rozwiązanie Atlassian Compass pozwala zarządzać złożonością skalowanej architektury rozproszonej. Jest to rozszerzalna platforma środowiska programistycznego, która w centralnej lokalizacji z możliwością wyszukiwania łączy niepowiązane informacje o wynikach prac inżynierskich i współpracy zespołowej. Oprócz pomocy w uporaniu się ze wzrostem liczby mikrousług dzięki katalogowi komponentów rozwiązanie Compass ułatwia ustalenie najlepszych praktyk i pomiar kondycji oprogramowania przy użyciu kart wyników oraz zapewnia dane i analizy dotyczące całego zestawu narzędzi DevOps za pomocą rozszerzeń opartych na platformie Atlassian Forge.
