Mikroserwisy w akcji - Отсутствует

Скачать книгу

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.

30195.jpg

      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.

      1.3.2. Wdrażanie mikroserwisów

      Rozwój i działanie muszą być ściśle powiązane przy budowaniu mikroserwisów. Jeśli coś zbudujemy i przekażemy, to nie powinniśmy przekazywać tego komuś innemu, aby to wdrożył i obsługiwał. W systemie złożonym z wielu autonomicznych usług, jeśli go zbudujemy, musimy go także uruchomić. Zrozumienie, w jaki sposób nasze usługi będą działać, pomoże nam w podejmowaniu lepszych decyzji dotyczących projektu, gdy nasz system będzie się rozwijał.

      Pamiętajmy, że to, co wyróżnia naszą aplikację, ma wpływ na biznes. Wynika to ze współpracy między wieloma usługami. W rzeczywistości wszystko można ujednolicić lub uprościć – oprócz unikalnej zdolności oferowanej przez daną usługę – co spowoduje, że zespoły będą skoncentrowane na wartości biznesowej. Ostatecznie powininniśmy osiągnąć etap, w którym nie będzie specjalnej ceremonii związanej z wdrażaniem nowej usługi. Bez tego zmarnujemy całą naszą energię, zamiast stworzyć wartość dla klientów.

      W tej książce pokażemy, jak stworzyć właściwą drogę do wdrażania istniejących i nowych usług. Koszt wdrożenia nowych usług musi być nieistotny, aby umożliwić szybkie wprowadzanie innowacji. Proces należy także ujednolicić, aby uprościć działanie systemu i zapewnić spójność między usługami. Aby to osiągnąć, musimy:

      ■ zestandaryzować artefakty wdrażania usług,

      ■ zaimplementować strumienie ciągłego wdrażania.

      Słyszeliśmy, że niezawodne wdrażanie jest traktowane jako nudne, ale nie o to chodzi, że nie jest ekscytujące, tylko że pozbawione jest incydentów. Niestety, widzieliśmy zbyt wiele zespołów, w których jest odwrotnie – wdrażanie oprogramowania jest stresujące i zachęca do niezdrowych zachowań typu „wszystkie ręce na pokład”. Jest to wystarczająco szkodliwe dla pojedynczej usługi – jeśli wdrażamy większą liczbę usług, sam lęk doprowadzi nas do szaleństwa! Przyjrzyjmy się, jak te kroki prowadzą do stabilnych i niezawodnych wdrożeń mikroserwisów.

      STANDARYZACJA ARTEFAKTÓW WDRAŻANIA USŁUG

      Często wydaje się, że każdy język i środowisko ma własne narzędzie do wdrażania. Python ma Fabric, Ruby ma Capistrano, Elixir ma exrm itd. Samo środowisko wdrożeniowe również jest złożone:

      ■ Na jakim serwerze działa aplikacja?

      ■ Jakie są zależności aplikacji od innych narzędzi?

      ■ Jak uruchomić tę aplikację?

      W środowisku wykonawczym zależności aplikacji (rys. 1.9) są silne i mogą obejmować biblioteki, pliki binarne i pakiety systemu operacyjnego (takie jak ImageMagick lub libc) oraz procesy systemu operacyjnego (takie jak cron lub fluentd).

      Technicznie, heterogeniczność jest fantastyczną korzyścią z autonomii usług. Ale nie ułatwia to wdrożenia. Bez unikania konsekwencji nie można zestandaryzować podejścia do wdrażania usług do produkcji, co zwiększa koszty zarządzania wdrożeniami i wprowadzania nowych technologii. W najgorszym przypadku każdy zespół ponownie musi wymyślić koło, tworząc różne podejścia do zarządzania zależnościami, budowania pakietów, umieszczania ich na serwerach i obsługi samej aplikacji.

      Nasze doświadczenie sugeruje, że najlepszym narzędziem do tego zadania są kontenery. Kontener to metoda wirtualizacji na poziomie systemu operacyjnego, która obsługuje uruchamianie izolowanych systemów na hoście, z których każdy ma własną sieć i przestrzeń dla procesów, współdzieląc to samo jądro. Kontener jest szybszy do

Скачать книгу