Spring Cloud – seria wpisów o zarządzaniu mikroserwisami

Spring Cloud to wspólna nazwa projektu pod którym kryje się masa bibliotek i narzędzi których celem jest radzenie sobie z wyzwaniami jakie niesie za sobą architektura mikroserwisów. Zanim przejdziemy do wyzwań przedstawie kilka zalet odnośnie samych mikroserwisów. Są to:

• Skalowalność:

Dzięki rozbiciu aplikacji na mniejsze jednostki mamy możliwość skalowania tych komponentów które stanowią kluczowe elementy systemu.

• Odporność na awarie:

Każdy mikroserwis może zostać odizolowany od reszty w taki sposób by awaria nie pociągała kolosalnych skutków dla całego systemu.

• Łatwość aplikowania zmian:

W celu wprowadzenia poprawek nie trzeba robić pełnego wdrożenia całej aplikacji. Zamiast tego zmiany mogą być wprowadzane w dowolnym mikroserwisie bez konieczności wyłączania z życia całego systemu.

• Różna technologia:

Każdy mikroserwis może być napisany z użyciem dowolnej technologii dzięki zastosowaniu protokołu HTTP który nie jest związany z żadnym konkretnym językiem, biblioteką czy frameworkiem.

Do wyzwań rozproszonej architektury mikroserwisów zaliczamy:

• Konfiguracja:

Zarządzanie dużą ilością mikroserwisów nie należy do łatwych. Jak zarządzać konfiguracją kiedy każdy mikroserwis może być uruchomiony w tym samym czasie w wielu instancjach?

• Skalowanie:

Jak automatycznie skalować aplikację bazując na naturalnym ruchu użytkowników w systemie?

• Inwestygacja:

Jak prześledzić żądanie klienta kiedy ścieżka wywołań może przechodzić przez wiele mikroserwisów?

• Obsługa błędów:

Jak w izolacji wykrywać błędy i naprawiać uszkodzone mikroserwisy?

Pamiętajmy, że liczba mikroserwisów nie może być za duża. Dlaczego? Załóżmy, że mamy 5 mikroserwisów. Każdy z nich ma SLA na poziomie 99,9%. Pytanie jakie SLA będzie posiadał cały system?

99,9% * 99,9% * 99,9% * 99,9% * 99,9% = 99%

Czy mikroserwisy posiadają wady? Nie ma rozwiązania pozbawionego wad. Przede wszystkim wytwarzanie oprogramowania z użyciem architektury mikroserwisów jest dużo trudniejsze w porównaniu do wytwarzania oprogramowania z użyciem podejścia monolitu. Tym wpisem rozpoczynam serię wpisów o projekcie Spring Cloud! Zobacz każdy wpis:

• https://javaleader.pl/2019/06/06/spring-cloud-config-server/
• https://javaleader.pl/2019/06/28/platforma-pivotal-cloud-foundry/
• https://javaleader.pl/2019/06/23/consumer-driven-contract-testy-kontraktowe-w-swiecie-mikroserwisow/
• https://javaleader.pl/2019/06/28/spring-cloud-hystrix-jako-realizacja-wzorca-circuit-breaker/
• https://javaleader.pl/2019/06/30/spring-cloud-feign/
• https://javaleader.pl/2019/06/29/spring-cloud-zipkin/
• https://javaleader.pl/2019/06/29/spring-cloud-bus-na-przykladzie-rabbitmq/
• https://javaleader.pl/2019/07/05/spring-cloud-zuul/
• https://javaleader.pl/2019/07/07/service-discovery-eureka/
• https://javaleader.pl/2019/07/07/spring-cloud-ribbon/