Интернетте (қызмет көрсету торы), міне, тағы біреуі. Ура! Бірақ неге? Содан кейін, мен Docker және Kubernetes сияқты контейнерлік платформалар пайда болғанға дейін сервистік торлар 10 жыл бұрын пайда болса жақсы болар еді деген пікірімді айтқым келеді. Мен өз көзқарасымды басқаларға қарағанда жақсы немесе нашар деп айтпаймын, бірақ қызмет көрсету торлары өте күрделі жануарлар болғандықтан, көптеген көзқарастар оларды жақсы түсінуге көмектеседі.
Мен жүзден астам микросервистерге құрылған және мыңдаған контейнерлік қосымшаларды қолдайтын dotCloud платформасы туралы айтатын боламын. Мен оны әзірлеу және іске қосу кезінде кездесетін қиындықтарды және қызмет торларының қалай көмектесетінін (немесе көмектесе алмайтынын) түсіндіремін.
dotCloud тарихы
Мен dotCloud тарихы және осы платформаның архитектуралық таңдаулары туралы жаздым, бірақ желілік деңгей туралы көп айтқан жоқпын. Егер сіз оқуды қаламасаңыз dotCloud туралы қысқаша түйін: бұл тұтынушыларға деректердің кең ауқымын қолдауымен кең ауқымды қолданбаларды (Java, PHP, Python...) іске қосуға мүмкіндік беретін қызмет ретіндегі PaaS платформасы. қызметтері (MongoDB, MySQL, Redis...) және Heroku сияқты жұмыс процесі: Сіз платформаға кодты жүктейсіз, ол контейнерлік кескіндерді жасайды және оларды орналастырады.
Мен сізге трафиктің dotCloud платформасына қалай бағытталғанын айтып беремін. Бұл өте керемет болғандықтан емес (жүйе өз уақытында жақсы жұмыс істеді!), бірақ, ең алдымен, заманауи құралдардың көмегімен мұндай дизайнды қарапайым команда қысқа мерзімде оңай жүзеге асыра алатындықтан, егер оларға трафикті топ арасында бағыттау әдісі қажет болса. микросервистердің немесе қосымшалардың жиынтығы. Осылайша, опцияларды салыстыруға болады: егер сіз бәрін өзіңіз дамытсаңыз немесе бар қызмет торын пайдалансаңыз не болады. Стандартты таңдау - оны өзіңіз жасау немесе сатып алу.
Орналастырылған қолданбалар үшін трафикті бағыттау
dotCloud қолданбалары HTTP және TCP соңғы нүктелерін көрсете алады.
HTTP соңғы нүктелері жүктеме теңестіру кластерінің конфигурациясына динамикалық түрде қосылған . Бұл бүгінгі ресурстарға ұқсас Kubernetes және жүк теңдестіргіш сияқты .
Клиенттер HTTP соңғы нүктелеріне домендік атау dotCloud жүктеме теңдестірушілерін көрсететін жағдайда, сәйкес домендер арқылы қосылады. Ерекше ештеңе жоқ.
TCP соңғы нүктелері порт нөмірімен байланыстырылады, содан кейін орта айнымалы мәндері арқылы сол стектегі барлық контейнерлерге жіберіледі.
Клиенттер TCP соңғы нүктелеріне сәйкес хост атауын (gateway-X.dotcloud.com сияқты) және порт нөмірін пайдаланып қосыла алады.
Бұл хост атауы «nats» сервер кластеріне (. қатысты емес) шешеді ), ол кіріс TCP қосылымдарын дұрыс контейнерге бағыттайды (немесе, жүктемені теңестіру қызметтері жағдайында, дұрыс контейнерлерге).
Егер сіз Kubernetes-пен таныс болсаңыз, бұл сізге Қызметтерді еске түсіруі мүмкін .
dotCloud платформасында балама қызметтер болған жоқ : Қарапайымдылық үшін қызметтерге платформаның ішінен де, сыртынан да бірдей жолмен қол жеткізілді.
Барлығы өте қарапайым түрде ұйымдастырылған: HTTP және TCP маршруттау желілерінің бастапқы іске асырылуы Python-ның бірнеше жүздеген жолдары болуы мүмкін. Платформаның өсуіне және қосымша талаптардың пайда болуына қарай нақтыланған қарапайым (мен аңғал дер едім) алгоритмдер.
Қолданыстағы кодты ауқымды рефакторинг талап етілмеді. Сондай-ақ, орта айнымалылары арқылы алынған мекенжайды тікелей пайдалана алады.
Бұл заманауи қызмет көрсету торынан несімен ерекшеленеді?
Шектеулі көріну. Бізде TCP маршруттау торына арналған ешқандай көрсеткіштер мүлде болған жоқ. HTTP маршрутизациясына келетін болсақ, кейінгі нұсқалар қате кодтары мен жауап беру уақыттары бар егжей-тегжейлі HTTP метрикасын енгізді, бірақ заманауи қызмет торлары, мысалы, Prometheus сияқты метрика жинау жүйелерімен интеграцияны қамтамасыз ететін одан әрі жүреді.
Көріну тек операциялық тұрғыдан (мәселелерді шешуге көмектесу үшін) ғана емес, сонымен қатар жаңа мүмкіндіктерді шығарған кезде де маңызды. Бұл қауіпсіз и .
Маршруттау тиімділігі да шектелген. DotCloud маршруттау торында барлық трафик арнайы бағыттау түйіндерінің кластері арқылы өтуі керек еді. Бұл бірнеше AZ (қолжетімділік аймағы) шекараларын әлеуетті кесіп өтуді және кідірісті айтарлықтай арттыруды білдіреді. Әр бетте жүзден астам SQL сұрауын жасайтын және әрбір сұрау үшін SQL серверіне жаңа қосылым ашатын ақаулықтарды жою коды есімде. Жергілікті іске қосылған кезде бет лезде жүктеледі, бірақ dotCloud жүйесінде жүктеуге бірнеше секунд кетеді, себебі әрбір TCP қосылымы (және одан кейінгі SQL сұрауы) ондаған миллисекундтарды алады. Бұл нақты жағдайда тұрақты қосылымдар мәселені шешті.
Заманауи сервистік торлар мұндай мәселелерді шешуде жақсырақ. Ең алдымен олар қосылымдардың бағытталуын тексереді көзде. Логикалық ағым бірдей: клиент → меш → сервис, бірақ қазір тор қашықтағы түйіндерде емес, жергілікті түрде жұмыс істейді, сондықтан қосылым клиент → меш жергілікті және өте жылдам (миллисекундтардың орнына микросекундтар).
Заманауи қызмет көрсету торлары сонымен қатар ақылды жүктемені теңестіру алгоритмдерін жүзеге асырады. Бекіткіштердің денсаулығын бақылау арқылы олар жылдамырақ серверлерге көбірек трафик жібере алады, нәтижесінде жалпы өнімділік жақсарады.
Қауіпсіздік жақсырақ. DotCloud маршруттау торы толығымен EC2 Classic жүйесінде жұмыс істеді және трафикті шифрламады (егер біреу EC2 желі трафигіне снайферді орната алса, сіз үлкен қиындыққа тап болдыңыз деген болжамға негізделген). Заманауи сервис торлары біздің барлық трафикті мөлдір қорғайды, мысалы, өзара TLS аутентификациясы және кейінгі шифрлау.
Платформа қызметтері үшін трафикті бағыттау
Жарайды, біз қолданбалар арасындағы трафикті талқыладық, бірақ dotCloud платформасының өзі ше?
Платформаның өзі әртүрлі функцияларға жауап беретін жүзге жуық микросервистерден тұрды. Кейбіреулер басқалардың сұрауларын қабылдады, ал кейбіреулері басқа қызметтерге қосылған, бірақ қосылымдарды өздері қабылдамайтын фондық жұмысшылар болды. Кез келген жағдайда, әрбір қызмет оған қосылу үшін қажетті мекенжайлардың соңғы нүктелерін білуі керек.
Көптеген жоғары деңгейлі қызметтер жоғарыда сипатталған маршруттау торын пайдалануы мүмкін. Шын мәнінде, dotCloud-тың жүзден астам микросервистерінің көпшілігі dotCloud платформасының өзінде кәдімгі қолданбалар ретінде орналастырылған. Бірақ төмен деңгейлі қызметтердің аз саны (әсіресе осы маршруттау торын жүзеге асыратындар) азырақ тәуелділікпен қарапайым нәрсе қажет болды (өйткені олар жұмыс істеу үшін өздеріне тәуелді бола алмады - ескі тауық пен жұмыртқа мәселесі).
Бұл төмен деңгейлі, миссия үшін маңызды қызметтер контейнерлерді бірнеше негізгі түйіндерде тікелей іске қосу арқылы орналастырылды. Бұл жағдайда стандартты платформа қызметтері пайдаланылмады: байланыстырушы, жоспарлаушы және жүгіруші. Егер сіз заманауи контейнерлік платформалармен салыстырғыңыз келсе, бұл басқару ұшағын басқару сияқты docker run Тапсырманы Кубернетеске берудің орнына тікелей түйіндерде. Тұжырымдамада ол өте ұқсас , ол пайдаланады немесе оқшау кластерді жүктеу кезінде.
Бұл қызметтер қарапайым және өрескел түрде көрсетілді: YAML файлында олардың аттары мен мекенжайлары көрсетілген; және әрбір клиент орналастыру үшін осы YAML файлының көшірмесін алуы керек болды.
Бір жағынан, бұл өте сенімді, себебі ол Zookeeper (есіңізде болсын, etcd немесе Consul ол кезде болмаған) сияқты сыртқы кілт/құнды дүкеннің қолдауын қажет етпейді. Екінші жағынан, бұл қызметтерді жылжытуды қиындатты. Әр жылжытылған сайын, барлық клиенттер жаңартылған YAML файлын алады (және ықтимал қайта жүктеледі). Өте ыңғайлы емес!
Кейіннен біз әрбір клиент жергілікті прокси-серверге қосылған жаңа схеманы іске асыра бастадық. Мекенжай мен порттың орнына ол тек қызметтің порт нөмірін біліп, арқылы қосылуы керек localhost. Жергілікті прокси бұл қосылымды өңдейді және оны нақты серверге жібереді. Енді серверді басқа құрылғыға жылжытқанда немесе масштабтағанда, барлық клиенттерді жаңартудың орнына, тек осы жергілікті прокси-серверлердің барлығын жаңарту қажет; және қайта жүктеу енді қажет емес.
(Сонымен қатар TLS қосылымдарындағы трафикті инкапсуляциялау және қабылдаушы тарапқа басқа прокси-серверді қою, сонымен қатар тек қосылымдарды қабылдау үшін конфигурацияланған қабылдау қызметінің қатысуынсыз TLS сертификаттарын тексеру жоспарланған болатын. localhost. Бұл туралы кейінірек).
Бұл өте ұқсас Airbnb ұсынған, бірақ маңызды айырмашылығы SmartStack енгізіліп, өндіріске орналастырылған, ал dotCloud Docker болған кезде dotCloud ішкі маршруттау жүйесі тоқтатылған.
Мен SmartStack-ті Istio, Linkerd және Consul Connect сияқты жүйелердің предшественниктерінің бірі деп санаймын, өйткені олардың барлығы бірдей үлгіні ұстанады:
- Әрбір түйінде проксиді іске қосыңыз.
- Клиенттер проксиге қосылады.
- Басқару жазықтығы серверлер өзгерген кезде прокси конфигурациясын жаңартады.
- ... Пайда!
Сервистік торды заманауи енгізу
Бізге бүгін осындай торды енгізу қажет болса, біз ұқсас принциптерді пайдалана аламыз. Мысалы, қызмет атауларын кеңістіктегі мекенжайларға салыстыру арқылы ішкі DNS аймағын конфигурациялаңыз 127.0.0.0/8. Содан кейін әрбір қызмет мекенжайында (сол ішкі желіде) қосылымдарды қабылдай отырып, кластердегі әрбір түйінде HAProxy іске қосыңыз. 127.0.0.0/8) және жүктемені сәйкес серверлерге қайта бағыттау/теңдестіру. HAProxy конфигурациясын басқаруға болады , сізге серверлік ақпаратты etcd немесе Consul ішінде сақтауға және қажет болғанда жаңартылған конфигурацияны HAProxy жүйесіне автоматты түрде жіберуге мүмкіндік береді.
Istio осылай жұмыс істейді! Бірақ кейбір айырмашылықтармен:
- Қолданады HAProxy орнына.
- etcd немесе Consul орнына Kubernetes API арқылы сервер конфигурациясын сақтайды.
- Қызметтер 127.0.0.0/8 орнына ішкі ішкі желіде (Kubernetes ClusterIP мекенжайлары) бөлінген мекенжайлар.
- Клиент пен серверлер арасында өзара TLS аутентификациясын қосу үшін қосымша құрамдас (Citadel) бар.
- Тізбекті ажырату, бөлінген бақылау, канарларды орналастыру және т.б. сияқты жаңа мүмкіндіктерді қолдайды.
Кейбір айырмашылықтарды жылдам қарастырайық.
Өкіл прокси
Envoy Proxy-ті Lyft жазды [Uber-тің такси нарығындағы бәсекелесі - шамамен. жолақ]. Ол басқа прокси-серверлерге (мысалы, HAProxy, Nginx, Traefik...) көп жағынан ұқсас, бірақ Lyft оларды жазды, өйткені оларға басқа прокси-серверлерде жетіспейтін мүмкіндіктер қажет болды және барын кеңейткеннен гөрі жаңасын жасау ақылдырақ болып көрінді.
Өкілді өз бетімен пайдалануға болады. Егер менде басқа қызметтерге қосылуды қажет ететін белгілі бір қызмет болса, мен оны Envoy қызметіне қосылу үшін конфигурациялай аламын, содан кейін көріну сияқты көптеген керемет қосымша функцияларды ала отырып, Envoy қызметін басқа қызметтердің орнымен динамикалық түрде конфигурациялап, қайта конфигурациялай аламын. Теңшелетін клиент кітапханасының немесе кодқа қоңырау іздерін енгізудің орнына біз Envoy қызметіне трафик жібереміз және ол біз үшін көрсеткіштерді жинайды.
Бірақ Елші ретінде де жұмыс істеуге қабілетті деректер жазықтығы (деректер жазықтығы) қызмет көрсету торына арналған. Бұл Envoy енді осы қызмет торы үшін конфигурацияланғанын білдіреді басқару ұшағы (басқару ұшағы).
Басқару ұшағы
Басқару жазықтығы үшін Istio Kubernetes API-ге сүйенеді. Бұл confd пайдаланудан айтарлықтай ерекшеленбейді, ол деректер қоймасындағы кілттер жинағын көру үшін etcd немесе Консулға сүйенеді. Istio Kubernetes ресурстарының жинағын көру үшін Kubernetes API пайдаланады.
Осыдан кейін: Мен мұны пайдалы деп таптым онда оқылады:
Kubernetes API сервері API ресурстары үшін сақтауды, нұсқаларды анықтауды, тексеруді, жаңартуды және семантиканы ұсынатын «ақымақ сервер» болып табылады.
Istio Kubernetes-пен жұмыс істеуге арналған; және оны Kubernetes-тен тыс пайдаланғыңыз келсе, Kubernetes API серверінің (және etcd көмекші қызметі) данасын іске қосуыңыз керек.
Қызмет мекенжайлары
Istio Kubernetes бөлетін ClusterIP мекенжайларына сүйенеді, сондықтан Istio қызметтері ішкі мекенжайды алады (ауқымда емес) 127.0.0.0/8).
Istio жоқ Kubernetes кластеріндегі белгілі бір қызметке арналған ClusterIP мекенжайына трафик kube-прокси арқылы тоқтатылады және сол прокси серверіне жіберіледі. Егер сізді техникалық мәліметтер қызықтырса, kube-proxy ClusterIP мекенжайына баратын қосылымдардың тағайындалған IP мекенжайларын қайта жазу үшін iptables ережелерін (немесе конфигурацияланғанына байланысты IPVS жүктеме теңестіргіштерін) орнатады.
Istio Kubernetes кластеріне орнатылғаннан кейін, контейнерді енгізу арқылы берілген тұтынушы немесе тіпті бүкіл аттар кеңістігі үшін нақты қосылғанша ештеңе өзгермейді. sidecar реттелетін бөліктерге. Бұл контейнер Envoy данасын айналдырады және басқа қызметтерге баратын трафикті тоқтату және сол трафикті Envoy қызметіне қайта бағыттау үшін iptables ережелер жинағын орнатады.
Kubernetes DNS жүйесімен біріктірілген кезде, бұл біздің код қызмет атауы бойынша қосыла алатынын және барлығы «жұмыс істейді» дегенді білдіреді. Басқаша айтқанда, біздің код сияқты сұраулар шығарады http://api/v1/users/4242, содан кейін api сұрауын шешу 10.97.105.48, iptables ережелері 10.97.105.48 нұсқасындағы қосылымдарды тоқтатады және оларды жергілікті Envoy проксиіне жібереді, ал жергілікті прокси сұрауды нақты сервер API интерфейсіне жібереді. Уф!
Қосымша бұйралар
Istio сонымен қатар mTLS (өзара TLS) арқылы түпкілікті шифрлауды және аутентификацияны қамтамасыз етеді. деп аталатын компонент Цитадель.
Құрамдас бөлігі де бар Миксер, ол үшін Өкіл сұрай алады әрқайсысының тақырыптар, серверлік жүктеме және т.б. сияқты әр түрлі факторларға байланысты осы сұрау туралы арнайы шешім қабылдауды сұрау... (уайымдамаңыз: Миксердің жұмысын жалғастырудың көптеген жолдары бар және ол бұзылса да, Envoy жұмысын жалғастырады. прокси ретінде жақсы).
Және, әрине, біз көріну туралы айттық: Envoy таратылған бақылауды қамтамасыз ете отырып, көптеген көрсеткіштерді жинайды. Микросервис архитектурасында, егер бір API сұрауы A, B, C және D микросервистері арқылы өтуі керек болса, жүйеге кірген кезде таратылған бақылау сұрауға бірегей идентификатор қосады және осы идентификаторды осы микросервистердің барлығына ішкі сұраулар арқылы сақтайды. түсірілетін барлық байланысты қоңыраулар, кешігулер және т.б.
Дамытыңыз немесе сатып алыңыз
Истио күрделі болу үшін беделге ие. Керісінше, мен осы жазбаның басында сипаттаған маршруттау торын құру бар құралдарды пайдалану арқылы салыстырмалы түрде қарапайым. Сонымен, оның орнына өз қызмет көрсету торын жасау мағынасы бар ма?
Егер бізде қарапайым қажеттіліктер болса (бізге көріну, автоматты ажыратқыш және басқа нәзіктіктер қажет емес), онда ойлар өз құралымызды әзірлеуге келеді. Бірақ егер біз Kubernetes-ті қолданатын болсақ, ол тіпті қажет болмауы мүмкін, өйткені Kubernetes қазірдің өзінде қызметтерді табу және жүктемені теңестіру үшін негізгі құралдарды қамтамасыз етеді.
Бірақ егер бізде кеңейтілген талаптар болса, онда қызмет көрсету торын «сатып алу» әлдеқайда жақсы нұсқа болып көрінеді. (Бұл әрқашан «сатып алу» емес, өйткені Istio ашық бастапқы код, бірақ біз оны түсіну, орналастыру және басқару үшін әлі де инженерлік уақытты жұмсауымыз керек.)
Istio, Linkerd немесе Consul Connect таңдауым керек пе?
Әзірге біз тек Istio туралы айттық, бірақ бұл жалғыз қызмет көрсету торы емес. Танымал балама - , және одан да көп .
Не таңдауға болады?
Шынымды айтсам, білмеймін. Қазіргі уақытта бұл сұраққа жауап беруге өзімді құзырлы санамаймын. Бірнеше бар осы құралдарды салыстырумен және тіпті .
Бір перспективалы тәсіл сияқты құралды пайдалану болып табылады . Ол қызмет торлары арқылы ашылатын API интерфейстерін жеңілдету және біріктіру үшін абстракциялық деңгейді жүзеге асырады. Әртүрлі қызмет көрсету торларының арнайы (және, менің ойымша, салыстырмалы түрде күрделі) API интерфейстерін үйренудің орнына, біз SuperGloo-ның қарапайым құрылымдарын пайдалана аламыз және бірінен екіншісіне оңай ауыса аламыз, өйткені бізде HTTP интерфейстері мен серверлерді сипаттайтын аралық конфигурация пішімі бар сияқты Nginx, HAProxy, Traefik, Apache үшін нақты конфигурацияны жасау ...
Мен Istio және SuperGloo-мен біраз айналыстым, келесі мақалада мен Istio немесе Linkerd-ті SuperGloo көмегімен бар кластерге қалай қосуға болатынын және соңғысы жұмысты қалай орындайтынын көрсеткім келеді, яғни сізге ауысуға мүмкіндік береді. конфигурацияларды қайта жазусыз бір қызмет торын екіншісіне.
Ақпарат көзі: www.habr.com