Ескерту. аударма: Сервис торы - бұл әлі орыс тіліне тұрақты аудармасы жоқ құбылыс (2 жылдан астам бұрын біз «қызметтерге арналған тор» опциясын ұсындық, ал сәл кейінірек кейбір әріптестер «қызметтік елеуіш» комбинациясын белсенді түрде алға тарта бастады) . Бұл технология туралы үнемі әңгімелесу маркетингтік және техникалық құрамдастардың тым тығыз байланыста болатын жағдайға әкелді. Түпнұсқа термин авторларының бірінің бұл тамаша материалы инженерлерге ғана емес, түсінікті етуге арналған.
Комикс
Кіріспе
Егер сіз серверлік жүйелер саласында жұмыс істейтін бағдарламалық жасақтама инженері болсаңыз, соңғы екі жылда «қызмет көрсету торы» термині сіздің санаңызда берік орын алған болуы мүмкін. Біртүрлі сәйкестіктің арқасында бұл сөз тіркесі саланы көбірек жаулап алуда, ал хайп пен соған қатысты жарнамалық ұсыныстар қар кесегі сияқты өсіп, төбеден төмен қарай ұшып, баяулау белгілерін көрсетпейді.
Қызмет көрсету торы бұлттың табиғи экожүйесінің бұлыңғыр, бұралған суларында дүниеге келген. Өкінішке орай, бұл оның айналасындағы дау-дамайлардың көпшілігі «төмен калориялы әңгімеден» бастап, техникалық терминді қолданатын болсақ, ашық ақымақтыққа дейін екенін білдіреді. Бірақ егер сіз барлық шуды сүзгіден өткізсеңіз, қызмет көрсету торының өте нақты, нақты және маңызды функциясы бар екенін таба аласыз.
Бұл постта мен мұны істеуге тырысамын: қызмет көрсету торына адал, терең, инженерге бағытталған нұсқаулық беріңіз. Мен жай ғана сұраққа жауап бермеймін: «Бұл не?», - бірақ және «Неге?», және де «Неге қазір?». Соңында, мен (менің ойымша) осы технологияның неліктен осындай ақылсыз дүрбелең тудырғанын сипаттауға тырысамын, бұл өзінше қызықты оқиға.
Мен кіммін?
Бәріңе сәлем! Менің атым . Мен жасаушылардың бірімін - ең бірінші сервистік тор жобасы және терминнің пайда болуына кінәлі жоба қызмет көрсету торы сияқты (кешіріңіз, жігіттер!). (Ескерту аударма.: Айтпақшы, бұл термин пайда болған кезде, 2,5 жылдан астам уақыт бұрын біз сол автордың ««.) Мен де басамын Linkerd және сияқты тамаша сервистік торларды құрастыратын стартап болып табылады .
Менің бұл мәселе бойынша өте біржақты және субъективті пікірім бар деп болжайтын шығарсыз. Дегенмен, мен біржақтылықты барынша азайтуға тырысамын (бір бөлімді қоспағанда: «Неліктен қызмет көрсету торы туралы көп әңгіме бар?», - онда мен өзімнің алдын ала ойластырылған идеяларыммен бөлісемін). Мен де осы нұсқаулықты мүмкіндігінше объективті ету үшін бар күшімді саламын. Нақты мысалдарда мен негізінен Linkerd тәжірибесіне сүйенемін, сонымен бірге қызмет көрсету торының басқа түрлерін жүзеге асыруда білетін айырмашылықтарды (бар болса) атап өтемін.
Жарайды, тәттілерге көшетін кез келді.
Қызмет көрсету торы дегеніміз не?
Барлық дүрбелеңге қарамастан, қызмет көрсету торы құрылымдық жағынан өте қарапайым. Бұл қызметтердің «жанында» орналасқан пайдаланушы кеңістігінің прокси-серверлерінің шоғыры ғана (біз «жақын» туралы кейінірек айтатын боламыз), сонымен қатар басқару процестерінің жиынтығы. Сенім білдірілген тұлғалар бірге шақырылады деректер жазықтығы, және басқару процестері деп аталады басқару жазықтығы. Деректер жазықтығы қызметтер арасындағы қоңырауларды ұстайды және олармен «басқа нәрсе» жасайды; басқару жазықтығы сәйкесінше прокси әрекетін үйлестіреді және сізге қол жеткізуді қамтамасыз етеді, яғни. оператор, API үшін желіні басқаруға және тұтастай өлшеуге мүмкіндік береді.
Бұл прокси дегеніміз не? Бұл «7-қабатты білетін» санатындағы TCP проксиі (яғни, OSI үлгісінің 7-ші қабатын «ескере отырып») HAProxy және NGINX сияқты. Сіз өз қалауыңыз бойынша прокси таңдай аласыз; Linkerd аты күрделі емес Rust проксиін пайдаланады . Біз оны қызмет көрсету торы үшін арнайы құрастырдық. Басқа торлар басқа проксилерді жақсы көреді (Елші - жалпы таңдау). Дегенмен, проксиді таңдау тек іске асыру мәселесі болып табылады.
Бұл прокси серверлер не істейді? Әлбетте, олар қызметтерге және одан шығатын қоңырауларды прокси арқылы жібереді (қатаң айтқанда, олар кіріс және шығыс қоңырауларды өңдейтін прокси және кері прокси ретінде әрекет етеді). Және олар қоңырауларға назар аударатын мүмкіндіктер жинағын жүзеге асырады арасында қызметтер. Қызметтер арасындағы трафикке бұл фокус қызмет торының проксиін, айталық, API шлюздерінен немесе кіру проксилерінен (соңғысы сыртқы әлемнен кластерге келетін қоңырауларға назар аударады) ерекшелендіреді. (Ескерту. аударма: Көпшілігі жоғарыда аталған Envoy қолданбасын пайдаланатын Kubernetes Ingress контроллерлерін салыстыру үшін қараңыз. .)
Сонымен, біз деректер жазықтығын анықтадық. Басқару жазықтығы қарапайымырақ: бұл деректер жазықтығы үйлесімді түрде жұмыс істеуге қажетті барлық механиканы қамтамасыз ететін құрамдастардың жиынтығы, соның ішінде қызметтерді табу, TLS сертификатын шығару, метрикаларды біріктіру, т.б.. Деректер жазықтығы басқару жазықтығы туралы ақпарат береді. оның мінез-құлқы; өз кезегінде басқару жазықтығы жалпы деректер жазықтығының әрекетін өзгертуге және бақылауға мүмкіндік беретін API ұсынады.
Төменде Linkerd-те басқару жазықтығы мен деректер жазықтығының диаграммасы берілген. Көріп отырғаныңыздай, басқару жазықтығы бірнеше түрлі құрамдастарды, соның ішінде прокси-серверлерден көрсеткіштерді жинайтын Prometheus данасын, сондай-ақ басқа компоненттерді қамтиды. destination (қызмет ашу), identity (сертификаттау орталығы, CA) және public-api (веб және CLI үшін соңғы нүктелер). Керісінше, деректер жазықтығы қолданба данасы жанындағы қарапайым linkerd-прокси болып табылады. Бұл жай ғана логикалық диаграмма; нақты әлемде орналастыруда сізде әрбір басқару жазықтығы құрамдас бөлігінің үш көшірмесі және деректер жазықтығында жүздеген немесе мыңдаған проксилер болуы мүмкін.
(Осы диаграммадағы көк жәшіктер Kubernetes қосқыштарының шекараларын көрсетеді. Linkerd-прокси бар контейнерлер қолданба контейнерлерімен бір бөлімшеде екенін көруге болады. Бұл схема ретінде белгілі бүйірлік контейнер.)
Қызмет торының архитектурасы бірнеше маңызды салдарға ие. Біріншіден, прокси қызметі қызметтер арасындағы қоңырауларды тоқтату болғандықтан, қолданбаңыз қызметтер жиынтығы үшін жасалған болса ғана қызмет торы мағынасы бар. тор болады монолиттермен бірге пайдалану, бірақ бұл бір прокси үшін артық екені анық және оның функционалдығы сұранысқа ие болуы екіталай.
Тағы бір маңызды нәтиже - қызмет көрсету торы қажет зор прокси-серверлер саны. Шын мәнінде, Linkerd әрбір қызмет данасына linkerd-проксиді тізбектейді (басқа енгізулер әрбір хост/хост/VM үшін прокси қосады. Бұл бәрібір көп). Проксиді мұндай белсенді пайдаланудың өзі бірқатар қосымша қиындықтарды тудырады:
- Деректер жазықтығында прокси болуы керек жылдам, себебі әрбір қоңырау үшін проксиге бірнеше қоңыраулар болады: біреуі клиент жағында, біреуі сервер жағында.
- Сондай-ақ, прокси болуы керек кішкентай и жеңіл. Әрқайсысы жад пен процессор ресурстарын тұтынады және бұл тұтыну қолданбамен сызықты түрде өседі.
- Сізге көптеген прокси-серверлерді орналастыру және жаңарту механизмі қажет болады. Оны қолмен жасау опция емес.
Тұтастай алғанда, қызмет көрсету торы келесідей көрінеді (кем дегенде құс көзімен): сіз ішкі, қызмет аралық трафикпен «бірдеңе жасайтын» пайдаланушы кеңістігінің прокси-серверлерінің шоғырын орналастырасыз және оларды бақылау және басқару үшін басқару жазықтығын пайдаланасыз.
«Неге?» деген сұрақтың уақыты келді.
Қызмет көрсету торы не үшін қажет?
Қызметтік тор идеясын алғаш рет кездестіргендер үшін аздап үрейлену кешіріледі. Қызмет торының дизайны қолданбаның кідірісін арттырып қана қоймайды, сонымен қатар оны арттырады тұтыну ресурстар және қосады инфрақұрылымдағы жаңа механизмдердің жиынтығы. Алдымен сіз қызмет көрсету торын орнатасыз, содан кейін кенеттен жүздеген (мыңдаған болмаса) проксиге қызмет көрсету қажет болады. Бұл үшін кім ерікті болады деген сұрақ туындайды.
Бұл сұрақтың жауабы екі бөліктен тұрады. Біріншіден, осы прокси-серверлерді орналастыруға байланысты транзакциялық шығындар экожүйеде болып жатқан кейбір өзгерістерге байланысты айтарлықтай қысқартылуы мүмкін (бұл туралы кейінірек).
Екіншіден, мұндай құрылғы жүйеге қосымша логиканы енгізудің тамаша тәсілі болып табылады. Көптеген жаңа мүмкіндіктерді сервистік тор арқылы қосуға болатындықтан ғана емес, сонымен қатар оны экожүйеге кедергі келтірмей жасауға болады. Шын мәнінде, бүкіл сервистік тор үлгісі осы постулатқа негізделген: мультисервистік жүйеде, не болса да жасау жеке қызметтер, трафик олардың арасында функционалдылықты қосу үшін тамаша нүкте болып табылады.
Мысалы, Linkerd бағдарламасында (көптеген торлардағы сияқты) функционалдылық негізінен HTTP қоңырауларына, соның ішінде HTTP/2 және gRPC* бағытталған. Функционалдық өте бай - оны үш сыныпқа бөлуге болады:
- Қатысты мүмкіндіктер сенімділік. Қайталау сұраулары, күту уақыттары, канарлық тәсіл (трафикті бөлу/қайта бағыттау) т.б.
- Қатысты мүмкіндіктер мониторинг. Әрбір қызмет немесе жеке бағыттар бойынша табыстылық көрсеткіштерін, кешігулер мен сұраныс көлемін біріктіру; қызметтердің топологиялық карталарын құру және т.б.
- Қатысты мүмкіндіктер қауіпсіздік. Өзара TLS, қол жеткізуді басқару және т.б.
* Linkerd көзқарасы бойынша, gRPC іс жүзінде HTTP/2-ден еш айырмашылығы жоқ: ол пайдалы жүктемеде протобуфты ғана пайдаланады. Әзірлеушінің көзқарасы бойынша, бұл екі нәрсе, әрине, әртүрлі.
Бұл механизмдердің көпшілігі сұрау деңгейінде жұмыс істейді (демек, «L7 прокси»). Мысалы, Foo қызметі қызмет жолына HTTP қоңырауын жасаса, Foo жағындағы linkerd-прокси бақыланатын кідіріс негізінде Foo-дан Bar даналарына қоңырауларды ақылды түрде жүктей алады және бағыттай алады; ол қажет болған жағдайда сұрауды қайталай алады (және ол идемпотентті болса); ол жауап кодын және күту уақытын жаза алады және т.б. Сол сияқты, жолақ жағындағы linkerd-прокси сұрауға рұқсат берілмесе немесе сұрау шегінен асып кетсе, оны қабылдамауы мүмкін; өз бөлігіндегі кідірісті түзете алады және т.б.
Проксилер қосылым деңгейінде де «бірдеңе істей» алады. Мысалы, Foo жағындағы linkerd-прокси TLS қосылымын қоса алады, ал жолақ жағындағы linkerd-прокси оны тоқтата алады және екі тарап бір-бірінің TLS сертификаттарын тексере алады*. Бұл қызметтер арасында шифрлауды ғана емес, сонымен қатар қызметтерді анықтаудың криптографиялық қауіпсіз әдісін қамтамасыз етеді: Foo және Bar өздерінің кім екенін «дәлелдей алады».
* «Достың досы» клиент сертификатының да расталғанын білдіреді (өзара TLS). «Классикалық» TLS-де, мысалы, браузер мен сервер арасында, әдетте тек бір тараптың (сервердің) сертификаты тексеріледі.
Олар сұрау деңгейінде жұмыс істей ме, әлде қосылым деңгейінде жұмыс істей ме, барлық қызмет көрсету торының мүмкіндіктері бар екенін атап өткен жөн операциялық кейіпкер. Linkerd JSON фрагментіне өрістерді қосу немесе протобуфқа өзгертулер енгізу сияқты пайдалы жүктеменің семантикасын түрлендіре алмайды. Бұл маңызды мүмкіндік туралы кейінірек ESB және аралық бағдарламалық құрал туралы сөйлесетін боламыз.
Бұл қызмет торы ұсынатын мүмкіндіктер жиынтығы. Сұрақ туындайды: неге оларды тікелей қолданбада жүзеге асырмасқа? Неліктен проксимен араласу керек?
Неліктен қызмет көрсету торы жақсы идея
Қызметтік тордың мүмкіндіктері таң қалдырғанымен, оның басты құндылығы мүмкіндіктерде емес. Соңында біз Болады оларды тікелей қолданбада іске асырыңыз (кейінірек бұл қызмет торының шығу тегі болғанын көреміз). Оны бір сөйлеммен айтсақ, қызмет торының мәні: ол заманауи серверлік бағдарламалық жасақтаманы дәйекті, стекке, қолданбалы кодты-агностикалық жолмен іске қосу үшін маңызды функционалдылықты қамтамасыз етеді..
Осы ұсынысты талдап көрейік.
«Қазіргі заманғы серверлік бағдарламалық құралды іске қосу үшін маңызды функциялар«. Егер сіз сыртқы әлемнен сұрауларды қабылдайтын және оларға қысқа уақыт ішінде жауап беретін жалпыға қолжетімді интернетке қосылған транзакциялық сервер қолданбасын жасап жатсаңыз - мысалы, веб-бағдарлама, API сервері және басқа заманауи қолданбалардың басым көпшілігі - және егер сіз оны бір-бірімен синхронды өзара әрекеттесетін қызметтер жиынтығы ретінде іске асырсаңыз және осы бағдарламалық жасақтаманы үнемі жаңартып, жаңа мүмкіндіктер қосып отырсаңыз және модификациялау процесінде осы жүйені жұмыс жағдайында ұстауға мәжбүр болсаңыз - бұл жағдайда, Құттықтаймыз, сіз заманауи серверлік бағдарламалық құрал жасап жатырсыз. Жоғарыда аталған керемет мүмкіндіктердің барлығы сіз үшін өте маңызды болып шығады. Қолданба сенімді, қауіпсіз болуы керек және сіз оның не істеп жатқанын көре алуыңыз керек. Дәл осы сұрақтарды сервистік тор шешуге көмектеседі.
(Жарайды, бұл тәсіл серверлік бағдарламалық жасақтаманы құрудың заманауи тәсілі деген сенімім алдыңғы абзацқа еніп кетті. Басқалары монолиттерді, «реактивті микросервистерді» және жоғарыда келтірілген анықтамаға жатпайтын басқа нәрселерді жасауды жөн көреді. Бұл адамдарда болуы мүмкін. менің пікірімнен ерекшеленетін пікір, және өз кезегінде, мен оларды «дұрыс емес» деп санаймын - кез келген жағдайда, қызмет көрсету торы олар үшін өте пайдалы емес).
«Бүкіл стекке біркелкі«. Қызмет көрсету торымен қамтамасыз етілген мүмкіндіктер тек маңызды емес. Олар қай тілде жазылғанына, қандай құрылымды пайдаланатынына, оларды кім жазғанына, қалай орналастырылғанына және оларды әзірлеу мен пайдаланудың барлық басқа нәзіктіктеріне қарамастан, қолданбадағы барлық қызметтерге қолданылады.
«Қолданба коды тәуелсіз" Соңында, қызмет торы бүкіл стек бойынша дәйекті функционалдылықты қамтамасыз етіп қана қоймайды, ол мұны қолданбаны өңдеуді қажет етпейтіндей жасайды. Конфигурациялау, жаңарту, пайдалану, техникалық қызмет көрсету және т.б. тапсырмаларды қоса, қызмет торының функционалдық негізі толығымен платформа деңгейінде болады және қолданбадан тәуелсіз. Қолданба қызмет көрсету торына әсер етпей өзгерте алады. Өз кезегінде, сервистік тор қолданбаның қатысуынсыз өзгеруі мүмкін.
Қысқаша айтқанда, қызмет торы өмірлік маңызды функционалдылықты қамтамасыз етіп қана қоймайды, бірақ ол мұны ғаламдық, біркелкі және қолданбадан тәуелсіз түрде жасайды. Сонымен, сервистік тордың функционалдығы сервистік кодта жүзеге асырылуы мүмкін болса да (мысалы, әрбір қызметке кіретін кітапхана ретінде), бұл тәсіл қызмет көрсету торы жағдайында соншалықты құнды болып табылатын біркелкі және тәуелсіздікті қамтамасыз етпейді. .
Сізге тек прокси-серверлерді қосу жеткілікті! Бұл проксилерді қосуға байланысты операциялық шығындарды жақын арада қарастырамыз деп уәде беремін. Бірақ алдымен осы тәуелсіздік идеясына әр түрлі көзқараспен тоқталып, қарастырайық. адамдар.
Қызмет көрсету торы кімге көмектеседі?
Қанша қолайсыз болса да, технология экожүйенің маңызды бөлігіне айналуы үшін оны адамдар қабылдауы керек. Сонымен, қызмет көрсету торына кім қызығушылық танытады? Оны пайдалану кімге тиімді?
Егер сіз заманауи серверлік бағдарламалық жасақтаманы жасасаңыз, сіз өз командаңызды топ ретінде елестете аласыз қызмет иелерібизнес логикасын бірге дамытып, жүзеге асыратындар және платформа иелеріосы қызметтер жұмыс істейтін ішкі платформаны әзірлеуге қатысады. Кішігірім ұйымдарда бұл бірдей адамдар болуы мүмкін, бірақ компания өскен сайын бұл рөлдер айқынырақ болады және тіпті қосалқы рөлдерге бөлінеді ... (Бұл жерде devops табиғатының өзгеретіні туралы көп нәрсе айтуға болады, микросервистердің ұйымдастырушылық әсері және т.
Осы тұрғыдан алғанда, сервистік тордың айқын бенефициарлары платформаның иелері болып табылады. Ақыр соңында, платформа командасының түпкілікті мақсаты - қызмет иелері бизнес логикасын жүзеге асыра алатын және оны оның жұмысының күрделі бөлшектерінен олардың максималды тәуелсіздігіне кепілдік беретін етіп жасай алатын ішкі платформа құру. Қызмет көрсету торы осы мақсатқа жету үшін маңызды мүмкіндіктерді ұсынып қана қоймайды, ол мұны өз кезегінде қызмет иелеріне ешқандай тәуелділік тудырмайтындай етіп жасайды.
Қызмет иелері де жанама түрде болса да пайда көреді. Қызмет иесінің мақсаты - бизнес-процестің логикасын жүзеге асыруда барынша өнімді болу және ол операциялық мәселелер туралы неғұрлым аз алаңдаса, соғұрлым жақсы. Саясаттарды немесе TLS қайталауды орындаудың орнына, олар тек бизнеске назар аудара алады және платформа қалғандарын шешеді деп үміттенеді. Олар үшін бұл үлкен артықшылық.
Платформалар мен қызметтер иелері арасындағы мұндай бөлудің ұйымдық құндылығын асыра бағалау мүмкін емес. Ол өз үлесін қосады деп ойлаймын негізгі қызмет көрсету торының құнына қосқан үлесі.
Біз бұл сабақты ерте Linkerd жанкүйері неліктен сервистік торды таңдағанын айтқан кезде білдік: бұл оларға «минималды түрде сөйлесуге» мүмкіндік берді. Міне, кейбір мәліметтер: бір үлкен компанияның жігіттері платформаларын Кубернетеске көшірді. Қолданба құпия ақпаратпен жұмыс істегендіктен, олар кластерлердегі барлық коммуникацияларды шифрлағысы келді. Дегенмен, жағдай жүздеген сервистер мен жүздеген әзірлеуші топтардың болуымен қиындады. Барлығымен байланысу және олардың жоспарларына TLS қолдауын қосуға сендіру перспективасы оларды мүлдем ұнатпады. Linkerd орнату арқылы олар көшті жауапкершілік әзірлеушілерден (олардың көзқарасы бойынша бұл қажетсіз қиындық тудырған) платформашыларға дейін, олар үшін бұл жоғары деңгейдегі басымдық болды. Басқаша айтқанда, Линкерд олар үшін ұйымдастырушылық емес, техникалық мәселені шешті.
Бір сөзбен айтқанда, сервистік тор - бұл техникалық шешім емес, бірақ әлеуметтік-техникалық Мәселелер. (Рақмет сізге осы терминді енгізгені үшін.
Қызмет көрсету торы менің барлық мәселелерімді шеше ме?
Иә. Айтайын дегенім, жоқ!
Жоғарыда сипатталған мүмкіндіктердің үш класына қарасақ - сенімділік, қауіпсіздік және бақыланатындық - қызмет көрсету торы осы мәселелердің ешқайсысына толық шешім емес екені анық болады. Linkerd қайталанатын сұрауларды жібере алатын болса да (егер ол олардың идемпотентті екенін білсе), егер қызмет ақыры тоқтап қалса, пайдаланушыға не қайтару керектігі туралы шешім қабылдай алмайды - мұндай шешімдерді қолданба қабылдауы керек. Linkerd сәтті сұраулар бойынша статистиканы сақтай алады, бірақ ол қызметті қарап, оның ішкі көрсеткіштерін қамтамасыз ете алмайды - қолданбада мұндай құралдар жинағы болуы керек. Linkerd mTLS орналастыру мүмкіндігіне ие болғанымен, толыққанды қауіпсіздік шешімдері көп нәрсені қажет етеді.
Қызмет торы ұсынатын осы аймақтардағы мүмкіндіктердің жиыны қатысты платформа мүмкіндіктері. Бұл арқылы мен мына функцияларды айтамын:
- Іскерлік логикаға тәуелсіз. Шақыру гистограммалары Foo және Bar арасында жасалу тәсілі, бұл немесе жоқтығына толығымен тәуелсіз неге Фу Барға қоңырау шалады.
- Дұрыс іске асыру қиын. Linkerd бағдарламасында қайталаулар қайталау бюджеттері сияқты сәнді заттардың барлық түрлерімен параметрленген. (бюджеттерді қайталап көріңіз), өйткені мұндай нәрселерді жүзеге асыруға қарапайым көзқарас «өтініштердің көшкіні» деп аталатындардың пайда болуына әкеледі. (қайтадан дауыл) және бөлінген жүйелерге тән басқа мәселелер.
- Тұрақты қолданғанда ең тиімді. TLS механизмі барлық жерде қолданылған жағдайда ғана мағынасы бар.
Бұл мүмкіндіктер прокси-деңгейде (қолданбалы деңгейде емес) жүзеге асырылатындықтан, қызмет торы оларды келесі жерде көрсетеді. платформалар, қолданбалар емес. Осылайша, қызметтер қай тілде жазылғаны, олар қандай шеңберді қолданатыны, оларды кім және не үшін жазғаны маңызды емес. Прокси-серверлер осы мәліметтердің барлығынан тыс жұмыс істейді және конфигурациялау, жаңарту, пайдалану, қолдау және т.б. тапсырмаларын қоса, бұл функционалдылықтың негізгі негізі тек платформа деңгейінде жатыр.
Қызметтік тор мүмкіндіктерінің мысалдары
Қорытындылай келе, қызмет көрсету торы сенімділік, бақылау мүмкіндігі немесе қауіпсіздік үшін толық шешім емес. Бұл аймақтардың ауқымы қызмет иелерінің, Ops/SRE командаларының және компанияның басқа да мүдделі тараптарының міндетті қатысуын білдіреді. Қызмет көрсету торы осы аймақтардың әрқайсысы үшін платформа деңгейінде тек «тілімді» қамтамасыз етеді.
Неліктен сервистік тор дәл қазір танымал болды?
Сізді дәл қазір қызықтыратын шығарсыз: Жарайды, егер қызмет көрсету торы соншалықты жақсы болса, неліктен біз миллиондаған проксилерді он жыл бұрын стекке орналастыруды бастамадық?
Бұл сұраққа банальды жауап бар: он жыл бұрын бәрі монолиттер салған және ешкімге қызмет көрсету торы қажет емес. Бұл дұрыс, бірақ менің ойымша, бұл жауап маңызды емес. Тіпті он жыл бұрын ауқымды жүйелерді құрудың перспективалық тәсілі ретінде микросервис концепциясы Twitter, Facebook, Google және Netflix сияқты компанияларда кеңінен талқыланып, қолданылды. Жалпы түсінік - кем дегенде мен байланысқан сала бөліктерінде - бұл микросервистер үлкен жүйелерді құрудың «дұрыс жолы», тіпті қиын болса да.
Әрине, он жыл бұрын микросервистерді пайдаланатын компаниялар болғанымен, олар сервистік тор құру үшін прокси-серверлерді барлық жерде жабыстырмады. Дегенмен, мұқият қарасаңыз, олар ұқсас нәрсені жасады: бұл компаниялардың көпшілігі желіге қосылу үшін арнайы ішкі кітапхананы пайдалануды міндеттеді (кейде майлы клиенттер кітапханасы деп аталады, майлы клиенттердің кітапханасы).
Netflix-те Hysterix, Google-де Stubby, Twitter-де Finagle кітапханасы болды. Мысалы, Finagle Twitter-дегі әрбір жаңа қызмет үшін міндетті болды. Ол қосылымдардың клиентті де, серверлік жағын да өңдеді, қайталанатын сұрауларға, қолдау көрсетілетін сұранысты бағыттауға, жүктемені теңестіруге және өлшеуге рұқсат берді. Бұл қызмет не істеп жатқанына қарамастан, бүкіл Twitter стекінде сенімділік пен бақылаудың тұрақты деңгейін қамтамасыз етті. Әрине, ол тек JVM тілдері үшін жұмыс істеді және бүкіл қолданба үшін қолданылуы керек бағдарламалау үлгісіне негізделген. Дегенмен, оның функционалдығы қызмет көрсету торымен дерлік бірдей болды. (Шын мәнінде, Linkerd-тің бірінші нұсқасы прокси пішінге оралған Finagle болды.)
Осылайша, он жыл бұрын тек микросервистер ғана емес, сонымен қатар сервистік тор бүгінгі таңда шешетін мәселелерді шешетін арнайы прото-сервис-торлы кітапханалар болды. Алайда, ол кезде сервистік тордың өзі болған жоқ. Ол пайда болғанға дейін тағы бір ауысым болуы керек еді.
Соңғы 10 жылда орын алған тағы бір өзгерісте жасырылған тереңірек жауап осында жатыр: микросервистерді енгізу құнының күрт төмендеуі байқалды. Он жыл бұрын микросервистерді пайдаланған жоғарыда аталған компаниялар - Twitter, Netflix, Facebook, Google - ауқымды және орасан ресурстары бар компаниялар. Оларда қажеттілік қана емес, сонымен қатар микросервистерге негізделген үлкен қосымшаларды құру, орналастыру және басқару мүмкіндігі болды. Твиттер инженерлерінің монолитті әдістен микросервистерге көшуге жұмсаған күші мен күші таңқаларлық. (Шынымды айтсам, ол жұмыс істеді.) Инфрақұрылымдық маневрдің мұндай түрі ол кезде кішігірім компаниялар үшін мүмкін емес еді.
Қазіргі уақытқа көшейік. Бүгінгі таңда микросервистердің әзірлеушілерге қатынасы 5:1 болатын стартаптар бар (немесе тіпті ), сонымен қатар олар олармен сәтті күреседі! Егер 5 адамнан тұратын стартап 50 микросервисті жүктемесіз басқара алатын болса, онда бір нәрсе оларды жүзеге асыру құнын төмендетті.
Монцодағы 1500 микросервис; әрбір жол трафикке рұқсат беретін белгіленген желі ережесі болып табылады
Операциялық микросервистердің құнының күрт төмендеуі бір процестің нәтижесі болып табылады: контейнерлердің танымалдылығы и оркестрлер. Бұл сервистік тордың пайда болуына не ықпал етті деген сұраққа нақты жауап. Бірдей технология қызмет торын да, микросервистерді де тартымды етті: Kubernetes және Docker.
Неліктен? Ал, Docker бір үлкен мәселені шешеді - қаптама мәселесі. Қолданбаны және оның (желіден тыс) орындалу уақытының тәуелділіктерін контейнерге буып-түю арқылы Docker қолданбаны кез келген жерде орналастыруға және іске қосуға болатын жұмыс істейтін бірлікке айналдырады. Сонымен қатар, ол жұмысты айтарлықтай жеңілдетеді. көптілді Стек: Контейнер орналастыру және операциялық мақсаттар үшін атомдық орындау бірлігі болғандықтан, JVM, Node, Go, Python немесе Ruby қолданбасы болсын, ішінде не бар екені маңызды емес. Сіз оны жай ғана іске қосасыз және бәрі де солай.
Кубернетес бәрін келесі деңгейге көтереді. Енді көптеген «орындалатын нәрселер» және оларды іске қосу үшін көптеген машиналар бар болғандықтан, оларды бір-біріне сәйкестендіретін құрал қажет. Кең мағынада сіз Kubernetes-ке көптеген контейнерлер мен көптеген машиналарды бересіз және ол оларды бір-бірімен сәйкестендіреді (әрине, бұл динамикалық және үнемі өзгеретін процесс: жаңа контейнерлер жүйеде қозғалады, машиналар іске қосылады және тоқтайды, т.б.. Дегенмен, Кубернетес мұның бәрін ескереді).
Kubernetes орнатылғаннан кейін, бір қызметті орналастыруға және пайдалануға кететін уақыт он қызметті орналастыру және пайдалану құнынан айтарлықтай ерекшеленбейді (шын мәнінде, бұл 100 қызмет үшін бірдей). Бұл контейнерлерге көптілді енгізуді ынталандыратын орау механизмі ретінде қосыңыз және сізде бірнеше тілде жазылған микросервистер ретінде енгізілген көптеген жаңа қолданбалар бар, дәл осы қызмет торы өте қолайлы орта түрі.
Сонымен, біз неліктен сервистік тор идеясы дәл қазір танымал болды деген сұраққа жауап береміз: Kubernetes қызметтерге ұсынатын біркелкі қызмет торының алдында тұрған операциялық міндеттерге тікелей қатысты. Сіз прокси-серверлерді контейнерлерге жинайсыз, Кубернеттерге мүмкіндігінше оларды жабыстыру тапсырмасын бересіз және вуила! Нәтижесінде сіз қызмет торын аласыз, ал Kubernetes оны орналастырудың барлық механикасын басқарады. (Кем дегенде, құстың көзімен. Әрине, бұл процестің көптеген нюанстары бар.)
Қорытындылай келе: сервистік тордың он жыл бұрын емес, қазір танымал болуының себебі - Кубернетес пен Докер айтарлықтай өсті. қажет онда көптілді микросервистердің жиынтықтары ретінде қосымшаларды енгізуді жеңілдету, сонымен қатар айтарлықтай қысқарту. шығындар қосалқы парктерді орналастыру және қолдау тетіктерін қамтамасыз ету арқылы оның жұмыс істеуі үшін.
Неліктен қызмет көрсету торы туралы көп айтылады?
Алдын алу: Бұл бөлімде мен барлық болжамдарды, жорамалдар, ойдан шығару және ішкі ақпаратты пайдаланамын.
«Қызмет көрсету торын» іздеңіз және сіз қайта өңделген төмен калориялы мазмұнды, оғаш жобаларды және жаңғырық камерасына лайық бұрмалану калейдоскопын кездестіресіз. Кез келген сәнді жаңа технология мұны жасайды, бірақ қызмет көрсету торы жағдайында мәселе әсіресе өткір. Неліктен?
Бұл ішінара менің кінәм. Мен көптеген блог жазбалары мен осы сияқты мақалалар арқылы әр мүмкіндікте Linkerd және сервистік торды жылжыту үшін бар күшімді салдым. Бірақ мен онша күшті емеспін. Бұл сұраққа нақты жауап беру үшін жалпы жағдай туралы аздап айту керек. Бұл туралы бір жобаны айтпай-ақ айту мүмкін емес: Google, IBM және Lyft бірлесіп әзірлеген ашық бастапқы қызметтік тор.
(Бұл үш компанияның рөлдері мүлдем басқа: Lyft-тің қатысуы тек атымен ғана шектелген сияқты; олар Envoy авторы, бірақ Istio-ны қолданбайды немесе әзірлеуге қатысады. IBM Istio әзірлеуге қатысады және оны пайдаланады. Google қатты Istio әзірлеуге қатысты, бірақ менің білуімше, оны қолданбайды.)
Istio жобасы екі нәрсемен ерекшеленеді. Біріншіден, бұл Google, атап айтқанда, оны жылжытуға жұмсайтын үлкен маркетингтік күш. Менің ойымша, қазіргі уақытта сервистік тор тұжырымдамасы туралы білетін адамдардың көпшілігі бұл туралы бірінші рет Istio арқасында білді. Екінші ерекшелігі - Истионы қаншалықты нашар қабылдады. Бұл мәселеде мен, әрине, мүдделі тараппын, бірақ мүмкіндігінше объективті болуға тырысамын, мен әлі де көмектесе алмаймын. , өте нақты емес (бірегей болмаса да: systemd есіме түседі, ...) ашық бастапқы жоба үшін.
(Тәжірибеде Istio-да күрделілік пен UX ғана емес, сонымен қатар өнімділікте де проблемалар бар сияқты. Мысалы, кезінде үшінші тарап жүргізген сарапшылар Истионың кешігуі Linkerd-ке қарағанда 100 есе жоғары болатын жағдайларды, сондай-ақ ресурстардың жетіспеушілік жағдайларын, Линкерд сәтті жұмысын жалғастырып, Истио жұмысын толығымен тоқтатты.)
Неліктен бұл орын алғаны туралы теорияларымды былай қойғанда, мен сервистік тордың айналасындағы ауқымды емес шу Google-дың қатысуына байланысты деп ойлаймын. Атап айтқанда, келесі үш фактордың комбинациясы:
- Google арқылы Isio-ны обсессивті жылжыту;
- жобаға сәйкес келмейтін, сыни көзқарас;
- Кубернетестің танымалдылығының жақында метеорлық өсуі, оның естеліктері әлі де жаңа.
Бұл факторлар бірігіп, ұтымды пайымдау қабілеті әлсіреген, біртүрлі масаңдық, аноксиктік ортаға бірігеді. .
Линкердтің көзқарасы бойынша, бұл... Мен оны аралас бата ретінде сипаттар едім. Айтайын дегенім, сервистік тордың негізгі ағымға енгені өте жақсы - бұл Linkerd алғаш рет пайда болған 2016 жылы болған жоқ және жобаға адамдардың назарын аудару шынымен қиын болды. Енді мұндай проблема жоқ! Бірақ жаман жаңалық мынада: сервистік тордың жағдайы бүгінде шатастырылып тұрғаны сонша, қай жобалар шынымен сервистік тор санатына жататынын анықтау мүмкін емес (нақты бір пайдалану жағдайына қайсысы жақсы екенін анықтауды былай қойғанда). Бұл, әрине, барлығына кедергі келтіреді (және кейбір жағдайларда Istio немесе басқа жоба Linkerd-тен жақсырақ, өйткені соңғысы бір өлшемді шешім емес).
Линкерд тарапынан біздің стратегиямыз шуды елемеу, қоғамдағы нақты мәселелерді шешуге назар аудару және негізінен хайптың сөнуін күту болды. Ақырында хайп басылып, біз тыныштықта жұмыс істей аламыз.
Оған дейін бәріміз шыдамды болуымыз керек.
Қызмет торы мен үшін пайдалы бола ма, қарапайым бағдарламалық жасақтама инженері?
Келесі сауалнама осы сұраққа жауап беруге көмектеседі:
Сіз тек бизнес логикасын жүзеге асырумен айналысасыз ба? Бұл жағдайда қызмет көрсету торы сізге пайдалы болмайды. Бұл, әрине, сізді қызықтыруы мүмкін, бірақ дұрысы, қызмет көрсету торы сіздің ортаңыздағы ештеңеге тікелей әсер етпеуі керек. Не үшін төлейтініңізбен жұмыс істей беріңіз.
Сіз Kubernetes пайдаланатын компанияда платформаны сақтайсыз ба? Иә, бұл жағдайда сізге қызмет көрсету торы қажет (әрине, егер сіз K8-ді тек монолитті немесе пакеттік өңдеуді іске қосу үшін пайдаланбасаңыз - бірақ мен сізге K8 не үшін қажет екенін сұрағым келеді). Сірә, сіз әртүрлі адамдар жазған көптеген микросервистермен жағдайға тап боласыз. Олардың барлығы бір-бірімен өзара әрекеттеседі және орындалу уақытына тәуелділіктердің шиеленісіне байланады және сіз мұның бәрін шешудің жолын табуыңыз керек. Kubernetes-ті пайдалану «өзің үшін» қызмет көрсету торын таңдауға мүмкіндік береді. Мұны істеу үшін олардың мүмкіндіктерімен және мүмкіндіктерімен танысыңыз және қол жетімді жобалардың кез келгені сізге сәйкес келеді ме деген сұраққа жауап беріңіз (зерттеуіңізді Linkerd-тен бастауды ұсынамын).
Сіз Kubernetes қолданбайтын, бірақ микросервистерді пайдаланатын компания үшін платформаны іске қосып жатырсыз ба? Бұл жағдайда қызмет көрсету торы сізге пайдалы болады, бірақ оны пайдалану тривиальды емес болады. Әрине аласыз еліктеу көптеген прокси-серверлерді орналастыру арқылы сервистік тор, бірақ Kubernetes-тің маңызды артықшылығы дәл орналастыру үлгісі болып табылады: бұл прокси-серверлерді қолмен ұстау әлдеқайда көп уақытты, күш пен шығынды талап етеді.
Сіз монолиттермен жұмыс істейтін компанияда платформаға жауаптысыз ба? Бұл жағдайда сізге қызмет көрсету торы қажет емес шығар. Егер сіз жақсы анықталған және сирек өзгеретін өзара әрекеттесу үлгілері бар монолиттермен (немесе тіпті монолиттердің жинақтарымен) жұмыс істеп жатсаңыз, онда қызмет көрсету торының сізге ұсынатыны аз. Сондықтан сіз оны елемей, жаман түс сияқты жоғалады деп үміттене аласыз ...
қорытынды
Мүмкін, сервистік торды әлі де «әлемдегі ең қызған технология» деп атауға болмайды - бұл күмәнді құрмет биткоинге немесе AI-ға тиесілі болуы мүмкін. Мүмкін ол алғашқы бестікке кіреді. Бірақ егер сіз шу мен дыбыс қабаттарын бұзсаңыз, қызмет көрсету торы Kubernetes-те қосымшаларды жасайтындарға нақты пайда әкелетіні белгілі болады.
Мен сізден Linkerd қолданбасын қолданып көргеніңізді қалаймын - оны Kubernetes кластеріне орнату (немесе тіпті ноутбукта Minikube) және не туралы айтып тұрғанымды өзіңіз көре аласыз.
FAQ
- Қызметтік торды елемей қалсам, ол жоғалып кете ме?
- Мен сізді ренжітуім керек: қызмет көрсету торы ұзақ уақыт бойы бізбен бірге.
— Бірақ мен қызмет көрсету торын пайдаланғым КЕЛМЕЙДІ!
-Жарайды, керек емес! Ең болмағанда оның негіздерімен танысу керек пе екенін білу үшін жоғарыдағы сауалнамамды оқып шығыңыз.
— Жаңа тұздықпен жақсы ескі ESB/орта ыдыс емес пе?
- Қызметтік тор семантикалық емес, операциялық логикамен айналысады. кәсіпорынның сервистік автобусы (). Бұл бөлуді сақтау қызмет көрсету торына бірдей тағдырды болдырмауға көмектеседі.
- Қызметтік тордың API шлюзінен айырмашылығы неде?
Бұл тақырып бойынша миллиондаған мақалалар бар. Тек Google.
Envoy қызмет көрсету торы ма?
- Жоқ, Envoy сервистік тор емес, бұл прокси сервер. Оны қызметтік торды ұйымдастыру үшін пайдалануға болады (және тағы басқалар - бұл жалпы мақсаттағы прокси). Бірақ бұл өздігінен қызмет көрсету торы емес.
- Network Service Mesh - бұл қызмет көрсету торы ма?
- Жоқ. Атауға қарамастан, бұл қызмет көрсету торы емес (сізге маркетингтің кереметтері қалай ұнайды?).
- Қызметтік тор хабарлама кезегіне негізделген реактивті асинхронды жүйеме көмектеседі ме?
- Жоқ, қызмет көрсету торы сізге көмектеспейді.
- Қандай қызмет көрсету торын пайдалануым керек?
- , ақыл жоқ.
- Мақала сұмдық! / Автор қош келдіңіз!
— Осыған көз жеткізу үшін оның сілтемесін барлық достарыңызбен бөлісіңіз!
Алғыс
Тақырыптан болжағаныңыздай, бұл мақала Джей Крепстің фантастикалық трактатынан шабыттандырылған ««. Мен Джеймен он жыл бұрын Linked In сайтында сұхбат берген кезде кездестім, содан бері ол маған шабыт берді.
Мен өзімді «Linkerd әзірлеушісі» деп атағанды ұнатсам да, мен жобадағы README.md файлының қолдаушысымын. Бүгін Linkerd-де жұмыс істеу , , адамдар, және бұл жоба салымшылар мен пайдаланушылардың таңғажайып қауымдастығынсыз мүмкін болмас еді.
Соңында, Linkerd жасаушысына ерекше рахмет, (primus inter pares), ол көп жылдар бұрын менімен бірге қызмет көрсету торымен осы әбігерге бас иген.
Аудармашыдан PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com