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

Podczas budowania aplikacji mikroserwisowej należy podjąć wiele takich decyzji projektowych, które nie pojawiłyby się podczas budowy aplikacji monolitycznych. Te ostatnie często są związane z dobrze znanymi wzorcami lub strukturami, takimi jak architektura trójwarstwowa lub Model–Widok–Kontroler (Model-View-Controller, MVC). Jednak techniki projektowania mikroserwisów wciąż są w powijakach. Należy wziąć pod uwagę:

■ czy zacząć od monolitu, czy od razu od mikroserwisów;

■ ogólną architekturę aplikacji i fasadę, która będzie udostępniona zewnętrznym konsumentom;

■ jak rozpoznać i określić zakres granic usług;

■ w jaki sposób usługi będą się ze sobą komunikować – synchronicznie czy asynchronicznie;

■ jak osiągnąć elastyczność w usługach.

To dość dużo do omówienia. Na razie pokrótce zajmiemy się każdym z tych zagadnień, aby się przekonać, dlaczego zwrócenie na nie uwagi ma kluczowe znaczenie dla dobrze zaprojektowanej aplikacji mikroserwisowej.

NAJPIERW MONOLIT?

Istnieją dwa przeciwstawne trendy dotyczące rozpoczynania pracy z mikroserwisami: najpierw monolit lub od razu tylko mikroserwisy. Zwolennicy pierwszego, według którego zawsze powinno się zaczynać od monolitu, uważają, że na wczesnym etapie nie można określić granic komponentów w systemie, a koszt powstania błędów z tym związanych jest znacznie większy w aplikacji mikroserwisowej. Jednocześnie granice wyznaczone w monolicie niekoniecznie będą tymi samymi, które zostaną określone w dobrze zaprojektowanej aplikacji mikroserwisowej.

Chociaż na początku rozwój może być wolniejszy, w przyszłości mikroserwisy zmniejszą tarcie i ryzyko. Wraz z dojrzewaniem narzędzi i frameworków dobre praktyki w zakresie mikroserwisów staną się coraz mniej zniechęcające do zastosowania. Tak czy inaczej, porady w tej książce powinny być użyteczne niezależnie od tego, czy myślimy o migracji z monolitu, czy o rozpoczęciu od nowa.

OKREŚLANIE ZAKRESÓW USŁUG

Wybór odpowiedniego poziomu odpowiedzialności dla każdej usługi – jej zakres – jest jednym z najtrudniejszych wyzwań przy projektowaniu aplikacji mikroserwisowej. Trzeba będzie modelować usługi, opierając się na zdolnościach biznesowych, które będą udostępniać dla firmy.

Przytoczmy przykład z początku tego rozdziału. Jak mogą zmienić się usługi, jeśli będziemy chcieli wprowadzić nowy, specjalny rodzaj zlecenia? Mamy trzy możliwości rozwiązania tego problemu (rys. 1.8):

1 rozszerzenie istniejącego interfejsu usługi,

2 dodanie nowego adresu usługi,

3 dodanie nowej usługi.

Każda z tych możliwości ma zalety i wady, które będą miały wpływ na spójność i łączenie usług w aplikacji.

UWAGA  W rozdziałach 2 i 4 omówimy zakresy usług i sposoby podejmowania optymalnych decyzji dotyczących ich odpowiedzialności.

Rysunek 1.8. Aby rozszerzyć funkcjonalność, musimy podjąć decyzję o tym, czy nowe zdolności będą należeć do istniejących usług, czy potrzebujemy zaprojektować nowe usługi

KOMUNIKACJA

Komunikacja między usługami może być asynchroniczna lub synchroniczna. Chociaż systemy synchroniczne są łatwiejsze do zrozumienia, systemy asynchroniczne mogą być bardziej od siebie oddzielone, co zmniejsza ryzyko zmian, i potencjalnie są bardziej odporne. Ale złożoność takiego systemu jest wysoka. W aplikacji mikroserwisowej musimy zrównoważyć synchroniczne i asynchroniczne przesyłanie komunikatów i efektywnie koordynować działania wielu mikroserwisów.

ELASTYCZNOŚĆ

W systemie rozproszonym usługa nie może ufać współpracującym z nią usługom niekoniecznie dlatego, że są one źle zaimplementowane lub zawierają ludzkie błędy, ale dlatego, że nie można bezpiecznie założyć, że sieć lub zachowanie tych usług są niezawodne lub przewidywalne. Usługi muszą być odporne na awarie. Aby to osiągnąć, musimy je tak zaprojektować, aby działały defensywnie, wycofując się w przypadku błędów, ograniczając żądania od kiepskich współpracowników i dynamicznie znajdując zdrowe usługi.