Избор на архитектурен стил (част 2)

Здравей, Хабр. Днес продължавам поредица от публикации, които написах специално за началото на нов поток от курса. "Софтуерен архитект".

въведение

Изборът на архитектурен стил е едно от основните технически решения при изграждане на информационна система. В тази поредица от статии предлагам да анализирам най-популярните архитектурни стилове за изграждане на приложения и да отговоря на въпроса кога кой архитектурен стил е най-предпочитан. В процеса на представяне ще се опитам да начертая логическа верига, която обяснява развитието на архитектурни стилове от монолити до микроуслуги.

В последен път занимавахме се с монолита и стигнахме до извода, че монолитът има редица проблеми: размер, свързаност, внедряване, мащабируемост, надеждност и твърдост.

Този път предлагам да поговорим за възможностите за организиране на система като набор от модули/библиотеки (ориентирана към компоненти архитектура) или услуги (ориентирана към услуги архитектура).

Компонентно-ориентирана архитектура

Компонентно-ориентираната архитектура включва изпълнение на система като набор от компоненти, които могат да се използват както в настоящи, така и в бъдещи проекти. При разделянето на системата на компоненти се вземат предвид следните: тяхната повторна употреба, тяхната заменяемост, независимост от контекста, разширяемост, капсулиране и независимост.

С правилното използване на компонентите проблемът с „голямата топка мръсотия“ (голям размер + високо свързване) се решава, а самите компоненти могат да бъдат както монтажни единици (модули, библиотеки), така и единици за разгръщане (услуги). Единиците за внедряване не винаги се съпоставят с изпълнявания процес: например уеб приложение и база данни се разполагат заедно.

Най-често монолитите се разработват като набор от модули. Този подход води до независимо развитие, но проблемите с независимото мащабиране и внедряване, устойчивостта на грешки и независимостта от цялостния технологичен стек остават. Ето защо модулът е частично независим компонент.

Най-големият проблем при такъв монолит е, че разделението на модули е чисто логично и лесно може да бъде нарушено от разработчиците. Може да се появи основен модул, който постепенно се превръща в сметище, графиката на зависимостите между модулите може да расте и т.н. За да се избегнат подобни проблеми, разработката трябва да се извършва или от много зрял екип, или под ръководството на „архитект“, който се занимава с преглед на кода на пълен работен ден и бие ръцете на разработчиците, които нарушават логическата структура.

„Идеалният“ монолит е набор от логически разделени модули, всеки от които гледа в собствена база данни.

Сервизно-ориентирана архитектура

Ако системата трябва да бъде организирана под формата на набор от услуги, тогава говорим за ориентирана към услуги архитектура. Неговите принципи са ориентирана към потребителя оперативна съвместимост на приложения, повторно използване на бизнес услуги, независимост на технологичния стек и автономност (независима еволюция, мащабируемост и внедряване).

Архитектурата, ориентирана към услугата (SOA = архитектура, ориентирана към услуга) решава всички идентифицирани проблеми на монолит: само една услуга е засегната, когато настъпи промяна, а добре дефиниран API поддържа добро капсулиране на компоненти.

Но не всичко е толкова гладко: SOA създава нови проблеми. Дистанционните разговори са по-скъпи от локалните, а преразпределянето на отговорностите между компонентите стана значително по-скъпо.

Между другото, възможността за независимо внедряване е много важна характеристика на услугата. Ако услугите трябва да бъдат разгърнати заедно или освен това в определена последователност, тогава системата не може да се счита за ориентирана към услуги. В този случай те говорят за разпределен монолит (считан за анти-модел не само от гледна точка на SOA, но и от гледна точка на архитектурата на микросервизите).

Архитектурата, ориентирана към услуги, се поддържа добре от архитектурната общност и доставчиците. Това предполага наличието на много курсове и сертификати, добре разработени модели. Последното включва, например, добре познатата корпоративна сервизна шина (ESB = корпоративна сервизна шина). В същото време ESB е багаж от доставчици; не е задължително да се използва в SOA.

Популярността на ориентираната към услуги архитектура достига своя връх около 2008 г., след което започва да намалява, което става значително по-драматично след появата на микроуслугите (~2015 г.).

Заключение

След като обсъдихме възможностите за организиране на информационни системи под формата на услуги и модули, предлагам най-накрая да преминем към принципите на архитектурата на микросервизите и да обърнем специално внимание на разликата между архитектурата на микросервизите и ориентираната към услуги архитектура в следващата част.

Източник: www.habr.com