Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 9

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:

■ każdy mikroserwis może być wdrożony niezależnie – bez tego aplikacja mikroserwisowa nadal byłaby monolityczna z perspektywy wdrażania;

■ mikroserwis jest wymienny – posiadanie jednej zdolności wyznacza naturalną granicę pod względem rozmiaru; ponadto, czyni łatwą do zrozumienia indywidualną odpowiedzialność lub rolę usługi.

Pomysł, że mikroserwisy są odpowiedzialne za koordynację działań w systemie jest zasadniczą różnicą między tym podejściem a tradycyjnymi architekturami zorientowanymi na usługi (SOA). Tego typu systemy często wykorzystywały korporacyjne magistrale usług (ESB) lub bardziej złożone standardy orkiestracji, aby uzewnętrzniać komunikację i proces orkiestracji z samych aplikacji. W tym modelu usługi często nie były spójne, ponieważ logika biznesowa była dodawana do magistrali usług, a nie do samych usług.

Warto się zastanowić, w jaki sposób wydzielanie funkcjonalności w internetowym systemie inwestycyjnym pozwala na większą elastyczność w obliczu zmieniających się wymagań. Wyobraźmy sobie, że musimy zmienić sposób naliczania opłat. Możemy wprowadzić i wydać te zmiany w usłudze fees bez żadnych zmian w usługach wyższego lub niższego poziomu. Albo przyjmijmy zupełnie nowy wymóg – musimy powiadomić zespół ds. ryzyka, gdy jest składane zamówienie niepasujące do typowych schematów handlu. Łatwo byłoby zbudować nowy mikroserwis, aby wykonać tę operację, bazując na zdarzeniu wywołanym przez usługę orders bez zmiany reszty systemu.

Rysunek 1.1. Przepływ komunikacji przez mikroserwisy w aplikacji, która pozwala użytkownikom sprzedawać papiery wartościowe