Эй Хабр! Назарларыңызға мақаланың аудармасын ұсынамын автор Мэт Клейн.
Бұл жолы мен қызмет көрсету торының құрамдас бөліктерінің, деректер жазықтығының және басқару жазықтығының сипаттамасын «қалады және аудардым». Бұл сипаттама маған ең түсінікті және қызықты болып көрінді, және ең бастысы «Бұл қажет пе?» Деген сұрақты түсінуге әкелді.
Соңғы екі жылда «Қызмет көрсету торы» идеясы барған сайын танымал бола бастағандықтан (10 жылғы 2017 қазандағы түпнұсқа мақала) және кеңістікке қатысушылардың саны көбейгендіктен, мен бүкіл әлем арасында шатасулардың сәйкес өсуін байқадым. әртүрлі шешімдерді салыстыру және салыстыру туралы техникалық қауымдастық.
Жағдайды мен шілде айында жазған твиттер сериясы жақсы қорытындылайды:
Қызмет торының шатасуы №1: Linkerd ~ = Nginx ~ = Haproxy ~ = Өкіл. Олардың ешқайсысы Истиоға тең келмейді. Истио мүлдем басқа нәрсе. 1 /
Біріншісі жай деректер жазықтықтары. Өздігінен олар ештеңе істемейді. Олар басқа нәрсеге көңіл-күйде болуы керек. 2/
Istio - бөліктерді бір-бірімен байланыстыратын басқару жазықтығының мысалы. Бұл басқа қабат. /Соңы
Алдыңғы твиттерде бірнеше түрлі жобалар (Linkerd, NGINX, HAProxy, Envoy және Istio) айтылған, бірақ одан да маңыздысы деректер жазықтығы, қызмет көрсету торы және басқару жазықтығы туралы жалпы түсініктерді енгізеді. Бұл постта мен бір қадам артқа шегінемін және «деректер жазықтығы» және «басқару ұшағы» терминдері арқылы нені білдіретінімді өте жоғары деңгейде айтамын, содан кейін терминдердің твиттерде айтылған жобаларға қалай қолданылатыны туралы сөйлесемін.
Қызмет көрсету торы дегеніміз не?
1-сурет: Қызмет торына шолу
Сурет 1 қызмет көрсету торының тұжырымдамасын ең негізгі деңгейде көрсетеді. Төрт қызмет көрсету кластері (AD) бар. Әрбір қызмет данасы жергілікті прокси сервермен байланысты. Бір қолданба данасынан барлық желілік трафик (HTTP, REST, gRPC, Redis және т.б.) жергілікті прокси арқылы сәйкес сыртқы қызмет кластерлеріне жіберіледі. Осылайша, қолданба данасы тұтас желіден бейхабар және тек жергілікті прокси-серверінен хабардар болады. Іс жүзінде таратылған жүйелік желі қызметтен жойылды.
Деректер жазықтығы
Қызметтік торда қолданба үшін жергілікті жерде орналасқан прокси сервер келесі тапсырмаларды орындайды:
- Қызметті табу. Қолданбаңыз үшін қандай қызметтер/қолданбалар қолжетімді?
- Денсаулықты тексеру. Қызметті табу арқылы қайтарылған қызмет даналары сау және желілік трафикті қабылдауға дайын ба? Бұған белсенді (мысалы, жауап/денсаулықты тексеру) және пассивті (мысалы, қызмет көрсетудің дұрыс емес күйінің көрсеткіші ретінде қатарынан 3 5xx қатесін пайдалану) денсаулық тексерулері кіруі мүмкін.
- Маршрутизация. REST қызметінен «/foo» сұрауын алған кезде сұрауды қай қызмет кластеріне жіберу керек?
- Жүктемені теңестіру. Маршруттау кезінде қызмет кластері таңдалғаннан кейін сұрауды қай қызмет данасына жіберу керек? Қандай тайм-аутпен? Қандай тізбекті ажырату параметрлерімен? Сұрау сәтсіз болса, оны қайталау керек пе?
- Аутентификация және авторизация. Кіріс сұраулары үшін қоңырау шалу қызметін mTLS немесе басқа механизмді пайдаланып криптографиялық сәйкестендіру/рұқсат ету мүмкін бе? Егер ол танылса/рұқсат етілсе, қызметте сұралған операцияға (соңғы нүктеге) қоңырау шалуға рұқсат етілген бе, әлде аутентификацияланбаған жауапты қайтару керек пе?
- Бақылау мүмкіндігі. Операторлар таратылған трафик ағынын және олар туындаған кезде жөндеу мәселелерін түсінуі үшін егжей-тегжейлі статистика, журналдар/журналдар және таратылған бақылау деректері әрбір сұрау үшін жасалуы керек.
Деректер жазықтығы қызмет көрсету торындағы барлық алдыңғы нүктелерге жауап береді. Шын мәнінде, қызметке жергілікті прокси (сервер) деректер жазықтығы болып табылады. Басқаша айтқанда, деректер жазықтығы қызметке немесе қызметтен жіберілетін әрбір желі пакетін шартты түрде таратуға, қайта жіберуге және бақылауға жауап береді.
Басқару жазықтығы
Жергілікті прокси деректер жазықтығында қамтамасыз ететін желі абстракциясы сиқырлы(?). Дегенмен, прокси В қызметіне "/foo" бағыты туралы шынымен қалай біледі? Прокси сұраулары арқылы толтырылған қызметті табу деректерін қалай пайдалануға болады? Жүктемені теңестіру, күту уақыты, тізбекті үзу және т.б. үшін параметрлер қалай конфигурацияланады? Қолданбаны көк/жасыл әдісті немесе трафикті тамаша өту әдісін қолданып қалай орналастыруға болады? Жүйе бойынша аутентификация және авторизация параметрлерін кім конфигурациялайды?
Жоғарыда аталған заттардың барлығы қызмет көрсету торының басқару жазықтығының бақылауында. Басқару жазықтығы оқшауланған азаматтығы жоқ прокси-серверлер жинағын алып, оларды бөлінген жүйеге айналдырады.
Менің ойымша, көптеген технологтардың деректер жазықтығы мен басқару ұшағы туралы жеке ұғымдарды шатастыратын себебі, көптеген адамдар үшін деректер жазықтығы таныс, ал басқару жазықтығы шетелдік/түсінікті емес. Біз физикалық желі маршрутизаторларымен және коммутаторларымен ұзақ уақыт бойы жұмыс істеп келеміз. Біз пакеттер/сұраныстардың А нүктесінен В нүктесіне өтуі керек екенін және бұл үшін аппараттық және бағдарламалық құралды пайдалана алатынымызды түсінеміз. Бағдарламалық жасақтаманың прокси-серверлерінің жаңа буыны - біз ұзақ уақыт бойы қолданып жүрген құралдардың жай ғана сәнді нұсқалары.
2-сурет: Адамның басқару ұшағы
Дегенмен, біз басқару ұшақтарын ұзақ уақыт бойы қолданып келеміз, дегенмен көптеген желілік операторлар жүйенің бұл бөлігін ешбір технологиялық құрамдаспен байланыстырмауы мүмкін. Себебі қарапайым:
Бүгінгі таңда қолданылатын басқару ұшақтарының көпшілігі... біз.
туралы 2 сурет Мен «Адамның басқару ұшағы» деп атайтын нәрсені көрсетеді. Орналастырудың бұл түрінде, әлі де өте кең таралған, мүмкін ашулы адам операторы статикалық конфигурацияларды жасайды - ықтимал сценарийлер арқылы - және оларды кейбір арнайы процесс арқылы барлық прокси-серверлерге орналастырады. Содан кейін прокси-серверлер осы конфигурацияны пайдалана бастайды және жаңартылған параметрлерді пайдаланып деректер жазықтығын өңдеуді бастайды.
3-сурет: Жетілдірілген қызмет көрсету торын басқару жазықтығы
туралы 3 сурет қызмет көрсету торының «кеңейтілген» басқару жазықтығын көрсетеді. Ол келесі бөліктерден тұрады:
- Адам: Бүкіл жүйеге қатысты жоғары деңгейдегі шешімдерді қабылдайтын адам әлі де бар (аз ашуланшақ).
- Басқару жазықтығы UI: Жүйені басқару үшін адам пайдаланушы интерфейсінің қандай да бір түрімен әрекеттеседі. Бұл веб-портал, пәрмен жолы қолданбасы (CLI) немесе басқа интерфейс болуы мүмкін. Пайдаланушы интерфейсін пайдалана отырып, оператор жаһандық жүйе конфигурациясының параметрлеріне қол жеткізе алады, мысалы:
- Орналастыруды басқару, көк/жасыл және/немесе трафиктің біртіндеп өтуі
- Аутентификация және авторизация опциялары
- Бағыттау кестесінің спецификациялары, мысалы, A қолданбасы "/foo" не болатыны туралы ақпаратты сұрағанда
- Күту, қайталау, тізбекті үзу параметрлері және т.б. сияқты жүктеме теңестіруші параметрлері.
- Жұмыс жүктемесін жоспарлаушы: Қызметтер инфрақұрылымда Kubernetes немесе Nomad сияқты жоспарлау/оркестрлеу жүйесінің кейбір түрі арқылы іске қосылады. Жоспарлаушы жергілікті проксимен бірге қызметті жүктеуге жауапты.
- Қызметті табу. Жоспарлаушы қызмет даналарын іске қосқанда және тоқтатқанда, ол денсаулық күйін қызметті табу жүйесіне хабарлайды.
- Sidecar прокси конфигурациясының API интерфейстері : Жергілікті прокси-серверлер әр түрлі жүйе құрамдастарынан күйді оператордың араласуынсыз ақырында дәйекті үлгіні пайдаланып динамикалық түрде шығарады. Ағымдағы жұмыс істеп тұрған барлық қызмет даналарынан және жергілікті прокси серверлерден тұратын бүкіл жүйе, сайып келгенде, бір экожүйеге біріктіріледі. Envoy әмбебап деректер жазықтығы API - бұл іс жүзінде қалай жұмыс істейтінінің бір мысалы.
Негізінде, басқару жазықтығының мақсаты ақыр соңында деректер жазықтығы қабылдайтын саясатты орнату болып табылады. Неғұрлым жетілдірілген басқару ұшақтары оператордан кейбір жүйелердің көбірек бөліктерін алып тастайды және олар дұрыс жұмыс істеген жағдайда қолмен жұмысты азырақ қажет етеді!...
Мәліметтер жазықтығы және басқару жазықтығы. Деректер жазықтығы мен басқару жазықтығы туралы қорытынды
- Қызметтік тор деректер жазықтығы: Жүйедегі әрбір пакетке/сұранысқа әсер етеді. Қолданбаны/қызметті анықтауға, денсаулықты тексеруге, маршруттауға, жүктемені теңестіруге, аутентификацияға/авторизацияға және бақылауға жауапты.
- Қызмет көрсету торын басқару жазықтығы: Қызмет көрсету желісіндегі барлық іске қосылған деректер жазықтықтары үшін саясат пен конфигурацияны қамтамасыз етеді. Жүйедегі пакеттерге/сұрауларға қол тигізбейді. Басқару жазықтығы барлық деректер жазықтықтарын бөлінген жүйеге айналдырады.
Ағымдағы жоба пейзажы
Жоғарыдағы түсіндірмені түсініп, сервистік тор жобасының ағымдағы жағдайын қарастырайық.
- Деректер жазықтықтары: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Басқару ұшақтары: Istio, Nelson, SmartStack
Жоғарыда келтірілген шешімдердің әрқайсысына терең талдау жасаудың орнына, мен қазір экожүйедегі көптеген шатасушылықтарды тудыратын кейбір мәселелерге қысқаша тоқталамын.
Linkerd 2016 жылдың басында сервистік торға арналған алғашқы деректер жазықтығы прокси-серверлерінің бірі болды және қызмет торының дизайны үлгісіне назар аудару мен хабардарлықты арттыру бойынша керемет жұмыс жасады. Осыдан шамамен 6 ай өткен соң, Елші Линкердке қосылды (бірақ ол 2015 жылдың соңынан бастап Lyft-те болған). Linkerd және Envoy - бұл қызмет торларын талқылау кезінде жиі айтылатын екі жоба.
Istio 2017 жылдың мамыр айында жарияланды. Istio жобасының мақсаттары көрсетілген кеңейтілген басқару жазықтығына өте ұқсас 3 сурет. Istio үшін өкіл әдепкі прокси болып табылады. Осылайша, Istio - басқару жазықтығы, ал Envoy - деректер жазықтығы. Қысқа уақыт ішінде Istio көптеген толқулар тудырды және басқа деректер ұшақтары Envoy-ді алмастыра бастады (Linkerd және NGINX екеуі де Istio-мен интеграцияны көрсетті). Бір басқару жазықтығында әртүрлі деректер жазықтықтарын қолдануға болатындығы басқару жазықтығы мен деректер жазықтығы міндетті түрде тығыз байланысты емес дегенді білдіреді. Envoy's generic data plane API сияқты API жүйенің екі бөлігі арасында көпір құра алады.
Нельсон және SmartStack басқару жазықтығы мен деректер жазықтығының бөлінуін қосымша суреттеуге көмектеседі. Нельсон Envoy-ді прокси ретінде пайдаланады және HashiCorp стекіне негізделген сервистік тор үшін сенімді басқару ұшағын құрады, яғни. Nomad және т.б. SmartStack сервистік торлардың жаңа толқынының алғашқысы болуы мүмкін. SmartStack HAProxy немесе NGINX төңірегінде басқару жазықтығын құрастырады, бұл басқару жазықтығының деректер жазықтығынан қызмет көрсету торынан ажырату мүмкіндігін көрсетеді.
Қызметтік торы бар микросервис архитектурасы барған сайын назар аударып келеді (дұрыс!), және осы бағытта көбірек жобалар мен жеткізушілер жұмыс істей бастады. Алдағы бірнеше жылда біз деректер жазықтығында да, басқару жазықтығында да көптеген жаңалықтарды, сондай-ақ әртүрлі компоненттерді одан әрі араластыруды көреміз. Сайып келгенде, микросервис архитектурасы оператор үшін мөлдір және сиқырлы (?) болуы керек.
Аз және азырақ тітіркендіреді деп үміттенеміз.
Негізгі қорытындылар
- Қызмет көрсету торы екі түрлі бөліктен тұрады: деректер жазықтығы және басқару жазықтығы. Екі компонент те қажет және оларсыз жүйе жұмыс істемейді.
- Барлығы басқару ұшағымен таныс және осы сәтте басқару ұшағы сіз болуыңыз мүмкін!
- Барлық деректер жазықтықтары мүмкіндіктер, өнімділік, конфигурациялау және кеңейту бойынша бір-бірімен бәсекелеседі.
- Барлық басқару ұшақтары бір-бірімен мүмкіндіктері, конфигурациялануы, кеңейтілуі және пайдаланудың қарапайымдылығы бойынша бәсекелеседі.
- Бір басқару жазықтығы дұрыс абстракцияларды және API интерфейстерін қамтуы мүмкін, осылайша бірнеше деректер жазықтығын пайдалануға болады.
Ақпарат көзі: www.habr.com