Witaj, Habr. Dziś kontynuuję cykl publikacji, który napisałem specjalnie na start nowego nurtu kursu. .
Wprowadzenie
Wybór stylu architektonicznego jest jedną z podstawowych decyzji technicznych przy budowie systemu informatycznego. W tym cyklu artykułów proponuję przeanalizować najpopularniejsze style architektoniczne w zastosowaniach budowlanych i odpowiedzieć na pytanie, kiedy który styl architektoniczny jest najbardziej preferowany. W trakcie prezentacji postaram się narysować logiczny łańcuch wyjaśniający rozwój stylów architektonicznych od monolitów po mikroserwisy.
Ostatnim razem rozmawialiśmy o różnych typach monolitów i wykorzystaniu komponentów do ich budowy, zarówno komponentów konstrukcyjnych, jak i komponentów rozmieszczających. Rozumiemy architekturę zorientowaną na usługi.
Teraz w końcu zdefiniujemy główne cechy architektury mikroserwisowej.
Związek architektur
Należy zrozumieć, że w oparciu o definicje podane w poprzednich artykułach każda usługa jest komponentem, ale nie każda usługa jest mikrousługą.
Charakterystyka architektury mikroserwisowej
Główne cechy architektury mikroserwisowej to:
- Zorganizowane wokół możliwości biznesowych
- Produkty, a nie projekty
- Inteligentne punkty końcowe i głupie potoki
- Zdecentralizowane zarządzanie
- Zdecentralizowane zarządzanie danymi
- Automatyka Infrastruktury
- Projekt na porażkę
- Architektura z ewolucyjnym rozwojem (Evolutionary Design)
Punkt pierwszy pochodzi z architektury zorientowanej na usługi, ponieważ mikrousługi są szczególnym przypadkiem usług. Inne punkty zasługują na osobne rozpatrzenie.
Zorganizowane wokół możliwości biznesowych
Teraz należy pamiętać o prawie Conwaya: organizacje tworzące systemy organizują swoją architekturę, kopiując strukturę interakcji wewnątrz tych organizacji. Jako przykład możemy przypomnieć przypadek tworzenia kompilatora: zespół siedmiu osób opracował kompilator siedmioprzebiegowy, a zespół pięciu opracował kompilator pięcioprzebiegowy.
Jeśli mówimy o monolitach i mikroserwisach, to jeśli rozwój organizują działy funkcjonalne (backend, frontend, administratorzy baz danych), to otrzymujemy klasyczny monolit.
Aby uzyskać mikrousługi, zespoły muszą być zorganizowane według możliwości biznesowych (zamówienia, wysyłki, zespół zajmujący się katalogiem). Taka organizacja pozwoli zespołom skoncentrować się na budowaniu określonych części aplikacji.
Produkty, a nie projekty
Podejście projektowe, w którym zespół przekazuje opracowaną funkcjonalność innym zespołom, jest całkowicie nieodpowiednie w przypadku architektury mikroserwisowej. Zespół musi wspierać system przez cały jego cykl życia. Amazon, jeden z liderów we wdrażaniu mikroserwisów, stwierdził: „budujesz, uruchamiasz”. Podejście produktowe pozwala zespołowi wyczuć potrzeby biznesu.
Inteligentne punkty końcowe i głupie potoki
W architekturze SOA dużą uwagę poświęcono kanałom komunikacji, w szczególności Enterprise Service Bus. Co często prowadzi do Błędnego Pudełko Spaghetti, czyli złożoność monolitu zamienia się w złożoność powiązań pomiędzy usługami. Architektura mikroserwisowa wykorzystuje wyłącznie proste metody komunikacji.
Zdecentralizowane zarządzanie
Kluczowe decyzje dotyczące mikroserwisów powinny podejmować osoby, które faktycznie je rozwijają. Tutaj kluczowe decyzje oznaczają wybory
języki programowania, metodologia wdrażania, umowy dotyczące interfejsu publicznego itp.
Zdecentralizowane zarządzanie danymi
Standardowe podejście, w którym aplikacja opiera się na jednej bazie danych, nie jest w stanie uwzględnić specyfiki każdej konkretnej usługi. MSA polega na zdecentralizowanym zarządzaniu danymi, w tym z wykorzystaniem różnych technologii.
Automatyka Infrastruktury
MSA wspiera ciągłe procesy wdrażania i dostarczania. Można to osiągnąć jedynie poprzez automatyzację procesów. Jednocześnie wdrożenie dużej liczby usług nie wygląda już jak coś strasznego. Proces wdrażania powinien stać się nudny. Drugi aspekt związany jest z zarządzaniem usługami w środowisku produktowym. Bez automatyzacji zarządzanie procesami przebiegającymi w różnych środowiskach operacyjnych staje się niemożliwe.
Projekt na porażkę
Wiele usług MSA jest podatnych na awarie. Jednocześnie obsługa błędów w systemie rozproszonym nie jest zadaniem trywialnym. Architektura aplikacji musi być odporna na takie awarie. Rebecca Parsons uważa, że bardzo ważne jest, abyśmy nie korzystali już nawet z komunikacji wewnątrzprocesowej między usługami; zamiast tego do komunikacji korzystaliśmy z protokołu HTTP, który nie jest tak niezawodny.
Architektura z ewolucyjnym rozwojem (Evolutionary Design)
Architektura systemu MSA powinna rozwijać się ewolucyjnie. Wskazane jest ograniczenie niezbędnych zmian do granic pojedynczej usługi. Należy również wziąć pod uwagę wpływ na inne usługi. Tradycyjne podejście polega na próbie rozwiązania tego problemu za pomocą wersjonowania, ale firma MSA sugeruje użycie wersjonowania
jako ostateczność.
wniosek
Po tym wszystkim możemy sformułować, czym są mikroserwisy. Architektura mikrousług to podejście do tworzenia pojedynczej aplikacji jako zbioru małych usług, z których każda działa w ramach własnego procesu i wchodzi w interakcję za pośrednictwem lekkich mechanizmów, często interfejsu API zasobów HTTP. Usługi te opierają się na możliwościach biznesowych i można je w pełni wdrożyć niezależnie
zautomatyzowany mechanizm wdrażania. Istnieje minimalny poziom scentralizowanego 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: www.habr.com