Mikrousługi

menu icon

Mikrousługi

W architekturze mikrousług pojedyncza aplikacja składa się z wielu luźno powiązanych, mniejszych usług, które można wdrażać niezależnie od siebie.

Czym są mikrousługi?

Mikrousługi (lub architektura mikrousług) to opracowane z myślą o chmurze podejście architektoniczne polegające na tym, że pojedyncza aplikacja składa się z wielu luźno powiązanych, mniejszych komponentów lub usług, które można wdrażać niezależnie od siebie. Usługi te zwykle mają następujące cechy:

  • Posiadają własny stos technologii, w tym bazę danych i model zarządzania danymi.
  • Komunikują się ze sobą za pomocą kombinacji interfejsów API REST, strumieniowego przesyłania zdarzeń i brokerów komunikatów.
  • Są zorganizowane według możliwości biznesowych, a linia oddzielająca usługi jest często nazywana ograniczonym kontekstem.

Chociaż znaczna część dyskusji na temat mikrousług dotyczy charakterystyki i definicji architektonicznych, ich wartość można lepiej zrozumieć z perspektywy prostych korzyści biznesowych i organizacyjnych:

  • Łatwiejsze aktualizowanie kodu — nowe funkcje można dodawać bez modyfikowania całej aplikacji.
  • Zespoły mogą korzystać z różnych stosów i języków programowania w przypadku różnych komponentów.
  • Komponenty można skalować niezależnie od siebie, zmniejszając straty i koszty związane ze skalowaniem całych aplikacji z powodu zbytniego obciążenia jednej funkcji.

Mikrousługi można także zdefiniować, określając, czym one nie są. Architektura mikrousług jest najczęściej porównywana z architekturą monolityczną i architekturą zorientowaną na usługi (service-oriented architecture — SOA).

Różnica między mikrousługami i architekturą monolityczną polega na tym, że mikrousługi to wiele mniejszych, luźno powiązanych usług tworzących aplikację. Aplikacja monolityczna to pojedyncza, zintegrowana usługa.

Aby dowiedzieć się więcej o różnicach między mikrousługami i architekturą monolityczną, obejrzyj ten film (6:37):

 

Różnice między mikrousługami i architekturą SOA mogą być nieco mniej oczywiste. Chociaż między mikrousługami i architekturą SOA można nakreślić różnice techniczne, zwłaszcza w kontekście roli magistrali komunikacyjnej, łatwiejsza do zobrazowania jest różnica zakresu. Architektura SOA była próbą zestandaryzowania sposobu komunikacji i integracji wszystkich usług WWW w organizacji, natomiast architektura mikrousług jest specyficzna dla aplikacji.

Wpis „Architektura SOA i mikrousługi: jaka jest różnica?” zawiera więcej szczegółów na ten temat.

Korzyści stosowania mikrousług w organizacji

Mikrousługi prawdopodobnie będą równie popularne wśród kierownictwa i menedżerów projektów, co programistów. Jest to jedna z bardziej nietypowych cech mikrousług, ponieważ entuzjazm względem architektury zwykle ogranicza się do zespołów tworzenia oprogramowania. Dzieje się tak, ponieważ mikrousługi lepiej odzwierciedlają sposób, w jaki wielu liderów biznesowych chce strukturyzować i prowadzić zespoły oraz procesy rozwoju.

Innymi słowy, mikrousługi to model architektoniczny, który bardziej ułatwia stosowanie żądanego modelu operacyjnego. W niedawnej ankiecie IBM przeprowadzonej wśród ponad 1200 programistów i dyrektorów IT 87% użytkowników mikrousług zgodziło się, że wydatki i nakład pracy związane z wdrożeniem mikrousług są warte uzyskiwanych efektów. Skorzystaj z poniższego interaktywnego narzędzia, aby poznać więcej korzyści i wyzwań związanych z mikrousługami:

(Źródło: „Microservices in the enterprise 2021: Real benefits, worth the challenges”).

Poniżej wymieniono tylko niektóre korzyści ze stosowania mikrousług w przedsiębiorstwach.

Niezależne wdrażanie

Prawdopodobnie najważniejszą cechą mikrousług jest to, że ponieważ są one mniejsze i można je wdrażać niezależnie, nie trzeba podejmować wielkiego wysiłku, aby zmienić wiersz kodu lub dodać nową funkcję do aplikacji.

Mikrousługi oferują organizacjom możliwość wprowadzania niewielkich zmian bez konieczności poświęcania na nie ogromnych ilości czasu. Dostrzeżenie wartości strategii, która zwiększa szybkość i sprawność działania, nie wymaga doktoratu z informatyki.

Szybkość to nie jedyna korzyść z takiego projektowania usług. Obecnie często stosuje się model organizacyjny, w którym zespoły z wielu dziedzin wspólnie pracują nad problemem biznesowym, usługą lub produktem. Model mikrousług idealnie wpisuje się w ten trend, ponieważ umożliwia organizacji tworzenie małych, wielozadaniowych zespołów, które mogą pracować nad usługą lub kolekcją usług w sposób zwinny.

Luźne powiązanie mikrousług zapewnia również pewien poziom izolacji w przypadku uszkodzeń oraz zwiększenie odporności aplikacji. Niewielki rozmiar usług w połączeniu z ich wyraźnymi granicami i wzorcami komunikacji ułatwia nowym członkom zespołu zrozumienie podstawy kodu i szybsze rozpoczęcie produktywnej pracy, co pozytywnie wpływa zarówno na szybkość realizacji projektów, jak i zadowolenie pracowników.

Narzędzie odpowiednie do danego zadania

W tradycyjnych wzorcach architektury n-warstwowej aplikacja zwykle korzysta ze wspólnego stosu z dużą, relacyjną bazą danych obsługującą całą aplikację. Takie podejście ma kilka oczywistych wad. Najważniejszą z nich jest fakt, że każdy komponent aplikacji musi współdzielić stos, model danych i bazę danych nawet wtedy, gdy w przypadku niektórych elementów istnieje wyraźnie skuteczniejsze narzędzie. Powoduje to tworzenie złej architektury i jest źródłem frustracji dla programistów, którzy wiedzą, że istnieje lepszy i wydajniejszy sposób budowania danych komponentów.

Natomiast w modelu mikrousług komponenty są wdrażane niezależnie i komunikują się przy użyciu kombinacji usług REST, strumieniowego przesyłania zdarzeń i brokerów komunikatów. Dzięki temu stos każdej usługi można zoptymalizować pod kątem tej usługi. Technologia stale się zmienia, a aplikację złożoną z wielu mniejszych usług można znacznie łatwiej i taniej rozwijać, korzystając z bardziej odpowiedniej technologii, gdy stanie się ona dostępna.

Precyzyjne skalowanie

W przypadku mikrousług pojedyncze usługi można oddzielnie wdrażać, ale można je też oddzielnie skalować. Korzyść jest oczywista: poprawnie opracowane mikrousługi wymagają mniej zasobów infrastruktury niż aplikacje monolityczne, ponieważ umożliwiają precyzyjne skalowanie tylko tych komponentów, które tego wymagają. Nie jest konieczne skalowanie całej aplikacji, jak w przypadku aplikacji monolitycznych.

Wyzwań nie brakuje

Zapewnienie korzyści z mikrousług wiąże się ze stawieniem czoła dużym wyzwaniom. Przejście z architektury monolitycznej na mikrousługi oznacza znaczne zwiększenie złożoności zarządzania — większa liczba usług tworzonych przez większą liczbę zespołów jest wdrażana w większej liczbie miejsc. Problemy z jedną usługą mogą powodować problemy w innych usługach lub być powodowane przez problemy w innych usługach. Rejestrowanych danych pochodzących z różnych usług (wykorzystywanych do monitorowania i rozwiązywania problemów) jest znacznie więcej i mogą one być niespójne. Nowe wersje mogą powodować problemy z kompatybilnością wsteczną. Aplikacje korzystają z większej liczby połączeń sieciowych, co oznacza więcej możliwości powstania opóźnień i wystąpienia problemów z łącznością. Zastosowanie metodologii tworzenia i eksploatacji oprogramowania (którą omawiamy poniżej) może rozwiązać wiele z tych problemów, ale wdrożenie procedur DevOps również wiąże się z wyzwaniami.

Nie powstrzymują one jednak firm przed wdrożeniem mikrousług po raz pierwszy. Nie zniechęcają też firm już korzystających z mikrousług do zwiększenia ich wykorzystania. Dane uzyskane w wyniku nowej ankiety IBM wskazują, że 56% podmiotów, które nie używają mikrousług, prawdopodobnie lub bardzo prawdopodobnie wdroży je w ciągu kolejnych dwóch lat, a 78% obecnych użytkowników mikrousług prawdopodobnie zwiększy czas, środki i nakład pracy zainwestowane w mikrousługi (patrz Rysunek 1).

Trzy wykresy kołowe przedstawiające 56 procent, 78 procent i 59 procent

Rysunek 1. Mikrousługi nie znikną. W ciągu kolejnych dwóch lat 56% podmiotów, które nie używają mikrousług, prawdopodobnie je wdroży, 78% użytkowników zwiększy inwestycje w mikrousługi, a 59% aplikacji będzie tworzonych przy użyciu mikrousług. (Źródło: „Microservices in the enterprise 2021: Real benefits, worth the challenges”).

Mikrousługi umożliwiają korzystanie z procedur DevOps, ale również tego wymagają

Architektura mikrousług jest często opisywana jako zoptymalizowana pod kątem tworzenia i eksploatacji oprogramowania oraz integracji ciągłej / dostarczania ciągłego (CI/CD). W kontekście małych usług, które mogą być często wdrażane, łatwo zrozumieć, dlaczego.

Na relację między mikrousługami oraz tworzeniem i eksploatacją oprogramowania można też spojrzeć w inny sposób: skuteczne wykorzystanie architektury mikrousług wymaga metodologii DevOps.Chociaż aplikacje monolityczne mają szereg wad omówionych wcześniej w tym artykule, ich zaletą jest to, że nie są złożonym systemem rozproszonym z wieloma zmieniającymi się elementami i niezależnymi stosami technologii. Z kolei biorąc pod uwagę ogromny wzrost złożoności, liczby zmieniających się elementów i zależności w przypadku mikrousług, ich wdrożenie bez znacznych inwestycji w automatyzację wdrażania, monitorowania i cyklu życia byłoby nierozsądne.

Andrea Crawford przedstawia bardziej szczegółowe informacje na temat tworzenia i eksploatacji oprogramowania w poniższym filmie:

Kluczowe technologie i narzędzia

Chociaż w architekturze mikrousług można używać niemal każdego nowoczesnego narzędzia lub języka, kilka podstawowych narzędzi jest istotnych na tyle, że niemal ją definiują:

kontenery, Docker i Kubernetes

Jedną z kluczowych cech mikrousługi jest jej niewielki rozmiar. (Nie ma ustalonej ilości kodu, która określa, czy coś jest, czy nie jest mikrousługą, ale słowo „mikro” jest zawarte w nazwie).

Gdy platforma Docker rozpoczęła nowoczesną erę kontenerów w 2013 roku, wprowadziła również model obliczeniowy, który jest teraz najmocniej kojarzony z mikrousługami. Ponieważ pojedyncze kontenery nie powodują dodatkowego obciążenia wynikającego z ich własnego systemu operacyjnego, są mniejsze i prostsze niż tradycyjne maszyny wirtualne oraz można je szybciej uruchamiać i wyłączać. Dzięki temu świetnie pasują do mniejszych i prostszych usług stosowanych w architekturach mikrousług.

Wraz z rozprzestrzenianiem się usług i kontenerów, harmonizacja dużych grup kontenerów oraz zarządzanie nimi szybko stało się jednym z newralgicznych wyzwań. Kubernetes, platforma typu Open Source do harmonizacji kontenerów, stała się jednym z najbardziej popularnych rozwiązań do harmonizacji, ponieważ świetnie sobie z tym radzi.

W filmie „Kubernetes bez tajemnic” Sai Vennam kompleksowo omawia wszystkie aspekty platformy Kubernetes:

 

Bramy API

Mikrousługi często komunikują się za pośrednictwem interfejsu API, zwłaszcza podczas pierwszego ustanawiania stanu. Chociaż klienty i usługi mogą komunikować się ze sobą bezpośrednio, bramy API są często użyteczną warstwą pośredniczącą, zwłaszcza że liczba usług w aplikacji z czasem rośnie. Brama API działa jako odwrotne proxy dla klientów, kierując żądania, zwielokrotniając je na wiele usług oraz zapewniając dodatkowe zabezpieczenia i uwierzytelnianie.

Bramy API można implementować przy użyciu wielu technologii, w tym platform zarządzania interfejsami API, ale jeśli architektura mikrousług jest wdrażana przy użyciu kontenerów i platformy Kubernetes, brama jest zwykle implementowana przy użyciu rozwiązania Ingress lub, ostatnio, Istio.

Przesyłanie komunikatów i strumieniowe przesyłanie zdarzeń

Chociaż sprawdzoną procedurą może być projektowanie usług bezstanowych, to jednak stan istnieje i usługi muszą mieć o nim informacje. Wywołanie interfejsu API jest często skutecznym sposobem początkowego ustanowienia stanu dla danej usługi, ale nie jest to szczególnie skuteczny sposób jego bieżącego aktualizowania. Podejście do utrzymywania aktualności usług przez ciągłe odpytywanie, czyli ciągłe zadawanie pytań typu „czy wszystko już gotowe?”, nie jest praktyczne.

Zamiast tego konieczne jest połączenie ustanawiających stan wywołań interfejsów API z przesyłaniem komunikatów lub przetwarzaniem strumieniowym zdarzeń, aby usługi mogły rozgłaszać zmiany stanu, a inne elementy — nasłuchiwać tych zmian i odpowiednio dostosowywać swoje działanie. To zadanie prawdopodobnie najlepiej wykona broker komunikatów ogólnego przeznaczenia, ale w niektórych przypadkach platforma strumieniowego przesyłania zdarzeń, taka jak Apache Kafka, może być dobrym rozwiązaniem. Dzięki połączeniu mikrousług z architekturą sterowaną zdarzeniami programiści mogą budować rozproszone, wysoce skalowalne, odporne na błędy i rozszerzalne systemy, zdolne wykorzystywać i przetwarzać bardzo duże ilości zdarzeń lub informacji w czasie rzeczywistym.

Bez serwera

Architektury bezserwerowe to logiczna ostateczna forma niektórych podstawowych wzorców chmury i mikrousług. W przypadku architektury bezserwerowej jednostka wykonania to nie tylko mała usługa, ale funkcja, która często może składać się jedynie z kilku wierszy kodu. Rozróżnienie między funkcją bezserwerową i mikrousługą nie jest wyraźne, ale powszechnie uznaje się, że funkcje są jeszcze mniejsze niż mikrousługi.

Podobieństwo między architekturami bezserwerowymi i platformami typu FaaS a mikrousługami polega na tym, że w ich przypadkach tworzy się mniejsze jednostki wdrażania i precyzyjnie skaluje w zależności od potrzeb.

Mikrousługi i usługi przetwarzania w chmurze

Mikrousługi nie mają zastosowania wyłącznie w przypadku przetwarzania w chmurze, ale istnieje kilka ważnych powodów, dla których są one tak często stosowane razem. Te powody wykraczają poza popularność struktury architektonicznej mikrousług i chmury jako miejsca hostowania dla nowych aplikacji.

Jedną z podstawowych korzyści z architektury mikrousług jest niższe wykorzystanie i koszty dzięki indywidualnemu wdrażaniu i skalowaniu komponentów. Chociaż te korzyści są w pewnym stopniu realizowane także w infrastrukturze lokalnej, dopiero połączenie niewielkich, niezależnie skalowalnych komponentów oraz infrastruktury dostępnej na żądanie z płatnością według faktycznego wykorzystania pozwala uzyskać rzeczywistą optymalizację kosztów.

Drugą, może nawet ważniejszą, podstawową korzyścią mikrousług jest to, że każdy komponent może stosować stos najlepiej dopasowany do konkretnego zadania. Większa liczba stosów może prowadzić do znacznego zwiększenia złożoności i nakładu pracy w przypadku samodzielnego zarządzania, ale zastosowanie obsługującego stosu w postaci usług przetwarzania w chmurze drastycznie minimalizuje wyzwania związane z zarządzaniem. Innymi słowy, korzystanie z własnej infrastruktury mikrousług jest możliwe, ale nie jest zalecane, zwłaszcza na początku.

Typowe wzorce

Architektury mikrousług obejmują wiele typowych i przydatnych wzorców projektowania, komunikacji i integracji, które pomagają w stawianiu czoła powszechnym wyzwaniom i wykorzystaniu pojawiających się możliwości, w tym:

  • Wzorzec zaplecza dla interfejsu (BFF): wzorzec ten zapewnia warstwę między środowiskiem użytkownika a zasobami, które to środowisko wywołuje. Na przykład aplikacja używana na komputerze będzie mieć inne limity wielkości ekranu, wyświetlania i wydajności niż na urządzeniu przenośnym. Dzięki wzorcowi BFF programiści mogą tworzyć i obsługiwać jeden typ zaplecza dla każdego interfejsu użytkownika przy użyciu najlepszych narzędzi dla tego interfejsu, zamiast próbować obsługiwać ogólne zaplecze, które działa z każdym interfejsem, ale może negatywnie wpływać na jego wydajność.
  • Wzorce encji i agregatów: encja to obiekt wyróżniony przez tożsamość. Na przykład w serwisie handlu elektronicznego obiekt produktu może być wyróżniany za pomocą nazwy, typu i ceny produktu. Agregat jest kolekcją powiązanych encji, które należy traktować jako pojedynczą jednostkę. W przypadku serwisu handlu elektronicznego zamówienie byłoby kolekcją (agregatem) produktów (encji) zamówionych przez klienta. Te wzorce są używane do klasyfikowania danych w zrozumiały sposób.
  • Wzorce wykrywania usług: pomagają aplikacjom i usługom we wzajemnym znajdowaniu się. W architekturze mikrousług instancje usług zmieniają się dynamicznie ze względu na skalowanie, aktualizacje, awarie usług, a nawet zakończenie usług. Te wzorce zapewniają mechanizmy wykrywania służące do radzenia sobie z tą zmiennością. Równoważenie obciążeń może korzystać z wzorców wykrywania usług, używając kontroli poprawności i awarii usług jako wyzwalaczy ponownego równoważenia ruchu.
  • Wzorce mikrousług adapterów: o wzorcach adapterów można myśleć tak, jak o przejściówkach używanych podczas podróży do innego kraju. Celem wzorców adapterów jest ułatwienie translacji relacji między klasami lub obiektami, które są ze sobą niekompatybilne. Aplikacja opierająca się na interfejsach API innych firm może wymagać użycia wzorca adaptera w celu zapewnienia, że aplikacja i interfejsy API mogą się komunikować.
  • Wzorzec dusiciela aplikacji: te wzorce pomagają w zarządzaniu refaktoryzacją aplikacji monolitycznej w celu przekształcenia jej w aplikacje oparte na mikrousługach. Barwna nazwa odnosi się do tego, jak pnącze (mikrousługi) powoli obrasta i dusi drzewo (aplikacja monolityczna).

Więcej informacji o tych wzorcach zawiera artykuł „How to use development patterns with microservices (part 4)” . Jeśli chcesz dowiedzieć się więcej o wzorcach kodu mikrousług, platforma IBM Developer również udostępnia wiele informacji.

Antywzorce

Chociaż istnieje wiele wzorców umożliwiających skuteczne wdrożenie mikrousług, jest też dużo takich, które mogą szybko wpędzić każdy zespół programistyczny w kłopoty. Niektóre z nich — wyrażone jako „czego nie robić w przypadku mikrousług” — są następujące:

  • Pierwsza zasada mikrousług to nie buduj mikrousług: dokładniej mówiąc, nie zaczynaj od mikrousług. Mikrousługi są sposobem na zarządzanie złożonością, gdy aplikacje stały się zbyt duże i nieporęczne, aby można je było łatwo aktualizować i utrzymywać. Dopiero wtedy, gdy złożoność aplikacji monolitycznej zaczną się dawać we znaki, warto rozważyć refaktoryzację aplikacji na mniejsze usługi. Do tego momentu monolit w zasadzie nie wymaga refaktoryzacji.
  • Nie wdrażaj mikrousług bez procedur tworzenia i eksploatacji oprogramowania lub usług przetwarzania w chmurze: budowanie mikrousług oznacza budowanie systemów rozproszonych, a systemy rozproszone są trudne w obsłudze (zwłaszcza wtedy, gdy dokonujesz wyborów, które dodatkowo to utrudniają). Próba wdrożenia mikrousług bez odpowiedniej automatyzacji wdrażania i monitorowania lub zarządzanych usług przetwarzania w chmurze, które będą wspierać rozrastającą się, heterogeniczną infrastrukturę, to proszenie się o niepotrzebne kłopoty. Oszczędź ich sobie, aby móc się skupić na stanie.
  • Nie twórz zbyt małych mikrousług, ponieważ będzie ich zbyt wiele: jeśli Twoje mikrousługi będą zbyt małe, łatwo może dojść do tego, że nakłady pracy i złożoność będą większe niż ogólne korzyści z architektury mikrousług. Lepiej jest tworzyć większe usługi i dzielić je dopiero wtedy, gdy zaczną pojawiać się problemy rozwiązywane przez mikrousługi — wdrażanie zmian staje się trudne i powolne, wspólny model danych staje się zbyt złożony lub różne części usługi mają różne wymagania związane z obciążeniami/skalowaniem.
  • Nie zmieniaj mikrousług w architekturę SOA: mikrousługi i architektura zorientowana na usługi (SOA) są często łączone, ponieważ na najbardziej podstawowym poziomie oba te podejścia dążą do budowania odrębnych komponentów wielokrotnego użytku, które mogą być wykorzystywane przez inne aplikacje. Różnica między mikrousługami i architekturą SOA polega na tym, że projekty mikrousług zazwyczaj obejmują refaktoryzację aplikacji, aby można nią było łatwiej zarządzać, natomiast architektura SOA skupia się na zmianie sposobu działania usług IT w całym przedsiębiorstwie. Projekt mikrousług, który zmieni się w projekt SOA, najprawdopodobniej załamie się pod własnym ciężarem.
  • Nie staraj się być jak Netflix: Netflix był jednym z pionierów architektury mikrousług podczas budowania i nadzorowania aplikacji, która stanowiła jedną trzecią całego ruchu internetowego. Tak trudne warunki wymagały napisania dużej ilości niestandardowego kodu i utworzenia wielu usług, które są zbędne w przypadku przeciętnej aplikacji. Na początku warto pracować w swoim tempie, unikać złożoności i używać tak wielu gotowych narzędzi, jak to możliwe.

Kursy: Rozwijanie umiejętności z dziedziny mikrousług

Jeśli chcesz się dowiedzieć więcej o korzystaniu z mikrousług lub rozwinąć związane z nimi umiejętności, skorzystaj z jednego z poniższych kursów:

Mikrousługi a IBM Cloud

Mikrousługi umożliwiają innowacyjne programowanie z szybkością nowoczesnego biznesu. Dowiedz się, jak wykorzystać skalowalność i elastyczność chmury, wdrażając niezależne mikrousługi w środowiskach chmurowych. Zobacz, jak IBM może pomóc w modernizacji Twoich aplikacji.

Wykonaj kolejny krok:

Już dzisiaj załóż konto w IBM Cloud.