Бид цул хэрэглээнээс микро үйлчилгээний архитектур руу шилжих үед шинэ сорилтуудтай тулгардаг.

Цул програмын хувьд системийн аль хэсэгт алдаа гарсан болохыг тодорхойлоход хялбар байдаг. Асуудал нь монолитийн код эсвэл мэдээллийн санд байгаа байх. Гэхдээ бид микро үйлчилгээний архитектурт асуудал хайж эхлэхэд бүх зүйл тийм ч тодорхой байхаа больсон. Бид хүсэлтийг эхнээс нь дуустал бүх замыг олж, олон зуун микро үйлчилгээнүүдээс сонгох хэрэгтэй. Түүгээр ч зогсохгүй тэдгээрийн олонх нь өөрийн гэсэн хадгалах байгууламжтай бөгөөд энэ нь логик алдаа, гүйцэтгэл, алдааг тэсвэрлэх чадвар зэрэг асуудлуудыг үүсгэдэг.

Би ийм асуудлыг даван туулахад туслах хэрэгслийг удаан хугацаанд хайж байсан (би энэ талаар Хабре дээр бичсэн: 1, 2), гэхдээ эцэст нь би өөрийн нээлттэй эхийн шийдлийг хийсэн. Энэ нийтлэлд би үйлчилгээний тор аргын ашиг тусын талаар ярьж, түүнийг хэрэгжүүлэх шинэ хэрэгслийг хуваалцах болно.

Тархсан систем дэх алдааг олж илрүүлэх нийтлэг шийдэл бол тархсан мөшгих юм. Сүлжээний харилцан үйлчлэлийн талаарх мэдээлэл цуглуулах энэ арга нь системд хараахан хэрэгжээгүй, эсвэл бүр муугаар бодоход системийн зарим хэсэг нь аль хэдийн хэвийн ажиллаж байгаа боловч зарим талаараа хуучин үйлчилгээнүүдэд нэмж оруулаагүй байгаа бол яах вэ? ? Асуудлын үндсэн шалтгааныг тодорхойлохын тулд системд юу болж байгааг бүрэн дүрсэлсэн байх шаардлагатай. Бизнесийн чухал замуудад аль бичил үйлчилгээ оролцож байгааг ойлгох нь ялангуяа чухал юм.

Сүлжээний мэдээллийг цуглуулах бүх машиныг үйлчилгээнээсээ доогуур түвшинд хариуцах үйлчилгээний сүлжээний арга нь бидэнд туслах болно. Энэ арга нь бүх урсгалыг таслан зогсоож, шууд дүн шинжилгээ хийх боломжийг олгодог. Түүнээс гадна, програмууд энэ талаар юу ч мэддэг байх албагүй.

Үйлчилгээний тор хандлага

Үйлчилгээний сүлжээний аргын гол санаа нь сүлжээн дээр дэд бүтцийн өөр давхаргыг нэмэх явдал бөгөөд энэ нь үйлчилгээ хоорондын харилцан үйлчлэлээр ямар ч зүйлийг хийх боломжийг бидэнд олгоно. Ихэнх хэрэгжүүлэлт нь дараах байдлаар ажилладаг: микро үйлчилгээ бүрт ил тод прокси бүхий нэмэлт хажуугийн савыг нэмж, үйлчилгээний бүх орж ирж буй урсгалыг дамжуулдаг. Энэ бол үйлчлүүлэгчийн тэнцвэрийг хангах, аюулгүй байдлын бодлогыг хэрэгжүүлэх, хүсэлтийн тоонд хязгаарлалт тавих, үйлдвэрлэл дэх үйлчилгээний харилцан үйлчлэлийн талаар чухал мэдээлэл цуглуулах боломжтой газар юм.

Шийдэл

Энэ аргын хэд хэдэн хэрэгжилт аль хэдийн бий: Истио и холбогч2. Тэд хайрцгаас гадна маш олон боломжуудыг өгдөг. Гэхдээ үүнтэй зэрэгцэн нөөцөд ихээхэн ачаалал ирдэг. Түүнчлэн, ийм систем ажиллаж буй кластер том байх тусам шинэ дэд бүтцийг хадгалахад илүү их нөөц шаардлагатай болно. Avito-д бид мянга мянган үйлчилгээний жишээг агуулсан kubernetes кластеруудыг ажиллуулдаг (мөн тэдний тоо хурдацтай өссөөр байна). Одоогийн байдлаар Istio нь үйлчилгээний тохиолдол бүрт ~300Mb RAM зарцуулдаг. Олон тооны боломжуудаас шалтгаалан ил тод тэнцвэржүүлэлт нь үйлчилгээний хариу өгөх нийт хугацаанд (10 мс хүртэл) нөлөөлдөг.

Үүний үр дүнд бид яг одоо бидэнд ямар чадвар хэрэгтэй байгааг судалж үзээд ийм шийдлүүдийг хэрэгжүүлж эхэлсэн гол шалтгаан нь бүхэл бүтэн системээс мөшгих мэдээллийг ил тод цуглуулах чадвар гэж шийдсэн. Мөн бид үйлчилгээний харилцан үйлчлэлд хяналт тавьж, үйлчилгээний хооронд дамждаг толгойнуудтай янз бүрийн залруулга хийхийг хүссэн.

Үүний үр дүнд бид дараахь шийдвэрт хүрсэн.  Нетрамеш.

Нетрамеш

Нетрамеш нь систем дэх үйлчилгээний тооноос үл хамааран хязгааргүй масштаблах чадвартай, хөнгөн үйлчилгээний тор шийдэл юм.

Шинэ шийдлийн гол зорилго нь нөөц багатай, өндөр гүйцэтгэлтэй байсан. Гол онцлогуудын дотроос бид Jaeger систем рүү мөшгих зайг ил тод илгээхийг тэр даруй хүссэн.

Өнөөдөр ихэнх үүлний шийдлүүд Голанг хотод хэрэгжиж байна. Мэдээжийн хэрэг, үүнд шалтгаан бий. Голанг хэл дээр оролт/гаралттай асинхроноор ажилладаг сүлжээний программуудыг бичих, шаардлагатай бол цөмд масштаблах нь тохиромжтой бөгөөд маш энгийн. Мөн хамгийн чухал зүйл бол гүйцэтгэл нь энэ асуудлыг шийдвэрлэхэд хангалттай юм. Тийм учраас бид ч бас Голанг сонгосон.

Бүтээмж

Бид хамгийн их бүтээмжид хүрэхийн тулд хүчин чармайлтаа төвлөрүүлсэн. Үйлчилгээний тохиолдол бүрийн хажууд байрлуулсан шийдлийн хувьд RAM болон CPU-ийн бага хэмжээний зарцуулалт шаардлагатай. Мэдээжийн хэрэг, хариу өгөх саатал бас бага байх ёстой.

Ямар үр дүнд хүрснийг харцгаая.

RAM

Netramesh нь трафикгүйгээр ~10Mb, нэг тохиолдол бүрт 50 RPS хүртэл ачаалалтай үед хамгийн ихдээ 10000Mb зарцуулдаг.

Istio элч прокси нь мянга мянган тохиолдол бүхий манай кластеруудад үргэлж ~300Mb зарцуулдаг. Энэ нь бүхэл бүтэн кластерт масштабтай байхыг зөвшөөрдөггүй.

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 нь анхны очих газартай холбоо тогтооно. Зангилаа дээрх pod IP дээрх NAT нь netra байхгүйтэй яг ижил хэвээр байна.

Тархсан мөрдөх болон контекст дамжуулалт

Netramesh нь HTTP харилцан үйлчлэлийн талаарх мөрийн зайг илгээхэд шаардлагатай функцээр хангадаг. Netra-sidecar нь HTTP протоколыг задлан шинжилж, хүсэлтийн саатлыг хэмжиж, HTTP толгой хэсгээс шаардлагатай мэдээллийг гаргаж авдаг. Эцсийн эцэст бид бүх ул мөрийг нэг Jaeger системээс олж авдаг. Нарийвчилсан тохиргооны хувьд та албан ёсны номын сангаас өгсөн орчны хувьсагчдыг ашиглаж болно jaeger go номын сан.

Гэхдээ асуудал байна. Үйлчилгээнүүд тусгай uber толгойг үүсгэж, илгээх хүртэл бид системд холбогдсон мөрийг харахгүй. Энэ бол асуудлын шалтгааныг хурдан олохын тулд бидэнд хэрэгтэй зүйл юм. Энд дахин Netramesh шийдэл байна. Прокси нь HTTP толгойг уншиж, хэрэв тэдгээр нь uber trace id-г агуулаагүй бол нэгийг үүсгэнэ. Мөн 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 нь урсгалыг таслан зогсоох сүлжээний дүрмийг тогтоодог. Тэр ашигладаг iptables дахин чиглүүлэх дүрэм 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-д маш их хэмжээний мөшгих мэдээлэл хүлээн авсны дараа би систем дэх харилцан үйлчлэлийн бүрэн графикийг авахыг хүсч байна. Гэхдээ хэрэв таны систем ачаалал ихтэй бөгөөд өдөрт хэдэн тэрбум мөрийн зай хуримтлагддаг бол тэдгээрийг нэгтгэх нь тийм ч амар ажил биш болно. Үүнийг хийх албан ёсны арга бий: оч хамаарал. Гэсэн хэдий ч бүрэн графикийг бүтээхэд хэдэн цаг шаардагдах бөгөөд сүүлийн XNUMX цагийн турш Jaeger-ээс бүх мэдээллийн багцыг татаж авах шаардлагатай болно.

Хэрэв та мөрийн зайг хадгалахын тулд Elasticsearch ашиглаж байгаа бол ашиглаж болно энгийн Голанг хэрэгсэл, энэ нь Elasticsearch-ийн онцлог, боломжуудыг ашиглан хэдэн минутын дотор ижил графикийг бүтээх болно.

Netramesh-ийг хэрхэн ашиглах вэ

Netra-г ямар ч оркестр ажиллуулж байгаа ямар ч үйлчилгээнд хялбархан нэмж болно. Та жишээг харж болно энд.

Одоогийн байдлаар Нетра үйлчилгээнд хажуугийн машиныг автоматаар нэвтрүүлэх чадваргүй байгаа ч хэрэгжүүлэх төлөвлөгөө бий.

Нетрамешийн ирээдүй

гол зорилго Нетрамеш Үйлчилгээ хоорондын харилцааг ажиглах, хянах үндсэн чадамжийг хангах, нөөцийн хамгийн бага зардал, өндөр гүйцэтгэлд хүрэх явдал юм.

Ирээдүйд Netramesh нь HTTP-ээс гадна бусад хэрэглээний түвшний протоколуудыг дэмжих болно. L7 чиглүүлэлт ойрын ирээдүйд бэлэн болно.

Хэрэв танд үүнтэй төстэй асуудал тулгарвал Netramesh-ийг ашиглаад асуулт, саналаа бидэнд бичээрэй.

Эх сурвалж: www.habr.com