انٽرنيٽ ۾ (سروس ميش)، ۽ هتي هڪ ٻيو آهي. هوري! پر ڇو؟ پوءِ ، مان پنهنجي راءِ بيان ڪرڻ چاهيان ٿو ته سروس ميش 10 سال اڳ بهتر هجي ها ، ڪنٽينر پليٽ فارمن جهڙوڪ ڊڪر ۽ ڪبرنيٽس جي اچڻ کان اڳ. مان اهو نه ٿو چوان ته منهنجو نقطه نظر ٻين کان بهتر يا خراب آهي، پر جيئن ته سروس ميش ڪافي پيچيده جانور آهن، انهن کي بهتر سمجهڻ ۾ ڪيترن ئي نقطي نظر ۾ مدد ملندي.
مان ڊاٽ ڪلائوڊ پليٽ فارم جي باري ۾ ڳالهائيندس، جيڪو هڪ سو کان وڌيڪ مائڪرو سروسز تي ٺهيل هو ۽ ڪنٽينرز ۾ هزارين ايپليڪيشنن جي حمايت ڪئي هئي. مان وضاحت ڪندس انهن چئلينجن کي جن جو اسان ان کي ڊولپمينٽ ۽ لانچ ڪرڻ ۾ پيش آيو، ۽ ڪيئن سروس ميشز (يا نه ٿي سگھي) مدد ڪري سگھي ٿي.
dotcloud تاريخ
مون اڳ ۾ ئي لکيو آهي ڊٽ ڪلائوڊ جي تاريخ ۽ هن پليٽ فارم لاءِ فن تعمير جي چونڊ، پر نيٽ ورڪ پرت بابت گهڻو ڪجهه نه ڳالهايو آهي. جيڪڏهن توهان پڙهڻ نٿا چاهيو dotCloud جي باري ۾، هتي ان جو خلاصو آهي: اهو هڪ PaaS پليٽ فارم-جي-هڪ-سروس آهي جيڪا صارفين کي ايپليڪيشنن جي وسيع رينج کي هلائڻ جي اجازت ڏئي ٿي (Java, PHP, Python...), ڊيٽا سروسز جي وسيع رينج جي مدد سان ( MongoDB، MySQL، Redis...) ۽ هڪ ورڪ فلو جهڙو هيروڪو: توهان پليٽ فارم تي پنهنجو ڪوڊ اپ لوڊ ڪريو ٿا، اهو ڪنٽينر تصويرون ٺاهي ٿو ۽ انهن کي ترتيب ڏئي ٿو.
مان توهان کي ٻڌايان ٿو ته ٽرئفڪ ڪيئن موڪليو ويو dotCloud پليٽ فارم تي. ان لاءِ نه ته اهو خاص طور تي ٿڌو هو (جيتوڻيڪ سسٽم پنهنجي وقت لاءِ سٺو ڪم ڪيو!)، پر بنيادي طور تي ڇاڪاڻ ته جديد اوزارن جي مدد سان، اهڙي ڊزائن کي ٿوري وقت ۾ آسانيءَ سان لاڳو ڪري سگهجي ٿو هڪ معمولي ٽيم جيڪڏهن انهن کي رستي جي ضرورت هجي. ٽريفڪ microservices يا ايپليڪيشنن جي هڪ گروپ جي وچ ۾. اهڙيء طرح، توهان اختيارن جو مقابلو ڪري سگهو ٿا: ڇا ٿيندو جيڪڏهن توهان پنهنجو پاڻ کي هر شي ٺاهي يا موجوده سروس ميش استعمال ڪريو. معياري چونڊ: پنهنجو پاڻ ٺاهيو يا خريد ڪريو.
ميزباني ڪيل ايپليڪيشنن لاءِ ٽرئفڪ جو رستو
DotCloud تي ايپليڪيشنون HTTP ۽ TCP جي آخري پوائنٽ کي بي نقاب ڪري سگھن ٿيون.
HTTP آخر پوائنٽس متحرڪ طور تي لوڊ بيلنس ڪلستر جي ترتيب ۾ شامل ڪيو ويو . اهو ساڳيو آهي جيڪو اڄڪلهه وسيلا ڪري رهيا آهن ڪبرنيٽس ۾ ۽ لوڊ بيلنس وانگر .
ڪلائنٽ مناسب ڊومينز ذريعي HTTP جي آخر پوائنٽن سان ڳنڍيندا آهن، مهيا ڪيل ڊومين جو نالو پوائنٽس dotCloud لوڊ بيلنسرز ڏانهن. ڪجه بـ خاص نـ.
TCP جي آخري پوائنٽ هڪ پورٽ نمبر سان لاڳاپيل آهي، جيڪو پوء ان اسٽيڪ ۾ سڀني ڪنٽينرز کي ماحولياتي متغير ذريعي منتقل ڪيو ويندو آهي.
ڪلائنٽ مناسب ميزبان نالو استعمال ڪندي TCP جي آخري پوائنٽن سان ڳنڍجي سگھن ٿا (جيئن gateway-X.dotcloud.com) ۽ پورٽ نمبر.
هي ميزبان نالو حل ڪري ٿو "nats" سرور ڪلستر (جي سان لاڳاپيل ناهي ) جيڪو ايندڙ TCP ڪنيڪشنن کي صحيح ڪنٽينر ڏانھن روٽ ڪندو (يا، لوڊ-متوازن خدمتن جي صورت ۾، صحيح ڪنٽينر ڏانھن).
جيڪڏهن توهان Kubernetes سان واقف آهيو، اهو شايد توهان کي خدمتن جي ياد ڏياريندو .
DotCloud پليٽ فارم تي ڪابه خدمت برابر نه هئي : سادگي لاءِ، خدمتن تائين رسائي ساڳي طرح پليٽ فارم جي اندر ۽ ٻاهران ٿي.
هر شي کي بلڪل سادو منظم ڪيو ويو: HTTP ۽ TCP روٽنگ نيٽ ورڪن جا اصل عمل شايد پٿون جون صرف چند سو لائينون هيون. سادو (مان چوان ٿو، بيوقوف) الگورتھم جيڪي پليٽ فارم جي ترقي ۽ اضافي گهرجن جي اڀار سان بهتر ڪيا ويا آهن.
موجوده ڪوڊ جي وسيع ريفيڪٽرنگ جي ضرورت نه هئي. خاص طور تي، ماحوليات جي متغيرن ذريعي حاصل ڪيل ايڊريس سڌو سنئون استعمال ڪري سگھن ٿا.
اهو ڪيئن مختلف آهي جديد سروس ميش کان؟
محدود داڻا. اسان وٽ TCP روٽنگ ميش لاءِ ڪا به ميٽرڪ نه هئي. جڏهن اهو اچي ٿو HTTP روٽنگ، وڌيڪ تازو ورزن ۾ تفصيلي HTTP ميٽرڪس آهن غلطي ڪوڊ ۽ جوابي وقتن سان، پر جديد سروس ميشز اڃا به اڳتي وڌندا آهن، مثال طور پرومٿيس وانگر ميٽرڪ گڏ ڪرڻ واري نظام سان انضمام مهيا ڪن ٿا.
ڏيکاءُ نه رڳو آپريشنل نقطه نظر کان (مسئلا حل ڪرڻ ۾ مدد لاءِ) اهم آهي، پر جڏهن نوان فيچرز جاري ڪيا وڃن ٿا. محفوظ بابت ڳالهائڻ и .
رستي جي ڪارڪردگي پڻ محدود آهي. ڊٽ ڪلائوڊ روٽنگ ميش ۾، سڀني ٽرئفڪ کي وقف ٿيل روٽنگ نوڊس جي ڪلستر مان گذرڻو پوندو. ان جو مطلب ممڪن طور تي گھڻن AZ (دستياب زون) جي حدن کي پار ڪرڻ ۽ ويڪرائي ۾ ھڪ اھم اضافو. مون کي ياد آهي مسئلو حل ڪرڻ وارو ڪوڊ جيڪو هر صفحي تي هڪ سئو SQL سوالن کان مٿي ڪيو ۽ هر سوال لاءِ SQL سرور سان نئون ڪنيڪشن کوليو. جڏهن مقامي طور تي هلايو وڃي ته صفحو فوري طور تي لوڊ ٿئي ٿو، پر dotCloud تي ان کي لوڊ ٿيڻ ۾ چند سيڪنڊ لڳن ٿا، ڇاڪاڻ ته هر TCP ڪنيڪشن (۽ ان کان پوءِ SQL سوال) ڏهن ملي سيڪنڊن جو وقت وٺندو آهي. هن خاص صورت ۾، مسلسل لاڳاپا مسئلو حل.
اهڙين مسئلن کي منهن ڏيڻ ۾ جديد سروس ميش بهتر آهن. سڀ کان پهريان، اهي چيڪ ڪن ٿا ته ڪنيڪشن روٽ ٿيل آهن ذريعن ۾. منطقي وهڪري ساڳيو آهي: клиент → меш → сервис، پر ھاڻي ميش مقامي طور ڪم ڪري ٿو ۽ نه ريموٽ نوڊس تي، تنھنڪري ڪنيڪشن клиент → меш مقامي ۽ تمام تيز آهي (ملي سيڪنڊن جي بدران مائڪرو سيڪنڊ).
جديد سروس ميشز پڻ سمارٽ لوڊ بيلنسنگ الگورتھم لاڳو ڪن ٿيون. پٺاڻن جي صحت جي نگراني ڪندي، اهي وڌيڪ ٽرئفڪ موڪلي سگھن ٿا تيز پس منظر ڏانهن، نتيجي ۾ بهتر مجموعي ڪارڪردگي.
حفاظت پڻ بهتر آهي. ڊٽ ڪلائوڊ روٽنگ ميش مڪمل طور تي EC2 کلاسک تي هليو ۽ ٽرئفڪ کي انڪرپٽ نه ڪيو (ان فرض جي تحت ته جيڪڏهن ڪو ماڻهو EC2 نيٽ ورڪ ٽرئفڪ تي سنيفر رکڻ ۾ ڪامياب ٿي ويو، توهان اڳ ۾ ئي وڏي مصيبت ۾ آهيو). جديد سروس ميشز شفاف طور تي اسان جي سڀني ٽرئفڪ جي حفاظت ڪن ٿا، مثال طور، باهمي TLS تصديق ۽ بعد ۾ انڪرپشن سان.
پليٽ فارم جي خدمتن لاء ٽرئفڪ جو رستو
ٺيڪ، اسان ايپليڪيشنن جي وچ ۾ ٽرئفڪ تي بحث ڪيو آهي، پر ڇا dotCloud پليٽ فارم پاڻ بابت؟
پليٽ فارم پاڻ ۾ لڳ ڀڳ هڪ سئو microservices تي مشتمل آهي مختلف ڪمن لاءِ ذميوار. ڪجهه ٻين کان درخواستون قبول ڪري رهيا هئا، ۽ ڪجهه پس منظر وارا ڪارڪن هئا جيڪي ٻين خدمتن سان ڳنڍيل هئا پر ڪنيڪشن پاڻ قبول نه ڪندا هئا. ٻنهي صورتن ۾، هر خدمت کي ڄاڻڻ گهرجي ته پتي جي آخري پوائنٽن کي ان سان ڳنڍڻ جي ضرورت آهي.
ڪيتريون ئي اعلي سطحي خدمتون استعمال ڪري سگھن ٿيون روٽنگ ميش مٿي بيان ڪيل. حقيقت ۾، XNUMX کان وڌيڪ dotCloud microservices مان ڪيتريون ئي ڊاٽ ڪلائوڊ پليٽ فارم تي باقاعده ايپليڪيشنن جي طور تي مقرر ڪيون ويون آهن. پر گهٽ سطحي خدمتن جو هڪ ننڍڙو تعداد (خاص طور تي، جيڪي هن روٽنگ ميش کي لاڳو ڪن ٿا) کي ڪجهه سادو گهربل آهي، گهٽ انحصار سان (ڇاڪاڻ ته اهي ڪم ڪرڻ لاءِ پاڻ تي ڀروسو نٿا ڪري سگهن - سٺو پراڻو ڪڪڙ ۽ هڏي جو مسئلو).
اهي گهٽ-سطح، ضروري خدمتون سرانجام ڏنيون ويون ڪنٽينرز کي سڌو سنئون چند اهم نوڊس تي. ساڳئي وقت، معياري پليٽ فارم خدمتون شامل نه هئا: لنڪر، شيڊولر، ۽ رنر. جيڪڏهن توهان جديد ڪنٽينر پليٽ فارمن سان مقابلو ڪرڻ چاهيو ٿا، اهو هڪ ڪنٽرول جهاز شروع ڪرڻ وانگر آهي docker run سڌو سنئون نوڊس تي، ڪم کي ڪبرنيٽس کي ڏيڻ بدران. اهو تصور ۾ ڪافي هڪجهڙائي آهي ، جيڪو استعمال ڪري ٿو يا جڏهن هڪ اسٽينڊل ڪلستر کي بوٽ ڪندي.
اهي خدمتون هڪ سادي ۽ خام انداز ۾ ظاهر ڪيون ويون آهن: هڪ YAML فائل انهن جا نالا ۽ پتا درج ڪيا ويا آهن؛ ۽ هر ڪلائنٽ کي هن YAML فائل جي هڪ ڪاپي وٺڻي هئي ڊيپلائي ڪرڻ لاءِ.
هڪ طرف، اهو انتهائي قابل اعتماد آهي، ڇاڪاڻ ته ان کي ڪنهن ٻاهرين ڪي/ويليو اسٽور جي مدد جي ضرورت ناهي، جهڙوڪ Zookeeper (ياد رکو، 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 ترتيب کي منظم ڪري سگھجي ٿو ، توهان کي بيڪ اينڊ معلومات کي وغيره ۾ ذخيرو ڪرڻ جي اجازت ڏئي ٿو يا ڪنسل ۽ خودڪار طريقي سان HAProxy تي تازه ڪاري ترتيب کي زور ڏئي ٿو جڏهن ضرورت هجي.
اهو ڪيئن آهي Istio ڪم ڪري ٿو! پر ڪجهه اختلافن سان:
- استعمال ڪري ٿو HAProxy جي بدران.
- پس منظر جي ترتيب کي محفوظ ڪري ٿو Kubernetes API ذريعي etcd يا قونصل جي بدران.
- خدمتون مختص ڪيون ويون آهن ايڊريس اندروني سب نيٽ تي (Kubernetes ClusterIP ايڊريس) بدران 127.0.0.0/8.
- ڪلائنٽ ۽ سرورز جي وچ ۾ باہمي TLS جي تصديق کي شامل ڪرڻ لاءِ ھڪڙو اضافي حصو (Citadel) آھي.
- نون خصوصيتن کي سپورٽ ڪري ٿو جهڙوڪ سرڪٽ ٽوڪنگ، ورهايل ٽريڪنگ، ڪينري جي ترتيب، وغيره.
اچو ته ڪجهه اختلافن تي هڪ تڪڙو نظر وٺو.
سفير پراکسي
Envoy Proxy لکيو ويو آهي Lyft [Uber جي مقابلي ۾ ٽيڪسي مارڪيٽ ۾ - تقريبن. في.]. اهو ڪيترن ئي طريقن سان ٻين پراکسيز (مثال طور HAProxy، Nginx، Traefik...) سان ملندڙ جلندڙ آهي، پر Lyft پنهنجو پاڻ لکيو آهي ڇاڪاڻ ته انهن کي اهي خاصيتون گهربل آهن جيڪي ٻين پراڪسيز وٽ نه آهن ۽ اهو وڌيڪ سمجهه ۾ اچي ٿو ته هڪ نئون ٺاهڻ بجاءِ واڌارو. هڪ موجود.
نمائندو پاڻ کي استعمال ڪري سگهجي ٿو. جيڪڏهن مون وٽ هڪ مخصوص خدمت آهي جنهن کي ٻين خدمتن سان ڳنڍڻ جي ضرورت آهي، مان ان کي سيٽ ڪري سگهان ٿو Envoy سان ڳنڍڻ لاءِ ۽ پوءِ متحرڪ طور تي ڪنفيگر ڪريان ٿو ۽ ٻيهر ترتيب ڏئي سگهان ٿو Envoy کي ٻين خدمتن جي مقام سان، جڏهن ته تمام گهڻيون واڌايون حاصل ڪرڻ جهڙوڪ visibility. ڪسٽم ڪلائنٽ لائبريري جي بدران يا ڪال ٽريڪنگ ڪوڊ ۾ انجيڪشن، اسان ٽريفڪ موڪليندا آهيون ايلچي ڏانهن، ۽ اهو اسان لاءِ ميٽرڪ گڏ ڪري ٿو.
پر Envoy به ڪم ڪرڻ جي قابل آهي جيئن ڊيٽا جهاز (ڊيٽا جهاز) سروس ميش لاءِ. هن جو مطلب آهي ته هاڻي هن خدمت جي ميش لاء، Envoy ترتيب ڏنل آهي ڪنٽرول جهاز (ڪنٽرول جهاز).
ڪنٽرول جهاز
ڪنٽرول جهاز ۾، Istio انحصار ڪري ٿو Kubernetes API. اهو استعمال ڪرڻ کان بلڪل مختلف ناهي confd، جيڪو ڊيٽا اسٽور ۾ چيڪن جو هڪ سيٽ ڏسڻ لاءِ etcd يا قونصل تي ڀاڙي ٿو. Istio Kubernetes API جي ذريعي Kubernetes وسيلن جي هڪ سيٽ ذريعي ڏسڻ ۾ اچي ٿو.
هن ۽ پوء جي وچ ۾: مون کي ذاتي طور تي اهو مفيد مليو جيڪو پڙهي ٿو:
Kubernetes API سرور ھڪڙو "بيوقوف سرور" آھي جيڪو پيش ڪري ٿو اسٽوريج، ورزننگ، تصديق، تازه ڪاري، ۽ API وسيلن جي معني.
Istio Kubernetes سان ڪم ڪرڻ لاء ٺهيل آهي؛ ۽ جيڪڏھن توھان ان کي ڪبرنيٽس کان ٻاھر استعمال ڪرڻ چاھيو ٿا، ته پوءِ توھان کي ڪبرنيٽس API سرور جو مثال شروع ڪرڻو پوندو (۽ etcd مددگار سروس).
سروس ايڊريس
Istio ClusterIP پتي تي ڀروسو ڪري ٿو جيڪي ڪبرنيٽس مختص ڪري ٿو، تنهن ڪري Istio خدمتن کي اندروني پتو ملي ٿو (رينج ۾ نه 127.0.0.0/8).
ٽريفڪ ڪلسٽر IP پتي تي ڪنهن مخصوص خدمت لاءِ ڪبرنيٽس ڪلستر ۾ Istio کان سواءِ kube-proxy ذريعي روڪيو ويندو آهي ۽ پراکسي جي پوئين آخر ڏانهن موڪليو ويندو آهي. جيڪڏهن توهان ٽيڪنيڪل تفصيلن ۾ دلچسپي رکو ٿا، kube-proxy سيٽ اپ ڪري ٿو iptables ضابطا (يا IPVS لوڊ بيلنسرز، ان تي منحصر آهي ته اهو ڪيئن ترتيب ڏنو ويو آهي) ڪنيڪشن جي منزل IP پتي کي ٻيهر لکڻ لاءِ ClusterIP ايڊريس ڏانهن وڃي ٿو.
هڪ دفعو Istio هڪ ڪبرنيٽس ڪلستر تي نصب ڪيو ويندو آهي، ڪجھ به تبديل نه ٿيندو جيستائين اهو واضح طور تي هڪ ڏنل صارف لاءِ فعال نه ڪيو وڃي، يا اڃا تائين پوري نالي جي جاءِ، ڪنٽينر متعارف ڪرائڻ سان. sidecar ڪسٽم پوڊز ڏانهن. هي ڪنٽينر هڪ ايلچي مثال شروع ڪندو ۽ iptables جي ضابطن جو هڪ سيٽ قائم ڪندو ٽرئفڪ کي روڪڻ لاءِ ٻين خدمتن ڏانهن وڃڻ ۽ انهي ٽرئفڪ کي ايلچي ڏانهن ريڊائريڪٽ ڪندو.
جڏهن 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 ذريعي وڃڻ جي ضرورت آهي، ته پوءِ لاگ ان ٿيڻ تي، ورهايل ٽريڪنگ درخواست ۾ هڪ منفرد سڃاڻپ ڪندڙ شامل ڪندو ۽ هن سڃاڻپ ڪندڙ کي ذيلي درخواستن ذريعي انهن سڀني مائيڪرو سروسز کي ذخيرو ڪرڻ جي اجازت ڏيندو. توهان سڀني لاڳاپيل ڪالن کي پڪڙڻ لاء، انهن جي دير، وغيره.
ترقي ڪريو يا خريد ڪريو
Istio هڪ پيچيده نظام هجڻ جي شهرت آهي. ان جي ابتڙ، رستي واري ميش جي تعمير جيڪا مون هن پوسٽ جي شروعات ۾ بيان ڪئي آهي نسبتا آسان آهي موجوده اوزار سان. تنهن ڪري، ڇا ان جي بدران توهان جي پنهنجي خدمت ميش ٺاهڻ جو احساس آهي؟
جيڪڏهن اسان وٽ معمولي ضرورتون آهن (اسان کي ڏسڻ جي ضرورت ناهي، هڪ سرڪٽ برڪر ۽ ٻين ذيلي ذخيري)، پوء خيال اسان جي پنهنجي اوزار کي ترقي ڪرڻ بابت اچن ٿا. پر جيڪڏهن اسان ڪبرنيٽس استعمال ڪري رهيا آهيون ته شايد ان جي ضرورت به نه هجي ڇاڪاڻ ته ڪبرنيٽس اڳ ۾ ئي بنيادي اوزار مهيا ڪري ٿو خدمت جي دريافت ۽ لوڊ بيلنسنگ لاءِ.
پر جيڪڏهن اسان وٽ جديد گهرجون آهن، ته پوء "خريد" هڪ خدمت ميش هڪ تمام بهتر اختيار وانگر لڳي ٿو. (اهو هميشه "خريداري" ناهي ڇو ته Istio اوپن سورس آهي، پر اسان کي اڃا تائين ان کي سمجهڻ، ترتيب ڏيڻ، ۽ انتظام ڪرڻ لاء انجنيئرنگ وقت خرچ ڪرڻ جي ضرورت آهي.)
ڇا چونڊيو: Istio، Linkerd يا Consul Connect؟
هينئر تائين اسان صرف Istio بابت ڳالهايو آهي، پر اهو صرف خدمت ميش ناهي. مشهور متبادل آهي ، پر اتي وڌيڪ آهي .
выбрать Что؟
ايماندار ٿيڻ لاء، مون کي خبر ناهي. هن وقت مان پاڻ کي ان سوال جو جواب ڏيڻ جي لائق نه ٿو سمجهان. ڪي ٿورا آهن انهن اوزارن جي مقابلي سان ۽ پڻ .
ھڪڙو واعدو ڪندڙ طريقو ھڪڙو اوزار استعمال ڪرڻ جھڙو آھي . اهو سروس ميشز پاران مهيا ڪيل APIs کي آسان ۽ متحد ڪرڻ لاءِ هڪ تجزياتي پرت لاڳو ڪري ٿو. مختلف سروس ميشز جي مخصوص (۽، منهنجي خيال ۾، نسبتا پيچيده) APIs کي سکڻ جي بدران، اسان استعمال ڪري سگهون ٿا آسان SuperGloo تعميرات - ۽ آساني سان هڪ کان ٻئي ڏانهن مٽائي سگهون ٿا، ڄڻ ته اسان وٽ هڪ وچولي ترتيب واري شڪل هئي HTTP انٽرفيس ۽ پس منظر کي بيان ڪندي. Nginx، HAProxy، Traefik، Apache لاءِ اصل تشڪيل پيدا ڪرڻ جي قابل ...
مون Istio ۽ SuperGloo سان ٿورڙي راند ڪئي، ۽ ايندڙ مضمون ۾ مان ڏيکارڻ چاهيان ٿو ته ڪيئن Istio يا Linkerd کي شامل ڪجي موجوده ڪلسٽر ۾ SuperGloo استعمال ڪندي، ۽ پوءِ ڪيئن ڪندو پنهنجو ڪم، يعني اهو توهان کي مٽائڻ جي اجازت ڏئي ٿو مان هڪ خدمت ميش ٻئي ڏانهن بغير ترتيب جي ٻيهر لکڻ جي.
جو ذريعو: www.habr.com