Architektura mikrousług - wprowadzenie
Mikrousługi to metodologia tworzenia aplikacji oparta na usługach. W tej metodologii duże aplikacje zostaną podzielone na najmniejsze niezależne jednostki usługowe. Mikrousługi to proces wdrażania architektury zorientowanej na usługi (SOA) polegający na podzieleniu całej aplikacji na zbiór połączonych ze sobą usług, gdzie każda usługa będzie służyć tylko jednej potrzebie biznesowej.
Koncepcja Going Micro
W architekturze zorientowanej na usługi całe pakiety oprogramowania zostaną podzielone na małe, wzajemnie połączone jednostki biznesowe. Każda z tych małych jednostek biznesowych będzie komunikować się ze sobą za pomocą różnych protokołów, aby zapewnić klientowi sukces biznesowy. Teraz pytanie brzmi, czym różni się architektura mikrousług (MSA) od architektury SOA? Jednym słowem, SOA to wzorzec projektowy, a Microservice to metodologia implementacji implementacji SOA lub możemy powiedzieć, że Microservice to typ SOA.
Poniżej znajduje się kilka zasad, o których musimy pamiętać podczas tworzenia aplikacji zorientowanej na mikrousługi.
Independent - Każda mikrousługa powinna być wdrażana niezależnie.
Coupling - Wszystkie mikrousługi powinny być luźno powiązane ze sobą, tak aby zmiany w jednej nie wpływały na inne.
Business Goal - Każda jednostka usługowa całej aplikacji powinna być najmniejsza i zdolna do realizacji jednego konkretnego celu biznesowego.
Rozważmy przykład portalu zakupów online, aby dogłębnie zrozumieć mikrousługę. Teraz podzielmy cały portal handlu elektronicznego na małe jednostki biznesowe, takie jak zarządzanie użytkownikami, zarządzanie zamówieniami, odprawa, zarządzanie płatnościami, zarządzanie dostawami itp. Jedno udane zamówienie musi przejść przez wszystkie te moduły w określonym czasie. rama. Poniżej przedstawiono skonsolidowany obraz różnych jednostek biznesowych powiązanych z jednym systemem handlu elektronicznego.
Każdy z tych modułów biznesowych powinien mieć własną logikę biznesową i interesariuszy. Komunikują się z oprogramowaniem innych dostawców dla określonych potrzeb, a także między sobą. Na przykład zarządzanie zamówieniami może komunikować się z zarządzaniem użytkownikami, aby uzyskać informacje o użytkowniku.
Biorąc pod uwagę, że prowadzisz portal zakupów online ze wszystkimi wspomnianymi wcześniej jednostkami biznesowymi, potrzebujesz aplikacji na poziomie przedsiębiorstwa składającej się z różnych warstw, takich jak front-end, back-end, baza danych itp. Jeśli Twoja aplikacja nie jest skalowana i całkowicie opracowany w jednym pliku wojennym, będzie nazywany typową monolityczną aplikacją. Według IBM, typowa aplikacja monolityczna powinna mieć wewnętrznie następującą strukturę modułową, w której tylko jeden punkt końcowy lub aplikacja będzie odpowiedzialna za obsługę wszystkich żądań użytkowników.
Na powyższym obrazku można zobaczyć różne moduły, takie jak Baza danych do przechowywania różnych użytkowników i danych biznesowych. Na froncie mamy inne urządzenie, na którym zwykle renderujemy dane użytkownika lub dane biznesowe. W środku mamy jeden pakiet, który może być plikiem EAR lub WAR, który można wdrożyć, który przyjmuje żądanie od użytkowników końcowych, przetwarza je za pomocą zasobów i przekazuje je z powrotem użytkownikom. Wszystko będzie dobrze, dopóki biznes nie zażąda zmian w powyższym przykładzie.
Rozważ następujące scenariusze, w których musisz zmienić aplikację zgodnie z potrzebami biznesowymi.
Jednostka biznesowa wymaga pewnych zmian w module „Wyszukiwanie”. Następnie musisz zmienić cały proces wyszukiwania i ponownie wdrożyć aplikację. W takim przypadku przerzucasz swoje pozostałe jednostki bez żadnych zmian.
Teraz znowu Twoja jednostka biznesowa potrzebuje pewnych zmian w module „Check out”, aby uwzględnić opcję „wallet”. Musisz teraz zmienić swój moduł „Wyewidencjonuj” i ponownie wdrożyć go na serwerze. Zwróć uwagę, że ponownie wdrażasz różne moduły pakietów oprogramowania, a my nie wprowadziliśmy w nich żadnych zmian. Oto koncepcja architektury zorientowanej na usługi, bardziej specyficzna dla architektury mikrousług. Możemy rozwijać naszą monolityczną aplikację w taki sposób, aby każdy moduł oprogramowania zachowywał się jak niezależna jednostka, zdolna do samodzielnej obsługi pojedynczego zadania biznesowego.
Rozważmy następujący przykład.
W powyższej architekturze nie tworzymy żadnego pliku usznego z kompaktową usługą end-to-end. Zamiast tego dzielimy różne części oprogramowania, udostępniając je jako usługę. Każda część oprogramowania może łatwo komunikować się ze sobą, korzystając z odpowiednich usług. W ten sposób mikrousługi odgrywają ogromną rolę w nowoczesnych aplikacjach internetowych.
Porównajmy nasz przykład koszyka w linii mikrousług. Możemy podzielić nasz koszyk na różne moduły, takie jak „Szukaj”, „Filtr”, „Kasa”, „Koszyk”, „Rekomendacja” itp. Jeśli chcemy zbudować portal koszyka, musimy zbudować wyżej wymienione moduły w taki sposób, że mogą się ze sobą łączyć, aby zapewnić Ci dobre wrażenia z zakupów 24x7.
Zalety wady
Poniżej przedstawiono kilka punktów dotyczących zalet korzystania z mikrousług zamiast korzystania z aplikacji monolitycznej.
Zalety
Small in size- Mikrousługi to implementacja wzorca projektowego SOA. Zaleca się, aby zachować jak najwięcej usług. Zasadniczo usługa nie powinna wykonywać więcej niż jednego zadania biznesowego, dlatego będzie oczywiście niewielka i łatwa w utrzymaniu niż jakakolwiek inna monolityczna aplikacja.
Focused- Jak wspomniano wcześniej, każda mikrousługa jest zaprojektowana do realizacji tylko jednego zadania biznesowego. Projektując mikrousługę, architekt powinien zwracać uwagę na centralny punkt usługi, czyli o jej dostarczanie. Z definicji jedna mikrousługa powinna mieć charakter pełnego stosu i powinna dostarczać tylko jedną właściwość biznesową.
Autonomous- Każda mikrousługa powinna być autonomiczną jednostką biznesową całej aplikacji. W związku z tym aplikacja staje się luźniej powiązana, co pomaga obniżyć koszty utrzymania.
Technology heterogeneity- Microservice obsługuje różne technologie do komunikacji między sobą w jednej jednostce biznesowej, co pomaga programistom w korzystaniu z właściwej technologii we właściwym miejscu. Wdrażając heterogeniczny system, można uzyskać maksymalne bezpieczeństwo, szybkość i skalowalność systemu.
Resilience- Odporność to właściwość izolowania jednostki oprogramowania. Microservice podąża za wysokim stopniem odporności w metodyce budowania, stąd każde niepowodzenie jednej jednostki nie wpływa na cały biznes. Odporność to kolejna właściwość, która wdraża wysoce skalowalny i mniej powiązany system.
Ease of deployment- Ponieważ cała aplikacja jest podzielona na małe części, każdy element powinien mieć charakter pełnego stosu. Wszystkie z nich można bardzo łatwo wdrożyć w dowolnym środowisku przy mniejszej złożoności czasowej, w przeciwieństwie do innych monolitycznych aplikacji tego samego rodzaju.
Poniżej przedstawiono kilka punktów dotyczących wad architektury mikrousług.
Niedogodności
Distributed system- Ze względu na niejednorodność techniczną, różne technologie będą wykorzystywane do opracowywania różnych części mikrousługi. Do obsługi tego dużego, heterogenicznego rozproszonego oprogramowania potrzebny jest ogromny zestaw wykwalifikowanych specjalistów. Stąd rozproszenie i heterogeniczność jest główną wadą korzystania z mikrousług.
Cost - Mikrousługi są kosztowne, ponieważ do różnych zadań biznesowych trzeba utrzymywać różne miejsca na serwerze.
Enterprise readiness- Architekturę mikrousług można uznać za konglomerat różnych technologii, ponieważ technologia ewoluuje z dnia na dzień. W związku z tym dość trudno jest przygotować przedsiębiorstwo wykorzystujące mikrousługi do porównania z konwencjonalnym modelem tworzenia oprogramowania.
Mikrousługa przez SOA
W poniższej tabeli wymieniono niektóre funkcje architektury SOA i mikrousług, zwracając uwagę na znaczenie korzystania z mikrousług zamiast architektury SOA.
| Składnik | SOA | Mikrousługi |
|---|---|---|
| Wzorzec projektowy | SOA to paradygmat projektowania oprogramowania komputerowego, w którym komponenty oprogramowania są wystawiane na zewnątrz w celu wykorzystania w postaci usług. | Usługa Micro Service jest częścią architektury SOA. Jest to wyspecjalizowana implementacja SOA. |
| Zależność | Jednostki biznesowe są od siebie zależne. | Wszystkie jednostki biznesowe są od siebie niezależne. |
| Rozmiar | Rozmiar oprogramowania jest większy niż oprogramowanie konwencjonalne. | Rozmiar oprogramowania jest mały. |
| Technologia | Stos technologii jest mniejszy niż Microservice. | Mikrousługi mają niejednorodny charakter, ponieważ do wykonania określonego zadania używane są dokładne technologie. Mikrousługi można uznać za konglomerat wielu technologii. |
| Autonomia i skupienie | Aplikacje SOA są zbudowane do wykonywania wielu zadań biznesowych. | Aplikacje mikrousług są zbudowane do wykonywania pojedynczego zadania biznesowego. |
| Natura | Charakter monolityczny. | Pełen stos w naturze. |
| Rozlokowanie | Wdrożenie jest czasochłonne. | Wdrożenie jest bardzo łatwe. Dzięki temu będzie to mniej czasochłonne. |
| Opłacalność | Bardziej opłacalne. | Mniej opłacalne. |
| Skalowalność | Mniej w porównaniu do mikrousług. | W pełni skalowane. |
| Przykład | Rozważmy jedną aplikację do rezerwacji CAB online. Jeśli chcemy zbudować tę aplikację przy użyciu architektury SOA, jej jednostki oprogramowania będą -
|
Jeśli ta sama aplikacja jest zbudowana przy użyciu architektury mikrousług, jej interfejsy API będą -
|