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.
В poradziliśmy sobie z monolitem i doszliśmy do wniosku, że monolit ma szereg problemów: rozmiar, łączność, wdrożenie, skalowalność, niezawodność i sztywność.
Tym razem proponuję porozmawiać o możliwościach zorganizowania systemu jako zestawu modułów/bibliotek (architektura zorientowana na komponenty) lub usług (architektura zorientowana na usługi).
Architektura zorientowana na komponenty
Architektura zorientowana komponentowo polega na wykonaniu systemu jako zbioru komponentów, które można wykorzystać zarówno w bieżących, jak i przyszłych projektach. Rozbijając system na komponenty, bierze się pod uwagę: ich możliwość ponownego użycia, możliwość zastępowania, niezależność od kontekstu, rozszerzalność, hermetyzację i niezależność.
Przy właściwym wykorzystaniu komponentów problem „wielkiej kuli brudu” (duży rozmiar + wysokie sprzęgnięcie) zostaje rozwiązany, a same komponenty mogą być zarówno jednostkami montażowymi (moduły, biblioteki), jak i jednostkami wdrożeniowymi (usługi). Jednostki wdrożeniowe nie zawsze są mapowane na działający proces: na przykład aplikacja internetowa i baza danych są wdrażane razem.
Najczęściej monolity opracowywane są jako zestaw modułów. Takie podejście prowadzi do niezależnego rozwoju, ale pozostają problemy związane z niezależnym skalowaniem i wdrażaniem, odpornością na awarie i niezależnością od ogólnego stosu technologii. Dlatego moduł jest częściowo niezależnym komponentem.
Największym problemem takiego monolitu jest to, że podział na moduły jest czysto logiczny i łatwo może zostać naruszony przez programistów. Może pojawić się moduł podstawowy, który stopniowo zamieni się w wysypisko śmieci, wykres zależności pomiędzy modułami może się rozrosnąć i tak dalej. Aby uniknąć takich problemów, rozwój powinien być prowadzony albo przez bardzo dojrzały zespół, albo pod okiem „architekta”, który na pełen etat zajmuje się przeglądaniem kodu i bije ręce programistów naruszających logiczną strukturę.
„Idealny” monolit to zbiór logicznie oddzielonych modułów, z których każdy przegląda własną bazę danych.
Architektura zorientowana na usługi
Jeśli system ma być zorganizowany w formie zbioru usług, to mówimy o architekturze zorientowanej na usługi. Jego zasady to interoperacyjność aplikacji zorientowana na użytkownika, ponowne wykorzystanie usług biznesowych, niezależność od stosu technologii i autonomia (niezależna ewolucja, skalowalność i wdrażanie).
Architektura zorientowana na usługi (SOA = architektura zorientowana na usługi) rozwiązuje wszystkie zidentyfikowane problemy monolitu: zmiana dotyczy tylko jednej usługi, a dobrze zdefiniowane API zapewnia dobrą enkapsulację komponentów.
Ale nie wszystko przebiega tak gładko: SOA stwarza nowe problemy. Połączenia zdalne są droższe niż lokalne, a redystrybucja obowiązków pomiędzy komponentami stała się znacznie droższa.
Swoją drogą, bardzo ważną cechą usługi jest możliwość samodzielnego wdrożenia. Jeśli usługi muszą być wdrażane razem lub co więcej, w określonej kolejności, wówczas systemu nie można uznać za zorientowany na usługi. W tym przypadku mówią o rozproszonym monolicie (uważanym za antywzorzec nie tylko z punktu widzenia SOA, ale także z punktu widzenia architektury mikroserwisów).
Architektura zorientowana na usługi cieszy się dużym poparciem społeczności architektonicznej i dostawców. Oznacza to obecność wielu kursów i certyfikatów, dobrze rozwiniętych wzorców. Do tej ostatniej zalicza się na przykład dobrze znana magistrala usług korporacyjnych (ESB = Enterprise Service Bus). Jednocześnie ESB jest bagażem dostawców i niekoniecznie musi być wykorzystywane w architekturze SOA.
Popularność architektury zorientowanej na usługi osiągnęła szczyt około 2008 roku, po czym zaczęła spadać, co stało się znacznie bardziej dramatyczne po pojawieniu się mikroserwisów (~2015).
wniosek
Po omówieniu możliwości organizacji systemów informatycznych w postaci usług i modułów, proponuję na koniec przejść do zasad architektury mikroserwisowej i w dalszej części zwrócić szczególną uwagę na różnicę pomiędzy architekturą mikroserwisową a architekturą zorientowaną na usługi.
Źródło: www.habr.com