Монолитті қолданбадан микросервис архитектурасына көшкен кезде біз жаңа қиындықтарға тап боламыз.
Монолитті қолданбада қате жүйенің қай бөлігінде орын алғанын анықтау өте оңай. Мәселе монолиттің кодында немесе дерекқорда болуы мүмкін. Бірақ біз микросервис архитектурасында проблеманы іздей бастағанда, бәрі енді соншалықты айқын болмайды. Біз сұраудың басынан аяғына дейін алған бүкіл жолды тауып, оны жүздеген микросервистердің ішінен таңдауымыз керек. Сонымен қатар, олардың көпшілігінде логикалық қателер, сондай-ақ өнімділік пен ақауларға төзімділік проблемалары тудыруы мүмкін жеке сақтау орындары бар.
Мен мұндай проблемаларды жеңуге көмектесетін құралды ұзақ уақыт іздедім (Мен бұл туралы Хабреде жаздым: , ), бірақ соңында мен өзімнің ашық бастапқы шешімімді жасадым. Бұл мақалада мен сервистік тор тәсілінің артықшылықтары туралы айтып, оны жүзеге асырудың жаңа құралымен бөлісемін.
Бөлінген бақылау – үлестірмелі жүйелердегі қателерді табу мәселесінің жалпы шешімі. Бірақ егер желілік өзара әрекеттесулер туралы ақпаратты жинаудың бұл тәсілі жүйеде әлі енгізілмеген болса немесе одан да жаманы, жүйенің бір бөлігінде ол дұрыс жұмыс істейді, бірақ ішінара ол ескі қызметтерге қосылмағандықтан, ол жұмыс істемейді. ? Ақаулықтың нақты түпкі себебін анықтау үшін жүйеде не болып жатқанының толық бейнесі болуы керек. Қандай микросервистердің бизнес үшін маңызды жолдарға қатысатынын түсіну әсіресе маңызды.
Мұнда желілік ақпаратты жинауға арналған барлық құрылғылармен қызметтердің өздері жұмыс істейтін деңгейден төмен деңгейде жұмыс істейтін сервистік тор тәсілі көмекке келеді. Бұл тәсіл бізге барлық трафикті ұстап тұруға және оны жылдам талдауға мүмкіндік береді. Сонымен қатар, қолданбалар бұл туралы ештеңе білмеуі керек.
Қызметтік тор тәсілі
Сервистік тор тәсілінің негізгі идеясы желіге басқа инфрақұрылымдық қабат қосу болып табылады, ол бізге сервисаралық өзара әрекеттесу арқылы кез келген нәрсені жасауға мүмкіндік береді. Көптеген іске асырулар келесідей жұмыс істейді: әрбір микросервиске мөлдір проксиі бар қосымша бүйірлік контейнер қосылады, ол арқылы қызметтің барлық кіріс және шығыс трафигі өтеді. Міне, дәл осы жерде біз клиент балансын жасай аламыз, қауіпсіздік саясатын қолдана аламыз, сұраныстар санына шектеулер қоя аламыз және өндірістегі қызметтердің өзара әрекеттесуі туралы маңызды ақпаратты жинай аламыз.
Шешімдер
Бұл тәсілдің бірнеше іске асырылуы бар: и . Олар қораптан тыс көптеген мүмкіндіктерді қамтамасыз етеді. Бірақ сонымен бірге ресурстарға үлкен шығындар түседі. Сонымен қатар, мұндай жүйе жұмыс істейтін кластер неғұрлым үлкен болса, жаңа инфрақұрылымды қолдау үшін соғұрлым көп ресурстар қажет болады. Avito-да біз мыңдаған сервистік даналарды қамтитын кубернет кластерлерін басқарамыз (және олардың саны тез өсуде). Ағымдағы іске асыруда Istio бір қызмет данасына ~ 300 Мб жедел жадты тұтынады. Мүмкіндіктердің көптігіне байланысты мөлдір теңгерімдеу қызметтердің жалпы жауап беру уақытына да әсер етеді (10 мс дейін).
Нәтижесінде біз дәл қазір бізге қандай мүмкіндіктер қажет екенін қарастырдық және мұндай шешімдерді енгізуді бастауымыздың басты себебі бүкіл жүйеден транзакциялық ақпаратты жинау мүмкіндігі деп шештік. Біз сондай-ақ қызметтердің өзара әрекеттесуін бақылауды және қызметтер арасында тасымалданатын тақырыптармен әртүрлі манипуляцияларды жасағымыз келді.
Нәтижесінде біз мынадай шешімге келдік: .
Netramesh
жүйедегі қызметтер санына қарамастан шексіз масштабтау мүмкіндігі бар жеңіл қызмет көрсету торының шешімі болып табылады.
Жаңа шешімнің негізгі мақсаттары аз ресурс шығындары және жоғары өнімділік болды. Негізгі мүмкіндіктердің ішінде біз бірден Jaeger жүйесіне трассаны мөлдір түрде жібергіміз келді.
Бүгінгі таңда бұлттық шешімдердің көпшілігі Голангта жүзеге асырылады. Және, әрине, мұның себептері бар. Голанг тілінде енгізу/шығарумен асинхронды жұмыс істейтін және қажетінше ядролар бойынша масштабталатын желілік қосымшаларды жазу ыңғайлы және өте қарапайым. Ең бастысы, өнімділік бұл мәселені шешу үшін жеткілікті. Сол себепті біз де Голангты таңдадық.
өнімділік
Біз күш-жігерімізді максималды өнімділікке жетуге бағыттадық. Қызметтің әрбір данасы жанында орналастырылған шешім үшін жедел жад пен процессор уақытының аз шығыны қажет. Және, әрине, жауаптың кешігуі де аз болуы керек.
Қандай нәтиже алғанымызды көрейік.
Жедел Жадтау Құрылғысы
Netramesh трафиксіз ~ 10 Мб және бір дана үшін 50 10000 RPS жүктемесі кезінде ең көбі XNUMX Мб тұтынады.
Istio envoy проксиі мыңдаған даналары бар кластерлерімізде әрқашан ~300 Мб тұтынады. Бұл оны бүкіл кластерге масштабтауға мүмкіндік бермейді.
Netramesh көмегімен біз жадты тұтынуды ~ 10 есе азайттық.
Орталық Есептеуіш Бөлім
Процессорды пайдалану жүктеме кезінде салыстырмалы түрде бірдей. Бұл арбаға уақыт бірлігіндегі сұраулар санына байланысты. Секундына 3000 сұраныстағы мәндер шыңында:
Тағы бір маңызды сәт бар: Netramesh - басқару жазықтығы жоқ және жүктемесіз шешім CPU уақытын жұмсамайды. Istio көмегімен арбалар әрқашан қызмет көрсетудің соңғы нүктелерін жаңартады. Нәтижесінде біз бұл суретті жүктемесіз көре аламыз:
Біз қызметтер арасындағы байланыс үшін HTTP/1 пайдаланамыз. Өкіл арқылы прокси жіберу кезінде Istio үшін жауап беру уақытының ұлғаюы 5-10 мс дейін болды, бұл миллисекундта жауап беруге дайын қызметтер үшін өте көп. Netramesh көмегімен бұл уақыт 0.5-2 мс дейін төмендеді.
Масштабтылық
Әрбір прокси тұтынатын ресурстардың аз мөлшері оны әрбір қызметтің жанында орналастыруға мүмкіндік береді. Netramesh әрбір бүйір вагонның жеңіл салмағын сақтау үшін басқару ұшағы құрамдас бөлігісіз әдейі жасалған. Көбінесе сервистік тор шешімдерінде басқару ұшағы қызмет көрсету туралы ақпаратты әр бүйірлік вагонға таратады. Онымен бірге күту уақыты мен теңгерім параметрлері туралы ақпарат келеді. Мұның бәрі сізге көптеген пайдалы нәрселерді жасауға мүмкіндік береді, бірақ, өкінішке орай, бұл көлемді бүйірлік арбаларды толтырады.
Қызметті табу
Netramesh қызметті табу үшін ешқандай қосымша механизмдерді қоспайды. Барлық трафик нетра серігі арқылы мөлдір түрде проксиденеді.
Netramesh HTTP/1 қолданба протоколын қолдайды. Оны анықтау үшін порттардың конфигурацияланатын тізімі пайдаланылады. Әдетте, жүйеде HTTP байланысы жүзеге асырылатын бірнеше порттар болады. Мысалы, қызметтер мен сыртқы сұраулар арасындағы өзара әрекеттесу үшін біз 80, 8890, 8080 пайдаланамыз. Бұл жағдайда оларды орта айнымалысы арқылы орнатуға болады. NETRA_HTTP_PORTS.
Егер сіз Kubernetes-ті оркестратор және оның қызметтері арасындағы кластер ішілік байланысы үшін оның Қызмет нысаны механизмі ретінде пайдалансаңыз, механизм дәл сол күйінде қалады. Біріншіден, микросервис kube-dns көмегімен қызметтік IP мекенжайын алады және оған жаңа қосылым ашады. Бұл байланыс алдымен жергілікті желілік желімен орнатылады және барлық TCP пакеттері бастапқыда нетраға келеді. Әрі қарай, netra-sidecar бастапқы тағайындалған орынмен байланыс орнатады. Түйіндегі IP подкастындағы NAT нетрасыз бірдей болып қалады.
Бөлінген бақылау және мәтінмәнді қайта жіберу
Netramesh HTTP өзара әрекеттесулері туралы бақылау аралығын жіберу үшін қажетті функционалдылықты қамтамасыз етеді. Netra-sidecar HTTP протоколын талдайды, сұрау кідірістерін өлшейді және HTTP тақырыптарынан қажетті ақпаратты шығарады. Сайып келгенде, біз барлық іздерді бір Jaeger жүйесінде аламыз. Нақты конфигурация үшін ресми кітапхана ұсынған ортаның айнымалы мәндерін де пайдалануға болады .
Бірақ мәселе бар. Қызметтер арнайы uber тақырыбын жасап, жібермейінше, жүйеде қосылған бақылау аралығын көрмейміз. Міне, мәселенің себебін тез табуымыз керек. Мұнда тағы да Netramesh шешімі бар. Прокси-серверлер HTTP тақырыптарын оқиды және оларда uber ізі идентификаторы болмаса, біреуін жасаңыз. Netramesh сонымен қатар кіріс және шығыс сұраулар туралы ақпаратты бүйірлік вагонда сақтайды және оларды қажетті шығыс сұрау тақырыптарымен байыту арқылы сәйкестендіреді. Қызметтерде сізге тек бір тақырыпты жіберу қажет X-Request-Id, ол орта айнымалысы арқылы конфигурациялануы мүмкін NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh контекстінің өлшемін басқару үшін келесі орта айнымалы мәндерін орнатуға болады: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (мәтіннің сақталатын уақыты) және NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (контекстті тазалау жиілігі).
Сондай-ақ жүйеде бірнеше жолдарды арнайы сеанс белгісімен белгілеу арқылы біріктіруге болады. Netra орнатуға мүмкіндік береді HTTP_HEADER_TAG_MAP HTTP тақырыптарын сәйкес трассалық тегтерге айналдыру үшін. Бұл әсіресе тестілеу үшін пайдалы болуы мүмкін. Функционалдық сынақтан өткеннен кейін тиісті сеанс кілті арқылы сүзу арқылы жүйенің қай бөлігіне әсер еткенін көруге болады.
Сұраныс көзін анықтау
Сұрау қайдан келгенін анықтау үшін дереккөзбен тақырыпты автоматты түрде қосу мүмкіндігін пайдалануға болады. Айнымалы ортаны пайдалану NETRA_HTTP_X_SOURCE_HEADER_NAME Автоматты түрде орнатылатын тақырып атауын көрсетуге болады. Көмегімен NETRA_HTTP_X_SOURCE_VALUE X-Source тақырыбы барлық шығыс сұраулар үшін орнатылатын мәнді орнатуға болады.
Бұл осы пайдалы тақырыпты таратуды бүкіл желіде біркелкі таратуға мүмкіндік береді. Содан кейін оны қызметтерде пайдалануға және журналдар мен көрсеткіштерге қосуға болады.
Трафикті маршруттау және Netramesh ішкі элементтері
Netramesh екі негізгі компоненттен тұрады. Бірінші, netra-init, трафикті тоқтату үшін желі ережелерін орнатады. Ол пайдаланады Netramesh-тің екінші негізгі құрамдас бөлігі болып табылатын вагондағы трафиктің толық немесе бір бөлігін ұстап тұру. Кіріс және шығыс TCP сеанстары үшін қандай порттарды ұстау керектігін конфигурациялауға болады: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Құралдың қызықты мүмкіндігі де бар - ықтималдық бағыттау. Netramesh-ті тек бақылау аралығын жинау үшін пайдалансаңыз, онда өндірістік ортада ресурстарды үнемдеуге және айнымалы мәндерді пайдаланып ықтималдық бағыттауды қосуға болады. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0-ден 1-ге дейін). Әдепкі мән 1 (барлық трафик ұсталады).
Сәтті ұстап алғаннан кейін, netra сейф жаңа қосылымды қабылдайды және пайдаланады SO_ORIGINAL_DST бастапқы тағайындалған жерді алу үшін розетка опциясы. Содан кейін Netra бастапқы IP мекенжайына жаңа қосылымды ашады және барлық өтетін трафикті тыңдай отырып, тараптар арасында екі жақты TCP байланысын орнатады. Егер порт HTTP ретінде анықталса, Netra оны талдауға және бақылауға тырысады. HTTP талдауы сәтсіз болса, Netra TCP-ге қайта түседі және байттарды мөлдір прокси жасайды.
Тәуелділік графигін құру
Jaeger-те бақылау ақпаратының үлкен көлемін алғаннан кейін, мен жүйедегі өзара әрекеттесулердің толық графигін алғым келеді. Бірақ егер сіздің жүйеңіз айтарлықтай жүктелсе және күніне миллиардтаған бақылау аралығы жиналса, оларды жинақтау оңай емес. Мұны істеудің ресми жолы бар: . Дегенмен, толық графикті құру бірнеше сағатты алады және соңғы XNUMX сағат ішінде Jaeger-тен бүкіл деректер жинағын жүктеп алуға мәжбүр етеді.
Бақылау аралығын сақтау үшін Elasticsearch қолданып жатсаңыз, пайдалануға болады , ол Elasticsearch мүмкіндіктері мен мүмкіндіктерін пайдалана отырып, сол графикті бірнеше минут ішінде құрастырады.
Netramesh қалай пайдалануға болады
Netra кез келген оркестрмен жұмыс істейтін кез келген қызметке оңай қосылуы мүмкін. Мысал көруге болады .
Қазіргі уақытта Netra-да сервистерге қосалқы көліктерді автоматты түрде енгізу мүмкіндігі жоқ, бірақ іске асыру жоспарлары бар.
Netramesh болашағы
басты мақсат ең аз ресурстық шығындарға және қызмет аралық байланысты бақылауға және бақылауға арналған негізгі мүмкіндіктерді қамтамасыз ететін жоғары өнімділікке қол жеткізу болып табылады.
Болашақта Netramesh HTTP протоколынан басқа қолданбалы деңгей протоколдарын қолдайды. L7 маршрутизациясы жақын арада қолжетімді болады.
Ұқсас мәселелерге тап болсаңыз, Netramesh пайдаланыңыз және сұрақтар мен ұсыныстарды бізге жазыңыз.
Ақпарат көзі: www.habr.com