Architektury mikrousugowe dr in Andrzej Szwabe Instytut Automatyki

Architektury mikrousługowe dr inż. Andrzej Szwabe Instytut Automatyki, Robotyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej e-mail: Andrzej. Szwabe@put. poznan. pl Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 1

Plan wykładu • • • Znaczenie pojęcia „mikrousługa” Wprowadzenie do architektur mikrousługowych (ang. microservices) – Główne różnice względem: • „klasycznych” warstwowych architektur SOA • współczesnych (heksagonalnych) architektur monolitycznych – Zalety i wady mikrousługowego wzorca architekturalnego Brama API (ang. API Gateway) jako ważny element architektury mikrousługowej – Funkcja reverse proxy – Funkcja rozkładania obciążenia ruchem sieciowym (ang. load balancing) Komunikacja międzyprocesowa (ang. Inter-Process Communication) Odkrywanie usług (ang. service discovery) Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 2

Bibliografia • • „Building Microservices. Designing Fine-Grained Systems”, Sam Newman, O'Reilly Media, 2015 "Microservices. From Design to Deployment", Chris Richardson, Floyd Smith, NGINX, Inc. 2016 "Microservices vs. Service-Oriented Architecture”, Mark Richards, O'Reilly Media, 2016 „Microservices Patterns with examples in Java”, Chris Richardson, MEAP began February 2017 Publication in Fall 2018 (estimated), whitehttps: //livebook. manning. com/#!/book/microservicespatterns/ Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 3

Wprowadzenie do architektur mikrousługowych Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 4

Znaczenie pojęcia mikrousługi • • • Zwolennicy koncepcji mikrousług twierdzą, że mikrousługowy wzorzec projektowy (ang. Microservices Architecture pattern) ma istotne zalety – przede wszystkim w kontekście tzw. zwinnego (ang. agile) wytwarzania oprogramowania infrastruktury usługowej i dostarczania złożonych aplikacji biznesowych. Niektórzy krytycy koncepcji mikrousług twierdzą z kolei, że to tylko nowe określenie na SOA (Service Oriented Architecture). Liczność usług stosowanych w architekturach określanych jako mikrousługowe (np. zdaniem Adriana Cockcrofta system firmy Netflix składa się z ponad 600 „drobnoziarnistych” usług) oraz realne znaczenie (rozpowszechnienie) oprogramowania o wyraźnej i kluczowej roli w architekturach okreslanych jako mikrousługowe – np. Ngnix, Apache Zookeeper, Netflix Eureka, Docker, Kubernetes – przemawiają za istotnością zarówno pojęcia mikrousługi, jak i pojęcia architektury mikrousługowej. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 5

Przykład współczesnej architektury („monolitycznej”) (1/3) • • Tzw. architektura sześciokątna (heksagonalna, określana też jako „Ports and Adapters”) stosowana zamiast klasycznej, warstwowej architektury SOA Wyraźne oddzielenie dziedzinowego modelu danych od interfejsów zewnętrznych – Rdzeniem jest implementacja logiki biznesowej z użyciem modułów definiujących usługi, obiekty dziedzinowe i zdarzenia. – Rdzeń otaczają adaptery łączące system ze środowiskiem zewnętrznym: z komponentami dostępu do baz danych, komponentami komunikacyjnymi produkującymi i przetwarzającymi wiadomości (ang. messages) i komponentami HTTP typu API lub UI. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 6

Przykład współczesnej architektury („monolitycznej”) (2/3) • Chociaż aplikacja (system) ma budowę logicznie modularną, jest ona uruchamiana (publikowana) „monolitycznie”. – • • Konkretny format uruchamianej aplikacji (jej komponentów) zależy od wyboru języka programowania i użytych bibliotek programistycznych. Monolityczna budowa aplikacji ułatwia przygotowanie jej kodu, publikowanie i testowanie – środowiska IDE i inne narzędzia wspierające budowę aplikacji WWW ułatwiają najbardziej budowę tego typu aplikacji. Na początkowym etapie rozwoju aplikacji do zapewnienia jej skalowalności wystarczy uruchomienie wielu jej „kopii” i rozdzielenie ruchu zapytań z użyciem podsystemu rozkładania obciążenia (ang. load balancer). Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 7

Przykład współczesnej architektury („monolitycznej”) (3/3) • • Wraz ze wzrostem złożoności logiki biznesowej aplikacji, uruchomienie jej kolejnej wersji jest coraz bardziej skomplikowane – przede wszystkim z powodu złożoności wzajemnych zależności użytych bibliotek i utworzonych klas przekraczającej możliwości pojedynczego projektanta-programisty, co może poważnie ograniczyć możliwość „zwinnej” rozbudowy. W systemie monolitycznym nie jest możliwe – – • • zastosowanie „wzajemnie sprzecznych” zestawów języków programowania i bibliotek programistycznych (np. różnych języków lub ich wersji czy też tych samych bibliotek w różnych ich wersjach), zastosowanie odmiennych środowisk uruchomieniowych dla poszczególnych komponentów systemu (np. różnych środowisk wirtualizacyjnych). Trudność w zrozumieniu budowy aplikacji przez programistów skutkuje trudnościami w wykrywaniu i usuwaniu błędów w implementacji. Wraz ze wzrostem złożoności logiki biznesowej aplikacji o monolitycznej budowie wydłuża się nie tylko cykl wprowadzania kolejnych jej wersji, ale również czas potrzebny na uruchomienie aplikacji (niekiedy nawet do wielu minut). Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 8

Przykład architektury mikrousługowej (1/3) • • Każdy obszar funkcjonalności przykładowej aplikacji „taksówkowej” realizowany jest przez odrębną mikrousługę. Każdy z interfejsów WWW UI przypisany jest jednemu typowi użytkowników - np. pasażerom, kierowcom. Funkcje niektórych z mikrousług dostępne są przez interfejsy API - używane przez inne mikrousługi, typowe aplikacje klienckie lub przez bramę typu API gateway. Inne mikrousługi dostarczają interfejsy UI. – Przykład: mikrousługa „Driver Management” używa mikrousługi „Notification” do powiadomienia dostępnego kierowcy o potencjalnym „kursie”. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 9

Przykład architektury mikrousługowej (2/3) • • • Mikrousługi realizujące funkcje UI wywołują inne usługi services w celu wygenerowania treści WWW. Mirkousługi stosują klasyczną, synchroniczną wymianę komunikatów lub asynchroniczną, bazującą na przekazywaniu „wiadomości” (ang. message-based). Niektóre z interfejsów API (typowo zgodnych z REST) obsługują zapytania aplikacji mobilnych używanych przez kierowców i pasażerów. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 10

Przykład architektury mikrousługowej (3/3) • • Każdej mikrousłudze przypisana jest odrębna baza danych. Typ bazy danych (relacyjna, „klucz-wartość”, dokumentowa) może być łatwo dobrany do potrzeb funkcjonalnych i wydajnościowych (tzw. „polyglot persistence architecture”). – Np. mikrousługa Driver Management może korzystać z bazy zdolnej efektywnie realizować zapytania geolokacyjne, dzięki czemu możliwe jest efektywne wyszukiwanie kierowców znajdujących się blisko potencjalnego pasażera. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 11

Inny przykład architektury mikrousługowej • • Aplikacja ecommerce służąca przyjmowaniu zamówień od klientów, weryfikująca możliwość realizacji zamówień i wysyłająca je. Mikrousługa Storefront jest implementacją interfejsu użytkownika komunikującą się z trzema mikrousługami bazowymi operującymi na odrębnych, wyspecjalizowanych funkcjonalnie bazach danych („backend”). Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 12

Podstawowe cechy architektury mikrousługowej (1/3) • • Mikrousługa jest „mikroaplikacją” realizującą tylko pojedynczą funkcję logiki biznesowej systemu – np. zarządzanie zamówieniami, klientami, itp. Mikrousługa ma swoją własną heksagonalną architekturę obejmującą logikę biznesową i wiele adapterów. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 13

Podstawowe cechy architektury mikrousługowej (2/3) • Aplikacje mobilne (podobnie jak inne aplikacje klienckie) nie komunikują się bezpośrednio z mikrousługami bazowymi (ang. backend services) – w komunikacji tej pośredniczy brama API (API Gateway) odpowiedzialna za: – rozkładanie obciążenia (dodatkowy „wymiar skalowalności”!), – caching, – kontrolę dostępu, – pomiary i monitorowanie wykorzystania API. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 14

Podstawowe cechy architektury mikrousługowej (3/3) • • • Skalowalność architektury mikrousługowej uzyskuje się przede wszystkim dzięki dekompozycji funkcjonalnej. Uzyskanie skalowalności „horyzontalnej” wymaga zastosowania zaawansowanej bramy API (API Gateway) wspieranej funkcją tzw. odkrywania usług (ang. service discovery) Instancja mikrousługi zwykle funkcjonuje w środowisku maszyny wirtualnej w „chmurze” albo kontenera Docker. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 15

Mikrousługowy wzorzec architekturalny • • • Niektórzy krytycy koncepcji mikrousług twierdzą, że to tylko nowe określenie na SOA (Service Oriented Architecture). Zwolennicy koncepcji mikrousług twierdzą z kolei, że mikrousługowy wzorzec projektowy (ang. Microservices Architecture pattern) ma istotne zalety – przede wszystkim w kontekście tzw. zwinnego wytwarzania oprogramowania infrastruktury usługowej i dostarczania złożonych aplikacji biznesowych. Wyraźną różnicą między SOA a architekturą mikrousługową jest brak (w przypadku tej drugiej) „obciążeń” mnogością standardów rodziny WS-* oraz brak konieczności stosowania szyny Enterprise Service Bus (ESB). W miejsce rozwiązań zgodnych z SOAP, WSDL i innymi powiązanymi standardami mikrousługowy wzorzec architekturalny zakłada stosowanie interfejsów wywodzących się z koncepcji REST. Mikrousługowy wzorzec architekturalny nie zakłada stosowania tzw. kanonicznego schematu danych wymienianych między usługami. Stosowanie mikrousługowego wzorca architekturalnego deklarują takie firmy jak Amazon, e. Bay i Netflix. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 16

Metody dekompozycji jako źródła skalowalności mikrousług (1/2) • Bezpośrednim źródłem skalowalności uzyskiwanej dzięki zastosowaniu mikrousługowego wzorca architekturalnego jest dekompozycja funkcjonalna – jeden z trzech podstawowych czynników skalowalności objętych znanym modelem zaproponowanym w książce Martina L. Abbotta i Michaela T. Fishera „The art of scalability”. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 17

Metody dekompozycji jako źródła skalowalności mikrousług (2/2) • Pośrednimi źródłami skalowalności uzyskiwanej dzięki zaawansowanemu zastosowaniu mikrousługowego wzorca architekturalnego są: – Horyzontalna duplikacja instancji mikrousług (określanych niekiedy jako węzły wykonawcze, ang. workers), – Partycjonowanie danych usprawniające dostęp do danych np. przez ich buforowanie w węzłach z tych danych korzystających. • Partycjonowanie danych – rozumiane jako jeden z trzech „wymiarów skalowalności” – jest po części naturalną konsekwencją dekompozycji funkcjonalnej. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 18

Duplikacja horyzontalna: rozkładanie ruchu i konteneryzacja • Przykład realizacji duplikacji horyzontalnej: – rozkładanie ruchu – serwery (maszyny) wirtualne (EC 2) w „chmurze” Amazon – konteneryzacja (z użyciem platformy Docker) Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 19

Zalety mikrousług i wzorca mikrousługowego • • • Przy tej samym zakresie funkcjonalności, system mikrousługowy jest łatwiejszy w konstrukcji, analizie i zarządzaniu. Stopień modularyzacji wymuszony zastosowaniem mikrousługowego wzorca architekturalnego jest w praktyce bardzo trudny do uzyskania w systemie monolitycznym (tj. z użyciem wyłącznie odpowiedniej hierarchii klas kodu źródłowego). Silna modularyzacja sprzyja szybszemu procesowi rozwoju kodu stanowiącego realizację poszczególnych mikrousług. Organizacja i praca zespołu pracującego nad kodem usługi o węższym zakresie funkcjonalności są łatwiejsze – m. in. ze względu na większą swobodę wyboru języka programowania, zestawu bibliotek i innych narzędzi programistycznych. To z kolei umożliwia szybsze pozbywanie się zależności wobec narzędzi przestarzałych. Wdrożenie/publikacja (ang. deployment) nowej wersji mikrousługi może być dokonywana bezpośrednio po jej przetestowaniu, tj. bez dodatkowej koordynacji z pracami nad innymi mikrousługami tego samego systemu - zgodnie z koncepcją ciągłej publikacji (ang. continuous deployment). Mikrousługa może skalowana niezależnie od skalowania innych – dzięki temu liczba instancji danej mikrousługi może lepiej odpowiadać umiejscowieniu „wąskich gardeł” wydajności systemu. Środowisko uruchomieniowe (w tym infrastruktura sprzętowa, wersja serwera VPS, itp. ) może być dostosowane do potrzeb konkretnej mikrousługi. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 20

Wady mikrousług i wzorca mikrousługowego • • • Niemożliwe jest testowanie systemu mikrousługowego bez użycia mechnizmów komunikacji interprocesowej (ang. Inter-Process Communication, IPC); używanie IPC jest dużo bardziej skomplikowane niż wewnętrzne wywoływanie metod w ramach systemu monolitycznego. Partycjonowanie (mnogość serwerów) architektury bazodanowej komplikuje realizację transakcji obejmujących wiele baz (do których dostęp mają poszczególne mikrousługi); wiodące rozwiązania typu No. SQL nie zapewniają realizacji rozproszonych transakcji ze względów wydajnościowych. Testowanie architektury mikrousługowej jest znacznie bardziej skomplikowane niż testowanie funkcjonalnie analogicznej architektury monolitycznej. – – • Współczesne narzędzia do testowania aplikacji monolitycznych są znacznym usprawnieniem. Niestety w przypadku aplikacji mikrousługowej klasa testowa musi tworzyć instancje wszystkich mikrousług zależnych od testowanej mikrousługi (tj. przez nią „wywoływanych”) lub przynajmniej instancje zaślepkowych implementacji tychże mikrousług zależnych. Niekiedy (na szczęście w przypadku poprawnie przeprowadzonej dekompozycji funkcjonalnej stosunkowo rzadko) pojawia się potrzeba wprowadzenia zmian wymagających równoczesnej modyfikacji wielu mikrousług. Systemy mikrousługowe nierzadko składają się z kilkuset mikroserwisów (np. wg Adriana Cockcrofta system firmy Netflix składa się z ponad 600 mikrousług), z których każdy działa wielu instancjach. – – Liczność „agentów” stawia wysokie wymagania technologiom służącym publikowaniu, konfiguracji, skalowaniu, monitorowaniu, a przede wszystkim – odkrywaniu instancji usług (przede wszystkim ich lokalizacji – adresów IP i numerów portów). Publikowanie nowych wersji mikrousług wymaga większego stopnia automatyzacji tego procesu niż to ma miejsce w przypadku architektur monolitycznych – np. dzięki użytkowaniu infrastruktury usług zewnętrznych typu Platform-as-aservice (Paa. S) lub własnej (np. zbudowanej z użyciem technologii takich jak Kubernetes i Docker). Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 21

Brama API jako ważny element architektury mikrousługowej Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 22

Funkcja reverse proxy jako warunek rozkładalności obciążenia • Zapewnienie tzw. przezroczystości bramy API na poziomie IP Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 23

Przykład konfiguracji funkcji rozkładania obciążenia • Przykład prostych konfiguracji serwera Ngnix realizującego rozkładanie obciążenia z użyciem: – – – algorytmu karuzelowego, algorytmu adaptacyjnego wyrównywania liczby aktualnych połączeń, algorytmu bazującego na funkcji skrótu (ang. hash) Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 24

Zastosowanie bramy API jako odpowiednika wzorca fasady z OOP • Zastosowanie bramy API odpowiada wzorcowi projektowemu fasady znanego z dziedziny programowania obiektowego [https: //pl. wikipedia. org/wiki/Fasada_(wzorzec_projektowy)] Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 25

Rozkładanie obciążenia a architektura monolityczna • W przypadku realizacji aplikacji w postaci architektury monolitycznej aplikacja kliencka (działająca na smartfonie) wysyła zapytania HTTP do właściwej usługi mające (przykładowo) postać: – GET api. company. com/productdetails/product. Id – W przypadku stosowania funkcji rozkładania obciążenia (ang. load balancing) zapytanie przekazywane jest do jednej z identycznych instancji usługi. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 26

Przykładowe zastosowanie bramy API (1/3) • Przykładowy scenariusz aplikacji mobilnej typu e-commerce: Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 27

Przykładowe zastosowanie bramy API (2/3) • Teoretycznie każda z mikrousług może być dostępna przez własny, publiczny punkt końcowy (ang. endpoint) postaci: – https: //service. Name. api. company. name – • • • Zapytania kierowane pod ten adres mogą być dystrybuowane (przez funkcję rozkładania obciążenia) pomiędzy aktualnie dostępne instancje mikrousług. W praktyce przyjęcie takiego rozwiązania oznaczałoby konieczność wykonywania przez klienta dużej liczby zapytań (np. w przypadku serwisu Amazon wygenerowanie jednej tylko strony WWW przedstawiającej dany produkt wymaga użycia setek mikrousług), co istotnie skomplikowałoby budowę aplikacji mobilnej i wydłużyło czas oczekiwania użytkownika na realizację nawet podstawowych funkcji systemu. Ponadto niektóre z mikrousług wymagają użycia protokołów innych niż typowe protokoły Internetu (np. protokołów systemów kolejkowych, np. Zero. MQ, AMQP), co komplikuje kwestie filtrowania ruchu przez zapory (ang. firewalls) innych niż HTTP i Web. Socket. Przyjęcie takiego rozwiązania utrudniłoby też refaktoryzację usług: połączenie dwóch usług w jedną nie oznaczałoby możliwości scalenia również interfejsów API tychże usług. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 28

Przykładowe zastosowanie bramy API (3/3) • • Brama API realizuje funkcje przekierowywania zapytań (ang. request routing), „komponowania” (ang. composition) zapytań do mikrousług (których wykonywanie stanowi podstawowy element logiki biznesowej API), i ewentualną translację pomiędzy protokołami (ang. protocol translation). Każde zapytanie kierowane z mobilnej aplikacji klienckiej trafia do bramy API, skąd jest przekierowywane do właściwej instancji właściwej mikrousługi. Brama API może być środkiem dostarczenia każdemu klientowi dostosowanej do jego potrzeb „wersji API” (ang. custom API), np. interfejs API obejmujący punkt końcowy postaci /productdetails? productid=xxx daje możliwość uzyskania przez klienta wbudowanego w aplikację mobilną danych o danym produkcie z użyciem pojedynczego zapytania. W prezentowanym przypadku rola bramy API w realizacji logiki biznesowej jest znaczna: brama wykonuje „aranżację” usług dostarczających informacji o produktach, ich rekomendacji, recenzji, itp. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 29

Inny przykład zastosowania bramy API • Netflix API Gateway – Usługa strumieniowa Netflix dostępna jest użytkownikom przystawek STB (set-top boxes), smartfonów, konsol gier, tabletów. – Pierwotnie firma Netflix stosowała jeden uniwersalny interfejs API dla wszystkich typów urządzeń, co powodowało znaczne różnice w złożoności i zakresie poszczególnych zapytań. – Obecnie stosowana jest zaawansowana brama API, która dopasowuje postać API do potrzeb każdego z typów aplikacji klienckiej – jest to realizowane przez „kontekstowe” uruchamianie kodu właściwego „adaptera API”. – Netflix API Gateway obsługuje miliardy zapytań dziennie. – Typowo pojedynczy „adapter API” obsługuje jedno zapytanie aplikacji klienckiej przez wykonanie około sześciu zapytań do mikrousług bazowych (ang. backend microservices). Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 30

Cechy zaawansowanej bramy API (1/3) • Zróżnicowanie mechanizmów komunikacyjnych bramy API – W architekturach mikrousługowych stosowane są dwa główne typy komunikacji interprocesowej: • Asynchroniczna, bazująca na wiadomościach (ang. messagingbased): – z użyciem brokera - np. zgodnie z Advanced Message Queuing Protocol (AMQP), – bez użycia brokera (tj. zakładająca bezpośrednią komunikację mikrousług) – jak w przypadku Zero. MQ • Synchroniczne wywołanie interfejsów – przede wszystkim z użyciem HTTP Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 31

Cechy zaawansowanej bramy API (2/3) • Funkcje rejestru/odkrywania usług – Usługi takie jak broker wiadomości (ang. message broker) zwykle dostępne są pod z góry określonym, statycznym adresem (który może być określony z użyciem zmiennych środowiskowych systemu operacyjnego). – Określanie dynamicznych lokalizacji (adresu IP i portu) mikrousług jest złożone - m. in. w wyniku dynamiki zbioru instancji usług spowodowanej aktualizacjami i automatycznym skalowaniem (ang. autoscaling). – W konsekwencji brama API – jako jedyny klient wchodzący w skład systemu mikrousługowego – potrzebuje dostępu do funkcji odkrywania usług – typu „server-side” albo „client-side”. – W przypadku zastosowania odkrywania usług po stronie klienta (ang. clientside discovery) brama API musi być w stanie uzyskiwać odpowiedzi od rejestru usług (ang. service registry) – wyspecjalizowanej bazy danych zawierającej dane o aktualnie działających instancjach mikrousług – szczególnie ich lokalizacjach. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 32

Cechy zaawansowanej bramy API (3/3) • • • Zaawansowana brama API powinna realizować funkcję tzw. obsługi częściowych awarii (ang. partial failure). W tym kontekście pojęcie awarii obejmuje również nieakceptowalnie długie czasu odpowiedzi mikrousługi. Podstawowym wymaganiem jest, aby brama API nigdy nie blokowała swojego działania oczekujac na odpowiedź ze strony (jakiejkolwiek) mikrousługi. Dokładny sposób realizacji obsługi awarii zależy od funkcji pełnionej przez dana mikrousługę. – – • • Na przykład, jeśli mikrousługa rekomendacyjna (rekomendująca produkty alternatywne lub komplementarne wobec produktu aktualnie wybranego przez użytkownika) nie odpowie na zapytanie w przyjętym maksymalnym czasie, bama API powinna – po upłynięciu tego czasu - odpowiedzieć aplikacji klienckiej na jej zapytanie o szczegóły danego produktu dostarczając niepełnej, ale „terminowej” informacji o produkcie. Lista produktów prezentowanych wówczas użytkownikowi jako „rekomendowane” może zawierać niekontekstową i niespersonalizowaną listę „bestsellerów” lub – w ostateczności – być pusta. Kluczowa treść – informacja o wybranym produkcie – powinna być dodatkowo przechowywana w pamięci podręcznej (cache, np. w bazie danych typu „in-memory key-value store”, np. Redis) i w razie potrzeby serwowana aplikacji klienckiej. Jeśli jednak kluczowa treść jest niedostępna – brama API powinna odpowiedzieć aplikacji klienckiej komunikatem błędu (np. kodem statusu HTTP 404). Wskazane jest stosowanie wzorca architekturalnego „przerywacza obwodu” (ang. circuit breaker pattern), który daje możliwość oceny „responsywności” poszczególnych instancji mikrousług oraz zdefiniowania (algorytmicznie) sposobu reakcji bramy API na niedostateczną jakość działania poszczególnych instancji (np. odczyt danych z pamięci podręcznej albo użycie wartości domyślnej). Przykładem zaawansowanej technologii wspierającej implementacje bramy API w zakresie redukowania wpływu awarii na postrzeganą przez użytkowników jakość obsługi jest biblioteka Netflix Hystrix. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 33

Wady i zalety stosowania bramy API • Zalety – Możliwość wykorzystania zaawansowanych funkcji bramy typu reverse proxy, szczególnie w zakresie rozkładanie obciążenia – Znacznie uproszczona może być implementacja (budowa kodu) aplikacji klienckiej, przed którą „ukryta” jest złożoność wewnętrznej struktury systemu mikrousługowego – Zredukowana jest liczba kroków sekwencji zapytań, które muszą być wykonane przez aplikację kliencką w celu realizacji typowej funkcjonalności systemu. • Wady – Złożoność zaawansowanej bramy API zwiększa ryzyko, że brama stanie się „wrażliwym” składnikiem architektury, od niezawodności i wydajności którego w dużym stopniu zależy niezawodność i wydajność całego systemu mikrousługowego. – Brama API może się też stać „wąskim gardłem” jeśli chodzi o aktualizację kodu systemu mikrousługowego – programiści muszą aktualizować kod bramy API w celu udostępnienia wszelkich nowododanych funkcji dowolnych mikrousług bazowych. – Proces aktualizacji bramy API musi być w szczególnym stopniu zoptymalizowany aby uniknąć długiej kolejki zmian oczekujących na wdrożenie. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 34

Komunikacja międzyprocesowa w architekturach mikrousługowych Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 35

Wywołania metod OOP a działanie interfejsów API • Funkcjonalna równoważność wywołań metod OOP i interfejsów API Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 36

Dwa wymiary klasyfikacji typów interakcji mikrousług (1/2) • Pierwszy wymiar charakteryzujący tryby interakcji mikrousług: – „Jeden do jednego” – Zapytanie jest realizowane przez dokładnie jedną instancję mikrousługi. – „Jeden do wielu” – Zapytanie jest realizowane przez wiele instancji mikrousług. • Drugi wymiar charakteryzujący tryby interakcji mikrousług: – Synchroniczny – Aplikacja kliencka oczekuje uzyskania odpowiedzi niezwłocznie po wysłaniu zapytania (może więc być tak zaprojektowana, że brak odpowiedzi blokuje wykonanie dalszych kroków algorytmu logiki biznesowej). – Asynchroniczny – Brak odpowiedzi nie blokuje wykonywania dalszych kroków algorytmu logiki biznesowej aplikacji klienckiej. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 37

Dwa wymiary klasyfikacji typów interakcji mikrousług (2/2) • Istnieją następujące rodzaje interakcji „jeden do jednego” – synchronicznych i asynchronicznych: – – – • Zapytanie-odpowiedź – Aplikacja kliencka wysyła zapytanie do usługi, po czym oczekuje na rychłą odpowiedź. Wątek, który wysłał zapytanie może być zablokowany na czas oczekiwania na odpowiedź. Powiadomienie (ang. notification, a. k. a. one-way request) – Aplikacja kliencka wysyła zapytanie do usługi bez oczekiwania na odpowiedź. Zapytanie-odpowiedź(asynchroniczna) – Brak odpowiedzi na zapytanie wysłane przez aplikację kliencką nie blokuje wykonywania dalszych kroków jej algorytmu. Istnieją następujące rodzaje interakcji „jeden do wielu” – oba asynchroniczne: – – Publikuj-subskrybuj – Aplikacja kliencka „publikuje” wiadomość, która jest następnie odbierana przez mikrousługi (żadną, jedną lub wiele), które „subskrybują” wiadomości aplikacji klienckiej. Publikuj-odpowiedz(asynchronicznie) – Aplikacja kliencka „publikuje” wiadomość, po czym oczekuje określony czas na odpowiedzi mikrousług (żadną, jednej lub wielu), które „subskrybują” wiadomości aplikacji klienckiej. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 38

Przykład zastosowania różnych typów interakcji mikrousług (1/2) • Typowo architektura mikrousługowa korzysta z wielu typów interakcji. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 39

Przykład zastosowania różnych typów interakcji mikrousług (2/2) • W przypadku przykładowej aplikacji „taksówkowej” mikrousługi używają kombinacji powiadomień, typu „zapytanie-odpowiedź” oraz „publikujsubskrybuj”. • • • Aplikacja kliencka działająca w smartfonie pasażera wysyła powiadomienie do usługi Trip Management. Usługa Trip Management sprawdza, czy konto pasażera jest aktywne wykonując zapytanie typu „zapytanie -odpowiedź” do mikrousługi Passenger Management Usługa Trip Management używa interakcji typu „publikuj-subskrybuj” do komunikacji z innymi mikrousługami - m. in. z usługą Dispatcher służącą lokalizacji dostępnego kierowcy. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 40

Ryzyko „rozszerzającego się blokowania usług” • W przypadku „naiwnej” implementacji architektury mikrousługowej występuje znaczne ryzyko rozszerzającego się blokowania się usług występującego w wyniku nieodpowiedniego zabezpieczenia interakcji typu „zapytanie-odpowiedź”. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 41

Metody zapobiegania blokowaniu się architektur mikrousługowych • • • Przedawnianie zapytań, tj. unikanie długich/nieskończonych czasów oczekiwania na odpowiedź Ograniczanie (w aplikacji klienckiej) liczby zapytań oczekujących na odpowiedź ze strony danej usługi Stosowanie wzorca architekturalnego przerywacza obwodu (ang. circuit breaker pattern) obejmujące: – monitorowanie liczby udanych i nieudanych zapytań kierowanych do poszczególnych mikrousług, – wyłączanie komunikacji z usługami, których zawodność przekracza określony poziom – aż do upłynięcia czasu przedawnienia wyłączenia. • W przypadku przedawnień zapytań - stosowanie zastępczych środków realizacji zapytań, takich jak odczyt danych z pamięci podręcznej albo „serwowanie” wartości domyślnej. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 42

Komunikacja asynchroniczna bazująca na „wiadomościach” • Wiadomości są przesyłane tzw. kanałami (ang. channels). – Wiadomości wysyłane do kanału mogą pochodzić z dowolnej liczby aplikacji klienckich (w tym wchodzących w skład mikrousług) określanych jako producenci. – Analogicznie widomości z kanału mogą być odbierane przez dowolną liczbę mikrousług określanych jako konsumenci. – Stosowane są dwa podstawowe typy kanałów: • „Punkt-punkt” (ang. point‑to‑point) – używane przez mikrousługi w celu realizacji komunikacji typu „jeden do jednego”. • „Publikuj-subskrybuj” (ang. publish‑subscribe) – używane w celu realizacji komunikacji typu „jeden do wielu”. • Niektóre z technologii komunikacji bazującej na „wiadomościach” są zgodne ze standardami protokołów – np. Advanced Message Queuing Protocol (AMQP). Inne – z niestandardowymi, ale udokumentowanymi protokołami. • Istnieje wiele systemów komunikacji bazującej na wiadomościach o otwartym kodzie – w tym Rabbit. MQ, Apache Kafka, Apache Active. MQ. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 43

Przykład użycia komunikacji bazującej na „wiadomościach” • • Usługa „Trip Management” wysyła „potencjalnie zainteresowanym usługom” – takim jak usługa „dyspozytorska” „Dispatcher” – dane o nowym przejeździe (tj. podróży) wysyłając wiadomość typu Trip Created do kanału „New Trips” typu publikujsubskrybuj. Usługa Dispatcher wykonuje procedurę znalezienia dostępnego kierowcy, a następnie wysyła dane o nim wysyłając wiadomość typu „Driver Proposed” do kanału „Dispatching” typu publikujsubskrybuj. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 44

Komunikacja synchroniczna w architekturach mikrousługowych • • Komunikacja synchroniczna w architekturach mikrousługowych to przede wszystkim zastosowanie HTTP i (zwykle selektywna) zgodność z paradygmatem REST. Przykład zastosowania REST w przedstawianym przypadku aplikacji „taksówkowej”: – Aplikacja kliencka działająca w telefonie pasażera zamawiającego „kurs” wysyła zapytanie POST na adres zasobu „/trips” mikrousługi „Trip Management”. – Mikrousługa „Trip Management” odpowiada na zapytanie m. in. przez wysłanie zapytania GET w celu pozyskania danych o pasażerze do mikrousługi „Passenger Management”. – Po pozytywnym zweryfikowaniu uprawnienia pasażera do skorzystania z usługi („taksówkowej”) mikrousługa „Trip Management” tworzy obiekt reprezentujący przejazd i wysyła do aplikacji klienckiej działającej w smartfonie odpowiedź z kodem statusu HTTP 201. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 45

Odkrywanie usług w architekturach mikrousługowych Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 46

Powody stosowania technik odkrywania usług • • Również w przypadku architektur alternatywnych wobec mikrousługowych usługi lub instancje usług mają dynamicznie przypisywane lokalizacje sieciowe (tj. adresy IP i numery portów). Jednak w przypadku architektur mikrousługowych lokalizacje instancji usług zmieniają się bardzo dynamicznie ze względu na zastosowanie funkcji automatycznego skalowania, nieuchronne awarie, czy wyłączenia spowodowane aktualizacjami. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 47

Wzorzec architekturalny odkrywania usług po stronie klienta (1/2) • • Aplikacja kliencka jest odpowiedzialna za identyfikowanie lokalizacji zarejestrowanych instancji mikrousług a następnie za rozkładanie pomiędzy nie obciążenia ruchem zapytań. Aplikacja kliencka wykonuje zapytania do rejestru usług – wyspecjalizowanej bazy danych dostępnych instancji mikrousług. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 48

Wzorzec architekturalny odkrywania usług po stronie klienta (2/2) • Lokalizacja instancji jest rejestrowana podczas startu tejże instancji a wyrejestrowywana kiedy instancja kończy funkcjonowanie. • Typowo rejestracja jest ponawiania periodycznie (metodą określaną jako „heartbeat mechanism”). • Przykładem zastosowania wzorca architekturalnego odkrywania usług po stronie klienta jest system rejestru usług Netflix Eureka (który dostarcza interfejs REST służący zarządzaniu rejestracjami i uzyskiwaniu danych o aktualnie dostępnych instancjach) współdziałający z klientem Netflix Ribbon realizującym rozkładanie obciążenia pomiędzy dostępne instancje. • Atutem odkrywania usług po stronie klienta jest możliwość zastosowania zaawansowanego, dostosowanego do potrzeb konkretnego systemu algorytmu rozkładania obciążenia, np. z użyciem funkcji skrótu. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 49

Wzorzec architekturalny odkrywania usług po stronie serwera (1/3) • • Aplikacja kliencka wysyła zapytania do mikrousług za pośrednictwem usługi rozkładającej obciążenie (bramy API, określanego też jako server-side discovery router). W odróżnieniu od wzorca architekturalnego odkrywania usług po stronie klienta to usługa rozkładająca obciążenie jest odpowiedzialna za identyfikowanie lokalizacji zarejestrowanych instancji mikrousług – to ona wykonuje zapytania do rejestru usług. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 50

Wzorzec architekturalny odkrywania usług po stronie serwera (2/3) • Przykładem implementacji serwera odkrywania usług realizującego rozkład obciążenia jest Amazon Web Services Elastic Load Balancer (AWS ELB). – Klient ELB wysyła zapytania (z użyciem stosu protokołów HTTP/TCP/IP lub TCP/IP) na adres DNS serwera ELB. Serwer ELB rozkłada obciążenie pomiędzy zarejestrowane instancje wirtualnych serwerów typu Elastic Compute Cloud (EC 2) lub instancje kontenerów typu EC 2 Container Service (ECS). – W przypadku ELB nie ma odrębnego rejestru usług: instancje EC 2 i ECS są rejestrowane bezpośrednio w ELB. • Innym przykładem implementacji serwera odkrywania usług realizującego rozkład obciążenia jest serwer HTTP Nginx. – Serwer Nginx może być wspierany narzędziem Consul, dzięki któremu (z użyciem szablonu Consul Template) ułatwiona jest dynamiczna rekonfiguracja funkcji reverse proxy serwera Nginx przez cykliczne odświeżanie jego plików konfiguracyjnych (w tym nginx. conf) według zawartości rejestru usług Consul. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 51

Wzorzec architekturalny odkrywania usług po stronie serwera (3/3) • • Dzięki zastosowaniu wzorca architekturalnego odkrywania usług po stronie serwera niepotrzebne jest implementowanie „logiki” odkrywania usług odrębnie dla każdego języka programowania i każdej z bibliotek programistycznych wykorzystywanych w implementacjach aplikacji klienckich. Niektóre środowiska uruchomieniowe („publikacyjne”, ang. deployment environments), takie jak np. Kubernetes dostarczają gotowe do użycia serwery proxy działające na każdym z hostów klastra i realizujące zarówno funkcję odkrywania usług po stronie serwera, jak i funkcję rozkładania obciążenia. – Aplikacja kliencka kieruje zapytanie do serwera proxy używając adresu hosta i portu przypisanego mikrousłudze, po czym serwer proxy transparentnie przekazuje zapytanie jednej z dostępnych instancji działających w klastrze. • Jeśli jednak dane środowisko uruchomieniowe nie dostarcza funkcji serwera proxy realizującego funkcje odkrywania usług po stronie serwera i rozkładania obciążenia, niezbędne jest wdrożenie tego – „wrażliwego” elementu architektury mikrousługowej. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 52

Rejestr usług • Rejestr usług jest kluczowym środkiem realizacji odkrywania usług. – – – • Przykładem implementacji rejestru usług jest system Netflix Eureka, który dostarcza interfejs API zgodny z REST służący rejestracji instancji usług i uzyskiwaniu o nich danych. – – – • Jest to baza danych, w której przechowywane są lokalizacje instancji mikrousług. Chociaż krytyczne jest, żeby zawartość rejestru usług była możliwie aktualna, aplikacje klienckie rejestru usług mogą przechowywać w swoich pamięciach podręcznych (ang. cache) rekordy uzyskane z rejestru usług. Rejestr usług – jako potencjalne „wąskie gardło” architektury mikrousługowej – implementowany jest często jako klaster serwerów wyposażony w funkcję replikacji danych. Instancja wysyła komunikat HTTP POST w celu dokonania rejestracji, po czym co 30 sekund wysyła komunikat HTTP PUT w celu podtrzymania tejże rejestracji. Rejestracja wygasa w wyniku otrzymania komunikatu HTTP DELETE lub w wyniku przedawnienia. Aplikacja kliencka wysyła komunikat HTTP GET w celu uzyskania danych o zarejestrowanych instancjach. Do innych implementacji rejestru usług należą: – – Consul – narzędzie umożliwiające m. in. monitorowanie użyteczności zarejestrowanych instancji mikrousług (tzw. health checks), Apache Zoo. Keeper – szeroko stosowany system wywodzący się z projektu Hadoop, etcd – rozproszona baza danych typu klucz-wartość używana do współdzielenia konfiguracji i odkrywania usług (wykorzystywana w Kubernetes i Cloud Foundry), rejestry wchodzące w skład systemów Kubernetes i AWS. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 53

Wzorce rejestracji usług • W przypadku stosowania wzorca samorejestracji (ang. Self-Registration Pattern) sama instancja mikrousługi jest odpowiedzialna za rejestrowanie się i wyrejestowywanie się z rejestru usług. – Aby uniknąć automatycznego przedawnienia się rejestracji instancji usługi instancja mikrousługi cyklicznie ponawia rejestrację. • W przypadku stosowania wzorca zewnętrznej rejestracji (ang. Third-Party Registration Pattern) zewnętrzny komponent rejestrujący (określany jako service registrar) jest odpowiedzialny za śledzenie działania instancji mikrousług w środowisku uruchomieniowym lub przez śledzenie odpowiednich typów zdarzeń – wykryta nowa instancja jest przez ten komponent rejestrowana w rejestrze usług. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 54

Bibliografia • • „Building Microservices. Designing Fine-Grained Systems”, Sam Newman, O'Reilly Media, 2015 "Microservices. From Design to Deployment", Chris Richardson, Floyd Smith, NGINX, Inc. 2016 "Microservices vs. Service-Oriented Architecture”, Mark Richards, O'Reilly Media, 2016 „Microservices Patterns with examples in Java”, Chris Richardson, MEAP began February 2017 Publication in Fall 2018 (estimated), whitehttps: //livebook. manning. com/#!/book/microservicespatterns/ Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 55

Dziękuję za uwagę. Andrzej Szwabe, Instytut Automatyki i Inżynierii Informatycznej, Wydział Elektryczny Politechniki Poznańskiej Technologie sieciowe 2 (TS 2) – Architektury mikrousługowe 56