Service Mesh микросервистерді біріктіруге және бұлттық инфрақұрылымға көшуге арналған белгілі архитектуралық үлгі болып табылады. Бүгінгі күні бұлт-контейнер әлемінде онсыз істеу өте қиын. Бірнеше ашық бастапқы сервистік торды енгізулер нарықта қазірдің өзінде қол жетімді, бірақ олардың функционалдығы, сенімділігі мен қауіпсіздігі әрқашан жеткіліксіз, әсіресе бүкіл ел бойынша ірі қаржылық компаниялардың талаптарына келгенде. Сондықтан біз Sbertech-те Service Mesh-ті теңшеуді шештік және Service Mesh-тің не жақсы екені, ненің соншалықты жақсы емес екендігі және бұл туралы не істейтініміз туралы сөйлескіміз келеді.
Service Mesh үлгісінің танымалдылығы бұлтты технологиялардың танымалдылығымен өсуде. Бұл әртүрлі желі қызметтері арасындағы өзара әрекеттесуді жеңілдететін арнайы инфрақұрылым қабаты. Заманауи бұлттық қолданбалар жүздеген, тіпті мыңдаған осындай қызметтерден тұрады, олардың әрқайсысында мыңдаған көшірмелер болуы мүмкін.
Осы қызметтер арасындағы өзара әрекеттесу және оларды басқару Service Mesh жүйесінің негізгі міндеті болып табылады. Шын мәнінде, бұл орталықтан басқарылатын және өте пайдалы функциялар жиынтығын орындайтын көптеген прокси-серверлердің желілік моделі.
Прокси деңгейінде (деректер жазықтығы):
- Маршруттау және трафикті теңестіру саясатын тағайындау және тарату
- Кілттерді, сертификаттарды, жетондарды тарату
- Телеметрия жинағы, бақылау метрикасын генерациялау
- Қауіпсіздік және мониторинг инфрақұрылымымен интеграция
Басқару жазықтығы деңгейінде:
- Маршрутизация және трафикті теңестіру саясатын қолдану
- Қайталау және күту уақытын басқару, «өлі» түйіндерді анықтау (тұйықталу), инъекциялық ақауларды басқару және басқа механизмдер арқылы қызметтің тұрақтылығын қамтамасыз ету
- Қоңыраудың аутентификациясы/авторизациясы
- Көрсеткіштерді түсіру (бақылау мүмкіндігі)
Бұл технологияны дамытуға мүдделі пайдаланушылардың ауқымы өте кең - шағын стартаптардан ірі интернет-корпорацияларға дейін, мысалы, PayPal.
Неліктен Service Mesh корпоративтік секторға қажет?
Қызметтік торды пайдаланудың көптеген айқын артықшылықтары бар. Ең алдымен, бұл әзірлеушілерге ыңғайлы: код жазу үшін технологиялық платформа пайда болады, бұл көлік қабаты қолданбалы логикадан толығымен оқшауланғандықтан, бұлттық инфрақұрылымға интеграцияны айтарлықтай жеңілдетеді.
Сонымен қатар, Service Mesh жеткізушілер мен тұтынушылар арасындағы қарым-қатынасты жеңілдетеді. Бүгінгі таңда API провайдерлері мен тұтынушылары үшін арнайы интеграциялық делдал мен төреші – кәсіпорынның сервистік автобусын тартпай-ақ, интерфейстер мен келісім-шарттарды дербес келісу әлдеқайда оңай. Бұл тәсіл екі көрсеткішке айтарлықтай әсер етеді. Жаңа функционалдылықты нарыққа шығару жылдамдығы (нарыққа шығу уақыты) артады, бірақ сонымен бірге шешімнің құны артады, өйткені интеграцияны дербес орындау керек. Бизнестің функционалдық мүмкіндіктерін дамыту топтарының Service Mesh пайдалануы осы жерде тепе-теңдікті сақтауға көмектеседі. Нәтижесінде API провайдерлері тек қана өз қызметінің қолданбалы құрамдас бөлігіне назар аудара алады және оны жай ғана Service Mesh жүйесінде жариялай алады - API дереу барлық клиенттерге қол жетімді болады және интеграция сапасы өндіріске дайын болады және бірдеңені қажет етпейді. қосымша код жолы.
Келесі артықшылығы - бұл әзірлеуші Service Mesh-ті пайдалана отырып, тек бизнес функционалдығына назар аударады — оның қызметінің технологиялық құрамдас бөлігінен гөрі өнімде. Мысалы, желі арқылы қызмет шақырылған жағдайда, бір жерде қосылым ақаулығы орын алуы мүмкін екендігі туралы ойланудың қажеті жоқ. Бұған қоса, Service Mesh бір қызметтің көшірмелері арасындағы трафикті теңестіруге көмектеседі: көшірмелердің бірі «өлсе», жүйе барлық трафикті қалған тірі көшірмелерге ауыстырады.
Қызмет торы - бұл таратылған қолданбаларды жасау үшін жақсы негіз болып табылады, ол клиенттен өз қызметтеріне ішкі және сыртқы қоңырауларды ұсыну мәліметтерін жасырады. Service Mesh пайдаланатын барлық қолданбалар тасымалдау деңгейінде желіден де, бір-бірінен де оқшауланған: олардың арасында байланыс жоқ. Бұл жағдайда әзірлеуші өз қызметтерін толық бақылауға алады.
Айта кету керек Қызметтік тор ортасында таратылған қолданбаларды жаңарту оңайырақ болады. Мысалы, орнату үшін екі қолданба ортасы қолжетімді, біреуі жаңартылмаған және күту режимінде болатын көк/жасыл орналастыру. Сәтсіз шығарылған жағдайда алдыңғы нұсқаға оралуды Service Mesh қызметі жақсы орындайтын арнайы маршрутизатор жүзеге асырады.. Жаңа нұсқаны тексеру үшін пайдалануға болады канарея шығару — жаңа нұсқаға трафиктің тек 10% немесе пилоттық клиенттер тобының сұрауларына ауысыңыз. Негізгі трафик ескі нұсқаға өтеді, ештеңе бұзылмайды.
Сондай-ақ, Service Mesh бізге нақты уақыттағы SLA басқаруын береді. Бөлінген прокси жүйесі клиенттердің бірі оған тағайындалған квотадан асып кеткен кезде қызметтің істен шығуына жол бермейді. Егер API өткізу мүмкіндігі шектеулі болса, оны транзакциялардың үлкен санымен ешкім басып кете алмайды: Service Mesh қызметтің алдында тұрады және қажетсіз трафикке жол бермейді. Ол жай ғана интеграциялық қабатта күреседі және қызметтердің өзі оны байқамай жұмысын жалғастырады.
Егер компания интеграциялық шешімдерді әзірлеуге арналған шығындарды азайтқысы келсе, Service Mesh сонымен қатар көмектеседі: Сіз оның ашық бастапқы нұсқасына коммерциялық өнімдерден ауыса аласыз. Біздің Enterprise Service Mesh жүйесі Service Mesh жүйесінің ашық бастапқы нұсқасына негізделген.
Тағы бір артықшылығы - интеграциялық қызметтердің бірыңғай толыққанды жиынтығының болуы. Барлық интеграция осы аралық бағдарлама арқылы жасалғандықтан, біз барлық интеграциялық трафикті және компанияның бизнес өзегін құрайтын қолданбалар арасындағы байланыстарды басқара аламыз. Бұл өте ыңғайлы.
Ақыр соңында Service Mesh компанияны динамикалық инфрақұрылымға көшуге шақырады. Қазір көбісі контейнерлеуді қарастыруда. Микросервистерге монолитті кесу, осының бәрін әдемі жүзеге асыру - тақырып көтерілуде. Бірақ көп жылдар бойы өндірісте болған жүйені жаңа платформаға көшіруге тырысқанда, сіз бірден бірқатар проблемаларға тап боласыз: оның бәрін контейнерлерге итеріп, платформаға орналастыру оңай емес. Ал осы таратылған құрамдастардың жүзеге асуы, синхронизациясы және өзара әрекеттесуі тағы бір өте күрделі тақырып. Олар бір-бірімен қалай байланысады? Каскадты сәтсіздіктер бола ма? Service Mesh осы мәселелердің кейбірін шешуге және ескі архитектурадан жаңасына көшуді жеңілдетуге мүмкіндік береді, өйткені желі алмасу логикасын ұмытуға болады.
Неліктен сізге Service Mesh теңшеу керек?
Біздің компанияда жүздеген жүйелер мен модульдер бірге жұмыс істейді және жұмыс уақыты өте жүктеледі. Сондықтан бір жүйенің екіншісін шақырып, жауап алудың қарапайым үлгісі жеткіліксіз, өйткені өндірісте біз көп нәрсені қалаймыз. Кәсіпорынның қызмет көрсету торынан тағы не қажет?
Оқиғаларды өңдеу қызметі
Біз нақты уақыттағы оқиғаны өңдеуді жасауымыз керек деп елестетіп көрейік - клиенттің іс-әрекетін нақты уақыт режимінде талдайтын және оған бірден сәйкес ұсыныс жасай алатын жүйе. Ұқсас функционалдылықты іске асыру үшін пайдаланыңыз оқиғаға негізделген архитектура (EDA) деп аталатын архитектуралық үлгі. Қазіргі қызмет көрсету торларының ешқайсысы мұндай үлгілерді қолдамайды, бірақ бұл өте маңызды, әсіресе банк үшін!
Қашықтан процедураны шақыруға (RPC) Service Mesh-тің барлық нұсқалары қолдау көрсететіні өте таңқаларлық, бірақ олар EDA-мен жақсы емес. Себебі Service Mesh - бұл заманауи таратылған интеграцияның бір түрі, ал EDA - тұтынушы тәжірибесі тұрғысынан бірегей нәрселерді жасауға мүмкіндік беретін өте өзекті архитектуралық үлгі.
Біздің Enterprise Service Mesh бұл мәселені шешуі керек. Бұдан басқа, біз онда әртүрлі сүзгілер мен үлгілерді пайдалана отырып, кепілдік берілген жеткізуді, ағынды және күрделі оқиғаларды өңдеуді жүзеге асыруды көргіміз келеді.
Файлдарды тасымалдау қызметі
EDA-дан басқа, файлдарды тасымалдау мүмкіндігі болуы жақсы болар еді: Кәсіпорын масштабында көбінесе тек файлдарды біріктіру мүмкін. Атап айтқанда, ETL (Extract, Transform, Load) архитектуралық үлгісі қолданылады. Онда, әдетте, барлығы файлдарды тек қана алмасады: үлкен деректер пайдаланылады, бұл бөлек сұрауларды жіберу мүмкін емес. Enterprise Service Mesh жүйесінде файлдарды тасымалдауды жергілікті түрде қолдау мүмкіндігі сізге бизнеске қажетті икемділік береді.
Оркестрлік қызмет
Ірі ұйымдарда әрдайым дерлік әртүрлі өнімдерді жасайтын әртүрлі командалар болады. Мысалы, банкте кейбір командалар депозиттермен жұмыс істесе, басқалары несиелік өнімдермен жұмыс істейді және мұндай жағдайлар өте көп. Бұл әр түрлі адамдар, өз өнімдерін жасайтын, API интерфейстерін әзірлейтін және оларды басқаларға беретін әртүрлі командалар. Көбінесе бұл қызметтерді құрастыру, сонымен қатар API жиынтығын дәйекті түрде шақыру үшін күрделі логиканы енгізу қажет. Бұл мәселені шешу үшін интеграциялық қабатта барлық осы құрама логиканы жеңілдететін шешім қажет (бірнеше API шақыру, сұрау маршрутын сипаттау және т.б.). Бұл Enterprise Service Mesh жүйесіндегі оркестрлік қызмет.
AI және ML
Микросервистер бір интеграциялық деңгей арқылы байланысқан кезде, Service Mesh әрбір қызметтің қоңыраулары туралы бәрін біледі. Біз телеметрияны жинаймыз: кім кімге, қашан, қанша уақытқа, қанша рет қоңырау шалды және т.б. Жүздеген мың осы қызметтер және миллиардтаған қоңыраулар болған кезде, мұның бәрі жинақталады және Big Data құрайды. Бұл деректерді AI, машиналық оқыту және т.б. қолдану арқылы талдауға болады, содан кейін талдау нәтижелеріне негізделген кейбір пайдалы нәрселерді жасауға болады. Барлық осы желілік трафикті және Service Mesh жүйесіне біріктірілген қолданбалы қоңырауларды басқаруды кем дегенде ішінара жасанды интеллектке тапсыру орынды болар еді.
API шлюз қызметі
Әдетте, Service Mesh сенімді периметрі ішінде бір-бірімен сөйлесетін прокси-серверлер мен қызметтерге ие. Бірақ сыртқы контрагенттер де бар. Тұтынушылардың осы тобына жататын API интерфейстеріне қойылатын талаптар әлдеқайда қатал. Бұл тапсырманы екі негізгі бөлікке бөлеміз.
- Қауіпсіздік. Ddos, хаттамалардың, қолданбалардың, операциялық жүйелердің осалдығы және т.б. қатысты мәселелер.
- Маштабы. Клиенттерге қызмет көрсету қажет API саны мыңдаған немесе тіпті жүздеген мыңға жеткенде, осы API жиынтығы үшін басқару құралының қандай да бір түрі қажет болады. Сіз API-ны үнемі бақылап отыруыңыз керек: олар жұмыс істеп жатыр ма, жоқ па, олардың мәртебесі қандай, трафик қандай, қандай статистика және т.б. API шлюзі бүкіл процесті басқарылатын және қауіпсіз ете отырып, бұл тапсырманы орындауы керек. Осы компоненттің арқасында Enterprise Service Mesh ішкі және сыртқы API интерфейстерін оңай жариялауды үйренеді.
Арнайы хаттамалар мен деректер пішімдерін қолдау қызметі (AS шлюзі)
Қазіргі уақытта көптеген Service Mesh шешімдері тек HTTP және HTTP2 трафигімен немесе TCP/IP деңгейінде азайтылған режимде жергілікті түрде жұмыс істей алады. Enterprise Service Mesh көптеген басқа өте нақты деректерді тасымалдау протоколдарымен бірге пайда болады. Кейбір жүйелер хабарлама брокерлерін пайдалана алады, басқалары дерекқор деңгейінде біріктірілген. Егер компанияда SAP болса, онда ол өзінің интеграциялық жүйесін де пайдалана алады. Оның үстіне, мұның бәрі жұмыс істейді және бизнестің маңызды бөлігі болып табылады.
Сіз жай ғана: «Мұрадан бас тартып, Service Mesh пайдалана алатын жаңа жүйелер жасайық» деп айта алмайсыз. Барлық ескі жүйелерді жаңаларымен (микросервис архитектурасында) қосу үшін Service Mesh пайдалана алатын жүйелерге қандай да бір адаптер, делдал, шлюз қажет болады. Келісемін, ол қызметпен бірге қорапта келсе жақсы болар еді. Айнымалы ток шлюзі кез келген біріктіру опциясын қолдай алады. Елестетіп көріңізші, сіз жай ғана Enterprise Service Mesh орнатасыз және ол сізге қажет барлық протоколдармен әрекеттесуге дайын. Бұл тәсіл біз үшін өте маңызды.
Біз Service Mesh (Enterprise Service Mesh) корпоративтік нұсқасын шамамен осылай елестетеміз. Сипатталған теңшеу интеграциялық платформаның дайын ашық бастапқы нұсқаларын пайдалануға тырысқанда туындайтын мәселелердің көпшілігін шешеді. Бірнеше жыл бұрын енгізілген Service Mesh архитектурасы дамуын жалғастыруда және біз оның дамуына үлес қоса алатынымызға қуаныштымыз. Біздің тәжірибеміз сізге пайдалы болады деп үміттенеміз.
Ақпарат көзі: www.habr.com