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

W aplikacji mikroserwisowej usługi będą oczywiście miały różne poziomy odpowiedzialności. Ale musimy zrównoważyć orkiestrację z choreografią. W systemie choreograficznym usługa nie musi bezpośrednio sterować i uruchamiać działań w innych serwisach. Zamiast tego każda usługa ma określone obowiązki, które wykonuje w reakcji na inne zdarzenia.

Wróćmy do wcześniejszego projektu i wykonajmy kilka poprawek:

■ gdy ktoś tworzy zlecenie, giełda może akurat nie być otwarta – musimy zarejestrować, w jakim stanie jest zamówienie: utworzone czy złożone; złożenie zamówienia nie musi być synchroniczne;

■ opłatę pobierzemy tylko po złożeniu zlecenia, więc nie muszą być one synchroniczne; w rzeczywistości powinno się to zdarzyć w reakcji na usługę obsługi giełdy, a nie być zorkiestrowane przez usługę obsługi zleceń.

Na rysunku 2.7 przedstawiono zmieniony projekt. Dodanie zdarzeń tworzy problem architektoniczny – potrzebujemy sposobu na ich przechowywanie i udostępnianie innym aplikacjom. W tym celu zalecamy użycie kolejki komunikatów, takiej jak RabbitMQ lub SQS.

Rysunek 2.7. Wykonujemy choreografię zachowań innych usług przez zdarzenia, redukując koordynującą 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.