لکه څنګه چې موږ د یو واحد غوښتنلیک څخه د مایکرو خدماتو جوړښت ته حرکت کوو، موږ له نویو ننګونو سره مخ یو.
په یو واحد غوښتنلیک کې، دا معمولا خورا اسانه وي چې معلومه کړي چې د سیسټم کومه برخه کې تېروتنه رامنځته شوې. ډیری احتمال، ستونزه پخپله د مونولیت کوډ کې ده، یا په ډیټابیس کې. مګر کله چې موږ د مایکرو سرویس معمارۍ کې د ستونزې په لټه کې شو ، نو هرڅه نور دومره څرګند ندي. موږ اړتیا لرو هغه ټوله لاره ومومئ چې غوښتنه یې له پیل څخه پای ته رسیدلې او د سلګونو مایکرو خدماتو څخه یې غوره کړه. سربیره پردې ، ډیری یې د دوی د ذخیره کولو اسانتیاوې هم لري ، کوم چې د منطقي غلطیو لامل کیدی شي ، په بیله بیا د فعالیت او غلطۍ زغم سره ستونزې.
زه د اوږدې مودې لپاره د یوې وسیلې په لټه کې وم چې د داسې ستونزو سره مقابله کې مرسته وکړي (ما پدې اړه په هابري کې لیکلي: , )، مګر په پای کې ما خپل د خلاصې سرچینې حل جوړ کړ. پدې مقاله کې زه د خدماتو میش چلند ګټو په اړه وغږیږم او د دې پلي کولو لپاره نوې وسیله شریکوم.
توزیع شوي تعقیب په توزیع شوي سیسټمونو کې د غلطیو موندلو ستونزې لپاره یو عام حل دی. مګر که څه هم د شبکې تعاملاتو په اړه د معلوماتو راټولولو لپاره دا طریقه لاهم په سیسټم کې نه ده پلي شوې، یا بدتر، د سیسټم په یوه برخه کې دا دمخه په سمه توګه کار کوي، مګر په یوه برخه کې دا نه کوي، ځکه چې دا په پخوانیو خدماتو کې ندي اضافه شوي. ؟ د دې لپاره چې د ستونزې اصلي لامل معلوم شي، دا اړینه ده چې په سیسټم کې څه پیښیږي بشپړ انځور ولرئ. دا په ځانګړې توګه مهمه ده چې پوه شي چې کوم کوچني خدمتونه د سوداګرۍ په مهمو لارو کې دخیل دي.
دلته د خدماتو میش چلند زموږ مرستې ته رسیدلی شي ، کوم چې به د شبکې معلوماتو راټولولو لپاره د ټولو ماشینونو سره معامله وکړي د خدماتو په پرتله په ټیټه کچه. دا طریقه موږ ته اجازه راکوي چې ټول ټرافیک ودروو او په الوتنه کې یې تحلیل کړو. سربیره پردې ، غوښتنلیکونه حتی د دې په اړه هیڅ نه پوهیږي.
د خدمت میش طریقه
د خدماتو میش چلند اصلي نظر په شبکه کې د زیربنا بل پرت اضافه کول دي ، کوم چې موږ ته اجازه راکوي چې د خدماتو متقابل عمل سره کوم شی ترسره کړو. ډیری پلي کول په لاندې ډول کار کوي: د شفاف پراکسي سره اضافي سایډ کار کانټینر په هر مایکرو خدمت کې اضافه کیږي ، د کوم له لارې چې د خدماتو ټول راتلونکی او بهر روان ترافیک تیریږي. او دا هغه ځای دی چیرې چې موږ کولی شو د پیرودونکي توازن ترسره کړو ، امنیتي پالیسۍ پلي کړو ، د غوښتنو شمیر باندې محدودیتونه وضع کړو او په تولید کې د خدماتو متقابل عمل مهم معلومات راټول کړو.
حلونه
د دې طریقې ډیری پلي کول لا دمخه شتون لري: и . دوی د بکس څخه بهر ډیری ځانګړتیاوې وړاندې کوي. مګر په ورته وخت کې، د سرچینو په اړه لوی سر راځي. سربیره پردې، هر څومره لوی کلستر په کوم کې چې دا ډول سیسټم کار کوي، د نوي زیربنا ساتلو لپاره به ډیرو سرچینو ته اړتیا وي. په Avito کې، موږ د kubernetes کلسترونه کاروو چې د زرګونو خدماتو مثالونه لري (او د دوی شمیر په چټکۍ سره وده کوي). په خپل اوسني تطبیق کې، اسټیو د هر خدمت مثال ~ 300Mb RAM مصرفوي. د ډیرو امکاناتو له امله، شفاف توازن هم د خدماتو ټول غبرګون وخت (تر 10ms پورې) اغیزه کوي.
د پایلې په توګه، موږ په سمه توګه وګورو چې موږ همدا اوس کومو وړتیاوو ته اړتیا لرو، او پریکړه یې وکړه چې اصلي دلیل چې ولې موږ د داسې حلونو پلي کول پیل کړل د ټول سیسټم څخه په شفاف ډول د تعقیب معلوماتو راټولولو وړتیا وه. موږ دا هم غوښتل چې د خدماتو تعامل کنټرول ولرو او د سرلیکونو سره مختلف لاسوهنې ترسره کړو چې د خدماتو ترمینځ لیږدول کیږي.
د پایلې په توګه، موږ خپلې پریکړې ته ورسیدو: .
نیترمیش
د لږ وزن خدمت میش حل دی چې په سیسټم کې د خدماتو شمیر په پام کې نیولو پرته ، په لامحدود اندازه کولو وړتیا سره.
د نوي حل اصلي اهداف د سرچینو ټیټ سر او لوړ فعالیت و. د اصلي ځانګړتیاو په مینځ کې، موږ سمدلاسه غوښتل چې وکوالی شو په شفاف ډول زموږ د جیجر سیسټم ته د تعقیب سپانونه واستوو.
نن ورځ، ډیری بادل حلونه په ګولنګ کې پلي کیږي. او البته، د دې لپاره دلیلونه شتون لري. په ګولنګ کې د شبکې غوښتنلیکونه لیکل چې د I/O سره په غیر متناسب ډول کار کوي او د اړتیا سره سم په کور کې اندازه کول اسانه او خورا ساده دي. او، هغه څه چې خورا مهم دي، فعالیت د دې ستونزې د حل لپاره کافي دی. له همدې امله موږ هم ګولنګ غوره کړ.
محصولات
موږ خپلې هڅې د اعظمي تولید ترلاسه کولو باندې متمرکزې کړې. د حل لپاره چې د خدماتو هرې بیلګې سره ځای پرځای شوي، د RAM او CPU وخت لږ مصرف ته اړتیا ده. او البته، د ځواب ځنډ باید هم کوچنی وي.
راځئ وګورو چې موږ کومې پایلې ترلاسه کړې.
مؤقتي حافظه
نیټرمیش ~ 10Mb پرته له ترافیک مصرفوي او په هر مثال کې تر 50 RPS پورې بار سره 10000Mb اعظمي مصرف کوي.
Istio envoy proxy تل زموږ په کلسترونو کې د زرګونو مثالونو سره ~ 300Mb مصرفوي. دا اجازه نه ورکوي چې ټول کلستر ته اندازه شي.
د نیټرمیش سره موږ د حافظې مصرف کې ~ 10x کمښت ترلاسه کړ.
سی پی یو
د CPU کارول د بار لاندې نسبتا مساوي دي. دا د سایډ کار ته د وخت په هر واحد کې د غوښتنو شمیر پورې اړه لري. په هر ثانیه کې د 3000 غوښتنو ارزښت په لوړ حالت کې:
یو بل مهم ټکی شتون لري: نیترمیش - د کنټرول الوتکې پرته حل او پرته له بار څخه د CPU وخت نه مصرفوي. د اسټیو سره ، سایډ کار تل د خدماتو پای ټکي تازه کوي. د پایلې په توګه، موږ کولی شو دا انځور د بار پرته وګورو:
موږ د خدماتو ترمنځ د اړیکو لپاره HTTP/1 کاروو. د اسټیو لپاره د غبرګون وخت زیاتوالی کله چې د استازي له لارې پراکسي کول تر 5-10ms پورې و، کوم چې د خدماتو لپاره خورا ډیر دی چې په ملی ثانیه کې ځواب ویلو ته چمتو دي. د نیټرمیش سره دا وخت 0.5-2ms ته راټیټ شوی.
د توزیع وړتیا
د هرې پراکسي لخوا مصرف شوي لږې سرچینې دا امکان ورکوي چې دا د هر خدمت سره نږدې ځای په ځای کړي. نیټرمیش په قصدي ډول د کنټرول الوتکې برخې پرته رامینځته شوی ترڅو په ساده ډول د هر سایډ کار لږ وزن وساتي. ډیری وختونه د خدماتو میش حلونو کې ، د کنټرول الوتکه هر سایډ کار ته د خدماتو کشف معلومات توزیع کوي. د دې سره د مهال ویش او توازن تنظیماتو په اړه معلومات راځي. دا ټول تاسو ته اجازه درکوي چې ډیری ګټور شیان ترسره کړئ، مګر، له بده مرغه، دا په اندازې کې د سایډ کارونه غوړوي.
د خدماتو کشف
نیټرمیش د خدماتو کشف لپاره کوم اضافي میکانیزم نه اضافه کوي. ټول ټرافیک په شفاف ډول د نیټرا سایډ کار له لارې تیریږي.
نیټرمیش د HTTP/1 غوښتنلیک پروتوکول ملاتړ کوي. د دې تعریف کولو لپاره ، د بندرونو ترتیب کیدونکی لیست کارول کیږي. عموما، سیسټم ډیری بندرونه لري چې له لارې یې د HTTP ارتباط واقع کیږي. د مثال په توګه، موږ د خدماتو او بهرنیو غوښتنو ترمنځ د تعامل لپاره 80, 8890, 8080 کاروو. پدې حالت کې، دوی د چاپیریال متغیر په کارولو سره تنظیم کیدی شي. NETRA_HTTP_PORTS.
که تاسو Kubernetes د یو آرکیسټرټر په توګه کاروئ او د خدماتو تر مینځ د انټرا کلستر اړیکو لپاره د دې خدماتو ادارې میکانیزم، نو بیا میکانیزم بالکل ورته پاتې کیږي. لومړی، مایکروسافټ د kube-dns په کارولو سره د خدماتو IP پته ترلاسه کوي او دې ته نوې اړیکه پرانیزي. دا اړیکه لومړی د محلي نیټرا سایډ کار سره رامینځته شوې او ټول TCP پاکټونه په پیل کې نیترا ته رسیږي. بیا، نیټرا سایډکار د اصلي منزل سره اړیکه رامینځته کوي. په نوډ کې د پوډ IP پر NAT بالکل د نیټرا پرته ورته پاتې کیږي.
توزیع شوي تعقیب او د شرایطو لیږل
نیټرمیش د HTTP تعاملاتو په اړه د تعقیب سپانونو لیږلو لپاره اړین فعالیت چمتو کوي. Netra-sidecar د HTTP پروتوکول پارس کوي، د ځنډ غوښتنه کوي، او د HTTP سرلیکونو څخه اړین معلومات استخراج کوي. په نهایت کې ، موږ ټول نښې په یو واحد جیجر سیسټم کې ترلاسه کوو. د ښه دانې ترتیب لپاره، تاسو کولی شئ د چاپیریال متغیرات هم وکاروئ چې د رسمي کتابتون لخوا چمتو شوي .
خو یوه ستونزه شته. تر هغه چې خدمتونه یو ځانګړی اوبر سرلیک تولید او واستوي، موږ به په سیسټم کې د تړل شوي تعقیب سپانونه ونه ګورو. او دا هغه څه دي چې موږ باید ژر تر ژره د ستونزو لامل ومومو. دلته بیا نیترمیش یو حل لري. پراکسي د HTTP سرلیکونه لولي او که چیرې دوی د uber ټریس ID نه لري، یو تولیدوي. نیټرمیش د راتلونکو او وتلو غوښتنو په اړه معلومات هم په سایډ کار کې ذخیره کوي او د اړتیا وړ بهر وتلو غوښتنې سرلیکونو سره بډایه کولو سره دوی سره سمون لري. ټول هغه څه چې تاسو یې په خدماتو کې کولو ته اړتیا لرئ یوازې یو سرلیک لیږل دي X-Request-Id، کوم چې د چاپیریال متغیر په کارولو سره تنظیم کیدی شي NETRA_HTTP_REQUEST_ID_HEADER_NAME. په نیټرمیش کې د شرایطو اندازه کنټرولولو لپاره ، تاسو کولی شئ لاندې چاپیریال تغیرات تنظیم کړئ: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (هغه وخت چې شرایط به زیرمه شي) او NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (د شرایطو پاکولو فریکونسی).
دا هم امکان لري چې ستاسو په سیسټم کې ډیری لارې د ځانګړي ناستې نښه کولو سره په نښه کولو سره یوځای کړئ. نیټرا تاسو ته اجازه درکوي نصب کړئ HTTP_HEADER_TAG_MAP د HTTP سرلیکونه په اړونده ټریسینګ سپان ټګونو بدلولو لپاره. دا په ځانګړي ډول د ازموینې لپاره ګټور کیدی شي. د فعال ازموینې پاس کولو وروسته، تاسو کولی شئ وګورئ چې د سیسټم کومه برخه د اړونده سیشن کیلي لخوا د فلټر کولو لخوا اغیزمنه شوې وه.
د غوښتنې سرچینې معلومول
د دې معلومولو لپاره چې غوښتنه له کوم ځای څخه راغلې، تاسو کولی شئ د سرچینې سره په اتوماتيک ډول د سرلیک اضافه کولو فعالیت وکاروئ. د چاپیریال متغیر کارول NETRA_HTTP_X_SOURCE_HEADER_NAME تاسو کولی شئ د سرلیک نوم مشخص کړئ چې په اتوماتيک ډول به نصب شي. په کارولو NETRA_HTTP_X_SOURCE_VALUE تاسو کولی شئ هغه ارزښت وټاکئ چې د ایکس سرچینې سرلیک به د ټولو وتلو غوښتنو لپاره تنظیم شي.
دا د دې ګټور سرلیک ویش ته اجازه ورکوي چې په ټوله شبکه کې په مساوي ډول توزیع شي. بیا تاسو کولی شئ دا په خدماتو کې وکاروئ او په لاګونو او میټریکونو کې یې اضافه کړئ.
د ټرافیکو لار او د نیټرمیش داخلي
Netramesh له دوو مهمو برخو څخه جوړه ده. لومړی، netra-init، د ټرافیک د مخنیوي لپاره د شبکې قواعد ټاکي. هغه کاروي په سایډ کار کې د ټرافیک ټول یا یوه برخه مداخله کول، کوم چې د نیترمیش دویمه اصلي برخه ده. تاسو کولی شئ تنظیم کړئ چې کوم بندرونه باید د راتلونکو او وتلو TCP غونډو لپاره مداخله وکړي: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
وسیله هم یو په زړه پوری ځانګړتیا لري - احتمالي روټینګ. که تاسو په ځانګړي ډول د ټریسنګ سپانونو راټولولو لپاره نیټرمیش کاروئ ، نو د تولید چاپیریال کې تاسو کولی شئ سرچینې خوندي کړئ او د متغیرونو په کارولو سره احتمالي روټینګ فعال کړئ NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (له 0 څخه تر 1 پورې). ډیفالټ ارزښت 1 دی (ټول ترافیک مداخله کیږي).
د بریالۍ مداخلې وروسته، نیټرا سایډ کار نوې اړیکه مني او کاروي SO_ORIGINAL_DST د اصلي منزل ترلاسه کولو لپاره ساکټ اختیار. نیټرا بیا د اصلي IP پتې سره نوې اړیکه پرانیزي او د اړخونو ترمینځ دوه طرفه TCP اړیکه رامینځته کوي ، ټول ټرافیک ته غوږ نیسي. که پورټ د HTTP په توګه تعریف شوی وي، نیترا هڅه کوي چې تحلیل او تعقیب کړي. که چیرې د HTTP تحلیل ناکام شي، نیترا بیرته TCP ته راځي او په شفاف ډول بایټونه پراکسي کوي.
د انحصار ګراف جوړول
په جیجر کې د لوی مقدار تعقیب معلوماتو ترلاسه کولو وروسته ، زه غواړم په سیسټم کې د متقابل عمل بشپړ ګراف ترلاسه کړم. مګر که ستاسو سیسټم خورا بار شوی وي او هره ورځ ملیاردونه ټریسینګ سپانونه راټولیږي ، د دوی راټولول دومره اسانه کار ندی. د دې کولو لپاره رسمي لاره شتون لري: . په هرصورت، دا به د بشپړ ګراف جوړولو لپاره ساعتونه ونیسي او تاسو به مجبور کړي چې د جیجر څخه د تیرو XNUMX ساعتونو لپاره ټول ډیټاسیټ ډاونلوډ کړئ.
که تاسو د ټریسینګ سپانونو ذخیره کولو لپاره Elasticsearch کاروئ ، تاسو یې کارولی شئ ، کوم چې به د Elasticsearch ځانګړتیاو او وړتیاو په کارولو سره په دقیقو کې ورته ګراف رامینځته کړي.
د نیټرمیش کارولو څرنګوالی
نیټرا په اسانۍ سره هر هغه خدمت کې اضافه کیدی شي چې کوم آرکیسټرټر چلوي. تاسو کولی شئ یو مثال وګورئ .
په اوس وخت کې، نیټرا د دې وړتیا نلري چې په اتوماتيک ډول خدماتو ته سایډ کارونه پلي کړي، مګر د پلي کولو لپاره پالنونه شتون لري.
د نیترمیش راتلونکی
اصلي هدف د منابعو لږ تر لږه لګښتونه او لوړ فعالیت ترالسه کول دي، د څارنې او د بین خدمت اړیکو کنټرول لپاره اساسي وړتیاوې چمتو کوي.
په راتلونکي کې، نیټرمیش به د HTTP سربیره د نورو غوښتنلیک پرت پروتوکولونو ملاتړ وکړي. L7 روټینګ به په نږدې راتلونکي کې شتون ولري.
د نیټرمیش څخه کار واخلئ که تاسو ورته ستونزې سره مخ شئ او موږ ته د پوښتنو او وړاندیزونو سره ولیکئ.
سرچینه: www.habr.com