Mikroserwisy w akcji. Отсутствует
co jest doskonale widoczne w tej kolekcji. Fascynacja odległymi krainami i podróże dla przyjemności były stosunkowo nowymi zjawiskami pod koniec XVIII w., 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 tomach Jefferysa jaskrawo mówi o wyjątkowości i indywidualności narodów świata około 200 lat temu. Od tego czasu sposoby ubierania uległy zmianie, a znaczna różnorodność w zależności od regionu i kraju, tak bogata w tamtym czasie, zanikła. Obecnie trudno jest odróżnić mieszkańców jednego kontynentu od drugiego. Być może, próbując spojrzeć na to optymistycznie, 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 drugiej, 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.
Część 1
Stan rzeczy
Wtej części wprowadzimy architekturę mikroserwisową, przedstawimy właściwości i zalety aplikacji mikroserwisowych oraz niektóre wyzwania, z jakimi trzeba się zmierzyć przy ich tworzeniu. Wprowadzimy SimpleBank – fikcyjną firmę, w której próby zbudowania aplikacji mikroserwisowej będą wspólnym wątkiem w wielu przykładach wykorzystywanych w tej książce.
1. Projektowanie i uruchamianie mikroserwisów
Niniejszy rozdział dotyczy:
■ definiowania aplikacji mikroserwisowych,
■ wyzwań związanych z podejściem opartym na mikroserwisach,
■ podejść do projektowania aplikacji mikroserwisowych,
■ podejść do skutecznego uruchamiania mikroserwisów.
Twórcy oprogramowania starają się tworzyć efektywne i ponadczasowe rozwiązania złożonych problemów. Pierwszy problem, który zazwyczaj próbujemy rozwiązać, to: Czego chce nasz klient? Jeśli mamy umiejętności (lub szczęście), uzyskamy odpowiedź. Ale nasze wysiłki rzadko się na tym kończą. Nasza udana aplikacja nadal będzie się rozwijać: debugujemy problemy, budujemy nowe funkcjonalności, zapewniamy, aby była dostępna i działała płynnie.
Nawet najbardziej zdyscyplinowane zespoły mogą borykać się z utrzymaniem początkowego tempa i zwinności w obliczu rozwoju aplikacji. W najgorszym przypadku nasz prosty i stabilny produkt staje się trudny i wrażliwy. Nie mamy możliwości zrównoważonego dostarczania dodatkowych funkcjonalności swoim klientom. Jesteśmy zmęczeni z powodu przestojów, lęku przed zwolnieniem i zbyt powolni, aby dostarczyć nowe funkcjonalności lub poprawki. Ani nasi klienci, ani nasi programiści nie są szczęśliwi.
Mikroserwisy oferują lepszy sposób zrównoważonego wpływania na biznes. Zamiast pojedynczej monolitycznej jednostki aplikacje zbudowane przy użyciu mikroserwisów składają się z luźno powiązanych autonomicznych usług. Budując usługi, które dobrze wykonują jedną rzecz, można uniknąć bezwładności i entropii dużych aplikacji. Nawet w istniejących aplikacjach można stopniowo wyodrębniać funkcjonalności w niezależne usługi, aby cały system był łatwiejszy w utrzymaniu.
Kiedy zaczęliśmy pracować z mikroserwisami, szybko zdaliśmy sobie sprawę, że budowanie mniejszych i bardziej samodzielnych usług było tylko częścią tworzenia stabilnej i krytycznej dla biznesu aplikacji. W końcu jakakolwiek udana aplikacja spędzi więcej czasu w produkcji niż w edytorze kodu. Aby dostarczyć produkt za pomocą mikroserwisów, nasz zespół nie może skupiać się wyłącznie na tworzeniu. Musimy mieć umiejętności w zakresie wdrażania, obserwacji i diagnozowania.
1.1. Czym jest aplikacja mikroserwisowa?
Aplikacja mikroserwisowa to zbiór autonomicznych usług, z których każda wykonuje dobrze jedną rzecz, i które współpracują ze sobą w celu wykonywania bardziej skomplikowanych operacji. Zamiast pojedynczego złożonego systemu tworzymy i zarządzamy pakietem stosunkowo prostych usług, które mogą wchodzić w interakcje w złożony sposób. Usługi te współpracują ze sobą za pomocą technologicznie agnostycznych protokołów komunikacji, zarówno punkt-punkt, jak i asynchronicznie.
Może się to wydawać prostym pomysłem, ale ma istotne implikacje dla zmniejszenia tarć w rozwoju złożonych systemów. Klasyczna praktyka inżynierii oprogramowania zaleca wysoką spójność i luźne powiązania jako pożądane właściwości dobrze zaprojektowanego systemu. System, który ma te właściwości, będzie łatwiejszy w utrzymaniu i bardziej podatny na zmiany.
Spójność jest stopniem, do którego elementy danego modułu są do siebie przynależne, podczas gdy wiązanie to stopień, w jakim jeden element wie o wewnętrznym działaniu drugiego. Zasada jednej odpowiedzialności Roberta C. Martina jest użytecznym sposobem na zrozumienie tego pierwszego:
Zbierz rzeczy, które zmieniają się z tych samych powodów. Oddziel te, które zmieniają się z różnych powodów.
W monolitycznej aplikacji próbujemy zaprojektować te właściwości na poziomie klasy, modułu lub biblioteki. W aplikacji mikroserwisowej zamiast tego dążymy do osiągnięcia tych właściwości na poziomie niezależnie wdrażalnych jednostek funkcjonalności. Pojedynczy mikroserwis powinien być wysoce spójny – musi być odpowiedzialny za pewne pojedyncze zdolności wewnątrz aplikacji. Ponadto, im każda usługa mniej wie o wewnętrznych działaniach innych usług, tym łatwiej dokonać zmian w jednej usłudze lub zdolności – bez wymuszania zmian w innych.
Aby lepiej zrozumieć, w jaki sposób aplikacja mikroserwisowa się integruje, zacznijmy od rozważenia niektórych funkcjonalności internetowego narzędzia do inwestowania:
■ otwieranie rachunku,
■ deponowanie i wypłacanie pieniędzy,
■ składanie zleceń na kupno lub sprzedaż papierów wartościowych (np. akcji),
■ modelowanie ryzyka i prognozowanie finansowe.
Przeanalizujmy proces sprzedaży akcji:
1 Użytkownik tworzy zlecenie sprzedaży części akcji ze swojego rachunku.
2 Papiery wartościowe są rezerwowane na jego rachunku, więc nie można ich sprzedać wiele razy.
3 Złożenie zlecenia na giełdzie kosztuje – rachunek jest obciążany opłatą.
4 System musi przekazać to zlecenie na właściwy rynek giełdowy.
Na rysunku 1.1 pokazano, jak może wyglądać umieszczenie tego zlecenia sprzedaży w ramach aplikacji mikroserwisowej. Można na nim zaobserwować trzy kluczowe cechy mikroserwisów:
■ każdy mikroserwis jest odpowiedzialny za jedną zdolność – może to być związane z biznesem lub stanowić zdolność techniczną, taką jak integracja z podmiotem zewnętrznym (np. giełdą);
■ mikroserwis jest właścicielem swoich zasobów danych, jeśli je ma; zmniejsza to powiązania między usługami, ponieważ inne usługi mogą uzyskiwać dostęp do danych, które nie są ich własnością, tylko za pośrednictwem interfejsu, który zapewnia usługa;
■ samodzielne mikroserwisy, a nie mechanizm komunikacyjny je łączący ani inne oprogramowanie, są odpowiedzialne za choreografię i współpracę – sekwencjonowanie komunikatów i działań w celu wykonania użytecznych czynności.
Oprócz tych trzech cech można wyróżnić jeszcze dwa podstawowe atrybuty mikroserwisów:
■