Mikroserwisy. Wzorce z przykładami w języku Java - ebook

przedmowa

Jednym z moich ulubionych cytatów jest

Przyszłość jest już dziś, tylko nierówno rozłożona.

William Gibson, autor fantastyki naukowej

Istotą tego cytatu jest to, że nowe pomysły i technologie potrzebują czasu, aby rozpowszechnić się w społeczności i zostać ogólnie przyjęte. Dobrym przykładem powolnego rozprzestrzeniania się pomysłów jest historia odkrywania mikrousług. Zaczęło się w 2006 r., kiedy zainspirowany przemówieniem ewangelisty AWS, podążyłem ścieżką, która ostatecznie doprowadziła mnie do stworzenia Cloud Foundry. (Jedyną wspólną cechą z dzisiejszym Cloud Foundry jest nazwa.) Cloud Foundry to platforma odgrywająca rolę usługi (PaaS) do automatyzacji wdrażania aplikacji Java na EC2. Jak każda inna aplikacja, którą stworzyłem w Javie, moja Cloud Foundry miała architekturę monolityczną składającą się z jednego pliku WAR (Java Web Application Archive).

Połączenie różnorodnego i złożonego zestawu funkcji, takich jak udostępnianie, konfiguracja, monitorowanie i zarządzanie w monolicie, stworzyło wyzwania rozwojowe i operacyjne. Nie można było na przykład zmienić interfejsu użytkownika bez testowania i ponownego wdrażania całej aplikacji. W związku z tym, że komponent monitorowania i zarządzania opierał się na silniku złożonego przetwarzania zdarzeń (Complex Event Processing, CEP), który utrzymywał stan w pamięci, nie mogliśmy uruchomić wielu instancji aplikacji! To było żenujące, ale to, co mogę powiedzieć, to, że jestem programistą i że „kto jest bez grzechu, niech pierwszy rzuci kamieniem”.

Najwyraźniej aplikacja szybko przerosła swoją monolityczną architekturę. Ale jaka była alternatywa? Po pewnym czasie odpowiedź pojawiła się w społeczności programistów w firmach, takich jak eBay czy Amazon. Na przykład Amazon zaczął migrować z monolitu około 2002 r. (https://plus.google.com/110981030061712822816/posts/AaygmbzVeRq). Nowa architektura zastąpiła monolit kolekcją luźno powiązanych usług. Usługi są własnością tego, kogo Amazon nazywa two pizza teams, czyli zespołów wystarczająco małych, aby mogły zostać nakarmione dwiema pizzami.

Amazon zastosował tę architekturę, żeby przyspieszyć tempo opracowywania oprogramowania, tak by firma mogła szybciej wprowadzać innowacje i skuteczniej konkurować na rynku. Wyniki są imponujące: podobno Amazon wprowadza zmiany produkcyjne co 11,6 sekundy!

Na początku 2010 r., po moim przejściu do innych projektów, przyszłość architektury oprogramowania w końcu mnie dopadła. Właśnie wtedy przeczytałem książkę The Art of Scalability: Scalable Web Architecture, Processes and Organizations for the Modern Enterprise (Addison-Wesley Professional, 2009) autorstwa Michaela T. Fishera i Martina L. Abbotta. Kluczową ideą w tej książce jest sześcian skal, który, jak opisano w rozdziale 2, jest trójwymiarowym modelem skalowania aplikacji. Skalowanie w osi Y określone przez dekompozycję funkcjonalną rozkłada aplikację na usługi. Z perspektywy czasu było to dość oczywiste, ale dla mnie był to moment „aha”! Mógłbym rozwiązać problemy, przed którymi stanąłem dwa lata wcześniej, i zaprojektować Cloud Foundry jako zestaw usług!

W kwietniu 2012 r. wygłosiłem swoje pierwsze przemówienie na temat tego podejścia architektonicznego, zatytułowane „Decomposing Applications of Deployability and Scalability” (www.slideshare.net/chris.e.richardson/decomposing-applications-for-scalability-and-deployability-april-2012). W tamtym czasie nie było ogólnie przyjętego terminu na tego rodzaju architekturę. Czasami nazywałem to modułową architekturą poliglotyczną, ponieważ usługi można było pisać w różnych językach.

Ale w przypadku innego przykładu tego, jak przyszłość jest nierównomiernie rozłożona, termin „mikroserwis” został użyty podczas warsztatów architektury oprogramowania w 2011 r. do opisania tego rodzaju architektury (https://en.wikipedia.org/wiki/Microservices). Po raz pierwszy zetknąłem się z tym terminem wtedy, kiedy usłyszałem, jak Fred George wygłasza przemówienie na Oredevie 2013. I podobało mi się to!

W styczniu 2014 r. utworzyłem witrynę https://microservices.io w celu dokumentowania architektury i wzorców projektowych, jakie napotkałem. Następnie, w marcu 2014 r., James Lewis i Martin Fowler opublikowali post na blogu na temat mikroserwisów (https://martinfowler.com/articles/microservices.html). Popularyzując termin „mikroserwisy”, post na blogu spowodował, że społeczność programistów skonsolidowała się wokół tej koncepcji.

Idea małych, luźno powiązanych zespołów, szybko i niezawodnie rozwijających się i dostarczających mikroserwisy powoli rozpowszechnia się w społeczności programistów. Ale jest prawdopodobne, że ta wizja przyszłości różni się od współczesnej rzeczywistości. Obecnie wielkie, krytyczne biznesowo aplikacje firm to zazwyczaj duże monolity opracowywane przez duże zespoły. Wydania oprogramowania zdarzają się rzadko i często są bolesne dla wszystkich zainteresowanych. Dział IT często stara się nadążyć za potrzebami firmy. Możemy wtedy zastanawiać się, jak do licha można zastosować w takim przypadku architekturę mikroserwisową.

Celem tej książki jest odpowiedź na to pytanie. Pozwoli ona dobrze zrozumieć architekturę mikroserwisową, jej zalety i wady oraz kiedy z niej korzystać. Książka opisuje, w jaki sposób rozwiązać liczne wyzwania projektowe, w tym wyzwania zarządzania rozproszonymi danymi. Obejmuje także sposób refaktoryzacji aplikacji monolitycznej do architektury mikroserwisowej. Ale ta książka nie jest manifestem mikroserwisów. Zamiast tego jest zorganizowana wokół kolekcji wzorców. Wzorzec jest rozwiązaniem wielokrotnego użytku dla problemu występującego w określonym kontekście. Piękno wzorca polega na tym, że oprócz opisu zalet rozwiązania opisuje on także wady i problemy, które należy rozwiązać, aby pomyślnie wdrożyć rozwiązanie. Z mojego doświadczenia wynika, że tego rodzaju obiektywizm podczas myślenia o rozwiązaniach prowadzi do znacznie lepszego podejmowania decyzji. Mam nadzieję, że spodoba ci się ta książka i że nauczy cię, jak skutecznie rozwijać mikroserwisy.podziękowania

Chociaż pisanie jest zajęciem samotniczym, potrzeba dużej liczby osób, aby zmienić surowe szkice w gotową książkę.

Po pierwsze, chcę podziękować Erinowi Twoheyowi i Michaelowi Stevensowi z Manninga za ich nieustające zachęty do napisania kolejnej książki. Chciałbym również podziękować moim redaktorom zajmującym się strukturą książki: Cynthii Kane i Marinie Michaels. Cynthia Kane umożliwiła mi rozpoczęcie i pracowała ze mną przez kilka pierwszych rozdziałów. Marina Michaels przejęła zadania Cynthii i pracowała ze mną do końca. Będę na zawsze jej wdzięczny za drobiazgową i konstruktywną krytykę moich rozdziałów. I chcę także podziękować reszcie zespołu Manninga, który był zaangażowany w publikację tej książki.

Chciałbym podziękować mojemu redaktorowi technicznemu Christianowi Mennerichowi, mojemu korektorowi technicznemu Andy’emu Milesowi oraz wszystkim moim zewnętrznym recenzentom: Andy’emu Kirschowi, Antonio Pessolano, Aregowi Melik-Adamyanowi, Cage’owi Slagelowi, Carlosowi Curotto, Drorowi Helperowi, Erosowi Pedriniemu, Hugo Cruzowi, Irinie Romanenko, Jesse’emu Rosalia, Joe’emu Justesenowi, Johnowi Guthrie, Keerthi Shetty, Michele Mauro, Paulowi Grenecowi, Pethuru Rajowi, Potito Coluccelliemu, Shobhie Iyer, Simeonowi Leyzerzon, Srihariemu Sridharanowi, Timowi Moore, Tony’emu Sweetsowi, Trentowi Whiteleyowi, Wesowi Shaddiksowi, Williamowi E. Wheelerowi i Zoltanowi Hamoriemu.

Pragnę również podziękować wszystkim, którzy kupili MEAP¹ i przekazali opinie na forum lub mnie bezpośrednio.

Chciałbym podziękować organizatorom i uczestnikom wszystkich konferencji i spotkań, na których przemawiałem, za możliwość zaprezentowania i zrewidowania moich pomysłów. Dziękuję też moim klientom, którym udzielałem konsultacji i których trenowałem, za umożliwienie realizacji moich pomysłów w praktyce.

Chcę także podziękować moim kolegom Andrew, Valentinowi, Artemowi i Stanislavowi z Eventuate, Inc. za ich wkład w stworzenie produktu Eventuate i projekty open source.

Na koniec pragnąłbym podziękować mojej żonie Laurie i moim dzieciom, Ellie, Thomasowi i Janet, za ich wsparcie i zrozumienie w ciągu ostatnich 18 miesięcy. Podczas gdy byłem przyklejony do laptopa, przegapiłem chodzenie na mecze piłki nożnej Ellie, obserwowanie, jak Thomas uczy się latać na swoim symulatorze lotów, i testowanie nowych restauracji z Janet.

Dziękuję Wam wszystkim!o książce

Celem tej książki jest nauczenie, jak z powodzeniem tworzyć aplikacje za pomocą architektury mikroserwisowej.

Nie tylko omawia ona zalety architektury mikroserwisowej, ale także opisuje jej wady. Dowiemy się, kiedy powinniśmy rozważyć użycie architektury monolitycznej i kiedy warto skorzystać z mikroserwisów.

Kto powinien przeczytać tę książkę

Ta książka koncentruje się na architekturze i rozwoju. Jest przeznaczona dla wszystkich osób odpowiedzialnych za tworzenie i dostarczanie oprogramowania, takich jak programiści, architekci, dyrektorzy (CTO) lub wiceprezesi (VP) ds. technicznych.

Książka skupia się na przedstawieniu wzorców architektury mikroserwisowej i innych koncepcji. Moim celem było sprawić, aby ten materiał stał się dostępny i przystępny niezależnie od używanego stosu technologicznego. Trzeba tylko znać podstawy architektury i projektowania aplikacji korporacyjnych. W szczególności należy rozumieć pojęcia, takie jak „architektura trójwarstwowa”, „projektowanie aplikacji internetowych”, „relacyjne bazy danych”, „komunikacja międzyprocesowa za pomocą przesyłania komunikatów i REST” oraz „podstawy bezpieczeństwa aplikacji”. Przykłady kodu używają Java i frameworka Spring. Aby uzyskać jak najwięcej z nich, warto zaznajomić się z frameworkiem Spring.

Mapa drogowa

Ta książka składa się z 13 rozdziałów:

- ■ Rozdział 1 opisuje objawy monolitycznego piekła. Występują one wówczas, gdy monolityczna aplikacja przerasta swoją architekturę. Doradza także, jak od tego uciec, przyjmując architekturę mikroserwisową. Zawiera również przegląd języka wzorców architektury mikroserwisowej, będącego motywem przewodnim znacznej części książki.
- ■ Rozdział 2 wyjaśnia, dlaczego architektura oprogramowania jest ważna, i opisuje wzorce, których można użyć do rozłożenia aplikacji na zbiór usług. Tłumaczy także, jak pokonać różne przeszkody, które zwykle napotykamy po drodze.
- ■ Rozdział 3 opisuje różne wzorce niezawodnej komunikacji międzyprocesowej w architekturze mikroserwisowej. Objaśnia, dlaczego asynchroniczna komunikacja oparta na komunikatach jest często najlepszym wyborem.
- ■ Rozdział 4 wyjaśnia, w jaki sposób zachować spójność danych w różnych usługach za pomocą wzorca sagi. Saga to sekwencja lokalnych transakcji koordynowanych za pomocą komunikatów asynchronicznych.
- ■ Rozdział 5 pokazuje, jak zaprojektować logikę biznesową dla usługi z użyciem wzorca agregatów DDD (domain-driven design) oraz zdarzeń domenowych.
- ■ Rozdział 6 opiera się na rozdziale 5 i wyjaśnia, w jaki sposób rozwijać logikę biznesową za pomocą skoncentrowanego na zdarzeniach wzorca event sourcingu w celu ustrukturyzowania logiki biznesowej i utrzymywania obiektów domenowych.
- ■ Rozdział 7 omawia sposób implementowania zapytań, które pobierają dane rozproszone w wielu usługach, z użyciem wzorca kompozycji API lub Command Query Responsibility Segregation (CQRS).
- ■ Rozdział 8 dotyczy wzorców zewnętrznych API do obsługi żądań ze zróżnicowanego zbioru klientów zewnętrznych, takich jak aplikacje mobilne, aplikacje JavaScript oparte na przeglądarce i aplikacje podmiotów zewnętrznych.
- ■ Rozdział 9 to pierwszy z dwóch rozdziałów na temat automatycznych technik testowania mikroserwisów. Wprowadza ważne koncepcje testowania, takie jak piramida testów, która opisuje względne proporcje każdego rodzaju testu w zestawie testów. Pokazuje także, jak pisać testy jednostkowe, które stanowią podstawę piramidy testów.
- ■ Rozdział 10 opiera się na rozdziale 9 i pokazuje, jak pisać inne typy testów w piramidzie testów, w tym testy integracyjne, testy kontraktowe i testy komponentów.
- ■ Rozdział 11 obejmuje różne aspekty opracowywania usług gotowych do produkcji, w tym bezpieczeństwo, wzorzec konfiguracji zewnętrznej i wzorce obserwowalności usług. Wzorce obserwowalności usług obejmują agregację dzienników, metryki aplikacji i śledzenie rozproszone.
- ■ Rozdział 12 opisuje różne wzorce wdrażania, których można użyć do wdrażania usług, w tym maszyny wirtualne, kontenery i wzorce bezserwerowe. Omówiono w nim także zalety korzystania z siatki usług, warstwy oprogramowania sieciowego, która pośredniczy w komunikacji w architekturze mikroserwisowej.
- ■ Rozdział 13 wyjaśnia, jak przyrostowo refaktoryzować architekturę monolityczną do architektury mikroserwisowej, stosując wzorzec aplikacji dusiciela: wdrażanie nowych funkcjonalności jako usług oraz wyodrębnianie modułów z monolitu i konwertowanie ich na usługi.

W miarę przechodzenia przez te rozdziały poznamy różne aspekty architektury mikroserwisowej.

O kodzie

Ta książka zawiera wiele przykładów kodu źródłowego, zarówno w ponumerowanych listingach, jak i wewnątrz zwykłego tekstu. W obu przypadkach kod źródłowy jest sformatowany w ten sposób czcionką o stałej szerokości, aby oddzielić go od zwykłego tekstu. Czasami kod jest również pogrubiony, żeby móc wskazać miejsca, w których się zmienił w porównaniu z poprzednimi krokami w danym rozdziale, na przykład gdy została dodana w nim nowa funkcjonalność. W wielu przypadkach ponownie sformatowaliśmy oryginalny kod źródłowy; dodaliśmy linie podziału i przerobiliśmy wcięcia, aby uwzględnić dostępne miejsce na stronie w książce. W rzadkich przypadkach nawet to nie było wystarczające, mimo że listingi zawierają znaczniki kontynuacji linii (➥). Ponadto często w listingach usuwaliśmy komentarze z kodu źródłowego, jeśli został on opisany w tekście. Wielu listingom towarzyszą adnotacje dotyczące kodu, podkreślające ważne pojęcia.

Każdy rozdział, z wyjątkiem rozdziałów 1, 2 i 13, zawiera kod z przykładowej aplikacji. Kod tej aplikacji można znaleźć w repozytorium GitHub: https://github.com/microservices-patterns/ftgo-application.

Forum książki

Zakup opracowania Mikroserwisy.Wzorce z przykładami w języku Java umożliwia bezpłatny dostęp do prywatnego forum internetowego prowadzonego przez Manning Publications. Można na nim zamieszczać komentarze na temat książki, zadawać pytania techniczne i otrzymywać pomoc od autorów i innych użytkowników. Aby uzyskać dostęp do forum, należy przejść do strony https://forums.manning.com/forums/microservices-patterns. Więcej o forach Manninga i zasadach korzystania można dowiedzieć się także na https://forums.manning.com/forums/about.

Zobowiązanie Manninga względem swoich czytelników polega na zapewnieniu miejsca, w którym może odbywać się konstruktywny dialog między poszczególnymi czytelnikami oraz między czytelnikami a autorami. Nie jest to zobowiązanie się do konkretnej formy uczestnictwa ze strony autorów, których wkład na forum pozostaje dobrowolny (i niepłatny). Sugerujemy zadawanie autorom wielu wymagających pytań, aby dzięki temu mogli zgłębiać temat! Forum i archiwa poprzednich dyskusji będą dostępne na stronie internetowej wydawcy tak długo, jak książka będzie publikowana.

Inne zasoby online

Innym doskonałym źródłem do nauki architektury mikroserwisowej jest moja strona http://microservices.io.

Zawiera ona nie tylko pełny język wzorców, ale także linki do innych zasobów, takich jak artykuły, prezentacje i przykładowy kod.o autorze

Chris Richardson jest programistą i architektem. Posiada tytuły Java Champion i JavaOne Rock Star oraz jest autorem książki POJOs in Action (Manning, 2006), która opisuje, jak budować aplikacje Java z platformami, takimi jak Spring i Hibernate.

Chris jest także założycielem oryginalnej CloudFoundry.com, wczesnego Java PaaS dla Amazon EC2.

Dziś jest uznanym liderem w dziedzinie mikroserwisów i regularnie wygłasza prelekcje na międzynarodowych konferencjach. Chris jest twórcą Microservices.io, języka wzorców dla mikroserwisów. Oferuje konsultacje i szkolenia w zakresie mikroserwisów dla organizacji, które stosują architekturę mikrousługową, na całym świecie. Chris pracuje nad swoim trzecim startupem Eventuate.io, platformą aplikacyjną do opracowywania transakcyjnych mikroserwisów.o ilustracji na okładce

Obraz na okładce książki Mikroserwisy. Wzorce z przykładami w języku Java jest zatytułowany „Habit of a Morisco Slave in 1568”. Ilustracja pochodzi z dzieła Thomasa Jefferysa A Collection of the Dresses of Different Nations, Ancient and Modern (cztery tomy), opublikowanego w Londynie w latach 1757–1772. Strona tytułowa głosi, że są to ręcznie kolorowane miedziane ryciny, wzmocnione gumą arabską.

Thomas Jefferys (1719–1771) został nazwany „Geografem Króla Jerzego III”. Był angielskim kartografem i głównym dostawcą map w swoich czasach. Wygrawerował i wydrukował mapy dla rządu i innych oficjalnych organów, a także opracował szeroki asortyment map i atlasów, zwłaszcza dla Ameryki Północnej. Jego praca jako twórcy map wzbudziła zainteresowanie lokalnymi zwyczajami ubioru na ziemiach, które zbadał i zmapował, co jest doskonale widoczne w tej kolekcji. Fascynacja odległymi krainami i podróże dla przyjemności były nowymi zjawiskami pod koniec XVIII wieku, a kolekcje takie jak te były popularne, wprowadzając zarówno turystów, jak i podróżujących palcem po mapie do mieszkańców innych krajów.

Różnorodność rysunków w dziełach Jefferysa wyraźnie pokazuje wyjątkowość i indywidualność narodów świata sprzed około 200 lat. Od tego czasu uległy zmianie sposoby ubierania się, a znaczna różnorodność w zależności od regionu i kraju, tak bogata w tamtym czasie, zanikła. Obecnie często trudno jest odróżnić mieszkańców jednego kontynentu od mieszkańców innych kontynentów. Być może, gdy spróbujemy spojrzeć na to optymistycznie, okaże się, że wymieniliśmy kulturową i wizualną różnorodność na bardziej zróżnicowane życie osobiste lub bardziej zróżnicowane i interesujące życie intelektualne i techniczne.

W czasach, gdy trudno jest odróżnić jedną książkę komputerową od innej, Manning łączy pomysłowość i inicjatywę biznesu komputerowego z okładkami opartymi na bogatej różnorodności życia regionalnego sprzed dwóch wieków, przywróconej do życia dzięki obrazom Jefferysa.