Привіт Хабр. Сьогодні я продовжую серію публікацій, яку написав спеціально до старту нового потоку курсу .
Запровадження
Вибір архітектурного стилю є одним із основних технічних рішень при побудові інформаційної системи. У цій серії статей я пропоную розібрати найпопулярніші архітектурні стилі побудови додатків і відповісти на питання коли який архітектурний стиль є найкращим. У процесі викладу я намагатимуся провести логічний ланцюжок, який пояснює розвиток архітектурних стилів від монолітів до мікросервісів.
В ми розібралися з монолітом і прийшли до того, що моноліт має низку проблем: розмір, пов'язаність, розгортання, масштабованість, надійність та відсталість.
На цей раз я пропоную поговорити про можливості організації системи у вигляді набору модулів/бібліотек (компонентно-орієнтована архітектура) або сервісів (сервіс-орієнтована архітектура).
Компонентно-орієнтована архітектура
Компонентно-орієнтована архітектура передбачає виконання системи як набору компонентів, які можна використовувати як у поточному, і у майбутніх проектах. При розбиття системи на компоненти враховуються: придатність їх для повторного використання, їх заміна, незалежність від контексту, розширюваність, інкапсуляцію та незалежність.
При грамотному використанні компонентів вирішується проблема «великої грудки бруду» (великий розмір + висока пов'язаність), а самі компоненти можуть являти собою як одиниці збірки (модулі, бібліотеки), так і одиниці розгортання (сервіси). Одиниці розгортання не завжди відображаються на процес, що виконується: наприклад, веб-додаток і база даних розгортаються спільно.
Найчастіше моноліти розробляють у вигляді набору модулів. Такий підхід призводить до забезпечення незалежності розробки, але при цьому проблеми незалежних масштабування та розгортання, відмовостійкості та незалежності від загального технологічного стеку залишаються. Саме тому модуль – частково незалежна компонента.
Найголовніша проблема такого моноліту полягає в тому, що поділ на модулі є суто логічним і може бути легко порушеним розробниками. Може з'явитися модуль core, який поступово перетворюється на смітник, може зростати граф залежностей між модулями і так далі. Для уникнення таких проблем розробка повинна вести або дуже зрілу команду, або під керівництвом «архітектора», який на full time займається code review і б'є розробників по руках, що порушують логічну структуру.
«Ідеальний» моноліт є набором логічно розділених модулів, кожен із яких дивиться у свою базу даних.
Сервіс-орієнтована архітектура
Якщо ж передбачається організація системи як набору сервісів, то йдеться про сервис-ориентированной архітектурі. Її принципи: поєднання програм, орієнтованих на користувачів, багаторазове використання бізнес-сервісів, незалежність від набору технологій і автономність (незалежні еволюція, масштабованість і розгортання).
Сервіс-орієнтована архітектура (SOA = service oriented architecture) вирішує всі зазначені проблеми моноліту: при зміні торкається лише одна служба, а чітко визначений API підтримує хорошу інкапсуляцію компонентів.
Але не все так гладко: SOA призводить до нових проблем. Віддалені виклики дорожчі за локальні, а перерозподіл обов'язків між компонентами став істотно дорожчим.
До речі, можливість незалежного розгортання — це дуже важлива особливість сервісу. Якщо послуги повинні розгортатися спільно або, тим більше, у певній послідовності, то система не може вважатися сервіс-орієнтованою. У такому разі говорять про розподілений моноліт (вважається антипаттерном не тільки з точки зору SOA, але й мікросервісної архітектури).
Сервіс-орієнтована архітектура непогано підтримується архітектурним ком'юніті та вендорами. Звідси випливає наявність безлічі курсів і сертифікацій, добре опрацьованих патернів. До останніх відноситься, наприклад, невідома сервісна шина підприємства (ESB = enterprise service bus). При цьому ESB це багаж від вендорів, вона не обов'язково повинна використовуватися в SOA.
Пік популярності сервіс-орієнтованої архітектури припадав приблизно на 2008 рік, після чого вона пішла на спад, який став значно різкішим після появи мікросервісів (~2015).
Висновок
Після того, як ми обговорили можливості організації інформаційних систем у вигляді сервісів та модулів, я пропоную нарешті перейти до принципів мікросервісної архітектури та приділити особливу увагу відмінності мікросервісної архітектури від сервіс-орієнтованої в наступній частині.
Джерело: habr.com