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.
W Zrozumieliśmy monolit i doszliśmy do wniosku, że ma on szereg problemów: wielkość, powiązania, wdrażanie, skalowalność, niezawodność i sztywność.
Tym razem proponuję porozmawiać o możliwościach organizacji systemu w postaci zestawu modułów/bibliotek (architektura zorientowana na komponenty) lub usług (architektura zorientowana na usługi).
Architektura zorientowana na komponenty
Architektura zorientowana na komponenty zakłada realizację systemu w postaci zestawu komponentów, które można wykorzystać zarówno w bieżących, jak i przyszłych projektach. Przy dzieleniu systemu na komponenty uwzględnia się: ich przydatność do ponownego wykorzystania, wymienność, niezależność od kontekstu, rozbudowę, enkapsulację i niezależność.
Przy umiejętnym wykorzystaniu komponentów rozwiązana zostaje kwestia „dużego kłębu bałaganu” (duży rozmiar + wysokie powiązania), a same komponenty mogą stanowić zarówno jednostki budowlane (moduły, biblioteki), jak i jednostki wdrażania (usługi). Jednostki wdrażania nie zawsze odpowiadają procesowi wykonywania: na przykład, aplikacja internetowa i baza danych są wdrażane wspólnie.
Najczęściej monolity są rozwijane w postaci zestawu modułów. Takie podejście prowadzi do zapewnienia niezależności rozwoju, ale przy tym problemy niezależnego skalowania i wdrażania, odporności na awarie i niezależności od wspólnego stosu technologicznego nadal pozostają. To dlatego moduł jest częściowo niezależnym komponentem.
Największym problemem takiego monolitu jest to, że podział na moduły jest czysto logiczny i może być łatwo naruszony przez programistów. Może się pojawić moduł core, który stopniowo przekształca się w bałagan, może rosnąć graf zależności między modułami i tak dalej. Aby uniknąć takich problemów, rozwój powinien być prowadzony albo przez bardzo dojrzały zespół, albo pod kierownictwem „architekta”, który na pełny etat zajmuje się przeglądami kodu i karze programistów naruszających logiczną strukturę.
„Idealny” monolit to zbiór logicznie wydzielonych modułów, z których każdy spogląda w swoją bazę danych.
Architektura zorientowana na usługi
Jeśli jednak planowane jest zorganizowanie systemu w postaci zestawu usług, to mamy do czynienia z architekturą zorientowaną na usługi. Jej zasady to: współpraca aplikacji zorientowanych na użytkowników, wielokrotne wykorzystanie usług biznesowych, niezależność od zestawu technologii oraz autonomiczność (niezależna ewolucja, skalowalność i wdrażalność).
Architektura zorientowana na usługi (SOA = service oriented architecture) rozwiązuje wszystkie zasygnalizowane problemy monolitu: przy zmianach dotyczy to tylko jednej usługi, a wyraźnie zdefiniowane API zapewnia dobrą enkapsulację komponentów.
Jednak nie wszystko jest takie proste: SOA prowadzi do pojawienia się nowych problemów. Wywołania zdalne są droższe niż lokalne, a redystrybucja obowiązków między komponentami stała się znacznie droższa.
Swoją drogą, możliwość niezależnego wdrażania to bardzo istotna cecha usługi. Jeśli usługi muszą być wdrażane wspólnie lub, co gorsza, w określonej kolejności, to system nie może być uznawany za zorientowany na usługi. W takim przypadku mówi się o rozproszonym monolicie (uznawanym za antipattern zarówno z perspektywy SOA, jak i architektury mikroserwisowej).
Architektura zorientowana na usługi jest dobrze wspierana przez społeczność architektów i dostawców. Stąd wynika obecność wielu kursów i certyfikacji, a także dobrze wpracowanych wzorców. Do ostatnich należy na przykład nie bez powodu znana autobus usług przedsiębiorstwa (ESB = enterprise service bus). Przy tym ESB to bagaż od dostawców, nie musi być koniecznie stosowane w SOA.
Szczyt popularności architektury zorientowanej na usługi przypadał na około 2008 rok, po czym zaczęła ona tracić na znaczeniu, co stało się znacznie bardziej wyraźne po pojawieniu się mikroserwisów (~2015 rok).
Podsumowanie
Po tym, jak omówiliśmy możliwości organizacji systemów informacyjnych w postaci usług i modułów, proponuję w końcu przejść do zasad architektury mikroserwisowej, poświęcając szczególną uwagę różnicom między architekturą mikroserwisową a zorientowaną na usługi w następnej części.
Źródło: habr.com
