Монолиттик тиркемеден микросервис архитектурасына өткөнүбүздө жаңы кыйынчылыктарга туш болобуз.
Монолиттик тиркемеде ката системанын кайсы бөлүгүндө болгонун аныктоо оңой. Кыязы, көйгөй монолиттин кодунда же маалымат базасында. Бирок биз микросервис архитектурасында көйгөйдү издеп баштаганда, баары ачык-айкын болбой калат. Сурам башынан аягына чейин бүт жолду таап, аны жүздөгөн микросервистердин ичинен тандап алышыбыз керек. Мындан тышкары, алардын көбү, ошондой эле логикалык каталарды, ошондой эле аткаруу жана ката чыдамкайлык менен көйгөйлөрдү алып келиши мүмкүн, өз сактоо жайлар бар.
Мен мындай көйгөйлөр менен күрөшүүгө жардам бере турган куралды көптөн бери издеп жүрдүм (Мен бул тууралуу Хабреде жаздым: , ), бирок акырында мен өзүмдүн ачык булактуу чечимимди жасадым. Бул макалада мен кызматтык тор мамиленин артыкчылыктары жөнүндө айтып, аны ишке ашыруу үчүн жаңы курал менен бөлүшөм.
Бөлүштүрүлгөн чалгындоо бөлүштүрүлгөн системалардагы каталарды табуу маселесине кеңири таралган чечим болуп саналат. Ал эми тармактык өз ара аракеттенүү жөнүндө маалыматты чогултуунун бул ыкмасы тутумда али ишке ашырыла элек болсо, же андан да жаманы, системанын бир бөлүгүндө ал буга чейин эле туура иштеп, бирок жарым-жартылай иштебейт, анткени ал эски кызматтарга кошула элек. ? Көйгөйдүн түпкү себебин так аныктоо үчүн системада эмне болуп жаткандыгы тууралуу толук маалымат болушу керек. Кайсы микросервистердин бизнес-критикалык жолдоруна катышканын түшүнүү өзгөчө маанилүү.
Бул жерде жардамга тармактык маалыматты чогултуу үчүн бардык техникалар кызмат көрсөткөн кызматтардан төмөн деңгээлдеги тейлөө тармагына мамиле жасай алат. Бул ыкма бизге бардык трафикти кармап турууга жана аны учуп анализдөөгө мүмкүндүк берет. Мындан тышкары, тиркемелер ал жөнүндө эч нерсе билиши керек эмес.
Кызмат сетка мамилеси
Кызматтык тор ыкмасынын негизги идеясы - бул тармакка дагы бир инфраструктуралык катмарды кошуу, бул бизге кызматтар аралык өз ара аракеттенүү менен каалаган нерсени кылууга мүмкүндүк берет. Көпчүлүк ишке ашыруулар төмөнкүдөй иштейт: ар бир микросервиске ачык прокси менен кошумча каптал контейнери кошулат, ал аркылуу кызматтын бардык кириш жана чыгыш трафиги өткөрүлөт. Бул жерде биз кардарлардын балансын түзө алабыз, коопсуздук саясатын колдонобуз, суроо-талаптардын санына чектөө киргизе алабыз жана өндүрүштөгү кызматтардын өз ара аракеттенүүсү боюнча маанилүү маалыматтарды чогултабыз.
Чечимдер
Бул ыкманын буга чейин эле бир нече ишке ашырылышы бар: и . Алар кутудан тышкары көптөгөн өзгөчөлүктөр менен камсыз кылат. Бирок ошол эле учурда ресурстарга чоң чыгым келип жатат. Мындан тышкары, мындай система иштеген кластер канчалык чоң болсо, жаңы инфраструктураны кармап туруу үчүн ошончолук көп каражат талап кылынат. Avitoдо биз миңдеген тейлөө инстанцияларын камтыган кубернет кластерлерин иштетебиз (жана алардын саны тездик менен өсүүдө). Учурдагы ишке ашырууда Istio бир кызмат көрсөтүү инстанциясына ~ 300 Мб оперативдүү эстутум керектейт. Мүмкүнчүлүктөрдүн көптүгүнө байланыштуу, ачык-айкын баланстоо кызматтардын жалпы жооп берүү убактысына да таасирин тийгизет (10 мс чейин).
Натыйжада, биз азыр бизге кандай мүмкүнчүлүктөр керек экенин карап чыктык жана мындай чечимдерди ишке ашыра баштаганыбыздын негизги себеби, бүт системадан ачык-айкын маалымат чогултуу мүмкүнчүлүгү деп чечтик. Биз ошондой эле кызматтардын өз ара аракеттенүүсүн көзөмөлдөөнү жана кызматтардын ортосунда өткөрүлүп жаткан баштар менен ар кандай манипуляцияларды жасоону кааладык.
Жыйынтыгында биз чечимге келдик: .
Netramesh
тутумдагы кызматтардын санына карабастан, чексиз масштабда иштөө мүмкүнчүлүгү бар жеңил кызматтык тор чечими.
Жаңы чечимдин негизги максаттары аз ресурстар жана жогорку көрсөткүчтөр болгон. Негизги өзгөчөлүктөрдүн арасында биз дароо Jaeger тутумубузга трассаны ачык-айкын жөнөтүүнү кааладык.
Бүгүнкү күндө көпчүлүк булут чечимдери Голангда ишке ашырылат. Анан, албетте, мунун себептери бар. Голангда I/O менен асинхрондуу иштеген жана зарылчылыкка жараша өзөктөр боюнча масштабдуу тармактык тиркемелерди жазуу ыңгайлуу жана абдан жөнөкөй. Жана эң маанилүүсү, бул маселени чечүү үчүн аткаруу жетиштүү. Ошондуктан биз да Голангды тандап алдык.
кирешелүүлүк
Биз куч-аракетибизди максималдуу эмгек ендурумдуулугуне жетишууге багыттадык. Кызматтын ар бир инстанциясынын жанында орнотулган чечим үчүн, RAM жана CPU убактысынын бир аз чыгымы талап кылынат. Анан, албетте, жооп кечигүү да аз болушу керек.
Келгиле, кандай натыйжаларга жетишкенибизди көрөлү.
RAM
Netramesh трафиксиз ~ 10 Мб жана 50 10000 RPS жүктөө менен максималдуу XNUMX Мб керектейт.
Istio элчи прокси миңдеген учурлары бар кластерлерибизде ар дайым ~300Мб керектейт. Бул бүткүл кластерге масштабдуу болууга мүмкүндүк бербейт.
Netramesh менен биз эстутум керектөөнү ~ 10 эсе кыскартты.
CPU
CPU колдонуу жүктөм астында салыштырмалуу бирдей. Бул капталга убакыт бирдигине суроо-талаптардын санына жараша болот. Чокусунда секундасына 3000 суроонун мааниси:
Дагы бир маанилүү жагдай бар: Netramesh - башкаруу учагы жок жана жүк жок чечим CPU убактысын талап кылбайт. Istio менен капталдар ар дайым кызматтын акыркы чекиттерин жаңыртышат. Натыйжада, биз бул сүрөттү жүк жок көрө алабыз:
Биз кызматтардын ортосундагы байланыш үчүн HTTP/1 колдонобуз. Элчи аркылуу проксисин жөнөтүүдө Istio үчүн жооп берүү убактысынын көбөйүшү 5-10 мс чейин болду, бул миллисекундда жооп берүүгө даяр кызматтар үчүн абдан көп. Netramesh менен бул убакыт 0.5-2 мс чейин кыскарган.
Масштабдуулук
Ар бир прокси тарабынан керектелген ресурстардын аз көлөмү аны ар бир кызматтын жанына жайгаштырууга мүмкүндүк берет. Netramesh ар бир капталдагы жеңил салмакты сактоо үчүн башкаруучу учактын компоненти жок атайын түзүлгөн. Көбүнчө тейлөө торчо чечимдеринде, башкаруу учагы кызматтын ачылыш маалыматын ар бир капталга таратат. Аны менен бирге тайм-ауттар жана тең салмактуулук орнотуулары жөнүндө маалымат келет. Мунун баары сизге көптөгөн пайдалуу нерселерди жасоого мүмкүндүк берет, бирок, тилекке каршы, бул көлөмдө капталдарды көбөйтөт.
Кызматтын ачылышы
Netramesh кызматты табуу үчүн эч кандай кошумча механизмдерди кошпойт. Бардык трафик Netra каптал аркылуу ачык-айкын прокси менен камсыз кылынат.
Netramesh HTTP/1 колдонмо протоколун колдойт. Аны аныктоо үчүн порттордун конфигурациялануучу тизмеси колдонулат. Адатта, системанын HTTP байланышы пайда болгон бир нече порттору бар. Мисалы, биз 80, 8890, 8080 кызматтарын жана тышкы суроо-талаптарды өз ара аракеттенүү үчүн колдонобуз NETRA_HTTP_PORTS.
Эгер сиз Kubernetesти оркестр катары жана анын Кызмат субъектинин механизмин кызматтардын ортосундагы кластердик байланыш үчүн колдонсоңуз, анда механизм ошол эле бойдон калат. Биринчиден, микросервис kube-dns аркылуу кызматтын IP дарегин алат жана ага жаңы туташууну ачат. Бул байланыш адегенде локалдык нетра-сайдер менен түзүлөт жана бардык TCP пакеттери алгач Netraга келет. Андан кийин, netra-sidecar баштапкы көздөгөн жер менен байланышты орнотот. Түйүндөгү IP боюнча NAT Netraсыз эле ошол бойдон калат.
Бөлүштүрүлгөн байкоо жана контекстти багыттоо
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 sidecar жаңы байланышты кабыл алат жана колдонот SO_ORIGINAL_DST баштапкы көздөгөн жерди алуу үчүн розетка опциясы. Андан кийин Netra түпнуска IP дарекке жаңы туташууну ачат жана өткөн бардык трафикти угуп, тараптардын ортосунда эки тараптуу TCP байланышын орнотот. Эгерде порт HTTP катары аныкталса, Netra аны талдоо жана көзөмөлдөөгө аракет кылат. HTTP талдоо ишке ашпай калса, Netra TCP'ге кайра түшүп, байттарды ачык проксиге салат.
Көз карандылык графигин түзүү
Jaegerде чоң көлөмдөгү издөө маалыматын алгандан кийин, мен системадагы өз ара аракеттенүүнүн толук графигин алгым келет. Бирок, эгер сиздин тутумуңуз бир топ жүктөлүп, күнүнө миллиарддаган трассалар топтолсо, аларды топтоо оңой иш эмес. Муну жасоонун расмий жолу бар: . Бирок, толук графикти түзүү үчүн бир нече саат талап кылынат жана акыркы 24 сааттын ичинде Jaegerден бардык маалыматтар топтомун жүктөп алууга мажбурлайт.
Эгер сиз Elasticsearchти трассаны сактоо үчүн колдонуп жатсаңыз, анда колдоно аласыз , ал Elasticsearch функцияларын жана мүмкүнчүлүктөрүн колдонуу менен бир нече мүнөттүн ичинде ошол эле графикти курат.
Netramesh кантип колдонсо болот
Netra оңой эле каалаган оркестрди башкарган каалаган кызматка кошууга болот. Сиз мисалды көрө аласыз .
Учурда Netraда сервистерге капталдарды автоматтык түрдө киргизүү мүмкүнчүлүгү жок, бирок ишке ашыруу пландары бар.
Netramesh келечеги
Негизги максат минималдуу ресурстук чыгымдарга жана кызматтар аралык байланышты көзөмөлдөө жана көзөмөлдөө үчүн негизги мүмкүнчүлүктөрдү камсыз кылуу менен жогорку көрсөткүчтөргө жетишүү болуп саналат.
Келечекте Netramesh HTTP'ден башка тиркеме катмарынын протоколдорун колдойт. L7 багыттоо жакынкы келечекте жеткиликтүү болот.
Ушул сыяктуу көйгөйлөргө туш болсоңуз, Netrameshти колдонуңуз жана суроолоруңуз жана сунуштарыңыз менен бизге жазыңыз.
Source: www.habr.com