Сәлем, Хабр. Бүгін мен курстың жаңа ағынын бастау үшін арнайы жазған басылымдар сериясын жалғастырамын. .
Кіріспе
Архитектуралық стильді таңдау ақпараттық жүйені құру кезінде негізгі техникалық шешімдердің бірі болып табылады. Осы мақалалар сериясында мен қосымшаларды салуға арналған ең танымал архитектуралық стильдерді талдауды және қай сәулет стилі ең қолайлы деген сұраққа жауап беруді ұсынамын. Презентация процесінде мен монолиттерден микросервистерге дейінгі архитектуралық стильдердің дамуын түсіндіретін логикалық тізбекті сызуға тырысамын.
Өткен жолы біз монолиттердің әртүрлі түрлері және оларды құрастыру үшін құрамдастарды пайдалану, құрамдас бөліктерді құрастыру және орналастыру компоненттері туралы айттық. Біз қызмет көрсетуге бағытталған архитектураны түсінеміз.
Енді біз микросервис архитектурасының негізгі сипаттамаларын анықтаймыз.
Архитектуралардың байланысы
Алдыңғы мақалаларда берілген анықтамаларға сүйене отырып, кез келген қызмет компонент болып табылатынын түсіну керек, бірақ әрбір қызмет микросервис емес.
Микросервис архитектурасының сипаттамалары
Микросервис архитектурасының негізгі сипаттамалары:
- Бизнес мүмкіндіктері төңірегінде ұйымдастырылған
- Өнімдер жобалар емес
- Ақылды соңғы нүктелер және мылқау құбырлар
- Орталықтандырылмаған басқару
- Орталықтандырылмаған деректерді басқару
- Инфрақұрылымды автоматтандыру
- Сәтсіздікке арналған дизайн
- Эволюциялық дамуы бар сәулет (эволюциялық дизайн)
1-ші тармақ сервиске бағытталған архитектурадан келеді, себебі микросервистер қызметтердің ерекше жағдайы болып табылады. Басқа тармақтар бөлек қарастырылуы керек.
Бизнес мүмкіндіктері төңірегінде ұйымдастырылған
Енді Конуэй заңын еске түсіру қажет: жүйелерді жасайтын ұйымдар оның архитектурасын ұйымдастырады, осы ұйымдардың ішіндегі өзара әрекеттесу құрылымын көшіреді. Мысал ретінде компиляторды құру жағдайын еске түсіруге болады: жеті адамнан тұратын топ жеті жолды компиляторды, ал бес адамнан тұратын топ бес жолды құрастырушыны әзірледі.
Егер біз монолиттер мен микросервистер туралы айтатын болсақ, онда әзірлеу функционалдық бөлімдермен (бэкенд, фронтенд, дерекқор әкімшілері) ұйымдастырылса, онда біз классикалық монолит аламыз.
Микросервистерді алу үшін командалар іскерлік мүмкіндіктері бойынша ұйымдастырылуы керек (тапсырыстар, жөнелтілімдер, каталог тобы). Бұл ұйым командаларға қолданбаның нақты бөліктерін құруға назар аударуға мүмкіндік береді.
Өнімдер жобалар емес
Топ әзірленген функционалдылықты басқа топтарға тасымалдайтын жоба тәсілі микросервис архитектурасы жағдайында мүлдем жарамсыз. Команда жүйенің өмірлік циклі бойына қолдау көрсетуі керек. Микросервистерді енгізудегі көшбасшылардың бірі Amazon: «Сіз саласыз, оны басқарасыз» деп мәлімдеді. Өнімге деген көзқарас командаға бизнестің қажеттіліктерін сезінуге мүмкіндік береді.
Ақылды соңғы нүктелер және мылқау құбырлар
SOA архитектурасы байланыс арналарына, атап айтқанда Enterprise Service Bus-қа үлкен көңіл бөлді. Бұл көбінесе қате спагетти қорапшасына әкеледі, яғни монолиттің күрделілігі қызметтер арасындағы байланыстардың күрделілігіне айналады. Микросервис архитектурасы тек қарапайым байланыс әдістерін пайдаланады.
Орталықтандырылмаған басқару
Микросервистерге қатысты негізгі шешімдерді микросервистерді нақты дамытатын адамдар қабылдауы керек. Мұнда негізгі шешімдер таңдауды білдіреді
бағдарламалау тілдері, орналастыру әдістемесі, жалпыға ортақ интерфейс келісімшарттары және т.б.
Орталықтандырылмаған деректерді басқару
Қолданба бір дерекқорға сүйенетін стандартты тәсіл әрбір нақты қызметтің ерекшеліктерін ескере алмайды. MSA әртүрлі технологияларды пайдалануды қоса, орталықтандырылмаған деректерді басқаруды қамтиды.
Инфрақұрылымды автоматтандыру
MSA үздіксіз орналастыру және жеткізу процестерін қолдайды. Бұған процестерді автоматтандыру арқылы ғана қол жеткізуге болады. Сонымен қатар, көптеген қызметтерді қолдану енді қорқынышты нәрсе сияқты емес. Орналастыру процесі қызықсыз болуы керек. Екінші аспект өнім ортасында қызметті басқарумен байланысты. Автоматтандырусыз әртүрлі операциялық орталарда жұмыс істейтін процестерді басқару мүмкін емес.
Сәтсіздікке арналған дизайн
Көптеген MSA қызметтері сәтсіздікке ұшырайды. Сонымен қатар үлестірілген жүйеде қателерді өңдеу тривиальды міндет емес. Қолданбаның архитектурасы мұндай сәтсіздіктерге төзімді болуы керек. Ребекка Парсонс бұдан былай қызметтер арасындағы процесс ішіндегі байланысты қолданбау өте маңызды деп санайды; оның орнына біз байланыс үшін HTTP-ге жүгінеміз, ол соншалықты сенімді емес.
Эволюциялық дамуы бар сәулет (эволюциялық дизайн)
MSA жүйесінің архитектурасы эволюциялық жолмен дамуы керек. Бір қызметтің шекарасына қажетті өзгерістерді шектеген жөн. Басқа қызметтерге әсерін де ескеру қажет. Дәстүрлі әдіс - бұл мәселені версиямен шешуге тырысу, бірақ MSA нұсқасын енгізуді пайдалануды ұсынады
соңғы шара ретінде.
қорытынды
Жоғарыда айтылғандардың барлығынан кейін біз микросервистердің не екенін тұжырымдай аламыз. Микросервис архитектурасы - бұл әрқайсысы өз процесінде жұмыс істейтін және жеңіл механизмдер, көбінесе HTTP ресурсының API арқылы өзара әрекеттесетін шағын қызметтер жиынтығы ретінде бір қолданбаны әзірлеу тәсілі. Бұл қызметтер іскерлік мүмкіндіктерге негізделген және оларды толығымен пайдалану арқылы дербес орналастыруға болады
автоматтандырылған орналастыру механизмі. Бұл қызметтерді орталықтандырылған басқарудың ең төменгі деңгейі бар, оны әртүрлі бағдарламалау тілдерінде жазуға және әртүрлі деректерді сақтау технологияларын қолдануға болады.
Ақпарат көзі: www.habr.com