په انټرنیټ کې (د خدمت میش)، او دلته یو بل دی. هورې! اخر ولې؟ بیا ، زه غواړم خپل نظر څرګند کړم چې دا به غوره وي که چیرې د خدماتو میشونه 10 کاله دمخه څرګند شوي وي ، مخکې لدې چې د کانټینر پلیټ فارمونو لکه ډاکر او کوبرنیټس راڅرګند شي. زه دا نه وایم چې زما نظر د نورو په پرتله ښه یا بد دی، مګر دا چې د خدماتو میشونه خورا پیچلي حیوانات دي، د لید ډیری نقطې به د دوی په ښه پوهیدو کې مرسته وکړي.
زه به د ډاټ کلاډ پلیټ فارم په اړه وغږیږم ، کوم چې له سلو څخه ډیر مایکرو خدماتو کې رامینځته شوی او د زرګونو کانټینر شوي غوښتنلیکونو ملاتړ کوي. زه به هغه ننګونې تشریح کړم چې موږ یې په پراختیا او پیل کولو کې ورسره مخ یو، او د خدماتو میشونه څنګه مرسته کولی شي (یا نشي کولی).
د dotCloud تاریخ
ما د ډاټ کلاډ تاریخ او د دې پلیټ فارم لپاره د جوړښت انتخابونو په اړه لیکلي دي ، مګر ما د شبکې پرت په اړه ډیرې خبرې نه دي کړي. که تاسو نه غواړئ په لوستلو کې ډوب شئ د ډاټ کلاډ په اړه، دلته په لنډه توګه لنډیز دی: دا د PaaS پلیټ فارم - د خدمت په توګه دی چې پیرودونکو ته اجازه ورکوي چې د ډیټا پراخه لړۍ ملاتړ سره ډیری غوښتنلیکونه (جاوا، پی ایچ پی، پایتون ...) پرمخ بوځي. خدمات (MongoDB، MySQL، Redis...) او د کار فلو لکه هیروکو: تاسو خپل کوډ پلیټ فارم ته اپلوډ کړئ، دا د کانټینر عکسونه جوړوي او ځای پرځای کوي.
زه به تاسو ته ووایم چې څنګه ټرافيک د ډاټ کلاډ پلیټ فارم ته لارښود شوی و. نه دا چې دا په ځانګړي ډول ښه و (که څه هم سیسټم د خپل وخت لپاره ښه کار کاوه!)، مګر په اصل کې د دې لپاره چې د عصري وسیلو سره دا ډول ډیزاین په اسانۍ سره د یو معتدل ټیم لخوا په لنډ وخت کې پلي کیدی شي که دوی د یوې ډلې تر منځ د ټرافیک د لیږد لپاره یوې لارې ته اړتیا ولري. د مایکرو خدماتو یا غوښتنلیکونو یوه ډله. پدې توګه ، تاسو کولی شئ اختیارونه پرتله کړئ: څه پیښیږي که تاسو هرڅه پخپله رامینځته کړئ یا د موجوده خدمت میش وکاروئ. معیاري انتخاب دا دی چې دا پخپله جوړ کړئ یا یې واخلئ.
د کوربه شوي غوښتنلیکونو لپاره د ټرافیک لاره
په ډاټ کلاډ کې غوښتنلیکونه کولی شي د HTTP او TCP پای ټکي افشا کړي.
د HTTP پای ټکي په متحرک ډول د بار بیلانس کلستر ترتیب کې اضافه شوی . دا د هغه څه سره ورته دی چې سرچینې نن ورځ ترسره کوي په Kubernetes او د بار بیلانس په څیر .
پیرودونکي د مناسبو ډومینونو له لارې د HTTP پای نقطو سره وصل کیږي، په دې شرط چې د ډومین نوم د ډاټ کلاډ بار بیلانسرز ته اشاره وکړي. هیڅ ځانګړی نه دی.
د TCP پای ټکي د پورټ نمبر سره تړاو لري، کوم چې بیا د چاپیریال متغیرونو له لارې په دې سټیک کې ټولو کانټینرونو ته لیږدول کیږي.
پیرودونکي کولی شي د مناسب کوربه نوم په کارولو سره د TCP پای ټکي سره وصل شي (یو څه لکه gateway-X.dotcloud.com) او د پورټ نمبر.
دا کوربه نوم د "ناټس" سرور کلستر ته حل کوي (په دې پورې اړه نلري )، کوم چې به سم کانټینر ته راتلونکي TCP پیوستونونه لیږدوي (یا، د بار متوازن خدماتو په صورت کې، سم کانټینر ته).
که تاسو د Kubernetes سره آشنا یاست، نو دا به تاسو ته د خدماتو یادونه وکړي .
په ډاټ کلاډ پلیټ فارم کې هیڅ مساوي خدمات شتون نلري : د سادګۍ لپاره، خدماتو ته د پلیټ فارم دننه او بهر دواړه په ورته ډول لاسرسی موندلی شو.
هرڅه په ساده ډول تنظیم شوي وو: د HTTP او TCP روټینګ شبکو لومړني پلي کول شاید د Python هر یو څو سوه لینونه وي. ساده (زه به یې ووایم) الګوریتمونه چې د پلیټ فارم وده او اضافي اړتیاوې څرګندیدو سره سم تنظیم شوي.
د موجوده کوډ پراخه بیاکتنې ته اړتیا نه وه. په تېره بیا، کولی شي مستقیم د چاپیریال تغیراتو له لارې ترلاسه شوي پته وکاروي.
دا څنګه د عصري خدماتو میش څخه توپیر لري؟
محدود لید. موږ د TCP روټینګ میش لپاره هیڅ میټریک نه درلود. کله چې دا د HTTP روټینګ ته راځي ، وروسته نسخو د غلطو کوډونو او ځواب وختونو سره تفصيلي HTTP میټریکونه معرفي کړل ، مګر د عصري خدماتو میشونه نور هم پرمخ ځي ، د مثال په توګه د پرومیټیوس په څیر د میټریک راټولولو سیسټمونو سره ادغام چمتو کوي.
لید نه یوازې د عملیاتي لید څخه مهم دی (د مسلو حل کولو کې مرسته کولو لپاره) ، بلکه د نوي ب featuresو خپرولو پرمهال هم. دا د خوندي په اړه ده и .
د روټینګ موثریت هم محدود دی. د ډاټ کلاډ روټینګ میش کې ، ټول ترافیک باید د وقف شوي روټینګ نوډونو کلستر څخه تیر شي. د دې معنی دا وه چې په احتمالي توګه د ډیری AZ (د شتون زون) حدود تیریدل او د پام وړ ځنډ ډیرول. زه د ستونزو حل کولو کوډ په یاد لرم چې په هره پاڼه کې له سلو څخه ډیر SQL پوښتنې رامینځته کوي او د هرې پوښتنې لپاره د SQL سرور سره نوې اړیکه پرانیزي. کله چې په محلي توګه چلول کیږي، پاڼه سمدلاسه پورته کیږي، مګر په ډاټ کلاډ کې دا یو څو ثانیې وخت نیسي ځکه چې د هر TCP پیوستون (او ورپسې د SQL پوښتنې) لسګونه ملیسیکنډونه نیسي. په دې ځانګړي حالت کې، دوامداره اړیکو ستونزه حل کړه.
د عصري خدماتو میشونه د داسې ستونزو سره معامله کولو کې غوره دي. تر ټولو لومړی، دوی ګوري چې اړیکې راټیټ شوي په سرچینه کې. منطقي جریان ورته دی: клиент → меш → сервис، مګر اوس میش په محلي توګه کار کوي نه په لیرې پرتو نوډونو کې، نو اړیکه клиент → меш ځایی او ډیر ګړندی دی (د ملی ثانیو پرځای مایکرو ثانیه).
د عصري خدماتو میشونه د هوښیار بار توازن الګوریتمونه هم پلي کوي. د بیکنډونو روغتیا څارلو سره، دوی کولی شي ګړندي بیکینډونو ته ډیر ترافیک واستوي ، چې پایله یې د عمومي فعالیت ښه کول دي.
امنیت هم ښه. د ډاټ کلاډ روټینګ میش په بشپړ ډول په EC2 کلاسیک کې روان و او ترافیک یې نه و کوډ کړی (د دې انګیرنې پراساس چې که یو څوک د EC2 شبکې ترافیک کې سنفیفر اداره کړي ، تاسو دمخه په لوی ستونزه کې یاست). د عصري خدماتو میشونه په شفاف ډول زموږ ټول ټرافیک ساتي، د بیلګې په توګه، د دوه اړخیز TLS تصدیق او ورپسې کوډ کولو سره.
د پلیټ فارم خدماتو لپاره د ټرافیک روټینګ
سمه ده، موږ د غوښتنلیکونو تر منځ د ټرافیک په اړه بحث کړی، مګر پخپله د ډاټ کلاډ پلیټ فارم په اړه څه دي؟
پخپله پلیټ فارم کې شاوخوا سل مایکرو خدمات شامل دي چې د مختلف دندو لپاره مسؤل دي. ځینې د نورو څخه غوښتنې منل شوي، او ځینې یې د شالید کارکونکي وو چې د نورو خدماتو سره وصل شوي مګر پخپله اړیکې نه مني. په هر حالت کې، هر خدمت باید د پتې پای ټکي وپیژني چې ورته اړتیا لري چې ورسره وصل شي.
ډیری لوړې کچې خدمتونه ممکن د روټینګ میش څخه کار واخلي چې پورته تشریح شوي. په حقیقت کې، د ډاټ کلاډ ډیری ډیری مایکرو خدمتونه د ډاټ کلاډ پلیټ فارم کې د منظم غوښتنلیکونو په توګه ګمارل شوي. مګر یو لږ شمیر د ټیټې کچې خدمتونه (په ځانګړي توګه هغه چې د دې روټینګ میش پلي کوي) یو څه ساده ته اړتیا لري ، د لږ انحصار سره (ځکه چې دوی نشي کولی د کار کولو لپاره په ځان تکیه وکړي - د ښه زوړ چرګ او هګۍ ستونزه).
دا د ټیټې کچې، ماموریت مهم خدمتونه په مستقیم ډول په څو کلیدي نوډونو کې د کانټینرونو په چلولو سره ځای پرځای شوي. پدې حالت کې، معیاري پلیټ فارم خدمتونه ندي کارول شوي: لینکر، مهالویش او رنر. که تاسو غواړئ د عصري کانټینر پلیټ فارمونو سره پرتله کړئ ، دا د کنټرول الوتکې چلولو په څیر دی docker run په مستقیم ډول په نوډونو کې، د دې پرځای چې دنده Kubernetes ته وسپارل شي. دا په مفهوم کې خورا ورته دی ، کوم چې دا کاروي او یا کله چې یو واحد کلستر بوټ کول.
دا خدمتونه په ساده او خام ډول افشا شوي: د YAML فایل د دوی نومونه او پتې لیست کړي؛ او هر پیرودونکی باید د ګمارنې لپاره د دې YAML فایل یوه کاپي واخلي.
له یوې خوا، دا خورا د باور وړ دی ځکه چې دا د بهرني کیلي / ارزښت پلورنځي ملاتړ ته اړتیا نلري لکه زوکیپر (په یاد ولرئ ، etcd یا قونسل په هغه وخت کې شتون نه درلود). له بلې خوا، دا د خدماتو حرکت کول ستونزمن کړي. هرکله چې یو حرکت ترسره شي، ټول پیرودونکي به د YAML تازه شوي فایل ترلاسه کړي (او احتمالي ریبوټ). ډیر آرام نه دی!
وروسته، موږ د نوي سکیم پلي کول پیل کړل، چیرته چې هر پیرودونکي د محلي پراکسي سرور سره وصل شوي. د پتې او بندر پرځای، دا یوازې اړتیا لري چې د خدماتو پورټ شمیره وپیژني، او له لارې وصل شي localhost. ځایی پراکسي دا اړیکه اداره کوي او اصلي سرور ته یې لیږي. اوس، کله چې بیک انډ بل ماشین ته یا اندازه کول، د ټولو مراجعینو د تازه کولو پر ځای، تاسو اړتیا لرئ چې دا ټول محلي پراکسي تازه کړئ؛ او بیا ریبوټ ته اړتیا نشته.
(دا هم پلان شوی و چې ترافیک په TLS اتصالونو کې ځای په ځای کړي او د ترلاسه کونکي اړخ کې بل پراکسي سرور ځای په ځای کړي ، په بیله بیا د ترلاسه کونکي خدمت له ګډون پرته د TLS سندونه تایید کړي ، کوم چې یوازې د اړیکو منلو لپاره ترتیب شوی. localhost. په دې اړه نور وروسته).
دا خورا ورته دی د Airbnb څخه، مګر د پام وړ توپیر دا دی چې SmartStack پلي کیږي او تولید ته ګمارل کیږي، پداسې حال کې چې د dotCloud داخلي روټینګ سیسټم خوندي شوی و کله چې dotCloud Docker شو.
زه په شخصي توګه د 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) لري.
- د نوي ب featuresو ملاتړ کوي لکه د سرکټ ماتول ، توزیع شوي تعقیب ، د کانري ځای په ځای کول ، او داسې نور.
راځئ چې ځینې توپیرونو ته یو ګړندۍ کتنه وکړو.
سفیر پراکسي
Envoy Proxy د ټیکسي بازار کې د لیفټ [Uber سیالي کونکي لخوا لیکل شوی و - نږدې. لین] دا په ډیری لارو کې نورو پراکسيونو ته ورته دی (د بیلګې په توګه HAProxy، Nginx، Traefik ...)، مګر لیفټ دوی لیکلي ځکه چې دوی داسې ځانګړتیاو ته اړتیا لري چې نور پراکسي نلري، او داسې ښکاري چې د موجوده پراخولو پر ځای یو نوی جوړ کړي.
انوان کولی شي په خپل ځان کې وکارول شي. که زه یو ځانګړی خدمت ولرم چې نورو خدماتو سره وصل کیدو ته اړتیا لري، زه کولی شم دا د سفیر سره وصل کولو لپاره تنظیم کړم، او بیا په متحرک ډول د نورو خدماتو موقعیت سره سفیر تنظیم او بیا تنظیم کړم، پداسې حال کې چې ډیر لوی اضافي فعالیت ترلاسه کول، لکه لید. د دې پرځای چې د دودیز پیرودونکي کتابتون یا کوډ ته د کال ټریس انجیک کړئ، موږ ټرافيک سفیر ته لیږو، او دا زموږ لپاره میټریکونه راټولوي.
مګر د سفیر په توګه د کار کولو وړتیا هم لري د معلوماتو الوتکه (د معلوماتو الوتکه) د خدمت میش لپاره. دا پدې مانا ده چې سفیر اوس د دې خدمت میش لپاره ترتیب شوی د کنټرول الوتکه (د کنټرول الوتکه).
د کنټرول الوتکه
د کنټرول الوتکې لپاره، اسټیو د Kubernetes API باندې تکیه کوي. دا د confd کارولو څخه ډیر توپیر نلري، کوم چې د ډیټا سټور کې د کیليونو سیټ لیدو لپاره په etcd یا قونسل تکیه کوي. Istio د Kubernetes د سرچینو سیټ لیدو لپاره د Kubernetes API کاروي.
د دې او بیا تر منځ: ما په شخصي توګه دا ګټور وموندل کوم چې لیکي:
د کوبرنیټس API سرور یو "ګونګ سرور" دی چې د API سرچینو لپاره ذخیره کول ، نسخه کول ، اعتبار کول ، تازه کول او سیمانټیک وړاندیز کوي.
Istio د Kubernetes سره کار کولو لپاره ډیزاین شوی؛ او که تاسو غواړئ دا د کوبرنیټس څخه بهر وکاروئ ، نو تاسو اړتیا لرئ د Kubernetes API سرور (او etcd مرستندویه خدمت) مثال چل کړئ.
د خدماتو پته
اسټیو د کلسټر IP پتې باندې تکیه کوي چې کوبرنیټس تخصیص کوي، نو د اسټیو خدمتونه داخلي پته ترلاسه کوي (په حد کې نه 127.0.0.0/8).
د Istio پرته د Kubernetes کلستر کې د ځانګړي خدمت لپاره د کلستر IP پتې ته ترافیک د کیوب پراکسي لخوا مداخله کیږي او د دې پراکسي شالید ته لیږل کیږي. که تاسو د تخنیکي توضیحاتو سره علاقه لرئ ، کیوب پراکسي د کلستر IP پتې ته د ارتباطاتو د منزل IP پتې بیا لیکلو لپاره د iptables قواعد (یا IPVS بار بیلنسرز ، د دې تنظیم کولو څرنګوالي پورې اړه لري) تنظیموي.
یوځل چې اسټیو په کوبرنیټس کلستر کې نصب شي ، هیڅ شی نه بدلیږي تر هغه چې دا د یو کانټینر په معرفي کولو سره د ورکړل شوي مصرف کونکي یا حتی ټول نوم ځای لپاره په واضح ډول فعال شوی نه وي. sidecar په دودیز پوډونو کې. دا کانټینر به د سفیر یوه بیلګه وګرځوي او د iptables مقرراتو یو سیټ رامینځته کړي ترڅو نورو خدماتو ته د ترافیک مخه ونیسي او هغه ټرافیک Envoy ته ولیږدوي.
کله چې د Kubernetes DNS سره مدغم شي، دا پدې مانا ده چې زموږ کوډ کولی شي د خدماتو نوم او هر څه سره وصل شي "یوازې کار کوي." په بل عبارت، زموږ کوډ د پوښتنو مسلې لکه http://api/v1/users/4242بیا api لپاره غوښتنه حل کړي 10.97.105.48، د iptables مقررات به د 10.97.105.48 څخه اړیکې مداخله وکړي او د ځایی استازي پراکسي ته یې واستوي ، او دا محلي پراکسي به غوښتنه ریښتیني پس منظر API ته واستوي. افف!
اضافي فریلونه
Istio د mTLS (متقابل TLS) له لارې د پای څخه تر پایه کوډ کول او تصدیق هم چمتو کوي. یوه برخه نومیږي د فراه تاريخي کلا.
یوه برخه هم شتون لري مخلوط، کوم چې سفیر کولی شي غوښتنه وکړي هر یو د دې غوښتنې په اړه د ځانګړي پریکړې کولو غوښتنه وکړئ د مختلف فاکتورونو پورې اړه لري لکه سرلیکونه ، د شالید بار ، او داسې نور ... ( اندیښنه مه کوئ: د مکسر د چلولو لپاره ډیری لارې شتون لري ، او حتی که دا غورځیږي ، نو سفیر به کار ته دوام ورکړي د پراکسي په توګه ښه).
او البته، موږ د لید لید یادونه وکړه: سفیر د توزیع شوي تعقیب چمتو کولو پرمهال د میټریک لوی مقدار راټولوي. د مایکرو سرویسس جوړښت کې، که چیرې د API یو واحد غوښتنه د مایکرو خدماتو A، B، C، او D څخه تیریږي، نو بیا د ننوتلو وروسته، ویشل شوي تعقیب به غوښتنې ته یو ځانګړی پیژندونکی اضافه کړي او دا پیژندونکی د دې ټولو مایکرو خدماتو ته د فرعي غوښتنو له لارې ذخیره کړي، اجازه ورکوي ټول اړوند زنګونه باید ونیول شي، ځنډ، او نور.
پراختیا او پیرود
اسټیو د پیچلي کیدو لپاره شهرت لري. په مقابل کې، د روټینګ میش جوړول چې ما د دې پوسټ په پیل کې تشریح کړل د موجوده وسیلو په کارولو سره نسبتا ساده دی. نو، ایا دا معنی لري چې د دې پرځای د خپل خدمت میش جوړ کړئ؟
که موږ معتدل اړتیاوې ولرو (موږ لید ته اړتیا نلرو ، سرکټ بریکر او نور فرعي) ، نو فکرونه زموږ د خپل وسیله رامینځته کولو ته راځي. مګر که موږ Kubernetes وکاروو، دا ممکن حتی اړتیا ونلري ځکه چې Kubernetes دمخه د خدماتو کشف او د بار توازن لپاره لومړني وسیلې چمتو کوي.
مګر که موږ پرمختللي اړتیاوې ولرو، نو د خدماتو میش "پیرود" خورا غوره انتخاب ښکاري. (دا تل "پیرود" نه وي ځکه چې اسټیو خلاص سرچینه ده ، مګر موږ لاهم اړتیا لرو د پوهیدو ، ځای په ځای کولو او اداره کولو لپاره د انجینرۍ وخت پانګونه وکړو.)
ایا زه باید Istio، Linkerd یا Consul Connect غوره کړم؟
تر دې دمه موږ یوازې د اسټیو په اړه خبرې کړې ، مګر دا یوازینی خدمت میش ندی. مشهور بدیل - ، او نور هم شته .
څه غوره کول
صادقانه، زه نه پوهیږم. دا مهال زه خپل ځان دومره وړ نه ګڼم چې دې پوښتنې ته ځواب ووایم. یو څو شتون لري د دې وسیلو او حتی پرتله کولو سره .
یو امید لرونکی چلند د یوې وسیلې کارول دي لکه . دا د خدماتو میشونو لخوا افشا شوي APIs ساده او متحد کولو لپاره د خلاصون پرت پلي کوي. د دې پرځای چې د مختلف خدماتو میشونو ځانګړي (او زما په نظر نسبتا پیچلي) APIs زده کړي، موږ کولی شو د SuperGloo ساده جوړښتونه وکاروو - او په اسانۍ سره له یو څخه بل ته لاړ شو، لکه څنګه چې موږ د منځګړیتوب ترتیب بڼه درلوده چې د HTTP انٹرفیسونه او بیکینډونه تشریح کوي. د Nginx، HAProxy، Traefik، Apache لپاره د ریښتیني تشکیلاتو رامینځته کول ...
ما د اسټیو او سوپر ګلو سره یو څه برخه اخیستې ، او په راتلونکې مقاله کې زه غواړم وښیم چې څنګه د سوپر ګلو په کارولو سره موجوده کلستر ته اسټیو یا لینکرډ اضافه کړم ، او وروستی څنګه کار سرته رسوي ، دا تاسو ته اجازه درکوي له دې څخه تیر شئ. د یو خدمت میش بل ته پرته له دې چې ترتیبونه له سره لیکل کیږي.
سرچینه: www.habr.com