Cześć, Habr. Dziś kontynuuję serię publikacji, którą napisałem specjalnie z okazji rozpoczęcia nowego cyklu kursu .
Wprowadzenie
Wybór stylu architektonicznego jest jednym z podstawowych decyzji technicznych przy budowie systemu informacyjnego. W tej serii artykułów proponuję omówić najpopularniejsze style architektoniczne budowy aplikacji i odpowiedzieć na pytanie, kiedy który styl architektoniczny jest najbardziej preferowany. W procesie przedstawiania postaram się przeprowadzić logiczny ciąg, który wyjaśnia rozwój stylów architektonicznych od monolitów do mikrosystemów.
Ostatnim razem porozmawialiśmy o różnych rodzajach monolitów i wykorzystaniu komponentów do ich budowy, zarówno komponentów zestawów, jak i komponentów wdrożeniowych. Zrozumieliśmy architekturę zorientowaną na usługi.
Teraz w końcu zdefiniujemy podstawowe cechy architektury mikrosystemowej.
Relacje architektoniczne
Należy zrozumieć, że na podstawie danych z poprzednich artykułów każdy serwis jest komponentem, ale nie każdy serwis jest mikrosystemem.
Cechy architektury mikrosystemowej
Podstawowymi cechami architektury mikrosystemowej są:
- Organizacja zgodnie z możliwościami biznesowymi (Organized around Business Capabilities)
- Produkty, a nie projekty (Products not Projects)
- Inteligentne punkty dostępu i głupie kanały (Smart endpoints and dumb pipes)
- Zdecentralizowane zarządzanie (Decentralized Governance)
- Zdecentralizowane zarządzanie danymi (Decentralized Data Management)
- Automatyzacja infrastruktury (Infrastructure Automation)
- Ubezpieczenie przed awariami (Design for failure)
- Architektura z ewolucyjnym rozwojem (Evolutionary Design)
Pierwszy punkt pochodzi od architektury zorientowanej na usługi, ponieważ mikrosystemy są szczególnym przypadkiem usług. Pozostałe punkty zasługują na osobne omówienie.
Organizacja zgodnie z możliwościami biznesowymi (Organized around Business Capabilities)
Teraz należy przypomnieć sobie prawo Conwaya: organizacje tworzące systemy organizują ich architekturę, kopując strukturę interakcji w ramach tych organizacji. Jako przykład można przypomnieć sobie przypadek tworzenia kompilatora: zespół składający się z siedmiu osób opracował siedmioprzebiegowy kompilator, a zespół z pięciu — pięcioprzebiegowy.
Jeśli mówimy o monolitach i mikrousługach, to w przypadku, gdy rozwój jest zorganizowany według funkcjonalnych działów (backend, frontend, administratorzy baz danych), powstaje klasyczny monolit.
Aby uzyskać mikrousługi, zespoły należy organizować według możliwości biznesowych (zespół zamówień, dostaw, katalogu). Taka organizacja pozwoli zespołom skupić się na tworzeniu konkretnych części aplikacji.
Produkty, a nie projekty (Products not Projects)
Podejście projektowe, w którym zespół przekazuje opracowaną funkcjonalność innym zespołom w przypadku architektury mikrousługowej, jest zupełnie nieodpowiednie. Zespół powinien wspierać system przez cały jego cykl życia. Firma Amazon, jeden z pionierów wprowadzania mikrousług, twierdziła: „tworzysz produkt, i to ty go uruchamiasz” („you build, you run it”). Podejście produktowe pozwala zespołowi poczuć potrzeby biznesu.
Inteligentne punkty dostępu i głupie kanały (Smart endpoints and dumb pipes)
Architektura SOA kładła duży nacisk na kanały komunikacji, w szczególności na Enterprise Service Bus (szynę usługową przedsiębiorstwa). Co często prowadzi do Erroneous Spaghetti Box, czyli złożoność monolitu przechodzi w złożoność połączeń między usługami. W architekturze mikrousługowej stosowane są tylko proste metody interakcji.
Zdecentralizowane zarządzanie (Decentralized Governance)
Kluczowe decyzje dotyczące mikrousług powinny podejmować osoby, które naprawdę rozwijają mikrousługi. Przez kluczowe decyzje rozumie się wybór
języków programowania, metodologii wdrażania, kontraktów publicznych interfejsów itd.
Zdecentralizowane zarządzanie danymi (Decentralized Data Management)
Standardowe podejście, w którym aplikacja polega na jednej bazie danych, nie może uwzględniać specyfiki każdego konkretnego serwisu. MSA zakłada zdecentralizowane zarządzanie danymi, aż do użycia różnych technologii.
Automatyzacja infrastruktury (Infrastructure Automation)
MSA wspiera procesy ciągłego wdrażania i dostarczania. Możliwe jest to tylko dzięki automatyzacji procesów. W tym przypadku, wdrażanie dużej liczby usług nie wydaje się już czymś przerażającym. Proces wdrażania powinien stać się nudny. Drugi aspekt dotyczy zarządzania usługami w środowisku produkcyjnym. Bez automatyzacji zarządzanie procesami uruchomionymi w różnych środowiskach operacyjnych staje się niemożliwe.
Ubezpieczenie przed awariami (Design for failure)
Wielu usługom MSA zdarzają się awarie. W związku z tym obsługa błędów w rozproszonym systemie jest dość skomplikowanym zadaniem. Architektura aplikacji powinna być odporna na takie awarie. Rebecca Parsons uważa, że bardzo ważne jest, abyśmy przestali używać nawet komunikacji wewnętrznej między usługami; zamiast tego do komunikacji korzystamy z HTTP, które nie jest tak niezawodne.
Architektura z ewolucyjnym rozwojem (Evolutionary Design)
Architektura systemu MSA powinna rozwijać się ewolucyjnie. Pożądane jest ograniczenie koniecznych zmian do granic jednej usługi. Należy także uwzględnić wpływ na inne usługi. Tradycyjne podejście polega na próbie rozwiązania tego problemu za pomocą zarządzania wersjami, ale MSA zakłada wykorzystanie zarządzania wersjami jako
środka ostatecznego.
Podsumowanie
Po wszystkim, co zostało powiedziane, możemy zestawić definicję mikrousług. Architektura mikrousług to podejście do tworzenia pojedynczej aplikacji jako zestawu małych usług, z których każda działa w swoim własnym procesie i komunikuje się za pośrednictwem uproszczonych mechanizmów, często interfejsu API HTTP zasobów. Usługi te są oparte na możliwościach biznesowych i mogą być wdrażane niezależnie za pomocą w pełni
zautomatyzowanego mechanizmu wdrażania. Istnieje minimalny poziom centralnego zarządzania tymi usługami, które mogą być napisane w różnych językach programowania i wykorzystywać różne technologie przechowywania danych.
Źródło: habr.com
