Мен микросервис архитектурасы тақырыбына мақала жазғым келді, бірақ екі нәрсе мені тоқтатты - мен тақырыпқа неғұрлым тереңірек енген сайын, мен білетін нәрсем анық және мен не істеймін? үйренуді және зерделеуді қажет етеді. Екінші жағынан, кең аудитория арасында талқыланатын нәрсе бар деп ойлаймын. Сондықтан балама пікірлер қабылданады.
Конвей заңы және бизнес, ұйым және ақпараттық жүйе арасындағы байланыс
Мен тағы да дәйексөз келтіруге рұқсат етемін:
«Жүйені жобалайтын кез келген ұйым (кең мағынада) құрылымы сол ұйымдағы командалардың құрылымын қайталайтын дизайнды алады».
- Мелвин Конуэй, 1967 ж
Менің ойымша, бұл заң тікелей ақпараттық жүйеге емес, бизнесті ұйымдастырудың орындылығына қатысты болуы ықтимал. Мысалмен түсіндірейін. Бізде кәсіпорынды ұйымдастырудың мағынасы бар өмірлік циклі бар жеткілікті тұрақты бизнес мүмкіндігі бар делік (бұл қате емес, бірақ мен ұрлаған бұл термин маған өте ұнайды). Әрине, бұл бизнестің қолдау жүйесі. ұйымдық және процесстік сәйкес болады осы бизнес.
Ақпараттық жүйелердің іскерлік бағыты
Мысалмен түсіндірейін. Пицца сататын бизнесті ұйымдастыруға бизнес мүмкіндігі бар делік. V1 нұсқасында (оны алдын ала ақпарат деп атаймыз) компания пиццерия, касса және жеткізу қызметі болды. Бұл нұсқа қоршаған ортаның төмен өзгергіштігі жағдайында ұзақ өмір сүрді. Содан кейін оның орнына 2 нұсқасы келді - анағұрлым жетілдірілген және монолитті архитектурасы бар бизнес үшін ақпараттық жүйені пайдалана алады. Бұл жерде, менің ойымша, монолиттерге қатысты қорқынышты әділетсіздік бар - монолитті архитектурасы домендік бизнес үлгісіне сәйкес келмейді. Иә, егер солай болса, жүйе мүлдем жұмыс істей алмас еді - сол Конуэй заңына және парасаттылыққа қайшы келеді. Жоқ, монолитті архитектура бизнесті дамытудың осы сатысындағы бизнес-модельге толығымен сәйкес келеді - мен, әрине, жүйе қазірдің өзінде жасалып, пайдалануға берілген кезеңді айтамын. Сәулеттік тәсілге қарамастан, қызметке бағытталған архитектураның 3-нұсқасы да, микросервис архитектурасының N нұсқасы да бірдей жақсы жұмыс істейтіні өте керемет факт. Бұл не?
Барлығы ағып жатыр, бәрі өзгереді немесе микросервис күрделілікпен күресу құралы ма?
Жалғастырмас бұрын, микросервис архитектурасы туралы кейбір қате түсініктерді қарастырайық.
Микросервис тәсілін қолдануды жақтаушылар көбінесе микросервистерге монолитті бөлу жеке қызметтердің кодтық базасын қысқарту арқылы әзірлеу тәсілін жеңілдетеді деп айтады. Менің ойымша, бұл мәлімдеме мүлдем бос сөз. Шынымен, монолитті және біртекті код ішіндегі айқын өзара әрекеттесу күрделі болып көрінеді ме? Егер бұл шынымен де солай болса, барлық жобалар бастапқыда микросервис ретінде құрылатын еді, ал тәжірибе монолиттен микросервистерге көшу әлдеқайда кең таралғанын көрсетеді. Күрделілік жойылмайды; ол жай ғана жеке модульдерден интерфейстерге (деректер шинасы, RPC, API және басқа хаттамалар болсын) және басқару жүйелеріне ауысады. Және бұл қиын!
Гетерогенді стекті пайдаланудың артықшылығы да күмәнді. Мен бұл да мүмкін деп дауласпаймын, бірақ іс жүзінде бұл сирек кездеседі (Алға қарасақ - бұл болуы керек - артықшылық емес, салдары ретінде).
Өнімнің өмірлік циклі және қызмет ету циклі
Жоғарыдағы диаграмманы тағы бір қараңыз. Мен бизнестің жеке нұсқасының өмірлік циклінің қысқаруын кездейсоқ атап өткен жоқпын - қазіргі жағдайда бизнестің нұсқалар арасындағы ауысуын жеделдету оның табысты болуы үшін шешуші болып табылады. Өнімнің жетістігі ондағы іскерлік гипотезаларды сынау жылдамдығымен анықталады. Міне, менің ойымша, микросервис архитектурасының басты артықшылығы осында. Бірақ ретімен барайық.
Ақпараттық жүйелер эволюциясының келесі кезеңіне – SOA сервистік бағытталған архитектурасына көшейік. Сонымен, белгілі бір сәтте біз өз өнімімізде ерекше атап өттік ұзақ мерзімді қызметтер - өнімнің нұсқалары арасында ауысқанда қызметтің өмірлік циклі өнімнің келесі нұсқасының өмірлік циклінен ұзағырақ болу мүмкіндігі бар деген мағынада ұзақ өмір сүру. Оларды мүлдем өзгертпеу қисынды болар еді – біз Маңыздысы - келесі нұсқаға өту жылдамдығы. Өкінішке орай, біз қызметтерге үнемі өзгерістер енгізуге мәжбүрміз - және мұнда бәрі біз үшін жұмыс істейді, DevOps тәжірибесі, контейнеризация және т.б. - ойға келгеннің бәрі. Бірақ бұл әлі де микросервис емес!
Микросервис күрделілікпен күресу құралы ретінде... конфигурацияны басқару
Міне, ең соңында микросервистердің анықтаушы рөліне көшуге болады - бұл өнім конфигурациясын басқаруды жеңілдететін тәсіл. Толығырақ айтқанда, әрбір микросервистің функциясы домен үлгісіне сәйкес өнім ішіндегі бизнес функциясын дәл сипаттайды - бұл қысқа мерзімді нұсқада емес, ұзақ өмір сүретін бизнес мүмкіндігінде өмір сүретін нәрселер. Өнімнің келесі нұсқасына көшу іс жүзінде байқалмайды - сіз бір микросервисті және мүмкін олардың өзара әрекеттесу схемасын өзгертесіз/қосасыз және кенеттен сіз болашақта өзіңізді табасыз, бұл нұсқалар арасында секіруді жалғастыратын жылап тұрған бәсекелестерді артта қалдырасыз. олардың монолиттері. Енді алдын ала анықталған интерфейстері мен іскерлік мүмкіндіктері бар микросервистердің айтарлықтай үлкен көлемі бар екенін елестетіп көріңіз. Ал сіз келіп, дайын микросервистерден өзіңіздің өніміңіздің құрылымын жасайсыз - мысалы, диаграмманы салу арқылы. Құттықтаймыз - сізде платформа бар - енді сіз өзіңізге бизнес тарта аласыз. Армандар Армандар.
қорытындылар
- Жүйенің архитектурасы оның құрамдас бөліктерінің өмірлік циклімен анықталуы керек. Егер құрамдас өнім нұсқасында өмір сүрсе, микросервис тәсілін қолдану арқылы жүйенің күрделілігін арттырудың қажеті жоқ.
- Микросервис архитектурасы домен үлгісіне негізделуі керек, өйткені бизнес мүмкіндігі ең ұзақ өмір сүретін домен болып табылады
- Жеткізу тәжірибесі (DevOps тәжірибелері) және оркестрлеу микросервис архитектурасы үшін ең маңыздыларының бірі болып табылады - құрамдас бөліктердің өзгеру жылдамдығының артуы жеткізу жылдамдығы мен сапасына жоғары талаптар қояды.
Ақпарат көзі: www.habr.com