Architektura mikroserwisów: znak rozpoznawczy kompetencji

Systemy monolityczne nie są już możliwe we współczesnych czasach konteneryzacji i przetwarzania w chmurze. W ostatnich latach nastąpił wzrost złożoności systemów oprogramowania, a tworzenie i utrzymanie systemów monolitycznych jest coraz bardziej skomplikowane.

Komponenty systemu są produkowane i łączone jako pojedyncza jednostka w systemie monolitycznym. Cały system musiałby zostać ponownie wdrożony w przypadku zmiany pojedynczego komponentu. To sprawia, że ​​jest trudniejsze do skalowania i mniej wszechstronne. Połączona i powiązana struktura samodzielnego systemu może być trudnym zadaniem dla programistów podczas konstruowania kompleksowych aplikacji. Zaatakowane systemy utrudniają również wprowadzanie kluczowych modyfikacji, przyjmowanie nowych stosów technologii lub wysyłanie ulepszeń i aktualizacji. Architektura zorientowana na usługi, która składa się z różnych usług, które mogą komunikować się ze sobą w systemie, wyznacza ramy dla przejścia od programowania monolitycznego w pierwszej kolejności.

Architektura mikrousług była kolejnym krokiem w tej domenie i była bardziej ujednoliconym, ale szczegółowym sposobem ustanowienia skutecznej strategii rozwoju oprogramowania. Wyrażenie „Architektura mikrousług” pojawiło się w ciągu ostatnich kilku lat, aby opisać konkretną technikę budowania systemów oprogramowania jako pakietów niezależnie wdrażanych usług. Chociaż nie ma konkretnej definicji tego stylu architektonicznego, istnieje kilka podobnych cech związanych z organizacją wokół możliwości biznesowych, zautomatyzowanego wdrażania, inteligencji w punktach końcowych oraz zdecentralizowanego zarządzania językami i danymi.

Jest to podejście do tworzenia oprogramowania, które dzieli system na mniejsze, niezależne sekcje, a następnie łączy je ze sobą. Usługi autonomiczne są gromadzone w celu zaspokojenia specjalistycznych wymagań jednego konkretnego sektora. Spotify, Amazon, PayPal, Netflix i Twitter zwróciły uwagę na to nowe odkrycie i intensywnie je reklamują.

Co to jest architektura mikroserwisów?

Sformułowanie „Architektura mikrousług” stało się bardziej popularne w ciągu ostatnich kilku lat, odnosząc się do specyficznego podejścia do architektury oprogramowania jako pakietów usług, które mogą być wdrażane niezależnie od siebie. Pomimo faktu, że ten styl architektoniczny nie może być precyzyjnie zdefiniowany, ma pewne cechy wspólne z innymi podejściami architektonicznymi. Obejmują one organizację opartą na możliwościach biznesowych, zautomatyzowane wdrażanie, inteligencję w punktach końcowych oraz zdecentralizowaną kontrolę języków i danych. Innymi słowy, zdolność mikroserwisów do niezależnego działania jest siłą napędową ich awansu na szczyt sceny rozwoju oprogramowania.

Architektura mikrousług, częściej nazywana po prostu mikrousługami, to paradygmat projektowy wykorzystywany podczas tworzenia oprogramowania aplikacyjnego. Mikrousługi umożliwiają rozbicie dużej aplikacji na kilka mniejszych, samodzielnych części, z których każda odpowiada za swój własny, unikalny zestaw zadań. Pojedyncze żądanie użytkownika może spowodować, że aplikacja oparta na mikrousługach wykona wiele wywołań do własnych mikrousług wewnętrznych w celu skonstruowania odpowiedzi.

Kontenery są doskonałym przykładem architektury mikrousług, ponieważ uwalniają Cię od konieczności martwienia się o zależności usług, dzięki czemu możesz skupić się na opracowywaniu samych usług. Kontenery są często wybieranym narzędziem do tworzenia aplikacji natywnych dla chmury dla współczesnych platform w formie mikrousług. Termin „architektura mikrousług” odnosi się do typu architektury aplikacji, w której sama aplikacja jest skonstruowana jako zbiór usług. Oferuje strukturę do niezależnego budowania, wdrażania i zarządzania diagramami architektonicznymi i usługami dla mikrousług.

Potrzeba rozwoju architektury mikroserwisów i ograniczenia architektury monolitycznej

1. Skalowanie aplikacji

Ponieważ dobrze prosperujące firmy działające na skalę internetową doświadczają ekspansji wykładniczej, ich oprogramowanie musi również zapewniać dużą skalowalność poziomą. Czasami tylko część oprogramowania, która obciąża procesor lub we/wy, musi być skalowana i obsługiwana indywidualnie (zaimplementowana za pomocą programowania wielojęzycznego). Oprogramowanie, które jest monolityczne, działa jako pojedyncza jednostka i jest tworzone przy użyciu jednego języka programowania i Tech Stack. Aby wykonać skalowanie w poziomie, konieczne jest przeskalowanie całej aplikacji. Ponieważ oprogramowanie monolityczne obsługuje tylko jeden język programowania, niemożliwe jest stworzenie nawet jednego modułu w innym języku programowania lub Tech Stack.

2. Prędkość rozwoju

Aby skrócić czas wprowadzania produktów na rynek, każda firma potrzebuje obecnie szybkiego rozwoju funkcji. W dużej, skomplikowanej, a czasem wielomilionowej Aplikacji Monolitycznej, dodawanie nowych funkcji jest niezwykle powolne z powodu ogromnego obciążenia poznawczego umieszczonego na Developerze. Moduły ogromnych programów monolitycznych są ze sobą ściśle powiązane, co utrudnia tworzenie nowych funkcjonalności. W konsekwencji dodawanie nowych funkcji do monolitycznego programu jest często powolne i kosztowne.

3. Skalowanie rozwoju

Aby zdobyć przewagę nad konkurencją lub przejąć nisko wiszące owoce, firmy często starają się zrównoleglać rozwój, zatrudniając więcej programistów. Programiści nie mogą pracować niezależnie na ogromnej, monolitycznej, ściśle powiązanej bazie kodu i często wymagają dodatkowej synchronizacji i czujności, aby uniknąć wzajemnego zakłócania pracy. Dodanie dodatkowych programistów nie powoduje zwiększenia liczby funkcji i może czasami skutkować mniejszą liczbą funkcji. Podobnie, ze względu na wysokie obciążenie poznawcze wymagane do zrozumienia całej bazy kodu monolitycznego, zwykle nowi rekruci lub niedawni absolwenci potrzebują znacznej ilości czasu, aby stworzyć pierwsze wiersze wydajnego kodu. W 2008 roku odbyłem wywiad z berlińską firmą telekomunikacyjną, w którym kierownik techniczny powiedział mi z zadowolonym uśmiechem, że baza kodu C++ firmy obejmuje miliony wierszy i że nowi inżynierowie mogą tworzyć produktywny kod dopiero po czterech do sześciu miesiącach.

4. Cykl wydania

Cykl wydawniczy dużych monolitycznych programów jest zazwyczaj nadmiernie długi i wynosi od sześciu do dwóch i pół roku, z dodatkowymi kilkumiesięcznymi do kilkuletnich opóźnieniem ze względu na ich wielkość. Duże cykle wydań często stawiają korporację w niekorzystnej sytuacji konkurencyjnej w dzisiejszych czasach, ponieważ nowy konkurent może wejść na rynek podczas luki w wydaniu.

5. Modularyzacja

W architekturze monolitycznej barierą między modułami jest zazwyczaj wewnętrzny interfejs. Gdy tylko rozmiar programu się zwiększa, separacja między modułami zaczyna się załamywać. W konsekwencji moduły w architekturze monolitycznej są często ściśle powiązane, a nie luźno powiązane i wysoce spójne. Jeśli porównamy rozwój oprogramowania do społeczeństwa, to monolityczna modularyzacja jest analogiczna do zasad moralistycznych i religijnych, które nie mogą zagwarantować prawa i porządku w społeczeństwie.

6. Modernizacja

Istniejące aplikacje, które odniosły sukces, wymagały modernizacji z różnych powodów (np. wykorzystanie nowoczesnego sprzętu, przeglądarki, przepustowości sieci, stosu technicznego lub przyciągnięcie dobrych programistów). Modernizacja programu monolitycznego może być kosztowna i czasochłonna, ponieważ wymaga modernizacji całej aplikacji typu Big Bang bez wpływu na usługę.

Rodzaje mikroserwisów

Mikrousługi różnicowe i integralne to dwa różne rodzaje mikrousług.

a. Mechanizm różnicowy

W tej formie architektury architektura rozkłada się na niezależne usługi, które są zdolne do rozdzielenia na transakcje. Powoduje to dystrybucję pojedynczej transakcji do wielu serwisów.

b. Całka

Aplikacje mikrousług mają na celu łączenie wielu mikrousług w zindywidualizowane środowisko użytkownika. Programy te obejmują kilka odrębnych potrzeb, w tym zarządzanie poziomem usług, udostępnianie na żądanie i dynamiczną kompozycję.

Charakterystyka mikroserwisów

1. Autonomiczny

Architektura mikrousług umożliwia budowanie, wdrażanie, zarządzanie i skalowanie każdego składnika usługi niezależnie od innych usług. Usługi nie muszą udostępniać swojego kodu ani sposobu działania innym usługom. Cała komunikacja między różnymi częściami odbywa się za pośrednictwem dobrze zdefiniowanych interfejsów API.

2. Specjalistyczne

Każda usługa opiera się na innym zestawie umiejętności i innym problemie. Z biegiem czasu, jeśli deweloperzy dodadzą więcej kodu do usługi, usługa może zostać podzielona na mniejsze usługi.

3. Komponentowanie za pośrednictwem usług

Chociaż architektury mikrousług będą korzystać z bibliotek, główną metodą komponowania własnego oprogramowania jest rozłożenie go na usługi. Biblioteki są komponentami, które są połączone z programem i wywoływane przy użyciu wywołań funkcji w pamięci, podczas gdy usługi są komponentami spoza procesu, które komunikują się z mechanizmem, takim jak żądanie usługi sieciowej lub zdalne wywołanie procedury. Definiujemy biblioteki jako komponenty, które są połączone z programem i wywoływane za pomocą wywołań funkcji w pamięci. (Jest to pomysł odmienny od tego, co jest określane jako obiekt usługi w wielu systemach OO. W przeciwieństwie do bibliotek, usługi mogą być wdrażane niezależnie, co jest jednym z głównych powodów, dla których są one używane jako komponenty, a nie biblioteki. Jeden dodatkowy Korzyścią z zastosowania usług zamiast komponentów jest generowanie bardziej przejrzystego interfejsu komponentów.Dobra technika ustanowienia jawnego interfejsu opublikowanego nie istnieje w większości języków programowania.

Dokumentacja i dyscyplina to zazwyczaj jedyne rzeczy, które uniemożliwiają klientom naruszenie zasad hermetyzacji komponentu, co skutkowałoby zbyt ścisłym sprzężeniem między komponentami. Korzystając z jawnych protokołów połączeń zdalnych, usługi ułatwiają użytkownikom uniknięcie tego. Korzystanie z tego rodzaju usług ma pewne wady. Ponieważ wywołania wykonywane zdalnie są bardziej kosztowne niż wywołania wykonywane w ramach tego samego procesu, używane zdalnie interfejsy API muszą być bardziej szczegółowe, co może utrudnić ich wykorzystanie. Kiedy przekraczasz granice procesu, trudniej jest dokonać zmian w zachowaniu, co utrudnia zmianę sposobu podziału obowiązków między komponenty.

4. Produkty, a nie projekty

Większość inicjatyw związanych z tworzeniem aplikacji, z którymi się spotykamy, opiera się na paradygmacie zwanym projektem, w którym głównym celem jest przekazanie oprogramowania, które jest następnie uważane za ukończone. Po zakończeniu projektu oprogramowanie zostaje przekazane organizacji utrzymania ruchu, a zespół odpowiedzialny za jego budowę zostaje rozbity.

Zwolennicy mikrousług zazwyczaj unikają tej architektury na rzecz koncepcji, zgodnie z którą zespół powinien posiadać produkt przez cały okres jego istnienia. Koncepcja Amazona „budujesz, obsługujesz”, w której zespół programistów bierze na siebie całkowitą odpowiedzialność za program, gdy jest on wykorzystywany w produkcji, jest znaczącym źródłem inspiracji. Pozwala to programistom na codzienny kontakt z tym, jak ich oprogramowanie działa w środowisku produkcyjnym, i poprawia komunikację z użytkownikami, ponieważ są oni zobowiązani do przejęcia przynajmniej części ciężaru zapewniania wsparcia dla programu.

5. Zdecentralizowane zarządzanie

Dodatkowo zespoły programistyczne mikrousług preferują odrębne podejście do standardów. Wolą dostarczać pomocne narzędzia, z których mogą korzystać inni programiści, aby sprostać wyzwaniom porównywalnym z tymi, z którymi mają do czynienia, niż polegać na zestawie skodyfikowanych standardów. Zazwyczaj narzędzia te pochodzą z implementacji i są udostępniane większej społeczności, czasami, ale nie zawsze, z wykorzystaniem wewnętrznego paradygmatu open source. Teraz, gdy git i github są de facto preferowanym systemem kontroli wersji, techniki open source stają się coraz bardziej powszechne w organizacjach.

Netflix jest świetnym przykładem firmy, która przestrzega tej zasady. Dzielenie się wartościowym i, co najważniejsze, sprawdzonym w bojach kodem jako bibliotekami, pomaga innym programistom radzić sobie z podobnymi problemami w podobny sposób, jednocześnie pozwalając im w razie potrzeby wybrać inną metodę. Biblioteki współdzielone zwykle koncentrują się na wspólnych problemach związanych z przechowywaniem danych, komunikacją między procesami i automatyzacją infrastruktury, co omówiono szczegółowo poniżej.

Dla społeczności mikrousług wydatki są szczególnie niepożądane.

6. Standardy sprawdzone w boju i standardy egzekwowane

To trochę paradoks, ponieważ zespoły mikroserwisowe wolą unikać tego typu rygorystycznie egzekwowanych standardów narzucanych przez grupy zajmujące się projektowaniem biznesowym, a mimo to wykorzystują, a nawet opowiadają się za otwartymi standardami, takimi jak HTTP, ATOM i inne mikroformaty.

Podstawowym rozróżnieniem jest sposób tworzenia i wdrażania standardów. Normy kontrolowane przez organizacje takie jak IETF nie stają się standardami, dopóki nie zostanie kilka ich wdrożeń na żywo w większym świecie, które często są wynikiem udanych inicjatyw open source.

Standardy te różnią się światem od większości standardów biznesowych, które są często tworzone przez osoby z ograniczoną wiedzą na temat programowania lub nadmiernym wpływem na dostawców.

7. Automatyzacja infrastruktury

Jednym ze skutków ubocznych większej automatyzacji w wyniku ciągłego dostarczania i wdrażania jest wprowadzenie przydatnych narzędzi pomagających programistom i osobom odpowiedzialnym za operacje. Narzędzia do tworzenia artefaktów, utrzymywania baz kodu, uruchamiania podstawowych usług lub dodawania standardowego monitorowania i rejestrowania są obecnie stosunkowo rozpowszechnione. Najlepszym przykładem w sieci jest niewątpliwie kolekcja narzędzi open source Netflixa, chociaż istnieją inne, w szczególności Dropwizard, z których intensywnie korzystaliśmy.

Przegląd mechanizmu komunikacji w architekturze mikroserwisów

Usługi składające się na architekturę mikroserwisów są wykonywane na wielu różnych serwerach. Protokoły takie jak HTTP, AMQP i TCP są wykorzystywane w celu ułatwienia komunikacji między tymi wieloma usługami. Dwa protokoły o największym rozpowszechnieniu to HTTP/REST i wiadomości asynchroniczne. Protokół HTTP jest często używany przez interfejs programowania aplikacji (API) REST dla usług online. Klienci mogą uzyskiwać dostęp do zasobów aplikacji i zmieniać je, korzystając z jednolitego lokalizatora zasobów w połączeniu z metodami HTTP, takimi jak GET, POST, PUT i DELETE (URL). Interfejs programowania aplikacji REST (API) działa jako punkt wejścia do funkcjonalności aplikacji. Klienci komunikują swoje potrzeby usługom, wysyłając żądania do interfejsów API. Klienci mają możliwość komunikowania się z mikroserwisami bezpośrednio lub poprzez bramę API.

Pojedynczy punkt wejścia jest określony dla wszystkich żądań skierowanych do usług przy użyciu wzorca bramy interfejsu API. Bramka interfejsu programowania aplikacji (API) po otrzymaniu żądania od klienta kieruje żądanie do odpowiedniej usługi.

Wzorzec bramy API ma wiele wariantów, z których jeden jest backendem dla wzorca frontendu. Ten projekt tworzy odrębną bramę interfejsu API dla każdego typu klienta (na przykład jedną bramę dla klientów mobilnych i drugą dla aplikacji internetowych).

Zalecaną praktyką jest utrzymywanie niskiego poziomu komunikacji między różnymi usługami. Komunikacja asynchroniczna jest lepsza od komunikacji synchronicznej w sytuacjach, gdy komunikacja jest koniecznością. Usługa, która wysłała żądanie, nie musi czekać na odpowiedź przed kontynuowaniem działania.

Po włączeniu do bazy danych kolejki wiadomości i systemy przesyłania strumieniowego są dobrymi sposobami na umożliwienie komunikacji asynchronicznej. Dodatkowo, gdy systemy te zapewniają semantykę transakcyjną dla operacji na danych i wysyłania wiadomości, są w stanie spełnić oba te wymagania. Dzięki temu wdrażanie mikrousług jest łatwiejsze i bardziej skalowalne. Gdy używane są tylko interfejsy API REST, komunikacja między mikrousługami musi być synchroniczna, co często uniemożliwia rozwój.

Do czego służy architektura mikroserwisów?

Mikrousługi to modny styl architektoniczny, którego celem jest projektowanie złożonych systemów jako zbiorów drobnoziarnistych i luźno powiązanych artefaktów oprogramowania zwanych mikrousługami; każda mikrousługa implementuje niewielką część lub nawet pojedynczą funkcję logiki biznesowej aplikacji. Mikrousługi zyskują na popularności, ponieważ mają na celu projektowanie złożonych systemów jako zbiorów drobnoziarnistych i luźno powiązanych artefaktów oprogramowania. Mikroserwisy są często wykorzystywane w celu przyspieszenia procesu tworzenia aplikacji.

Idea mikro została rozwinięta w odpowiedzi na monolityczną infrastrukturę, na której początkowo opierała się większość organizacji, zwłaszcza jeśli dana firma działa od co najmniej dziesięciu lat. Każdy składnik architektury mikrousług zawiera następujące funkcje zamiast projektu monolitycznego:

• Unikalny dla niego procesor
• Własny system operacyjny i środowisko uruchomieniowe
• W wielu przypadkach będzie nad tym pracował wyspecjalizowany zespół, aby każda usługa była odróżnialna od innych.

Dzięki takiemu projektowi każda usługa jest w stanie:

• Wykonaj własną, jedyną w swoim rodzaju procedurę
• Niezależnie komunikuj się ze sobą bez konieczności polegania na komunikacji innych mikrousług lub aplikacji jako całości.

Istnieje szerokie zastosowanie architektur mikrousług opartych na Javie, zwłaszcza tych zbudowanych przy użyciu Spring Boot. Ponadto mikrousługi i architektura zorientowana na usługi są często porównywane ze sobą. Oba podejścia mają ten sam cel, którym jest podzielenie dużych programów na łatwiejsze do zarządzania części, ale ich metodologia jest inna. Ponadto wiele firm znajduje się pod presją swoich rywali, aby jak najszybciej wprowadzali zmiany w swoich systemach, jednocześnie minimalizując wpływ takich zmian na dostępność swoich systemów. Wymaga to odpowiednich projektów, stylów architektonicznych i technik rozwoju. Inżynieria oprogramowania oferuje różnorodne paradygmaty, które mogą częściowo zaspokoić te potrzeby. Te paradygmaty dzielą systemy oprogramowania na drobnoziarniste jednostki oprogramowania, co poprawia modułowość, łatwość konserwacji i możliwość ponownego użycia, a w rezultacie skraca czas potrzebny na wprowadzenie produktu na rynek.

Krótko mówiąc, zapewnia zwinność przez długi czas. Mikrousługi umożliwiają lepszą konserwację w złożonych, dużych i wysoce skalowalnych systemach, umożliwiając tworzenie aplikacji opartych na dużej liczbie niezależnie wdrażanych usług, z których każda ma swój własny, granularny i autonomiczny cykl życia. Odbywa się to poprzez umożliwienie tworzenia aplikacji opartych na dużej liczbie usług.

Dodatkową zaletą mikrousług jest możliwość samodzielnego skalowania. Nie musisz mieć pojedynczej, monolitycznej aplikacji, którą musisz skalować jako pojedynczą jednostkę, ponieważ możesz zamiast tego skalować poszczególne mikrousługi. Będziesz mógł rozwijać tylko obszar funkcjonalny programu, który wymaga dodatkowej mocy obliczeniowej lub przepustowości sieci, aby zaspokoić zapotrzebowanie w ten sposób, zamiast skalować inne części aplikacji, które nie wymagają skalowania. Powoduje to oszczędności kosztów ze względu na mniejszą ilość wymaganego sprzętu.

Oto kilka przykładów architektury mikroserwisów

a. Relokacja strony internetowej

Możliwa jest relokacja strony internetowej; na przykład witrynę internetową hostowaną na złożonej platformie monolitycznej można przenieść na platformę mikrousług opartą na chmurze i kontenerach.

b. Zawartość mediów

Skalowalny system obiektowej pamięci masowej może być używany do przechowywania obrazów i zasobów wideo, a architektura mikrousług może służyć do oferowania tych materiałów bezpośrednio w Internecie lub na urządzeniach mobilnych.

c. Negocjacje finansowe i rozliczenia

Możliwe jest potraktowanie realizacji płatności i zamówienia jako dwóch odrębnych, odrębnych usług. Umożliwia to przyjmowanie płatności nawet w przypadku problemów z systemem rozliczeniowym.

d. Przetwarzanie danych

Usługi modułowego przetwarzania danych można usprawnić w zakresie obsługi chmury za pomocą platformy mikroserwisowej, która może być również wykorzystywana do przetwarzania danych.

Wzorce projektowe dla mikroserwisów

Język wzorców jest Twoim przewodnikiem!

a) Wzorce dekompozycji

• Bulkhead oddziela ważne zasoby, takie jak pula połączeń, pamięć i procesor, dla każdego obciążenia lub usługi. Wdrażając przegrody, pojedyncze obciążenie (lub usługa) nie może wykorzystać wszystkich zasobów, głodując innych. Takie podejście zwiększa niezawodność systemu, eliminując kaskadowe awarie spowodowane przez jedną usługę. Ten wzór jest nazywany grodzią, ponieważ przypomina podzielone na części przegrody kadłuba statku. Podziel instancje usług na odrębne grupy na podstawie obciążenia klienta i potrzeb w zakresie dostępności. Architektura ta pomaga izolować usterki i umożliwia zachowanie zdolności serwisowych niektórych użytkowników, nawet podczas awarii.
• Sidecar instaluje przydatne składniki aplikacji jako odrębny pojemnik lub proces, aby umożliwić izolację i hermetyzację. Ten wzorzec może również umożliwić składanie aplikacji z różnych komponentów i technologii. Ten wzór nazywa się Sidecar, ponieważ przypomina przyczepę boczną przyczepioną do motocykla. W projekcie wózek boczny jest połączony z aplikacją nadrzędną i oferuje funkcje pomocnicze dla aplikacji. Podobnie, sidecar podąża za tym samym czasem życia, co aplikacja nadrzędna, jest budowany i kończony wraz z rodzicem. Wzór wózka bocznego jest często określany jako wzór pomocnika i jest ostatnim wzorem dekompozycji, który pokazujemy w poście.
• Strangler Fig wspiera stopniową refaktoryzację aplikacji poprzez stopniowe zastępowanie określonych elementów funkcjonalności nowymi usługami.

b) Wzorce integracji

1. Połączony wzorzec mikroserwisu

Będzie kilka zależności dla pojedynczych usług lub mikrousług, na przykład sprzedaż mikrousługi zależy od produktów mikrousług i zamówienia. Połączony wzorzec projektowy mikrousług pomoże Ci w zapewnieniu skonsolidowanej odpowiedzi na Twoje żądanie. Mikrousługa-1 odbiera żądanie, a następnie komunikuje się z mikrousługą-2; może również komunikować się z mikroserwisem-3. Wszystkie te wywołania usług są synchroniczne.

2. Wzorzec agregatora

Przy dzieleniu działalności biznesowej na wiele mniejszych logicznych fragmentów kodu, istotne staje się rozważenie, w jaki sposób dane podane przez każdą usługę zostaną scalone. Klient nie może zostać za to pociągnięty do odpowiedzialności.

Wzorzec Agregator pomaga w rozwiązaniu tego problemu. Opisuje, w jaki sposób możemy połączyć dane z kilku źródeł, a następnie dać końcowy wynik użytkownikowi. Jest to możliwe na dwa sposoby:

• Złożona mikrousługa będzie wywoływać wszystkie niezbędne mikrousługi, agregować i zmieniać dane, a następnie zwracać je.
• Oprócz partycjonowania żądania na kilka mikrousług, brama interfejsu API może również agregować dane przed przekazaniem ich konsumentowi.

3. Wzór proxy

Po prostu oferujemy Mikroserwisy przez bramę API. Zezwalam GW na nabycie cech API, takich jak bezpieczeństwo i klasyfikowanie API. W tym przypadku brama API składa się z trzech modułów API:

• Mobile API, który implementuje API dla klienta mobilnego FTGO
• Browser API, który implementuje API do aplikacji JavaScript działającej w przeglądarce
• Public API, który implementuje API dla zewnętrznych programistów

4. Wzór gałęzi

Możliwe, że mikrousługa będzie musiała uzyskać niezbędne dane z różnych źródeł, w tym z innych mikrousług. Wzorzec mikrousługi oddziału jest hybrydą wzorców projektowych Agregator i Chain. Umożliwia jednoczesne przetwarzanie żądań/odpowiedzi z co najmniej dwóch mikrousług i łączy zalety obu. Wywoływana mikrousługa może składać się z kilku innych mikrousług. Wzorzec Brach może być również wykorzystany do przywołania pojedynczego łańcucha mikroserwisów lub kilku łańcuchów tego samego rodzaju, w zależności od wymagań Twojej firmy.

Korzyści z architektury mikroserwisów

W dającej się przewidzieć przyszłości zapotrzebowanie na mikroserwisy gwałtownie wzrośnie. Za pomocą mikroserwisów aktualizowane są starsze programy. Dzięki refaktoryzacji aplikacje monolityczne można podzielić na mikrousługi. Prowadzi to do stopniowej modernizacji przestarzałego oprogramowania i jest lepsze niż przebudowa produktu od podstaw przy użyciu mikroserwisów. Tworzenie aplikacji może znacznie skorzystać z projektu mikrousług. Poniżej wymieniono niektóre z jego głównych zalet:

a. Doskonała produktywność

Łatwiej jest tworzyć i utrzymywać aplikację, jeśli jest ona podzielona na mniejsze, samowystarczalne sekcje. W zależności od wymagań, każda usługa może być niezależnie rozwijana, wdrażana i utrzymywana przy użyciu wielu języków programowania, technologii i środowisk oprogramowania. Ponieważ każdy modułowy składnik aplikacji ma mniejszą bazę kodu, łatwiej jest wydać, skalować, wdrażać i testować wiele usług, a powiązane zadania mogą być dzielone między zespoły programistyczne i wykonywane jednocześnie.

b. Lepsza odporność

Każda mikrousługa w architekturze mikrousług jest pojedynczą usługą zaprojektowaną do obsługi funkcji aplikacji i wykonywania odrębnych zadań. Każda mikrousługa łączy się z innymi usługami za pomocą prostych interfejsów do obsługi problemów biznesowych. Po ustanowieniu projektu opartego na mikrousługach cały proces wykrywania i rozwiązywania problemów związanych z wydajnością staje się raczej prosty.

Co więcej, ponieważ ta forma konstrukcji zapewnia ulepszony mechanizm izolacji uszkodzeń w porównaniu z pojedynczymi modułami, większe aplikacje są często niewrażliwe na pojedynczą awarię. Dlatego w dłuższej perspektywie ryzyko przyszłych przestojów jest znacznie zmniejszone, ponieważ programiści mają czas na wydanie aktualizacji lub wymianę modułu bez konieczności ponownego uruchamiania całego programu.

c. Rozszerzona skalowalność

Zespoły DevOps mogą wybrać optymalny stos technologii dla każdego modułu, nie martwiąc się o niezgodność, jeśli każda usługa jest tworzona przy użyciu innego języka programowania lub technologii. Poszczególne usługi mogą być rozwijane niezależnie, a nowe komponenty mogą być dodawane bez przestojów systemu lub ponownego wdrażania. Dodatkowo usługi mogą być rozdzielone na wiele serwerów, łagodząc wpływ na wydajność bardzo wymagających komponentów. W ciągu kilku sekund mikrousługi mogą dostarczyć skalowanie poziome.

W rzeczywistości to wysokie skalowanie horyzontalne zmusza organizacje takie jak Netflix, Spotify, Uber i Google do przejścia z architektury monolitycznej na architekturę mikroserwisową. Po drugie, jeśli jedna mikrousługa obciąża procesor, może być napisana w języku programowania zoptymalizowanym pod kątem procesora (C/C++, Rust), podczas gdy inne mikrousługi mogą być napisane w języku interpretowanym (Java, PHP).

d. Ciągła integracja / ciągłe dostarczanie (CI/CD)

Ciągłe dostarczanie i integracja to fundamentalne elementy zarówno metodyki Agile, jak i filozofii DevOps. Projekt mikrousług umożliwia zespołowi wielofunkcyjnemu niezależne tworzenie, debugowanie, testowanie, wdrażanie i aktualizowanie usług, co w dłuższej perspektywie spowoduje szybsze rozwiązywanie problemów i wdrażanie.

mi. Modularyzacja

W architekturze mikrousług bariera między mikrousługami składa się z trudnych do przekroczenia fizycznych (sieciowych) interfejsów. W związku z tym dobrze zaprojektowane mikrousługi zazwyczaj zapewniają „luźno połączoną, wysoce spójną” modularyzację. Jeśli rozwój oprogramowania jest porównywany do społeczeństwa, to modulacja mikrousług jest porównywalna z prawem krajowym i międzynarodowym z policją/karami. Jak już wiemy, rygorystyczne przepisy krajowe i międzynarodowe często mogą utrzymać porządek społeczny.

f. Harmonogram wydań

Najmilszym aspektem architektury mikrousług jest to, że każdy mikrousługa może być wdrażana indywidualnie. As a result, the Software Release Cycle for Microservice Applications is substantially shorter, and with CI/CD, many releases may be made each day.

Disadvantages of Microservices Architecture

a. Increased Complexity of Communication Between the Services

When an application is broken up into smaller parts, it takes more time to send and receive messages. When handling requests between the different modules, developers have to be extra careful. Different systems might talk to each other in different ways, so there might be a need for an interpreter. This can make it harder to set up the whole system all at once. One of the biggest problems with microservices is that it might be hard to switch from a monolith to microservices because it's hard to manage.

This basically means that a lot of services made by a lot of different teams are deployed in a lot of different places, making it very hard to manage them. For example, Monolithic Architecture gives the same answer whether a Web app has a few thousand lines of code or several million lines of code (Enterprise Java or Ruby on Rails or PHP). But in Microservice Architecture, there are many possible solutions depending on the applications and use cases.

So, Microservice Architecture is doomed to fail if the wrong solution is used for the wrong application size or type (like putting a child's clothes on an adult man or the other way around). Also, it's hard to design Microservices because they have a lot more moving parts than Monoliths. Most of the time, a Microservice with bad design is worse than a Monolith.

b. Complex Configuration

Despite being isolated and self-contained, a microservice must be regularly configured, especially when it is moved from development to test to staging to production. This arrangement may be rather intricate. Moreover, if a microservice must utilize other microservices, these bindings must be defined before deployment or even during runtime.

c. Context Boundary Translation

Despite the fact that it would be ideal if all microservices within a MOA used the same data structures and communication protocols to interact with one another, this is typically not the case.

d. More Assets in Return for More Autonomy

MOAs demand a great deal of horsepower. Remember that each MOA microservice has its own runtime environment and data storage. In some instances, even the most streamlined microservice might consume the same amount of resources as a single monolithic program.

mi. Unfeasible for Small Applications

Larger applications can benefit from microservices design. However, implementation will likely be more time-consuming and difficult for smaller applications.

f. Relatively Complex Deployment

The deployment might be a difficult and complicated process. During deployment, coordination between numerous services would be required. Deploying a WAR file in a container would not be as straightforward as it sounds.

g. Distributed Debugging

The difficulty of troubleshooting a MOA including hundreds of microservices communicating in concert is one of the downsides of microservices. Tracing the course of a request into and out of a MOA is challenging due to the independence of each container. The MOA is opaque if there is no effective monitoring mechanism in place. Logging the internals of a MOA offers a limited perspective, but MOA monitoring requires a comprehensive view.

h. Contributes to Enhanced Fault Tolerance

Large applications with several services deployed have more fault tolerance in the event that any one module fails. Microservices allow applications to continue functioning even if one service fails. This is because the services are not tightly coupled.

i. Costly

An improper service partition might be expensive. For instance, if an application is improperly partitioned, the services are connected to a certain degree, and they will create numerous inter-service interactions via the network, which can degrade performance.

j. Greater Security Risks

Lastly, because microservices will reside across several environments, computers, and API requests, they provide a greater number of entry points for an attacker to compromise the system.

k. Communication Complexities

Microservices accomplish rigorous modularity and development independence via process/network barriers, as previously mentioned. The disadvantage is that services may only communicate over the physical network, resulting in increased network latency. Microservices may connect with one another in a variety of methods, including synchronous communication using REST, gRPC, and asynchronous communication using Message Queue and Message Broker, each of which has advantages and disadvantages.

Synchronous communication is simpler to build, but it might result in a Distributed Monolith. Asynchronous Communication via Messaging provides greater flexibility at the expense of increased implementation complexity. In Microservice Architecture, choosing the appropriate Communication channel based on the application is equally tough.

l. Złożona konfiguracja

Mimo że mikrousługa jest izolowana i samodzielna, należy ją regularnie konfigurować, zwłaszcza gdy jest przenoszona z etapu projektowania do testowania i przemieszczania do środowiska produkcyjnego. Ten układ może być dość skomplikowany. Co więcej, jeśli mikrousługa musi korzystać z innych mikrousług, te powiązania muszą zostać zdefiniowane przed wdrożeniem lub nawet w czasie wykonywania.

Narzędzia mikroserwisowe

1. System operacyjny

Najważniejszym aspektem tworzenia aplikacji jest stworzenie dla niej solidnych podstaw, za co odpowiada system operacyjny. Linux jest przykładem tego typu systemu operacyjnego, który jest często wykorzystywany w procesie tworzenia aplikacji. W przypadku korzystania z kontenerów systemu Linux będziesz mieć dostęp do samodzielnego środowiska wykonawczego. Daje to możliwość zorganizowania szerokiej gamy usług, od przechowywania i sieci po bezpieczeństwo i uwierzytelnianie.

2. Języki programowania

Dzięki Emizentech możesz teraz bezproblemowo poszerzyć swój repertuar programistyczny. Ten instrument jest zarówno praktyczny, jak i aktualny. Ogólnie jest przeznaczony do użytku ze wszystkimi językami programowania. Dodatkowo jest kompatybilny z kodem bajtowym wyświetlanym na BEAM, który jest również określany jako maszyna wirtualna Erlanga.

3. Narzędzia do zarządzania i testowania API (bramki API)

Budowanie i publikowanie API, egzekwowanie ich standardów użytkowania, ograniczanie dostępu, kultywowanie społeczności deweloperów, zbieranie i analizowanie statystyk użytkowania oraz raportowanie wydajności to elementy administracji API.

W rzeczywistości platforma zarządzania API składa się z następujących elementów:

• Narzędzia deweloperskie
• Wejście
• Raportowanie i analityka

4. Narzędzia do przesyłania wiadomości (przesyłanie wiadomości i strumieniowanie zdarzeń)

Aby komunikacja mogła mieć miejsce, system mikroserwisowy musi korzystać z niezależnych usług. Jest to główny czynnik, który określa, czego kolejka wiadomości wymaga od swoich użytkowników. RabbitMQ i Apache Kafka to dwa najpopularniejsze rozwiązania wykorzystywane do komunikacji.

LinkedIn jest odpowiedzialny za stworzenie technologii znanej jako Apache Kafka, która później została wniesiona do społeczności Apache.

Wzorce są wykorzystywane przez narzędzie RabbitMQ w celu ułatwienia komunikacji między wieloma mikrousługami. Dodatkowo wspomaga proces jednoczesnego skalowania aplikacji.

5. Zestawy narzędzi

Mówiąc prościej, zestaw narzędzi to po prostu zbiór narzędzi używanych podczas wykonywania określonej procedury. Toolkit to składnik architektury mikroserwisów, który umożliwia konstruowanie wielu aplikacji. Z tego powodu istnieje wiele różnych zestawów narzędzi, z których każdy służy innym celom w jego zastosowaniu. Wiele narzędzi dostępnych do wyboru w Fabric8 i Seneca.

• Fabric8 to technologia platformy jako usługi, która z pomocą Git umożliwia twórcom oprogramowania tworzenie systemu zarządzania konfiguracją dla ich aplikacji.
• Seneca, działająca jako Node, jest wykorzystywana w procesie tworzenia mikroserwisów zorientowanych na wiadomości.

6. Ramy architektoniczne i zestaw narzędzi Js

Ponieważ mikrousługi są stylem architektonicznym, należy zwrócić uwagę na ramy architektoniczne, z których korzystają. Są to frameworki, które są wykorzystywane w połączeniu z obecnymi technologiami w celu konstruowania najnowszych aplikacji. Goa i Kong to obecnie najpopularniejsze ramy architektoniczne.

7. Narzędzia do orkiestracji

Ze względu na ogólny sposób, w jaki kontenery i mikrousługi działają razem, aranżacja kontenerów jest bardzo ważnym tematem do przemyślenia. Conductor, Kubernetes i Istio to trzy rozwiązania do aranżacji mikrousług, które są najczęściej używane do aranżacji kontenerów. Dostępnych jest jednak wiele innych narzędzi. Jako część ekosystemu oprogramowania open source (OSS) obsługiwanego przez Netflix, dyrygent służy jako silnik orkiestracji mikrousług. Dyrygent to program, który działa w chmurze i używa implementacji zwanej orkiestratorem przepływu do wykonywania różnych czynności przy użyciu mikrousług. Oprócz tego ułatwia zarządzanie i wyświetlanie wszystkich interakcji zachodzących w mikrousługach.

8. Narzędzia do monitorowania

Po zbudowaniu aplikacji mikroserwisowej zadania z nią związane muszą zostać obsłużone. Aby osiągnąć to samo, będziesz potrzebować narzędzi do monitorowania mikrousług. Prometheus i Log Stash to dwie najczęściej wykorzystywane technologie monitorowania mikrousług. Logstash to doskonałe oprogramowanie. Jest to platforma, która pozwala konsolidować, przechowywać i manipulować danymi, i jest open source.

9. Narzędzia bezserwerowe

SA Istotnym składnikiem mikrousług jest technologia bezserwerowa, często znana jako funkcja jako usługa. Poprawia efektywność procesu demontażu obiektów na najbardziej podstawowe elementy. Zarówno Claudia, jak i AWS Lambda to przykłady narzędzi bezserwerowych, które są szeroko stosowane do tworzenia mikrousług. Instalacje AWS Lambda i API Gateway są również częścią obowiązków Claudii. Oprócz tego Claudia jest w stanie zautomatyzować podatne na błędy działania związane z wdrażaniem i konfiguracją, zachowując jednocześnie funkcjonalność „po wyjęciu z pudełka”.

10. Kontenery, Docker i Kubernetes

• Kontenery: Kontenery zasadniczo wirtualizują system operacyjny hosta (lub jądro), izolując potrzeby aplikacji od potrzeb innych kontenerów działających na tym samym komputerze.
• Docker: Docker składa się z kilku różnych części, w tym środowiska uruchomieniowego kontenera zwanego dockerd, narzędzia do tworzenia obrazów kontenera znanego jako BuildKit oraz interfejsu wiersza poleceń używanego do interakcji z programem do tworzenia, kontenerami i silnikiem (tzw. docker).
• Kubernetes to bezpłatna technologia zarządzania kontenerami typu open source, która łączy grupę komputerów w jedną pulę zasobów obliczeniowych. Kubernetes został opracowany przez Google. Kubernetes umożliwia strukturyzację aplikacji w postaci grup kontenerów, które są następnie wykonywane przez silnik Dockera. Kubernetes dba o to, aby Twoja aplikacja nadal działała w określony przez Ciebie sposób.

Wspólne wzorce w architekturze mikroserwisów

a. Wzorzec backend-for-frontend (BFF)

BFF zapewnia prosty interfejs między frontendem a mikroserwisami. W idealnym scenariuszu zespół front-endowy będzie również odpowiedzialny za zarządzanie BFF. Pojedynczy BFF dotyczy wyłącznie jednego interfejsu użytkownika. W konsekwencji będziemy mogli uprościć nasze frontendy i mieć jeden widok danych za pośrednictwem jego backendu.

b. Wzorce encji i agregatów

Istota to odrębna rzecz oparta na swojej tożsamości. Na przykład w witrynie e-commerce obiekt Produktu można zidentyfikować na podstawie nazwy, typu i ceny produktu. Agregat to grupa rzeczy, które należy traktować jako pojedynczą jednostkę. Dlatego w przypadku witryny e-commerce Zamówienie będzie zbiorem (zagregowaniem) rzeczy (podmiotów), które klient kupił. Te wzorce służą do sensownej kategoryzacji danych.

c. Wzorce wykrywania usług

Odgrywają kluczową rolę w ułatwianiu odkrywania usług i aplikacji. Wystąpienia usług mogą się różnić w kontekście architektury mikrousług ze względu na przyczyny, takie jak awaria usługi, skalowalność, zakończenie usługi i uaktualnienia. Te wzorce dają narzędzia do odkrywania, aby poradzić sobie z tym przemijaniem. Wykorzystując kontrole kondycji i awarie usług jako wyzwalacze równoważenia ruchu, równoważenie obciążenia może wykorzystywać techniki wykrywania usług.

d. Wzorce mikrousług adaptera

W razie potrzeby projekt Adapter Microservices dostosowuje się między zorientowanym na biznes interfejsem API zbudowanym przy użyciu technik przesyłania komunikatów zgodnych z REST lub uproszczonych — przy użyciu tych samych metodologii opartych na domenie, co typowa mikrousługa — a starszym interfejsem API lub klasyczną usługą SOAP opartą na WS-*. Adaptacja jest wymagana na przykład wtedy, gdy zespołowi programistycznemu brakuje zdecentralizowanej kontroli nad źródłem danych aplikacji.

mi. Wzór aplikacji dusiciela

Wzorzec Strangler to dobrze znany wzorzec architektoniczny służący do powolnego przekształcania aplikacji monolitycznej w mikrousługi przez zastąpienie określonej funkcjonalności nową usługą.

Antywzorce w architekturze mikroserwisów

a. Spójność Chaosu

Usługi muszą wyraźnie odpowiadać możliwościom biznesowym i nie powinny próbować osiągać niczego poza ich zakresem. Funkcjonalne rozdzielenie problemów ma kluczowe znaczenie dla zarządzania architekturą; w przeciwnym razie zrujnowałoby to zwinność, wydajność i skalowalność, skutkując ściśle połączoną architekturą z entropią dostarczania i chaosem spójności.

b. Architektura usług warstwowych

Jednym z najczęstszych błędów SOA było niezrozumienie, jak osiągnąć możliwość ponownego wykorzystania usług. Zespoły w dużej mierze zajmowały się spójnością techniczną, a nie funkcjonalnym ponownym wykorzystaniem.

c. Złożoność

Kolejnym ważnym czynnikiem wsparcia architektury mikroserwisów jest dojrzałość organizacyjna. Zespoły programistyczne muszą zostać zreformowane, aby przejąć większą odpowiedzialność za cały stos, DevOps, zamiast po prostu przesyłać bilety w jedną stronę do zespołu ds. infrastruktury.

d. Słaba strategia wersjonowania

Nieefektywna strategia wersjonowania skutkuje niemożliwym do zarządzania kodem i zależnościami. W rezultacie powinno istnieć wydajne podejście do obsługi wersji dla architektury mikrousług. Jednym z najbardziej podstawowych podejść jest utworzenie wersji interfejsu API i uwzględnienie tej wersji w adresie URL trasy.

mi. Niewłaściwy projekt wzorców dostępu do danych obciążenia mikrousługami

Niewłaściwe wzorce dostępu do danych obciążenia mikrousługami: Architektura mikrousługi zależy od bazy danych organizacji. Wzorce dostępu do danych w mikrousługach powinny być wyraźnie oddzielone. Często dopuszczalne jest korzystanie z jednej bazy danych w kilku wystąpieniach usług, o ile dane znajdują się w odpowiednio podzielonych na partycje tabelach/kolekcjach.

f. Zaburzenie zależności

Zaburzenie zależności to anty-wzorzec, który rozwija się, gdy masz świadomość, że usługi muszą być wdrażane w określonej kolejności, aby działały prawidłowo. Gdy nie ma kontroli nad funkcjonalnym oddzieleniem obaw, może powstać chaos spójności.

Dobrym sposobem na uniknięcie tego antywzorca jest wprowadzenie bramy interfejsu API.

Różnice między architekturą monolityczną, mikroserwisową i zorientowaną na usługi

Kluczowe rynki pionowe wymagające mikrousług

Opieka zdrowotna: Przewiduje się, że rynek mikrousług opieki zdrowotnej wzrośnie ze 130 mln USD w 2015 r. do 519 mln USD do 2025 r. Potrzeby szybszego wdrażania usług, szybszej akceptacji nowatorskich technologii i lepszej wydajności napędzają rozwój w branży opieki zdrowotnej. Branża opieki zdrowotnej poszukuje odpowiedzi na swoje potrzeby w zakresie bezpieczeństwa danych i zgodności z przepisami, a także sposobów przezwyciężenia trudności wdrożeniowych.

Bankowość, finanse i ubezpieczenia: Aspen Mesh identyfikuje trzy ważne zalety mikrousług dla usług finansowych: zwiększone bezpieczeństwo dzięki utworzeniu odrębnej usługi tożsamości, szybsze dostarczanie nowych funkcji i łatwiejsza w zarządzaniu warstwa interfejsu API.

Instytucje rządowe: Oprócz różnych korzyści płynących z architektury mikrousług, firmy rządowe mogą czerpać korzyści z jej zdolności do projektowania funkcjonalności, które odpowiadają celom biznesowym, umożliwiając zespołom IT tworzenie lub ulepszanie usług w zależności od potrzeb użytkowników.

Handel detaliczny: Amazon i eBay udowodniły korzyści płynące z mikrousług dla branży detalicznej, w tym wysoce dostępne i skalowalne usługi oraz bardziej efektywne zarządzanie błędami i błędami.

Media i rozrywka: w 2009 r. Netflix przeszedł na mikroserwisy, a obecnie usługa codziennie przetwarza 2 miliardy żądań brzegowych, korzystając z ponad 500 mikroserwisów. Zmiana zapewnia szybkość, skalowalność i dostępność.

Przykłady firm, które przyjęły architekturę mikroserwisów

Amazon, Coca-Cola i Zalando m.in. zmieniają swoją infrastrukturę IT na architekturę mikroserwisową. Ponadto reorganizują swoje wewnętrzne struktury organizacyjne i wypychają swoje przedsiębiorstwa do czołówki rynku. Wdrażanie architektury mikrousług jest przyjemne, gdy zdobywasz wiedzę od najlepszych w branży. Oto niektóre z najskuteczniejszych wystąpień mikroserwisów.

#1. Uber

Koncepcja własności została zdewastowana przez splecione ze sobą monolityczne zależności. Migracja stała się wyzwaniem. Nowi deweloperzy nie byli w stanie wnieść wkładu do monolitu. Małe błędy doprowadziły do ​​katastrofalnych rezultatów. Uber zdecydował się na wdrożenie usług w chmurze. Uber opracował mikrousługi dla kilku operacji, w tym fakturowania oraz zarządzania pasażerami i podróżami. Bramy API służą do komunikacji z usługami.

Dodatkowo Uber ustanowił światowe standardy dla swoich mikrousług. Zapewniają ilościowe kryteria dotyczące dokumentacji, niezawodności, odporności na awarie i tak dalej. Te cechy były monitorowane za pomocą wskaźników komercyjnych, takich jak wizyty na stronie. Wkrótce ich usługi osiągnęły szczyt doskonałości.

#2. Netflix

Następnie Netflix przeszedł na opartą na chmurze infrastrukturę danych rozproszonych. AWS został wykorzystany do dostarczania skalowalnych horyzontalnie systemów i dodatkowych usług/funkcji. W 2009 roku Netflix rozpoczął transfer, który zakończył się po prawie trzech latach. Następnie Netflix przekształcił wszystkie swoje aplikacje skierowane do użytkowników w autonomiczne mikroserwisy. W 2012 roku zakończono metamorfozę. Do 2015 roku Netflix wyeliminował wszystkie przerwy w działaniu usług i był w stanie przetwarzać około 2 miliardy zapytań API dziennie. Obecnie Netflix ma ponad 139 milionów użytkowników w 190 krajach. Obecnie Netflix obsługuje osobno około 700 systemów mikroserwisów.

#3. Amazonka

Amazon miał duży monolit w 2001 roku. W 2021 roku praktycznie każdy zna Amazon Web Services (AWS) — wewnętrzne rozwiązanie, które ze względu na swoją wyższość stało się komercyjną usługą chmury obliczeniowej. Mikroserwisy doskonale nadają się do handlu elektronicznego, ponieważ mogą śledzić aktywność użytkowników, zakupy i pełny lejek sprzedaży. Według starszego menedżera produktu w Amazon

Następnie generują dane przydatne do optymalizacji prezentacji produktów i samego procesu sprzedaży. Amazon jest jedną z pierwszych firm, w których mikroserwisy odegrały znaczącą rolę w zmianie całej organizacji. Światowy behemot odniósł niesamowity sukces w czasach, gdy projektowanie monolitów było „normą” w konstruowaniu systemów informatycznych.

Wszystkie istotne modyfikacje kodu zostały wstrzymane w procesie wdrażania na tygodnie, zanim zostały udostępnione użytkownikom. Amazon zastosował mikrousługi, aby usprawnić i skrócić czas trwania procesu. Rozdzielając struktury na poszczególne aplikacje, programiści byli w stanie określić, gdzie znajdują się wąskie gardła, charakter spowolnień i odbudować struktury jako architektury zorientowane na usługi, każda z małym zespołem zajmującym się pojedynczą usługą.

To, co zaczęło się jako czyszczenie systemu, zaowocowało wzrostem jednego z głównych graczy online we współczesnej architekturze. Amazon był pionierem na drodze dla innych firm, wypuszczając szereg technologii open-source, takich jak AWS (Amazon Web Services), które są teraz wszechobecne.

#4. eBay

System eBay obsługuje około tysiąca mikroserwisów. Środowiska front-end, takie jak aplikacje internetowe i natywne dla systemów iOS i Android, kontaktują się z usługami pośredniczącymi, które koordynują połączenia, które następnie komunikują się z usługami zaplecza. Każda z usług ma własną autonomiczną grupę rozwojową. Większość mikroserwisów eBaya ewoluowała bez architekta, a system zawsze był projektowany od podstaw. Większość dużych firm, takich jak eBay, wylądowała na zbiorze mikrousług wielojęzycznych, które działają zgodnie z wymaganiami klientów i oczywiście ciągle się zmieniają.

#5. SoundCloud

Każda usługa jest niezależnie rozwijana i wdrażana, łącząc się z innymi usługami za pośrednictwem sieci przy użyciu lekkich standardów wymiany danych, takich jak JSON lub Thrift. Przez cały czas trwania zmiany nowe mikroserwisy nie były w stanie zmienić modelu relacyjnego w MySQL ani, co gorsza, wykorzystać innego silnika pamięci masowej. W ekstremalnych sytuacjach, takich jak komunikacja między użytkownikami, w których model oparty na wątkach został zastąpiony modelem podobnym do czatu, firma używała zadań cronjob do synchronizacji oddzielnych baz danych.

#6. Spotify

Aby zapobiec piekłu synchronizacji wewnątrz firmy, Spotify został zaprojektowany w oparciu o architekturę mikroserwisową z autonomicznymi zespołami z pełnymi stosami. Spotify wykorzystuje architekturę mikroserwisów, w której każdy programista pisze na zamkniętych „terytoriach” z własnymi unikalnymi możliwościami. Każda mikrousługa ma jedną, bezpośrednią odpowiedzialność i, w większości przypadków, bazę danych i logikę, do których nie ma dostępu inny proces.

Jakie wyzwania mogą Ci pomóc mikroserwisy?

To jest odpowiedź na pytanie „jakie trudności rozwiązują mikroserwisy?”; przyjrzyjmy się przeszkodom, które architektury mikrousług pomogły pokonać.

PRZYPADEK 1 Saldo eBay odzyskane

eBay korzysta z prawie tysiąca usług. Wiele usług frontonu wysyła wywołania interfejsu API, podczas gdy usługi zaplecza wykonują operacje administracyjne i związane z wysyłką. eBay pierwotnie wykorzystywał monolityczny program Perl i C++. Witryna eBay jest podstawowym produktem, podobnie jak wielu innych internetowych tytanów. Wciąż rosła potrzeba dodawania kilku dodatkowych funkcji do witryny eBay. Ponadto tego typu strona internetowa musiała być dostępna 24 godziny na dobę, siedem dni w tygodniu, nawet w miarę dodawania nowych funkcji.

Ze względu na potrzebę minimalizacji przestojów eBay zdecydował się przejść na architekturę mikroserwisów. Dzięki temu witryna stała się bardziej stabilna i promowała integrację asynchroniczną. Dokonano znaczących ulepszeń w zakresie elastyczności wdrażania i czasu trwania cyklu wydania. Gdy usługi były izolowane, wydajność wzrosła, a skalowanie stało się łatwiejsze.

PRZYPADEK 2 Uber i szybka ekspansja

Uber, najpopularniejsza usługa wezwania taksówek, rozpoczęła się od jednego pakietu obsługującego osoby dojeżdżające do pracy w San Francisco, gdzie została początkowo wdrożona. To ściśle powiązane oprogramowanie było w stanie zarządzać większością, jeśli nie wszystkimi działaniami biznesowymi, w tym rozliczeniami, płatnościami i usługami łączenia kierowców. Jednak wraz z rozwojem firmy sytuacja zaczęła się pogarszać. Uber rozszerzał swój zasięg i oferował inne usługi.

W miarę dodawania kolejnych funkcji pakiet stawał się coraz bardziej spójny. Cała logika znajdowała się w jednym miejscu i zaczęły się pojawiać trudności. Wkrótce nawet niewielka modyfikacja wymagała ponownego wdrożenia całego programu. Ciągła integracja niemal natychmiast staje się poważnym obciążeniem.

Brak modelu własności wynikał z wielu współzależnych zależności monolitu. Dlatego migracja była trudna. Zdarzało się również, że nowo zatrudnieni deweloperzy nie byli w stanie wnieść wkładu do monolitu. Nawet jeśli wystąpił drobny błąd, konsekwencje były dotkliwe. To wtedy podjęli decyzję o wdrożeniu mikroserwisów. Ich ruch zajął trochę czasu. Rozmontowali całą usługę i przeprowadzili migrację monolitycznej aplikacji do architektury zorientowanej na mikrousługi zbudowanej przy użyciu Pythona, Node.js i Apache Thrift.

CASE 3 Ulepszony czas działania Twittera

To była ta sama stara historia: Twitter po raz pierwszy wykorzystał monolityczny projekt, co miało wiele sensu. Jednak gdy więcej osób zarejestrowało się na Twitterze, pojawiły się problemy. SDLC stawało się większe i bardziej nieporęczne, z dłuższymi czasami kompilacji, a jego skalowalność znacznie się pogorszyła, z okazjonalnymi ostrzeżeniami o błędach związanych z nadmiarem pojemności.

Aby rozwiązać ten problem, Twitter uciekł się do zmiany architektury na mikroserwisy. Każda mikrousługa została stworzona jako modułowa, dobrze zdefiniowana i autonomiczna. Mogą indywidualnie testować i wdrażać każdy komponent. Mogą być również mierzone niezależnie. Wkrótce ostrzeżenia o błędach całkowicie zniknęły.

PRZYPADEK 4 KarmaWifi i kod spaghetti

Na Karmie są ludzie, gadżety i sklep. W pewnym momencie, gdy dostępny był monolityczny program, kod związany z użytkownikiem znalazł się w częściach związanych z urządzeniem. Ponadto interfejsy API sklepu podążały za interfejsami API urządzeń. Wkrótce trudno było ustalić, co się zmieniło i kto to zmienił. Chociaż początkowym celem było podzielenie monolitu na funkcjonalne biblioteki, okazało się, że rozbudowa i adaptacja do nowszych wersji oprogramowania będzie wyzwaniem. Ponadto nie byliby w stanie eksperymentować z przyszłymi innowacjami, które będą wprowadzane na rynek.

Do tego czasu zdecydowali się na architekturę opartą na mikroserwisach. Kiedy uznali to za niezbędne, rozdzielili części aplikacji zaplecza na poszczególne usługi. Części początkowo były ogromne, ale z czasem podzielono je na mniejsze serwisy. Ostatecznie każda mikrousługa miała jedno zadanie i maksymalny rozmiar, o który trzeba się martwić.

PRZYPADEK 5 Poprawiona wydajność Walmart

Przygoda Walmart z mikroserwisami rozpoczęła się od przejęcia platformy DevOps od małej firmy o nazwie OneOps. Zdecydowali się uczynić z niej inicjatywę typu open source, aby mogli wnieść swój wkład do społeczności.

Zaczęli wykorzystywać technologie, takie jak bazy danych Node.js i Cassandra, do tworzenia różnych mikrousług, które mogą być dynamicznie uruchamiane za pośrednictwem interfejsów API. Celem było ułatwienie programistom pracującym w wielu działach biznesowych Walmart posiadania własnych aplikacji i umożliwienie im tego. Odkryli, że zmniejsza to zależność od scentralizowanej grupy IT.

Ostatecznie zdolność programistów do rozszerzenia możliwości zaplecza oferty eCommerce organizacji przyczyniła się do zwiększenia elastyczności biznesowej.

Jak wdrożyć architekturę mikroserwisów na Androida i iOS?

1. Krok 1: Zdecyduj, czy naprawdę tego potrzebuje Twoja firma.
2. Krok 2: Jeśli tak, spójrz na istniejącą już infrastrukturę.
3. Krok 3: Przygotuj swój zespół do zastosowania tej metody.
4. Krok 4: Jeśli przechodzisz z systemu monolitycznego na system mikrousług, skontaktuj się z administratorem danych, aby sprawdzić, czy jest dobrze poinformowany i rozumie zadanie.
5. Krok 5: Wybierz język i strukturę kodowania.
6. Krok 6: Skonfiguruj podstawową architekturę z usługami, kontenerami i szablonami maszyn wirtualnych.
7. Krok 7: Podziel bazę danych na wiele mniejszych baz danych, jeśli Twoja architektura jest „monolitem”.
8. Krok 8: Umieść bramy API na swoim miejscu.
9. Krok 9: Śledź śledzenie i stwórz jego mapę.
10. Krok 10: Testuj za pomocą automatyzacji.

Czy mikroserwisy to przyszłość?

Głównym celem tego artykułu jest wyjaśnienie podstawowych pojęć i zasad mikrousług. Podejmując wysiłek, aby to osiągnąć, oczywiste jest, że uważamy styl architektoniczny mikrousług za podstawową koncepcję – taką, którą aplikacje korporacyjne powinny dokładnie przeanalizować. Ostatnio opracowaliśmy wiele systemów wykorzystujących ten sposób i znamy innych, którzy doceniają tę metodę. Amazon, Netflix, The Guardian, brytyjski rząd Digital Service, realestate.com.au, Forward i Comparethemarket.com to jedne z tych, o których wiemy, że są pionierami stylu architektonicznego w jakiejś formie.

Często faktyczne konsekwencje decyzji architektonicznych są widoczne dopiero kilka lat później. Dobry zespół z silnym dążeniem do modułowości czasami skonstruował monolityczną konstrukcję, która z czasem uległa pogorszeniu. Wiele osób twierdzi, że takie pogorszenie jest mniej możliwe w przypadku mikrousług, ponieważ granice usług są oczywiste i trudne do naprawienia. Nie możemy jednak dokładnie ocenić dojrzałości architektur mikrousług, dopóki nie będziemy mieć wystarczającej liczby systemów w odpowiednim wieku.

Zdecydowanie istnieją powody, by przewidywać powolny rozwój mikroserwisów. Powodzenie każdego przedsięwzięcia dotyczącego komponentyzacji zależy od tego, jak dobrze oprogramowanie pasuje do komponentów. Trudno jest określić, gdzie należy umieścić granice elementów. Projekt ewolucyjny dostrzega trudność w ustaleniu prawidłowych granic, a tym samym znaczenie ułatwienia ich przepracowania. Jednak gdy komponenty są usługami z komunikacją zewnętrzną, refaktoryzacja jest znacznie trudniejsza niż w przypadku pracy z bibliotekami w procesie.

Przenoszenie kodu poza granice usług jest skomplikowane, wszelkie modyfikacje interfejsu muszą być zaaranżowane między uczestnikami, muszą zostać ustanowione dodatkowe warstwy kompatybilności, a testowanie jest skomplikowane. Jeśli komponenty nie komponują się ładnie, po prostu przenosisz złożoność z wnętrza komponentu na połączenia między komponentami. To nie tylko przesuwa złożoność, ale także przenosi ją do miejsca, które jest mniej wyraźne i trudniejsze do zarządzania. Przyglądając się wnętrzu niewielkiego, prostego elementu, łatwo przeoczyć skomplikowane powiązania między usługami i dojść do wniosku, że wszystko jest lepsze niż w rzeczywistości.

Wreszcie należy wziąć pod uwagę kompetencje zespołu. Umiejętne zespoły są bardziej skłonne do przyjęcia nowych praktyk. Podejście, które jest bardziej skuteczne w przypadku wysoko wykwalifikowanych zespołów, może jednak nie zawsze działać w przypadku mniej wykwalifikowanych zespołów. Widzieliśmy kilka przykładów niekompetentnych zespołów konstruujących niechlujne monolityczne struktury, ale zajmie trochę czasu, aby ustalić, co się stanie, gdy ten rodzaj chaosu wystąpi z mikrousługami. Kiepski zespół zawsze stworzy kiepski system; trudno powiedzieć, czy mikroserwisy poprawiają, czy pogarszają sytuację w tej sytuacji.

 Dlatego piszemy to z ostrożnym optymizmem. Wierzymy, że mikroserwisy nie znikną!

Dlaczego warto wybrać EmizenTech?

Emizentech może pomóc w migracji aplikacji z architektury monolitycznej do architektury mikrousług. Możemy pomóc Ci w uproszczeniu obsługi i skalowalności Twojej aplikacji korporacyjnej. Jeśli chcesz się rozwijać i rozwijać swój biznes i szukasz nowych sposobów, aby to zrobić, emizentech może Ci pomóc we właściwy sposób, jednocześnie zapewniając długoterminowy wzrost. Możesz również odwiedzić naszą stronę internetową, aby dowiedzieć się więcej o mikroserwisach, dowiedzieć się, czy Twoja firma jest na nie gotowa i porozmawiać o tym, jak wdrożyć tę architekturę. Jest to sposób tworzenia oprogramowania, który skupia się na rozbiciu aplikacji na moduły, które wykonują tylko jedną rzecz i mają dobrze zdefiniowane interfejsy.

Cechami wyróżniającymi nasze usługi są:

• Architektura oparta na domenie, która zapobiega awariom aplikacji
• Zapewnij wysoki stopień skalowalności
• Zdecentralizowany projekt bazy danych
• Włącz prostą izolację awarii i
• Włącz ciągłe dostarczanie przy użyciu kultury DevOps.

Myśli zamykające

Zrób następny krok!

W tym blogu podjęliśmy wysiłek zbadania kilku aspektów architektury mikroserwisów i możliwości, jakie oferuje. Funkcjonalność systemu aplikacji można podzielić na kilka mniejszych jednostek funkcjonalnych, korzystając z podejścia architektonicznego znanego jako mikrousługi. Wdrażanie i zarządzanie usługami są obsługiwane oddzielnie. Gdy systemy monolityczne są dzielone na mniejsze części przy użyciu architektury mikrousług, liczba poszczególnych komponentów dramatycznie rośnie.

Dlatego konieczne jest sprawne zarządzanie istniejącymi między nimi zależnościami. W porównaniu z monolityczną architekturą oprogramowania prawdą jest, że tworzenie i wykonywanie architektury mikrousług stanowi szereg wyzwań i wymaga zmiany paradygmatu. W podobnym duchu architektura mikroserwisowa nie jest w żaden sposób magicznym pociskiem, który może rozwiązać problemy złożoności, które pojawiają się we wszystkich rodzajach systemów.

Biorąc wszystko pod uwagę, uważamy, że architektura mikroserwisów jest niezwykle pomocnym i wygodnym narzędziem do współczesnego tworzenia oprogramowania. Architektura mikrousług jest jedyną realną strategią dla dużych przedsiębiorstw, które zazwyczaj generują skomplikowane oprogramowanie, ponieważ jest to jedyna metoda skutecznego radzenia sobie ze złożonością i utrzymania przewagi konkurencyjnej na rynku. Architektura mikroserwisowa powinna być wykorzystywana do zrównoważonego rozwoju oprogramowania, co może przynieść długoterminowe korzyści nie tylko dużym korporacjom, ale także małym i średnim firmom.

Należy zauważyć, że pierwsi użytkownicy architektury mikroserwisowej, tacy jak Spotify, Netflix, LinkedIn, Amazon i Google, byli w stanie uzyskać znaczną przewagę konkurencyjną nad rywalami dzięki przyjęciu architektury mikroserwisowej. Opracowanie i badanie modelu architektonicznego to realne opcje pomocy w tym przedsięwzięciu. Ta metoda obiecuje uproszczenie rzeczy i ułatwienie życia deweloperom bez negatywnego wpływu na wynik finansowy, co jest szczególnie ważne teraz, gdy firmy wchodzą w nowy okres ostrej konkurencji.

Zdecydowana większość firm jest zainteresowana zwiększeniem swojej efektywności kosztowej, a na tym tle oczekuje się, że architektura bezserwerowa zdobędzie większą popularność w ciągu najbliższych lat. Potencjalny zasięg mikroserwisów w przyszłości na świecie wydaje się być dość obiecujący.

Czy mikroserwisy mogą pomóc Twojej firmie rozwijać się? Zapraszamy do kontaktu na niezobowiązującą konsultację!

Dziękuje za przeczytanie!

Często zadawane pytania dotyczące architektury mikroserwisów