Mikroserwisy w akcji. Отсутствует
rolę usługi obsługi zleceń. Zauważmy, że niektóre działania, na przykład dwie akcje o numerze 3,występują jednocześnie
W tym projekcie usunęliśmy następujące odpowiedzialności z usługi obsługi zleceń:
■ naliczanie opłat – usługa obsługi zleceń nie wie teraz, że opłata jest naliczana po złożeniu zlecenia na giełdę;
■ składanie zleceń – usługa obsługi zleceń nie ma bezpośredniej interakcji z usługą obsługi giełdy; można ją łatwo zastąpić inną implementacją, a nawet usługą per giełda, bez konieczności zmiany samej usługi obsługi zleceń.
Sama usługa obsługi zleceń reaguje także na zachowanie innych usług, subskrybując zdarzenie OrderPlaced wyzwalane przez usługę obsługi giełdy. Łatwo możemy rozszerzyć to na dalsze wymagania; na przykład, usługa obsługi zleceń może subskrybować zdarzenia TradeExecuted, aby zarejestrować, kiedy sprzedaż została zakończona na giełdzie lub zdarzenia OrderExpired, jeśli sprzedaż nie może być dokonana w określonym czasie.
Ta konfiguracja jest bardziej skomplikowana niż oryginalna synchroniczna współpraca. Jednak preferując choreografię tam, gdzie to możliwe, zbudujemy usługi, które w dużym stopniu będą od siebie oddzielone, a zatem będą niezależne i łatwe do wdrożenia. Korzyści te wiążą się z pewnym kosztem – kolejka komunikatów to kolejna infrastruktura do zarządzania i skalowania, która może stać się pojedynczym punktem awarii.
Projekt, który stworzyliśmy, ma także pewne zalety w zakresie odporności. Na przykład błąd w usłudze obsługi giełdy jest izolowany od niepowodzenia w usłudze obsługi zleceń. Jeśli złożenie zlecenia się nie powiedzie, możemy to zdarzenie wykonać ponownie później6, gdy tylko usługa będzie dostępna lub wygaśnie, jeśli minie zbyt dużo czasu. Jednocześnie obecnie trudniej będzie prześledzić pełną aktywność systemu, którą będziemy musieli wziąć pod uwagę, gdy będziemy chcieli monitorować usługi podczas produkcji.
2.4. Udostępnianie usług na zewnątrz
Do tej pory zbadaliśmy, w jaki sposób usługi współpracują ze sobą, aby osiągnąć cel biznesowy. W jaki sposób udostępnimy tę funkcjonalność prawdziwej aplikacji użytkownika?
SimpleBank chce budować zarówno produkty webowe, jak i mobilne. Aby to zrobić, zespół inżynierów zdecydował się zbudować bramę API jako fasadę tych usług. To ukrywa działanie backendu przed aplikacją z niego korzystającą, zapewniając, że nie musi ona wiedzieć o istnieniu mikroserwisów oraz o tym, jak te usługi współdziałają ze sobą, aby zapewnić funkcjonalność. Brama API deleguje żądania do właściwych usług oraz przekształca lub łączy ich odpowiedzi w zależności od potrzeb publicznego API.
Wyobraźmy sobie ekran interfejsu użytkownika do składania zlecenia. Ma on cztery kluczowe elementy:
■ wyświetlanie informacji o bieżących aktywach na rachunku klienta, w tym zarówno ilości, jak i wartości;
■ wyświetlanie danych rynkowych pokazujących ceny i transakcje dotyczące aktywów;
■ wprowadzanie zleceń, w tym kalkulacji kosztów;
■ żądanie wykonania tych zleceń w odniesieniu do określonych aktywów.
Na rysunku 2.8 pokazano, w jaki sposób brama API obsługuje te funkcjonalności i jak współpracuje z podstawowymi usługami.
Rysunek 2.8. Interfejs użytkownika, taki jak strona internetowa lub aplikacja mobilna, współdziała z interfejsem API REST udostępnianym przez bramę API. Brama zapewnia fasadę dla mikroserwisów na zapleczu i przekierowuje żądania do odpowiednich z nich
Wzorzec wykorzystujący bramę API jest elegancki, ale ma kilka wad. Ponieważ działa jako pojedynczy punkt dla wielu usług, stanie się duży i prawdopodobnie nieporęczny. Może też istnieć pokusa dodania logiki biznesowej do bramy zamiast traktowania go tylko jako pośrednika. Może też starać się być wszystkim dla wszystkich aplikacji – gdy aplikacja klienta mobilnego będzie mogła wymagać mniejszych zasobów, to wewnętrzna aplikacja administracyjna będzie potrzebowała znacznie więcej danych. Może być trudno wyważyć te przeciwstawne dążenia podczas budowania spójnego interfejsu API.
UWAGA W rozdziale 3 ponownie wrócimy do wzorca bramy API i omówimy alternatywne podejścia.
2.5. Wdrażanie funkcjonalności na produkcję
Zaprojektowaliśmy funkcjonalność SimpleBank, która wymaga interakcji wielu usług, kolejki zdarzeń i bramy API. Powiedzmy, że zrobiliśmy też następny krok – zbudowaliśmy te usługi, a teraz dyrektor generalny naciska na nas, abyśmy wprowadzili je do produkcji.
W publicznych chmurach, takich jak AWS, Azure lub GCE, oczywistym rozwiązaniem jest wdrożenie każdej usługi do grupy maszyn wirtualnych. Możemy użyć load balancera w celu równomiernego rozłożenia obciążenia między instancjami każdej usługi lub użyć zarządzanej kolejki zdarzeń, takiej jak AWS Simple Queue Service do rozdziału zdarzeń między usługami.
UWAGA Dogłębna dyskusja na temat skutecznej automatyzacji i zarządzania infrastrukturą wykracza poza zakres tej książki. Większość dostawców usług w chmurze zapewnia tę możliwość dzięki niestandardowym narzędziom, takim jak AWS CloudFormation lub AWS Elastic Beanstalk. Można również rozważyć użycie narzędzi open source, takich jak Chef lub Terraform.
W każdym razie – skompilowaliśmy kod, załadowaliśmy go na maszyny wirtualne, uruchomiliśmy bazy danych i wypróbowaliśmy niektóre testowe żądania. Zajęło to kilka dni. Na rysunku 2.9 pokazaliśmy naszą infrastrukturę produkcyjną.
Rysunek 2.9. W prostym wdrożeniu mikroserwisów żądania do każdej usługi są równomiernie rozdzielane na wiele instancji uruchomionych na wielu maszynach wirtualnych. Ponadto wiele instancji usługi może subskrybować kolejkę
Przez kilka tygodni nie działało to bardzo źle. Wprowadziliśmy kilka zmian i wdrożyliśmy nowy kod. Ale wkrótce zaczęliśmy wpadać w kłopoty. Trudno było stwierdzić, czy usługi działają zgodnie z oczekiwaniami. Co gorsza, jesteśmy jedynymi w SimpleBanku, którzy wiedzą, jak wydać nową wersję. Jest jeszcze gorzej – człowiek, który napisał usługę obsługi transakcji wyjechał na wakacje na kilka tygodni i nikt nie wie, w jaki sposób usługa została wdrożona. Usługi te miałyby bus factor równy 1, co oznacza, że nie przetrwałyby zniknięcia członka zespołu.
DEFINICJA Bus factor jest miarą ryzyka wynikającą z umiejętności niedzielonych między członków zespołu. Pochodzi to od wyrażenia „w sytuacji, gdyby zostali potrąceni przez autobus”. Jest to również znane jako truck factor. Im niższa wartość bus factor, tym gorzej.
Coś zdecydowanie poszło nie tak. Przypomnieliśmy sobie, że w ostatniej pracy w GiantBanku zespół zarządzający infrastrukturą zajmował się wydaniami. Należało do niego zgłosić sprawę, chodzić wokół niej, a po kilku tygodniach można było uzyskać to, czego się potrzebowało … a czasami nie, sprawę zatem zgłaszało się ponownie. To też nie wydaje się być właściwym podejściem. W rzeczywistości cieszyliśmy się, że korzystanie z mikroserwisów pozwoli nam zarządzać wdrożeniami.
Można z całą pewnością powiedzieć, że nasze usługi nie były gotowe do produkcji. Uruchamianie mikroserwisów wymaga od zespołu inżynierskiego poziomu wiedzy operacyjnej i radzenia sobie z problemami nie tylko typowymi dla aplikacji monolitycznej. Można powiedzieć,
Zakładając, że sama kolejka jest trwała.