Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00131 000697 12926024 na godz. na dobę w sumie
Budowanie mikrousług - ebook/pdf
Budowanie mikrousług - ebook/pdf
Autor: Liczba stron: 272
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-1384-2 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook (-40%), audiobook).

Wykorzystaj potencjał architektury usług!

Architektura mikrousług to sposób na odejście od dużych, monolitycznych aplikacji. Wyspecjalizowane usługi realizujące konkretne zadania i komunikujące się z otoczeniem pozwalają na lepsze zapanowanie nad kodem, są łatwiejsze do przetestowania oraz bardziej elastyczne. Jednak oprócz zalet mają też wady. Sięgnij po tę książkę i dowiedz się, jak najlepiej radzić sobie z architekturą mikrousług!

Autor przedstawia w książce skuteczne techniki projektowania i korzystania z architektury mikrousług. W trakcie lektury kolejnych rozdziałów poznasz w szczegółach ideę mikrousług, korzyści ich stosowania, sposoby modelowania usług oraz skuteczne techniki dzielenia dużej aplikacji na mikrousługi. Ponadto zapoznasz się z możliwymi sposobami integracji: zdalne wywołanie procedur, REST i zdarzenia — to tylko niektóre z poruszanych kwestii. Na sam koniec zaznajomisz się z najlepszymi metodami testowania i monitorowania usług, zapewnisz im bezpieczeństwo dzięki kluczom API oraz innym technikom. Ta książka jest obowiązkową lekturą dla wszystkich osób chcących tworzyć nowoczesne systemy bazujące na architekturze mikrousług.

Przekonaj się, jak architektura mikrousług zmieni Twoje spojrzenie na aplikacje!



Sam Newman — technolog w firmie ThoughtWorks odpowiedzialny za wspomaganie klientów oraz architekturę wewnętrznych systemów. Prelegent, autor artykułów dla wydawnictwa O’Reilly. Programista języków Java oraz Python.
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Building Microservices Tłumaczenie: Radosław Meryk ISBN: 978-83-283-1381-1 © 2015 Helion S.A. Authorized Polish translation of the English edition of Building Microservices, ISBN 9781491950357 © 2015 Sam Newman. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/budmik Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Przedmowa .............................................................................................................. 13 Czym są mikrousługi? Najważniejsze korzyści Niewielkie, skoncentrowane na dobrym wykonywaniu jednej rzeczy Autonomiczne 1. Mikrousługi .............................................................................................................. 19 20 20 21 22 22 23 23 24 25 25 25 26 27 27 28 29 29 Niejednorodność technologii Odporność na błędy Skalowanie Łatwość wdrażania Dopasowanie do organizacji zespołów Interoperatywność Optymalizacja w kierunku wymienności Architektura zorientowana na usługi Inne techniki dekompozycji Biblioteki współdzielone Moduły Nie istnieje panaceum na wszystko Podsumowanie Niedokładne porównania Ewolucyjna wizja architekta Podział na strefy Pryncypialne podejście 2. Ewolucyjny architekt ................................................................................................. 31 31 33 34 35 36 36 37 Cele strategiczne Zasady Praktyki 3 Poleć książkęKup książkę Łączenie zasad i praktyk Praktyczny przykład Wymagane standardy Monitorowanie Interfejsy Bezpieczeństwo architektury Zarządzanie za pośrednictwem kodu Przykładowe egzemplarze Spersonalizowany szablon usługi Dług techniczny Obsługa wyjątków Zarządzanie i przewodnictwo od środka Budowanie zespołu Podsumowanie 37 37 38 39 39 39 40 40 40 42 42 43 44 45 Przedstawiamy firmę MusicCorp Co decyduje o tym, że usługa jest dobra? Luźne sprzężenia Wysoka spójność Ograniczony kontekst 3. Jak modelować usługi? .............................................................................................. 47 47 48 48 48 49 49 51 51 52 52 54 54 55 Możliwości biznesowe Żółwie aż do spodu Komunikacja w kategoriach pojęć biznesowych Granice techniczne Podsumowanie Modele współdzielone i ukryte Moduły i usługi Przedwczesna dekompozycja 4. Unikanie wprowadzania przełomowych zmian Dbanie o niezależność interfejsów API od technologii Dbałość o zapewnienie prostoty usługi dla konsumentów Ukrycie wewnętrznych szczegółów implementacji Integracja ................................................................................................................. 57 57 Poszukiwanie idealnej technologii integracji 57 57 58 58 58 59 60 61 Interfejs z klientami Wspólna baza danych Komunikacja synchroniczna kontra asynchroniczna Aranżacja kontra choreografia 4 (cid:95) Spis treści Poleć książkęKup książkę Zdalne wywołania procedur Sprzężenia technologii Wywołania lokalne różnią się od zdalnych Kruchość Czy wywołania RPC są złym rozwiązaniem? REST REST a HTTP Hipermedium jako silnik stanu aplikacji JSON, XML czy coś innego? Uważaj na zbyt wielkie wygody Wady interfejsu REST przez HTTP Implementacja współpracy asynchronicznej, bazującej na zdarzeniach Opcje wyboru technologii Zawiłości architektur asynchronicznych Usługi jako maszyny stanów Rozszerzenia reaktywne DRY i perypetie wielokrotnego wykorzystania kodu w świecie mikrousług Biblioteki klienckie Dostęp przez referencję Zarządzanie wersjami Odkładaj modyfikowanie interfejsu tak długo, jak to możliwe Wczesne wychwytywanie zmian naruszających zgodność interfejsu Zastosowanie semantycznej kontroli wersji Współistnienie różnych punktów końcowych Korzystanie z wielu równoległych wersji usługi Interfejsy użytkownika W stronę środowiska cyfrowego Ograniczenia Kompozycja interfejsów API Kompozycja fragmentu interfejsu użytkownika Zaplecza dla frontonów Podejście hybrydowe Integracja z oprogramowaniem zewnętrznych producentów Brak kontroli Personalizacja Makaron integracji Personalizacja na własnych warunkach Wzorzec Dusiciel Podsumowanie 64 64 65 65 67 67 68 68 70 71 72 73 73 74 76 76 77 77 78 80 80 81 81 82 83 84 85 85 86 87 89 90 91 92 92 92 93 95 96 Spis treści (cid:95) 5 Poleć książkęKup książkę Tempo zmian Struktura zespołu Bezpieczeństwo Technologia To wszystko są szwy Podział systemu w firmie MusicCorp Powody dzielenia monolitu Splątane zależności Baza danych Zlikwidowanie problemu Przykład: eliminowanie relacji kluczy obcych Przykład: wspólne statyczne dane Przykład: współdzielone dane Przykład: wspólne tabele Refaktoryzacja baz danych 5. Dzielenie monolitu .................................................................................................... 97 97 98 99 99 99 99 100 100 100 100 101 103 104 105 106 106 107 108 109 109 110 111 111 112 114 115 116 117 117 117 118 119 Alternatywne lokalizacje docelowe Pompa danych sterowana zdarzeniami Pompa danych z kopii zapasowej W stronę czasu rzeczywistego Koszty zmiany Zrozumieć przyczyny Podsumowanie Raportowanie Bazy danych raportowania Pobieranie danych za pośrednictwem wywołania usługi Pompy danych Podział na etapy Granice transakcyjne Spróbuj ponownie później Odrzucenie całej operacji Transakcje rozproszone Jakie rozwiązanie wybrać? Krótkie wprowadzenie do ciągłej integracji 6. Wdrażanie .............................................................................................................. 121 121 122 123 125 126 Mapowanie ciągłej integracji na mikrousługi Potoki kompilacji a ciągłe dostawy Czy rzeczywiście to robisz? Nieuniknione wyjątki 6 (cid:95) Spis treści Poleć książkęKup książkę Artefakty specyficzne dla platformy Artefakty systemu operacyjnego Spersonalizowane obrazy Obrazy jako artefakty Serwery niezmienne Środowiska Konfiguracja usługi Odwzorowanie usługa-host Wiele usług na hoście Kontenery aplikacji Jedna usługa na host Platforma jako usługa Automatyzacja Dwa studia przypadków na potwierdzenie potęgi automatyzacji Od świata fizycznego do wirtualnego Tradycyjna wirtualizacja Vagrant Kontenery w Linuksie Docker Interfejs instalacji Definicja środowiska Podsumowanie 127 128 129 131 131 131 133 133 134 136 137 138 139 139 140 140 141 142 144 145 146 147 Rodzaje testów Zakres testów Implementacja testów usług Makiety lub namiastki Inteligentniejsza namiastka usługi Testy jednostkowe Testy usług Testy od końca do końca Kompromisy Ile? 7. Testowanie ..............................................................................................................149 149 150 152 152 153 153 154 154 155 155 156 157 158 159 159 160 161 Kłopotliwe testy od końca do końca Wady testowania od końca do końca Testy kruche i łamliwe Kto pisze te testy? Jak długo? Piętrzące się zaległości Metawersje Spis treści (cid:95) 7 Poleć książkęKup książkę Testuj ścieżki, a nie historie Testy sterowane potrzebami konsumentów Pact Konwersacje Czy należy używać testów od końca do końca? Testowanie po opublikowaniu systemu do produkcji Oddzielenie wdrożenia od publikacji Publikacje kanarkowe Średni czas do naprawy kontra średni czas między awariami Testy współzależności funkcjonalnych Testy wydajności Podsumowanie 161 162 163 165 165 166 166 167 168 169 170 171 Jedna usługa, jeden serwer Jedna usługa, wiele serwerów Wiele usług, wiele serwerów Logi, logi i jeszcze raz logi… Śledzenie metryk dotyczących wielu usług Metryki usług Monitorowanie syntetyczne 8. Monitorowanie ....................................................................................................... 173 174 174 175 176 177 178 178 179 180 182 182 183 184 185 Identyfikatory korelacji Kaskada Standaryzacja Weź pod uwagę użytkowników Przyszłość Podsumowanie Implementacja monitorowania semantycznego Uwierzytelnianie i autoryzacja Uwierzytelnianie i autoryzacja w trybie usługa-usługa Popularne implementacje pojedynczego logowania Brama pojedynczego logowania Szczegółowa autoryzacja 9. Bezpieczeństwo ...................................................................................................... 187 187 188 189 190 191 191 192 192 193 194 195 195 Zezwalaj na wszystko wewnątrz obszaru Podstawowe uwierzytelnianie HTTP(S) Korzystanie z SAML lub OpenID Connect Certyfikaty klienta HMAC przez HTTP Klucze API Problem zastępcy 8 (cid:95) Spis treści Poleć książkęKup książkę Zabezpieczanie danych w spoczynku Korzystaj ze sprawdzonych sposobów Wszystko dotyczy kluczy Wybierz swoje cele Odszyfruj dane na żądanie Szyfruj kopie zapasowe Obrona wielostrefowa Zapory firewall Rejestrowanie Systemy wykrywania włamań (i zapobiegania im) Podział sieci System operacyjny Praktyczny przykład Bądź oszczędny Czynnik ludzki Złota reguła Wdrażanie zabezpieczeń Zewnętrzna weryfikacja Podsumowanie 197 198 198 199 199 199 199 199 200 200 200 201 201 204 204 204 205 206 206 Dowody Organizacje sprzężone luźno i ściśle Windows Vista Netflix i Amazon Co można z tym zrobić? Dostosowanie się do ścieżek komunikacyjnych Własność usługi Powody współdzielenia usług 10. Prawo Conwaya a projektowanie systemów .............................................................207 207 208 208 208 209 209 210 211 211 211 212 212 213 213 214 214 214 215 216 217 218 Konteksty ograniczone a struktura zespołów Usługa osierocona? Studium przypadku: RealEstate.com.au Odwrócone prawo Conwaya Ludzie Podsumowanie Zbyt trudne do rozdzielenia Zespoły funkcyjne Wąskie gardła dostaw Wewnętrzne Open Source Rola opiekunów Dojrzałość Narzędzia Spis treści (cid:95) 9 Poleć książkęKup książkę Awarie zdarzają się wszędzie Jak wiele jest zbyt wiele? Degradowanie funkcjonalności Środki bezpieczeństwa architektury Antykrucha organizacja Limity czasu Bezpieczniki Grodzie Izolacja Idempotencja Skalowanie Zwiększenie rozmiarów Podział obciążeń Rozłożenie ryzyka Równoważenie obciążenia Systemy bazujące na wątkach roboczych Zaczynanie od nowa Skalowanie baz danych 11. Mikrousługi w projektach dużej skali ....................................................................... 219 219 220 221 222 224 225 225 227 229 229 230 230 231 231 232 234 235 236 236 236 237 238 238 239 239 240 242 242 242 243 244 245 246 247 247 248 249 249 250 Buforowanie po stronie klienta, na serwerze proxy i po stronie serwera Buforowanie w HTTP Buforowanie operacji zapisu Buforowanie w celu poprawy niezawodności Ukrywanie źródła Zachowaj prostotę Zatrucie pamięcią podręczną: historia ku przestrodze Poświęcenie spójności Poświęcenie dostępności Poświęcenie tolerancji podziału? AP czy CP? To nie jest zasada „wszystko albo nic” Świat rzeczywisty Dostępność usługi kontra trwałość danych Skalowanie do obsługi operacji odczytu Skalowanie do obsługi operacji zapisu Wspólna infrastruktura bazy danych CQRS Buforowanie Autoskalowanie Twierdzenie CAP 10 (cid:95) Spis treści Poleć książkęKup książkę Wykrywanie usług DNS Dynamiczne rejestry usług Zookeeper Consul Eureka Tworzenie własnych rozwiązań Nie zapomnij o ludziach! Dokumentowanie usług Swagger HAL i przeglądarka HAL System samoopisujący się Podsumowanie 250 251 252 252 253 254 254 255 255 256 256 257 258 Zasady dotyczące mikrousług 12. Podsumowanie ........................................................................................................259 259 260 260 261 261 262 262 263 263 264 Wzorowanie na koncepcjach działania biznesu Przyjęcie kultury automatyzacji Ukrywanie wewnętrznych szczegółów implementacji Decentralizacja wszystkich operacji Możliwość niezależnej instalacji Izolowanie awarii Łatwe do obserwacji Kiedy nie należy używać mikrousług? Ostatnie słowo Skorowidz ................................................................................................................265 Spis treści (cid:95) 11 Poleć książkęKup książkę 12 (cid:95) Spis treści Poleć książkęKup książkę ROZDZIAŁ 1. Mikrousługi Od wielu lat próbujemy znaleźć lepsze sposoby budowania systemów. Uczymy się na podstawie tego, co było wcześniej, adoptujemy nowe technologie i obserwujemy różne sposoby działania przedstawicieli nowej fali firm po to, aby tworzyć systemy informatyczne, które uszczęśliwią za- równo klientów, jak i twórców systemów. Książka Erica Evansa Domain-Driven Design (Addison-Wesley) pomogła nam zrozumieć zna- czenie reprezentowania w kodzie rzeczywistego świata oraz pokazała lepsze sposoby modelowa- nia naszych systemów. Koncepcja ciągłych dostaw (continuous delivery) pokazała, jak można skuteczniej i wydajniej wdrażać tworzone oprogramowanie. Zaszczepiła w nas pomysł, aby wersję z każdej operacji wgrania kodu do repozytorium (check-in) traktować jako potencjalną wersję do publikacji. Zrozumienie sposobu działania sieci WWW doprowadziło nas do opracowania lepszych sposobów komunikowania się maszyn. Koncepcja architektury sześciokątnej Alistaira Cockburna (http://alistair.cockburn.us/Hexagonal+architecture) odwiodła nas od architektur warstwowych, które pozwalały ukryć logikę biznesową. Platformy wirtualizacji pozwoliły na konfigurowanie i zmianę rozmiarów maszyn, na żądanie gwarantując automatyzację infrastruktury, która umoż- liwia obsługę tych maszyn w skali. Niektóre duże organizacje, takie jak Amazon i Google, odnio- sły sukces, forsując wizję niewielkich zespołów odpowiedzialnych za pełny cykl życia swoich usług. A w ostatnim czasie firma Netflix zaproponowała sposoby budowania elastycznych syste- mów (antifragile — dosł. ‘antykruchych’) w skali, która zaledwie 10 lat temu byłaby trudna do zrozumienia. Projektowanie tematyczne (domain-driven design — DDD). Ciągłe dostarczanie. Wirtualizacja na żądanie. Automatyzacja infrastruktury. Małe autonomiczne zespoły. Systemy w skali. Z tego świata wyłoniły się mikrousługi. Nie zostały wymyślone lub opisane „z góry”, przed wdrożeniem — pojawiły się one jako trend lub wzorzec z praktycznych zastosowań. Jednak istnieją tylko dla- tego, że wcześniej stosowano wszystkie wymienione powyżej techniki. W tej książce będę wyciągał wnioski z tych wcześniejszych prac po to, by wskazać sposób, w jaki można budować, zarządzać i rozwijać mikrousługi. W wielu firmach zdano sobie sprawę, że wykorzystanie drobnoziarnistych architektur mikro- usług pozwala stosować nowe technologie i szybciej dostarczać oprogramowanie. Mikrousługi dają nam znacznie więcej swobody reakcji oraz podejmowania różnych decyzji, co pozwala nam szybciej reagować na nieuniknione zmiany, które mają wpływ na nas wszystkich. 19 Poleć książkęKup książkę Czym są mikrousługi? Mikrousługi są niewielkimi, współpracującymi ze sobą, autonomicznymi usługami. Spróbujmy rozbić tę definicję na mniejsze części i przeanalizować cechy, które wyróżniają mikrousługi spo- śród innych architektur. Niewielkie, skoncentrowane na dobrym wykonywaniu jednej rzeczy W wyniku pisania kodu, który dodaje nowe funkcje, bazy kodu rozrastają się. Z czasem ze względu na to, że baza kodu rozrośnie się do olbrzymich rozmiarów, stwierdzenie, gdzie należy wprowa- dzić zmiany, może być trudne. Pomimo że dąży się do czytelnych, modułowych, monolitycznych baz kodu, nazbyt często te arbitralne granice wewnątrz procesów się rozpływają. Kod pełniący podobne funkcje zaczyna rozsiewać się po całym projekcie. W związku z tym usuwanie błędów lub implementacja stają się trudniejsze. W ramach monolitycznego systemu zwalczamy te trendy, starając się zapewnić większą spójność kodu. Często w tym celu tworzymy nowe abstrakcje lub moduły. Spójność — dążenie do grupowania powiązanego ze sobą kodu — to bardzo ważne pojęcie, kiedy zaczynamy myśleć o mikrousługach. Cechę tę wzmacnia zasada pojedynczej odpowiedzialności (http://programmer.97things.oreilly.com/ wiki/index.php/The_Single_Responsibility_Principle) Roberta C. Martina, która mówi „Pogrupuj ze sobą te elementy, które będą się zmieniać z tego samego powodu, i rozdziel te, które zmieniają się z różnych powodów”. Mikrousługi pozwalają zastosować to samo podejście do niezależnych usług. Wyznaczając granice usług, koncentrujemy się na kategoriach biznesowych. Dzięki temu lokalizacja fragmentu kodu odpowiedzialnego za określone funkcjonalności staje się oczywista. Dzięki zapewnieniu czytel- nych granic usługi możemy uniknąć pokusy zbytniej rozbudowy kodu — wraz ze wszystkimi związanymi z tym trudnościami. Pytanie, które często jest mi zadawane, brzmi: ile to jest mało? Podanie dokładnej liczby wierszy kodu stwarza problemy, ponieważ niektóre języki są bardziej ekspresywne od innych, dlatego po- zwalają na wyrażenie więcej za pomocą mniejszej liczby wierszy kodu. Trzeba także wziąć pod uwagę fakt wielu możliwych zależności, które same w sobie zawierają wiele wierszy kodu. Po- nadto niektóre części dziedziny mogą być bardziej złożone od innych, co może wymagać dodat- kowych ilości kodu. Jon Eaves z firmy RealEstate.com.au z Australii charakteryzuje mikrousługę jako kod, który można przepisać w dwa tygodnie — to reguła „spod dużego palca”, która ma sens w tym konkretnym kontekście. Inna, trochę banalna odpowiedź, jakiej mogę udzielić, brzmi: małe jest wystarczająco małe, ale nie mniejsze. Wygłaszając referaty na konferencjach, prawie zawsze zadaję pytanie: kto utrzymuje system, który jest zbyt duży i który należałoby rozdzielić? Prawie wszyscy podnieśli ręce. Wydaje się, że mamy bardzo dobre poczucie tego, co jest zbyt duże, a więc można argumentować, że jeśli frag- ment kodu nie będzie nam się wydawał zbyt duży, to prawdopodobnie jest wystarczająco mały. 20 (cid:95) Rozdział 1. Mikrousługi Poleć książkęKup książkę Bardzo pomocne w udzieleniu odpowiedzi na pytanie o to, jak mały jest fragment kodu, jest po- równanie kodu do struktury zespołu. Jeśli baza kodu jest zbyt duża, aby mogła być zarządzana przez mały zespół, dążenie do jej podzielenia jest bardzo rozsądne. Tematykę organizacji zespo- łów zgodnie z rozmiarami bazy kodu poruszymy w dalszej części tej książki. Przy próbach rozstrzygania, jak małe jest wystarczająco małe, myślę w następujących kategoriach: im mniejsza usługa, tym łatwiej zmaksymalizować korzyści i zminimalizować wady architektury mikrousług. W miarę jak usługi stają się coraz mniejsze, zwiększają się korzyści wynikające ze współzależności. Jednak wprowadza to również pewną złożoność. Jej źródłem jest istnienie coraz większej liczby ruchomych części — opowiemy o tym w dalszej części tej książki. Im lepiej uda się obsłużyć tę złożoność, tym łatwiej będzie można stosować coraz mniejsze usługi. Autonomiczne Mikrousługa jest odrębnym podmiotem. Może być wdrożona jako odizolowana usługa w ramach infrastruktury PaaS (Platform as a Service) lub może być procesem systemu operacyjnego. Staramy się unikać pakowania zbyt wielu usług na tej samej maszynie, mimo że definicja maszyny w dzi- siejszym świecie jest dość mglista! Zgodnie z tym, co powiemy później, chociaż ta izolacja może wprowadzić pewien narzut, to wynikowa prostota sprawia, że nasz rozproszony system jest znacznie łatwiejszy do analizowania, a zastosowanie nowszych technologii pozwala złagodzić wiele wy- zwań związanych z tą formą wdrażania. Cała komunikacja pomiędzy samym usługami odbywa się za pośrednictwem wywołań sieci. To pozwala wymusić podział między usługami i unikać niebezpieczeństw związanych ze zbyt ścisły- mi sprzężeniami. Usługi muszą pozwalać na wprowadzanie zmian niezależnie od innych usług oraz pozwalać na odrębne wdrażanie — bez konieczności zmiany konsumentów. Powinniśmy pomyśleć o tym, co nasze usługi mają udostępniać i jakie cechy mają być możliwe do ukrycia. Jeśli istnieje zbyt wiele współdzielenia, usługi konsumenckie stają się sprzężone z wewnętrznymi reprezentacjami. To obniża autonomię, ponieważ wymaga dodatkowej koordynacji z konsumentami podczas wpro- wadzania zmian. Usługa udostępnia interfejs programowania aplikacji (API), przez który komunikują się z nią usługi współpracujące. Musimy także pomyśleć o tym, jaka technologia jest odpowiednia do tego, aby nie wprowadzała sprzężeń z konsumentami. Może to oznaczać wybieranie interfejsów API agnostycznych pod względem technologii, tak by nie ograniczać możliwości wyboru technologii. Do tego, jak ważne są dobre, pozbawione sprzężeń interfejsy API, będziemy powracać w całej książce. Bez eliminacji sprzężeń cała architektura upada. Istnieje złota zasada: czy potrafisz wprowadzić zmiany w usłudze i wdrożyć ją osobno bez zmieniania czegokolwiek innego? Jeśli odpowiedź na to pytanie brzmi „nie”, to wiele korzyści, które omawiamy na kartach całej tej książki, będzie trudne do osiągnięcia. Aby dobrze rozdzielić interfejsy API, należy właściwie zamodelować usługi oraz odpowiednio za- projektować interfejsy API. Ten temat będzie często poruszany w tej książce. Czym są mikrousługi? (cid:95) 21 Poleć książkęKup książkę Najważniejsze korzyści Korzyści ze stosowania mikrousług jest wiele i są one zróżnicowane. Wiele z nich uzyskuje się dla każdego systemu rozproszonego. Stosowanie mikrousług pozwala jednak na osiągnięcie tych ko- rzyści w większym stopniu. Przede wszystkim ze względu na poziom wykorzystania systemów rozproszonych i architektury zorientowanej na usługi. Niejednorodność technologii W systemie złożonym z wielu współpracujących ze sobą usług do zaimplementowania każdej z tych usług można zastosować inną technologię. Pozwala to na wybranie odpowiednich narzędzi dla każdego zadania. Nie trzeba stosować bardziej znormalizowanego, jednego uniwersalnego na- rzędzia, które często pełni funkcję najmniejszego wspólnego mianownika. Jeśli w jednej części systemu trzeba poprawić wydajność, możemy zdecydować się na wykorzystanie innego stosu technologii — takiego, który pozwala łatwiej osiągnąć wymagany poziom wydajno- ści. Możemy też zadecydować że sposób przechowywania danych w różnych częściach systemu będzie różny. Na przykład w sieci społecznościowej interakcje pomiędzy użytkownikami mogą być przechowywane w bazie danych o strukturze grafu. Taka baza danych odzwierciedla charak- ter wielu wewnętrznych powiązań występujących w społeczności, ale posty, które użytkownicy publikują, mogą być przechowywane w magazynie danych zorientowanym na dokumenty. W ten sposób powstaje architektura heterogeniczna, podobna do takiej, którą pokazano na rysunku 1.1. Rysunek 1.1. Mikrousługi pozwalają na łatwe wykorzystywanie różnych technologii Dzięki zastosowaniu mikrousług jesteśmy również w stanie szybciej adaptować technologie i le- piej zrozumieć, jak mogą nam pomóc nowe usprawnienia. Jedną z największych barier podczas próbowania i adoptowania nowych technologii są związane z nimi zagrożenia. W przypadku mo- nolitycznej aplikacji wypróbowanie nowego języka programowania, bazy danych lub frameworka przy każdej zmianie będzie wpływać na duży fragment systemu. W przypadku systemu składają- cego się z wielu usług jest wiele miejsc, w których można wypróbować nowe technologie. Można wybrać usługę, której modyfikacja wiąże się z najmniejszym ryzykiem, i tam spróbować nowej technologii, mając świadomość możliwości ograniczenia wszelkich potencjalnych negatywnych skutków. W wielu firmach przyjmuje się stanowisko, że zdolność szybszej absorpcji nowych tech- nologii przynosi realne korzyści. 22 (cid:95) Rozdział 1. Mikrousługi Poleć książkęKup książkę Wykorzystywanie wielu technologii oczywiście nie przychodzi bez kosztów. W niektórych fir- mach stosowane są pewne ograniczenia odnośnie wyboru języka. Na przykład w firmach Netflix i Twitter najczęściej w roli platformy wykorzystywana jest maszyna wirtualna Javy (Java Virtual Machine — JVM) ze względu na doświadczenia tych firm w zakresie niezawodności i wydajności tego systemu. Firmy te tworzą również biblioteki i narzędzia dla platformy JVM, dzięki którym skalowanie systemów staje się znacznie łatwiejsze, a jednocześnie jest trudne do wykorzystania przez usługi i aplikacje klienckie, które nie są napisane w Javie. Ale ani Twitter, ani Netflix nie stosują tylko jednego stosu technologii do realizacji wszystkich zadań. Innym czynnikiem, który należy wziąć pod uwagę w przypadku mieszania różnych technologii, jest skala systemu. Jeśli na- prawdę można przepisać mikrousługę w ciągu dwóch tygodni, z łatwością może również zmniej- szyć zagrożenia związane z zastosowaniem nowej technologii. Podczas lektury tej książki przekonamy się, że w wielu aspektach projektowania systemów bazu- jących na mikrousługach najistotniejsze jest znalezienie odpowiedniej równowagi. Sposoby do- konywania wyboru technologii omówimy w rozdziale 2., który skupia się na ewolucji architektury, a także w rozdziale 4., poświęconym zagadnieniom integracji. Dowiemy się z nich, w jaki sposób zapewnić ewolucję stosowanych technologii wewnątrz usług niezależnie od siebie — bez zbęd- nych sprzężeń. Odporność na błędy Kluczowym pojęciem w inżynierii odporności na błędy są tzw. przegrody (bulkhead). Jeśli jeden składnik systemu ulegnie awarii, ale ta awaria nie rozprzestrzenia się kaskadowo, to można wy- izolować problem, a reszta systemu może kontynuować pracę. Granice usług stają się oczywistymi przegrodami. W usłudze monolitycznej awaria powoduje, że wszystko przestaje działać. System monolityczny można uruchomić na wielu maszynach, aby zmniejszyć ryzyko awarii, ale w przy- padku mikrousług możemy budować systemy, które obsługują całkowitą awarię usług i odpo- wiednią degradację funkcjonalności. Trzeba jednak zachować ostrożność. Aby upewnić się, że systemy bazujące na mikrousługach właściwie wykorzystują tę poprawioną odporność, musimy zdać sobie sprawę z nowych źródeł awarii, z którymi muszą sobie radzić systemy rozproszone. Sieci, podobnie jak komputery, mogą ulegać awariom i to czasami się zdarza. Trzeba wiedzieć, jak sobie z tym poradzić i jaki wpływ (jeśli w ogóle) powinna mieć awaria na użytkowników naszego oprogramowania. Więcej informacji na temat obsługi odporności na błędy oraz sposobów obsługi trybów awarii można znaleźć w rozdziale 11. Skalowanie W dużej monolitycznej usłudze wszystkie elementy muszą być skalowane razem. Jedna mała część całego systemu ma ograniczoną wydajność, ale jeśli to zachowanie jest zamknięte w gigantycznej monolitycznej aplikacji, musimy obsłużyć skalowanie wszystkiego jako komponentu. W przypadku korzystania z mniejszych usług możemy skalować tylko te usługi, które wymagają skalowania. Dzięki temu inne części systemu mogą być uruchamiane na słabszym sprzęcie (patrz rysunek 1.2). Najważniejsze korzyści (cid:95) 23 Poleć książkęKup książkę Rysunek 1.2. Skalowanie może dotyczyć tylko tych mikrousług, które wymagają skalowania Gilt, firma zajmująca się internetową sprzedażą detaliczną odzieży, zastosowała mikrousługi do- kładnie w tym celu. W 2007 roku system miał postać monolitycznej aplikacji Rails. Do 2009 roku system firmy Gilt nie był w stanie obsłużyć przychodzącego obciążenia. Dzięki podzieleniu pod- stawowych części swojego systemu firmie Gilt udało się lepiej obsłużyć szczytowe natężenie ruchu. Obecnie system składa się z ponad 450 mikrousług, z których każda działa na kilku odrębnych komputerach. W przypadku systemów konfigurowania na żądanie, podobnych do tych, które są stosowane w usługach Amazon Web Services, można nawet stosować skalowanie na żądanie tylko dla tych fragmentów, które tego wymagają. To pozwala skuteczniej kontrolować koszty. Sytuacja, w której zmiany w architekturze są tak ściśle skorelowane z niemal natychmiastowymi oszczędnościami, nie jest zbyt częsta. Łatwość wdrażania Opublikowanie zmiany jednego wiersza w monolitycznej aplikacji zawierającej milion wierszy kodu wymaga przygotowania wydania całej aplikacji. To może być operacja wywierająca duży wpływ na użytkowników i obarczona wysokim ryzykiem. W praktyce takie operacje są wyko- nywane rzadko ze względu na zrozumiałe obawy. Niestety, to oznacza, że liczba zmian pomiędzy wydaniami kumuluje się. Kiedy nowa wersja aplikacji trafi do produkcji, zawiera olbrzymią liczbę zmian w porównaniu z poprzednią wersją. A im większe różnice pomiędzy wydaniami, tym więk- sze ryzyko popełnienia błędów! W przypadku zastosowania mikrousług możemy wprowadzić zmiany w pojedynczej usłudze i wdrożyć ją niezależnie od reszty systemu. Ta własność pozwala nam na szybsze wdrażanie kodu. Jeśli wystąpi problem, może być szybko wyizolowany do pojedynczej usługi. Dzięki temu można łatwo cofnąć wprowadzoną zmianę. Oznacza to również, że możemy łatwiej udostępnić nową funkcjonalność klientom. Jest to jeden z głównych powodów, dla których takie firmy jak Amazon i Netflix stosują takie architektury — robią to po to, aby usunąć jak najwięcej przeszkód związa- nych z publikowaniem oprogramowania. 24 (cid:95) Rozdział 1. Mikrousługi Poleć książkęKup książkę W ciągu ostatnich kilku lat technologia w tym obszarze znacznie się zmieniła. Więcej informacji na temat wdrażania mikrousług można znaleźć w rozdziale 6. Dopasowanie do organizacji zespołów Wielu z nas doświadczyło problemów związanych z dużymi zespołami i rozbudowanymi bazami kodu. Problemy te mogą się dodatkowo nasilić w przypadku, gdy zespół jest rozproszony. Wiemy również, że mniejsze zespoły pracujące na mniejszych bazach kodu zwykle są bardziej wydajne. Mikrousługi pozwalają na lepsze dopasowanie architektury do organizacji oraz pomagają zmini- malizować liczbę osób pracujących nad określoną bazą kodu. W ten sposób można łatwiej dosto- sować proporcje pomiędzy wielkością zespołu a jego wydajnością. Możemy również dokonać zmiany własności usług pomiędzy zespołami, aby osoby zajmujące się jedną usługą pracowały we wspólnej lokalizacji. Znacznie więcej szczegółów na ten temat podamy przy okazji omawiania prawa Conwaya w rozdziale 10. Interoperatywność Jedną z głównych korzyści, jaką powinno przynieść zastosowanie systemów rozproszonych i ar- chitektury zorientowanej na usługi, jest możliwość wielokrotnego wykorzystania funkcjonalności. W przypadku systemu bazującego na mikrousługach funkcjonalności mogą być wykorzystywane w różny sposób w różnych celach. Może to być szczególnie ważne w przypadku, gdy weźmiemy pod uwagę sposób, w jaki konsumenci używają naszego oprogramowania. Dawno minęły czasy, kiedy można było postrzegać aplikację w wąskiej perspektywie — jako aplikację desktop, witrynę WWW lub aplikację mobilną. Obecnie trzeba wziąć pod uwagę mnóstwo sposobów kombinowa- nego wykorzystania możliwości oprogramowania w internecie, aplikacjach natywnych, mobilnych witrynach Web, aplikacjach na tablety, telefony komórkowe lub urządzenia przenośne. W miarę jak organizacje odchodzą od myślenia w kategoriach wąskich kanałów i skłaniają się do bardziej holistycznych koncepcji zaangażowania klienta, potrzebujemy architektur, które będą mogły sprostać nowym wymaganiom. Zastosowanie mikrousług pozwala nam zwolnić szwy w naszym systemie, które mogą być wyko- rzystane do integracji systemów zewnętrznych. W przypadku zmian okoliczności możemy zbu- dować system w inny sposób. Aplikacje monolityczne często są wyposażone w jeden „gruby szew”, który może być użyty z zewnątrz. Aby zerwać ten szew w celu uzyskania czegoś bardziej poży- tecznego, potrzebny jest młot! W rozdziale 5. zostaną omówione sposoby podziału istniejących monolitycznych systemów i ich modyfikowania do postaci mikrousług umożliwiających wielo- krotne użytkowanie i komponowanie w dowolnych konfiguracjach. Optymalizacja w kierunku wymienności W dużych lub średnich firmach często działają duże, rozbudowane i przestarzałe systemy. Są to systemy, których nikt nie chce dotykać. Mają kluczowe znaczenie dla działania firmy, ale często zostały napisane w jakimś dziwnym dialekcie Fortrana i działają wyłącznie na sprzęcie, którego nie produkuje się od co najmniej 25 lat. Dlaczego taki system nie został zastąpiony innym? Wia- domo dlaczego: jest zbyt duży, a jego wymiana zbyt ryzykowna. Najważniejsze korzyści (cid:95) 25 Poleć książkęKup książkę W przypadku pojedynczych usług niewielkich rozmiarów koszty zastąpienia wybranej usługi inną, lepszą implementacją, lub nawet całkowita rezygnacja z pojedynczej usługi, są znacznie niższe, a operacja jest znacznie łatwiejsza do przeprowadzenia. Przypomnijmy sobie, jak często zdarza się nam usunąć ponad sto wierszy kodu jednego dnia, nie martwiąc się zbytnio tym, jakie zmiany to spowoduje. Ponieważ mikrousługi często mają podobne rozmiary, opór przed przepisaniem lub całkowitym usunięciem usługi jest bardzo mały. Zespoły stosujące architektury bazujące na mikrousługach nie wahają się przepisywać od podstaw usług, jeśli zachodzi taka konieczność, lub po prostu eliminować pojedynczych usług, jeśli prze- staną one być potrzebne. Jeśli baza kodu obejmuje zaledwie kilkaset wierszy, trudno emocjonal- nie się do niej przywiązać, a koszty zastąpienia jej inną są dość małe. Architektura zorientowana na usługi Architektura zorientowana na usługi (service-oriented architecture — SOA) to podejście do pro- jektowania, w którym wiele usług współpracuje ze sobą w celu świadczenia pewnego skończonego zbioru możliwości. Usługa zazwyczaj oznacza w tym przypadku całkowicie odrębny proces sys- temu operacyjnego. Komunikacja pomiędzy tymi usługami odbywa się za pośrednictwem wy- wołań przez sieć zamiast wywołań metod w granicach procesu. Architektury SOA pojawiły się jako podejście do zwalczania wyzwań właściwych dla dużych, mo- nolitycznych aplikacji. Jest to podejście, które ma na celu promowanie wielokrotnego wykorzy- stania oprogramowania. Na przykład dwie lub większa liczba aplikacji użytkowych mogą jedno- cześnie korzystać z tych samych usług. Architektury SOA mają na celu ułatwienie utrzymania lub przepisania oprogramowania. Teoretycznie można zastąpić jedną usługę inną bez niczyjej wiedzy, pod warunkiem że semantyka nowej usługi zbytnio się nie zmieni. SOA w swojej istocie jest bardzo sensownym pomysłem. Jednak pomimo wielu wysiłków brakuje dobrego konsensusu co do tego, w jaki sposób dobrze budować architektury SOA. Moim zdaniem wśród większości przedstawicieli branży brakuje dostatecznie holistycznego spojrzenia na ten problem. Prezentowane są przekonujące alternatywy wyrażane przez różnych dostawców. Wiele problemów przyporządkowywanych do architektury SOA to w rzeczywistości problemy dotyczące takich elementów jak protokoły komunikacyjne (na przykład SOAP), dostawcy warstwy middleware, brak wytycznych na temat ziarnistości usługi lub niewłaściwe wytyczne dotyczące wyboru miejsc podziału systemu. Każdym z tych problemów zajmiemy się po kolei w dalszej czę- ści książki. Cynik mógłby zasugerować, że producenci wykorzystali (a w niektórych przypadkach zmodyfikowali) ruch SOA do zwiększenia sprzedaży swoich produktów. Takie podejście w gruncie rzeczy pozostaje w sprzeczności z celem SOA. Znaczna część wiedzy na temat SOA nie pozwala zrozumieć tego, jak podzielić duży system w taki sposób, by uzyskać mały. Nie wynika z niej odpowiedź na pytanie: jak dużo, to za dużo. Nie mówi wystarczająco dużo na temat rzeczywistych, praktycznych sposobów eliminacji niepotrzebnych sprzężeń pomiędzy usługami. Te wszystkie niedopowiedziane rzeczy są źródłem wielu pułapek związanych z architekturami SOA. 26 (cid:95) Rozdział 1. Mikrousługi Poleć książkęKup książkę Podejście do projektowania bazujące na mikrousługach pochodzi z zastosowań w rzeczywistym świecie, uwzględnia lepsze zrozumienie systemów i architektury tak, by właściwie projektować architekturę SOA. Zatem o mikrousługach powinniśmy myśleć raczej jak o szczególnym podej- ściu do SOA, na podobnej zasadzie, na jakiej XP lub Scrum prezentują specyficzne podejście do zwinnego wytwarzania oprogramowania. Inne techniki dekompozycji Kiedy przyjrzymy się mikrousługom bliżej, okaże się, że wiele zalet architektury bazującej na mi- krousługach wynika z jej granularnej natury oraz tego, że gwarantuje ona dużo więcej możliwości rozwiązywania problemów. Jednak czy można osiągnąć te same korzyści, stosując inne techniki dekompozycji? Biblioteki współdzielone Standardową techniką dekompozycji, która jest wbudowana w praktycznie każdym języku pro- gramowania, jest podzielenie bazy kodu na wiele bibliotek. Biblioteki te mogą być dostarczane przez producentów zewnętrznych lub tworzone we własnym zakresie. Biblioteki gwarantują sposób współdzielenia funkcjonalności pomiędzy zespołami i usługami. Na przykład można utworzyć kolekcję przydatnych narzędzi lub bibliotekę obliczeń statystycz- nych, która może być wykorzystywana wielokrotnie. Wokół tych bibliotek można organizować zespoły, a same biblioteki mogą być wykorzystywane wielokrotnie. Są jednak pewne wady takiego podejścia. Po pierwsze, tracimy prawdziwą różnorodność technologii. Biblioteki zazwyczaj muszą być napi- sane w tym samym języku lub przynajmniej działać na tej samej platformie. Po drugie, łatwość, z jaką można skalować części systemu niezależnie od siebie, jest ograniczona. Poza tym, jeśli nie używamy bibliotek łączonych dynamicznie, nie możemy zainstalować nowej biblioteki bez po- nownej instalacji całego procesu, zatem zdolność do wdrażania zmian w izolacji jest ograniczona. I być może najgorszy jest brak oczywistych „szwów”, które zapewniają architekturze środki bez- pieczeństwa uodparniające system na awarie. Biblioteki współdzielone mają swoje zastosowania. Czasami tworzy się kod dla typowych zadań, które nie są specyficzne dla domeny biznesowej, a które mają być wielokrotnie wykorzystywane w różnych miejscach organizacji. Taki kod jest oczywistym kandydatem do tego, by stać się bi- blioteką wielokrotnego użytku. Trzeba jednak zachować ostrożność. Współdzielony kod używany do komunikacji między usługami może stać się punktem sprzężeń — czymś, co będziemy oma- wiali w rozdziale 4. W usługach można i należy korzystać z zewnętrznych bibliotek w celu wielokrotnego wykorzy- stywania wspólnego kodu. Jednak nie są one rozwiązaniem wszystkich problemów. Inne techniki dekompozycji (cid:95) 27 Poleć książkęKup książkę Moduły W niektórych językach dostępne są odrębne techniki dekompozycji bazujące na modułach, któ- rych możliwości wykraczają poza proste biblioteki. Pozwalają one na zarządzanie cyklem życia modułów — na przykład możliwością instalowania wewnątrz działających procesów, co pozwala na wprowadzanie zmian bez zatrzymywania całego procesu. Warto wymienić projekt OSGi (Open Source Gateway initiative) jako przykład specyficznego dla technologii podejścia do dekompozycji na moduły. W Javie nie istnieje rzeczywista koncepcja modułów. Na dodanie tej konstrukcji do języka trzeba będzie poczekać co najmniej do publikacji Java 9. Obecnie, aby dodać koncepcję modułów w Javie za pośrednictwem biblioteki, wykorzy- stywany jest komponent OSGi, który pojawił się jako framework umożliwiający instalowanie wtyczek w środowisku IDE języka Java Eclipse. Problem z OSGi polega na tym, że framework ten stara się wprowadzić takie elementy jak zarzą- dzanie cyklem życia modułów bez wystarczającego wsparcia w obrębie samego języka. W efekcie autorzy modułów, aby zapewnić właściwą izolację, muszą wykonać więcej pracy. Ponadto w ra- mach procesu znacznie łatwiej wpaść w pułapkę tworzenia modułów zbyt mocno sprzężonych ze sobą, co sprawia różnego rodzaju problemy. Moje doświadczenia z OSGi (pokrywają się one z do- świadczeniami moich kolegów z branży) są takie, że nawet w przypadku dobrych zespołów łatwo doprowadzić do sytuacji, w której framework OSGi staje się znacznie większym źródłem złożono- ści niż gwarantem korzyści. W języku Erlang zastosowano inne podejście — moduły są wbudowane w mechanizm wykonawczy (runtime) języka. Tak więc w języku Erlang zastosowano bardzo dojrzałe podejście do dekompo- zycji na moduły. Moduły Erlanga bez problemu można zatrzymać, zrestartować i zaktualizować. Erlang obsługuje nawet uruchamianie więcej niż jednej wersji modułu w danym momencie, co pozwala na łatwiejszą aktualizację modułów. Możliwości modułów Erlanga są rzeczywiście imponujące, ale nawet jeśli mamy szczęście korzy- stać z platformy gwarantującej takie możliwości, nadal musimy znosić te same wady jak w przy- padku zastosowania standardowej współdzielonej biblioteki. Jesteśmy ściśle ograniczeni w zdol- ności do korzystania z nowych technologii. Ograniczeni możliwościami niezależnego skalowania, sposobami dryfowania w kierunku technik integracji, które są nadmiernie sprzężone, i pozbawieni szwów spełniających rolę środków bezpieczeństwa dla architektury. Mam jedno spostrzeżenie — według mnie godne uwagi. Z technicznego punktu widzenia powinno być możliwe tworzenie dobrze ukształtowanych, niezależnych modułów w obrębie pojedynczego monolitycznego procesu. Pomimo to rzadko można spotkać tego rodzaju architektury. Same moduły szybko stają się ściśle powiązane z pozostałą częścią kodu, co zaprzecza jednej z ich naj- ważniejszych zalet. Uzyskanie separacji granic procesu egzekwuje czystą higienę pod tym wzglę- dem (lub przynajmniej utrudnia stosowanie niewłaściwych praktyk). Oczywiście nie sugeruję, że to powinno być głównym motorem dla separacji procesów, ale interesujące jest to, że separacja modułów w granicach procesu jest rzadko spotykana w rzeczywistym świecie. 28 (cid:95) Rozdział 1. Mikrousługi Poleć książkęKup książkę O ile zatem dekompozycja na moduły w granicach procesu może być czymś, co chcielibyśmy zrobić razem z dekompozycją systemu na usługi, o tyle sama dekompozycja na moduły nie po- może rozwiązać wszystkich problemów. Jeśli programujemy wyłącznie w języku Erlang, jakość implementacji modułów w Erlangu może nam bardzo pomóc, ale nie podejrzewam, aby zbyt wielu Czytelników było w takiej sytuacji. Reszta z nas powinna postrzegać moduły jako mechani- zmy oferujące te same korzyści co biblioteki współdzielone. Nie istnieje panaceum na wszystko Zanim zakończymy ten rozdział, powinienem podkreślić, że mikrousługi nie są „darmowym obiadem” czy „srebrną kulą” i nie sprawdzą się jako złoty młotek. Mają wszystkie zawiłości zwią- zane z systemami rozproszonymi i o ile dowiedzieliśmy się sporo o tym, jak należy właściwie za- rządzać systemami rozproszonymi (które będziemy omawiać w całej książce), o tyle zarządzanie nimi jest pomimo wszystko trudne. Jeżeli nasze spojrzenie na systemy ewoluuje z perspektywy systemu monolitycznego, będziemy musieli znacznie więcej uwagi poświęcić zagadnieniom ob- sługi wdrażania, testowania i monitorowania tak, aby odblokować korzyści, o których opowie- dzieliśmy do tej pory. Będziemy również musieli inaczej podejść do skalowania systemów i zapew- nić ich odporność na awarie. Nie powinniśmy również być zaskoczeni koniecznością uwzględnienia takich elementów jak transakcje rozproszone lub twierdzenie CAP! Każda firma, organizacja i system mają inną specyfikę. Na to, czy mikrousługi są właściwe w da- nej sytuacji oraz na jaką agresywność można sobie pozwolić podczas ich wdrażania, wpływa sze- reg czynników. W każdym rozdziale w tej książce spróbuję przekazać wskazówki podkreślające potencjalne pułapki. Wskazówki te powinny pomóc w wytyczeniu stabilnej ścieżki postępowania. Podsumowanie Mam nadzieję, że po lekturze tego rozdziału Czytelnik wie, czym są mikrousługi i co odróżnia je od innych technik kompozycji, a także jakie są niektóre ich główne atuty. W każdym z następnych rozdziałów będziemy prezentowali więcej szczegółów na temat możliwości wykorzystania tych atutów, a także powiemy, jak uniknąć niektórych typowych pułapek. Jest szereg tematów do omówienia, ale trzeba od czegoś zacząć. Jednym z głównych wyzwań, któ- re stawiają przed nami mikrousługi, jest zmiana roli tych, którzy często sterują ewolucją naszych systemów: architektów. W następnym rozdziale przyjrzymy się kilku różnym aspektom tej roli — takim, które pozwolą uzyskać z opisywanej nowej architektury jak najwięcej korzyści. Podsumowanie (cid:95) 29 Poleć książkęKup książkę 30 (cid:95) Rozdział 1. Mikrousługi Poleć książkęKup książkę Skorowidz bezpieczniki, 225 BFF, backends for frontends, 89 biblioteki klienckie, 77 współdzielone, 27 blokada usług, 203 brama pojedynczego logowania, 189 budowanie zespołu, 44 buforowanie, 239 dla poprawy niezawodności, 242 na serwerze proxy, 239 operacji zapisu, 242 po stronie klienta, 239 po stronie serwera, 239 w HTTP, 240 C CaaS, Containers as a Service, 144 CD, continuous delivery, 125 CDC, consumer-driven contract, 162 cele COBIT, 43 cele strategiczne, 36 certyfikaty klienta, 193 CFR, cross-functional requirements, 169 chmury VPC, 200 choreografia, 61, 63 CI, continuous integration, 121 ciągła dostawa, CD, 125 integracja, CI, 121 CMS jako usługa, 93 Conway Melvin, 207 CP, 249 CQRS, 238 CRM, Customer Relationship Management, 94 A abstrakcje repozytoriów, 49 aktualizacja tabel, 108 Amazon, 208 antykrucha organizacja, 224 AP, 249 API, 21 aplikacja-dusiciel, 222 aranżacja, 61, 62 architekt, 32 IT, 33 kodowania, 35 architektura na cebulkę, 54 SOA, 48 zorientowana na usługi, 26 artefakty specyficzne dla platformy, 127 systemu operacyjnego, 128 atak man-in-the-middle, 191 atrapy, 155 automatyzacja, 139, 260 autonomia, 21, 45 autoryzacja, 187, 191 szczegółowa, 190 autoskalowanie, 245 awarie, 219 kaskadowe, 182 B baza danych, 59, 100 raportowania, 111 bezpieczeństwo, 99, 187 architektury, 39, 222 265 Poleć książkęKup książkę CRUD, create, read, update, delete, 52 czas reakcji, 221 czynnik ludzki, 204 D Datensparsamkeit, 204 DDD, domain-driven design, 19 decentralizacja wszystkich operacji, 261 definicja maszyny, 21 środowiska, 146 degradowanie funkcjonalności, 221 dekompozycja, 51 dług techniczny, 42 długi ogon danych, 113 dni ćwiczeń, 224 DNS, 251 Docker, 144 dokumentowanie usług, 255 dostawca tożsamości, 188 usług, 188 dostęp przez referencję, 78 dostępność, 221, 246, 247 usługi, 236 DRY, don’t repeat yourself, 77 dynamiczne rejestry usług, 252 działanie bezpieczników, 226 E eliminowanie relacji kluczy obcych, 101 empatia, 45 F fałszywki, 155 firma MusicCorp, 47 format HTML, 71 JSON, 70 JSONPATH, 71 XML, 70 XPATH, 71 framework, 41 OSGi, 28 REST, 72 fronton, 89 266 (cid:95) Skorowidz granice techniczne, 54 transakcyjne, 107 usług, 55 grodzie, 227 G H HAL, Hypertext Application Language, 71 hipermedium, 68 hipernadzorca, 141 HMAC, hash-based messaging code, 194 I IaaS, Infrastructure as a Service, 144, 177 idempotencja, 229 identyfikator korelacji, 180 URI, 83 IDS, intrusion detection systems, 200 implementacja, 58 grodzi, 228 monitorowania semantycznego, 179 pojedynczego logowania, 188 RPC, 65 testów usług, 154 współpracy asynchronicznej, 73 zabezpieczeń, 201 informacje o klientach, 59 instalacja niezależna, 262 usługi, 145 integracja, 57, 92 interfejs, 39 API, 86 instalacji, 145 programowania aplikacji, 21 REST, 72, 96 RPC, 96 użytkownika, 84, 87 z klientami, 58 interoperatywność, 25 IPS, intrusion prevention systems, 200 izolacja, 229 izolowanie awarii, 262 Poleć książkęKup książkę J Java RMI, 65 jedna usługa, 174 na host, 137 język Erlang, 28 HAL, 71, 256 JVM, Java Virtual Machine, 23 JWT, JSON Web Token, 194 K kaskada, 182 klucze, 198 API, 195 obce, 101 kompilacja CI, 124 na mikrousługę, 125 komponenty interfejsu użytkownika, 87 kompozycja interfejsów API, 86 komunikacja, 54 asynchroniczna, 60, 74 synchroniczna, 60 konfiguracja ostatecznie spójna, 236 usługi, 133 konta usług, 193 kontekst, 49, 98 klienta, 105 ograniczony, 214 kontenery, 142 aplikacji, 136 kontrola wersji, 81, 92 konwersacje, 165 końcowa spójność, 109 kończenie sesji SSL, 233 kopia zapasowa, 117 korelacje, 180 koszty zmiany, 117 kwadrant testowania, 150 L limity czasu, 225 LOB, line of business, 215 logi, 176 lokalizacje docelowe, 115 luźne sprzężenia, 48 Ł łączenie zasad i praktyk, 37 M mapowanie ciągłej integracji, 123 maskowanie systemu CRM, 95 maszyna JVM, 23, 136 stanów, 76 wirtualna, 130 mechanizm semantycznego monitorowania, 263 SSO, 189 wykonawczy, 28 XPath, 80 menedżer transakcji, 109 metadane, 202 metryki usług, 178 mieszanie hasła z solą, 198 mikrousługi, 13, 19, 123, 260 w projektach dużej skali, 219 modele ukryte, 49 współdzielone, 49 modelowanie usług, 47, 54 moduły, 28 moduły i usługi, 51 modyfikowanie interfejsu, 80 monitorowanie, 39, 173 semantyczne, 165, 263 syntetyczne, 178 monolityczna usługa, 99 możliwości biznesowe, 52 przystosowawcze, 45 N namiastka usługi, 155 narzędzie ELB, 147 LXC, 142 Pact, 163 Netflix, 208 Newman Sam, 265 niezależność interfejsów API, 57 niezawodność, 242 Skorowidz (cid:95) 267 Poleć książkęKup książkę O obiekty fikcyjne, 155 obowiązki ewolucyjnego architekta, 45 obraz maszyny wirtualnej, 130 obrazy jako artefakty, 131 obrona wielostrefowa, 190, 199 obsługa operacji odczytu, 236 operacji zapisu, 237 systemu e-commerce, 234 wyjątków, 42 wywołań, 89 oddzielanie wdrożenia od publikacji, 167 odporność na błędy, 23 odrzucenie operacji, 109 odwrócone prawo Conwaya, 216 odwzorowanie usługa-host, 133 ograniczenia, 85 ograniczone konteksty, 49, 53 opcje wyboru technologii, 73 OpenID Connect, 192 operacje CRUD, 52 oprogramowanie zewnętrznych producentów, 91 optymalizacja, 25 organizacja zespołów, 25 organizacje sprzężone, 208 P PaaS, Platform as a Service, 21, 119, 138, 144 pakiet, 98 personalizacja, 92, 93 pierścień, 238 piramida testów, 151, 163 platforma jako usługa, PaaS, 21, 119, 138, 144 wdrożeń, 141 pobieranie danych, 112 podział obciążeń, 231 sieci, 200 systemu, 98 pojedyncza operacja, 108 transakcja, 108 usługa, 174 pojedyncze logowanie, SSO, 188 pojęcia biznesowe, 54 268 (cid:95) Skorowidz pompa danych, 114 sterowana zdarzeniami, 116 z kopii zapasowej, 117 poświęcenie dostępności, 247 spójności, 247 tolerancji podziału, 248 potoki kompilacji, 125 poziom usług, 232 pozyskiwanie zdarzeń, 239 praktyki, 37 prawo Conwaya, 207, 216 prezentowanie interfejsu użytkownika, 86 problem wspólnej tabeli, 106 zastępcy, 195, 196 zdezorientowanego zastępcy, 196 projekt dużej skali, 219 OSGi, 28 sterowany testami, TDD, 152 projektowanie systemów, 207 tematyczne, 19 prostota usługi, 58 protokół HTTP, 68 TLS, 193 przeglądarka HAL, 256 przykładowe egzemplarze, 40 publikacja, 166 kanarkowa, 167 niebieska-zielona, 166 punkt końcowy, 82 usługi, 65 R raportowanie, 111 RDBMS, 236 redukcja obciążenia, 228 refaktoryzacja baz danych, 106 referencja, 78 rejestrowanie, 200 relacje kluczy obcych, 101 relacyjna baza danych, 236 replikacja odczytu, 111 w trybie multiprimary, 247 Poleć książkęKup książkę repliki odczytu, 236 repozytorium kodu źródłowego, 124, 125 REST, REpresentational State Transfer, 67 rodzaje testów, 149 rozdzielanie warstw repozytorium, 101 rozłożenie ryzyka, 231 rozszerzenia reaktywne, 76 równoległe wersje usługi, 83 równoważenie obciążenia, 232 RPC, Remote Procedure Call, 54, 67 rywalizujący konsument, 74 S SAML, 188, 192 schemat raportowania, 115 semantyczna kontrola wersji, 81 serwery niezmienne, 131 sieci WiFi, 202 silnik stanu aplikacji, 68 skalowanie, 23, 230 baz danych, 236 operacji odczytu, 236 operacji zapisu, 237 systemu, 220 SLA, Service Level Agreement, 232 SOA, service-oriented architecture, 26 SOAP, 64 specyfikacja ATOM, 74 spersonalizowane obrazy, 129 spójność, 246, 247 sprzężenia technologii, 64 SSO, single sign on, 188 standard ATOM, 74 standardy, 38 standaryzacja, 182 stos technologii, 22 stosowanie mikrousług, 22 strefy, 34 struktura zespołu, 99, 214 system AP, 247, 249 bezpieczny, 203 Consul, 253 CP, 249 CRM, 94 DNS, 251 Docker, 144 Eureka, 254 Kibana, 176 kontroli wersji, 92 niezabezpieczony, 202 operacyjny, 201 samoopisujący się, 257 Swagger, 256 Zookeeper, 252 systemy wykrywania włamań, IDS, 200 zapobiegania włamaniom, IPS, 200 szablony usług, 40 szew, seam, 97 szyfrowanie kopii zapasowych, 199 Ś ścieżki komunikacyjne, 209 śledzenie łańcuchów wywołań, 181 metryk, 177 śnieżny stożek testów, 154 średni czas do naprawy, 168 czas między awariami, 168 środki bezpieczeństwa architektury, 222 środowisko, 131, 146 T tabele współdzielone, 105 TDD, test-driven design, 152 TDE, Transparent Data Encryption, 198 techniki dekompozycji, 27 technologia, 22, 100 HAL, 257 JWT, 194 REST, 67 TDE, 198 technologie integracji, 57 tempo zmian, 99 testowanie, 149 po opublikowaniu systemu, 166 ścieżki, 161 według potrzeb konsumenta, 162, 163 testy CDC, 162 dymne, 166 jednostkowe, 152 kruche i łamliwe, 158 Skorowidz (cid:95) 269 Poleć książkęKup książkę testy od końca do końca, 153, 156 metawersje, 161 obsługa standardowa, 157 używanie, 165 wady, 157 usług, 152, 154 współzależności funkcjonalnych, 169 wydajności, 170 TLS, Transport Layer Security, 193 tolerancja podziału, 246, 248 transakcja kompensacyjna, 109 rozproszona, 109 syntetyczna, 179 trwałość danych, 221, 236 twierdzenie CAP, 246 tworzenie klienta, 62, 63 U ukrywanie systemu CMS, 94 szczegółów implementacji, 261 źródła, 242 usługa AWS, 234 katalogowa, 188 monolityczna, 99 osierocona, 214 usługa-host, 133 usługa-usługa, 191 usługi AWS, 143 jako maszyny stanów, 76 kleiste, 94 na hoście, 134 RESTFul, 71 sidecar, 41 w osobnych kontenerach, 143 uwierzytelnianie, 187, 191 podstawowe HTTP, 192 używanie mikrousług, 263 V Vagrant, 141 VLAN, 233 VMware, 130 VPC, virtual private cloud, 200 270 (cid:95) Skorowidz W wady interfejsu REST, 72 warstwy repozytorium, 101 wąskie gardła dostaw, 212 wątki robocze, 234 wczesne wychwytywanie zmian, 81 wdrażanie, 24, 121, 166 zabezpieczeń, 205 wewnętrzne Open Source, 212 wiele serwerów, 174, 175 usług, 175, 177 wielokrotne wykorzystanie kodu, 77 Windows Vista, 208 wirtualizacja, 140 typu 2, 141 wirtualna chmura prywatna, VPC, 200 wizja, 45 własność usługi, 210 wskaźnik MTTR, 171 wspólna baza danych, 59 wspólne statyczne dane, 103 współdzielenie usług, 211 współdzielone dane, 104 współdzielony model, 50 współistnienie punktów końcowych, 82 współpraca, 45 sterowana zdarzeniami, 61 wszechobecny język, 49 wyjątki, 126 wykrywanie usług, 250 wymagania niefunkcjonalne, 169 wymogi współzależności funkcjonalnych, CFR, 169 wysoka spójność, 48 wywołania lokalne, 65 RPC, 67 usług, 112 zdalne, 65 wzorzec BFF, 89 CQRS, 238 Dusiciel, 95 Z zabezpieczanie danych, 197 zakres testów, 150 jednostkowych, 152, 153 Poleć książkęKup książkę zależności, 100 zaplecza dla frontonów, 89, 90 zapory firewall, 199 zarządzanie, 40, 43, 45 połączeniami SSL, 233 wersjami, 80 zasada pojedynczej odpowiedzialności, 20 zasady, 36 dotyczące mikrousług, 259 zatrucie pamięcią podręczną, 244 zatwierdzanie dwufazowe, 109 zdalne wywoływanie procedury, 54, 64 zdarzenia, 73, 116 zespoły funkcyjne, 211 zestaw testów dymnych, 166 zewnętrzna weryfikacja, 206 złota reguła, 204 Ż żądanie GET, 241 żądanie-odpowiedź, 61 Skorowidz (cid:95) 271 Poleć książkęKup książkę Poleć książkęKup książkę
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Budowanie mikrousług
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: