انٹرنیٹ میں (سروس میش)، اور یہاں ایک اور ہے۔ ہورے! لیکن کیوں؟ پھر، میں اپنی رائے کا اظہار کرنا چاہتا ہوں کہ بہتر ہوتا اگر سروس میشز 10 سال پہلے، کنٹینر پلیٹ فارم جیسے ڈوکر اور کبرنیٹس کی آمد سے پہلے ظاہر ہوتے۔ میں یہ نہیں کہہ رہا ہوں کہ میرا نقطہ نظر دوسروں سے بہتر یا بدتر ہے، لیکن چونکہ سروس میشز کافی پیچیدہ جانور ہیں، اس لیے متعدد نقطہ نظر ان کو بہتر طور پر سمجھنے میں مدد کریں گے۔
میں ڈاٹ کلاؤڈ پلیٹ فارم کے بارے میں بات کروں گا، جو سو سے زیادہ مائیکرو سروسز پر بنایا گیا تھا اور ہزاروں کنٹینرائزڈ ایپلی کیشنز کو سپورٹ کرتا تھا۔ میں ان چیلنجوں کی وضاحت کروں گا جن کا ہمیں اسے تیار کرنے اور اسے شروع کرنے میں درپیش تھا، اور کس طرح سروس میشز مدد کر سکتے ہیں (یا نہیں کر سکتے)۔
ڈاٹ کلاؤڈ کی تاریخ
میں نے ڈاٹ کلاؤڈ کی تاریخ اور اس پلیٹ فارم کے لیے فن تعمیر کے انتخاب کے بارے میں لکھا ہے، لیکن میں نے نیٹ ورک پرت کے بارے میں زیادہ بات نہیں کی ہے۔ اگر آپ پڑھنے میں غوطہ لگانا نہیں چاہتے ہیں۔ ڈاٹ کلاؤڈ کے بارے میں، یہاں مختصراً خلاصہ ہے: یہ ایک PaaS پلیٹ فارم-ایک-سروس ہے جو صارفین کو ڈیٹا کی وسیع رینج کے لیے سپورٹ کے ساتھ ایپلی کیشنز کی ایک وسیع رینج (جاوا، پی ایچ پی، ازگر...) چلانے کی اجازت دیتا ہے۔ خدمات (MongoDB, MySQL, Redis...) اور ایک ورک فلو جیسا کہ Heroku: آپ اپنا کوڈ پلیٹ فارم پر اپ لوڈ کرتے ہیں، یہ کنٹینر کی تصاویر بناتا ہے اور انہیں تعینات کرتا ہے۔
میں آپ کو بتاؤں گا کہ ٹریفک کو ڈاٹ کلاؤڈ پلیٹ فارم پر کیسے بھیج دیا گیا تھا۔ اس لیے نہیں کہ یہ خاص طور پر ٹھنڈا تھا (حالانکہ سسٹم نے اپنے وقت کے لیے اچھی طرح کام کیا تھا!)، بلکہ بنیادی طور پر اس لیے کہ جدید ٹولز کے ساتھ اس طرح کے ڈیزائن کو ایک معمولی ٹیم آسانی سے مختصر وقت میں نافذ کر سکتی ہے اگر انہیں ایک گروپ کے درمیان ٹریفک کو روٹ کرنے کے لیے کسی راستے کی ضرورت ہو۔ مائیکرو سروسز یا ایپلی کیشنز کا ایک گروپ۔ اس طرح، آپ اختیارات کا موازنہ کر سکتے ہیں: اگر آپ ہر چیز کو خود تیار کرتے ہیں یا موجودہ سروس میش استعمال کرتے ہیں تو کیا ہوتا ہے۔ معیاری انتخاب یہ ہے کہ اسے خود بنائیں یا خریدیں۔
میزبان ایپلی کیشنز کے لیے ٹریفک روٹنگ
ڈاٹ کلاؤڈ پر ایپلیکیشنز HTTP اور TCP اینڈ پوائنٹس کو بے نقاب کر سکتی ہیں۔
HTTP اختتامی پوائنٹس متحرک طور پر لوڈ بیلنس کلسٹر کنفیگریشن میں شامل کیا گیا۔ . یہ وہی ہے جو آج کے وسائل کرتے ہیں۔ Kubernetes میں اور ایک لوڈ بیلنسر جیسے .
کلائنٹ مناسب ڈومینز کے ذریعے HTTP اینڈ پوائنٹس سے جڑتے ہیں، بشرطیکہ ڈومین کا نام ڈاٹ کلاؤڈ لوڈ بیلنسرز کی طرف اشارہ کرے۔ کچھ خاص نہیں.
TCP اینڈ پوائنٹس ایک پورٹ نمبر کے ساتھ منسلک، جو پھر اس اسٹیک میں موجود تمام کنٹینرز کو ماحولیاتی متغیرات کے ذریعے منتقل کیا جاتا ہے۔
کلائنٹ مناسب میزبان نام (جیسے gateway-X.dotcloud.com) اور پورٹ نمبر کا استعمال کرتے ہوئے TCP اینڈ پوائنٹس سے جڑ سکتے ہیں۔
یہ میزبان نام "nats" سرور کلسٹر کو حل کرتا ہے (سے متعلق نہیں )، جو آنے والے TCP کنکشنز کو درست کنٹینر تک لے جائے گا (یا، لوڈ بیلنس سروسز کی صورت میں، صحیح کنٹینرز تک)۔
اگر آپ Kubernetes سے واقف ہیں، تو یہ شاید آپ کو خدمات کی یاد دلائے گا۔ .
ڈاٹ کلاؤڈ پلیٹ فارم پر کوئی مساوی خدمات نہیں تھیں۔ : سادگی کے لیے، پلیٹ فارم کے اندر اور باہر دونوں طرح سے خدمات تک رسائی حاصل کی گئی۔
ہر چیز کو کافی آسانی سے ترتیب دیا گیا تھا: HTTP اور TCP روٹنگ نیٹ ورکس کے ابتدائی نفاذ شاید ازگر کی صرف چند سو لائنوں پر مشتمل تھے۔ سادہ (میں بولی کہوں گا) الگورتھم جو پلیٹ فارم کے بڑھنے اور اضافی تقاضوں کے ظاہر ہونے کے ساتھ ہی بہتر ہو گئے تھے۔
موجودہ کوڈ کی وسیع ری فیکٹرنگ کی ضرورت نہیں تھی۔ خاص طور پر، ماحولیاتی متغیرات کے ذریعے حاصل کردہ ایڈریس کو براہ راست استعمال کر سکتے ہیں۔
یہ جدید سروس میش سے کیسے مختلف ہے؟
محدود مرئیت. ہمارے پاس TCP روٹنگ میش کے لیے بالکل بھی کوئی میٹرکس نہیں تھا۔ جب HTTP روٹنگ کی بات آتی ہے، تو بعد کے ورژنز نے خرابی کوڈز اور رسپانس ٹائمز کے ساتھ تفصیلی HTTP میٹرکس متعارف کرایا، لیکن جدید سروس میشز اس سے بھی آگے بڑھتے ہیں، مثال کے طور پر پرومیتھیس جیسے میٹرکس کلیکشن سسٹم کے ساتھ انضمام فراہم کرتے ہیں۔
مرئیت نہ صرف آپریشنل نقطہ نظر سے اہم ہے (مسائل کو حل کرنے میں مدد کے لیے) بلکہ نئی خصوصیات جاری کرتے وقت بھی۔ یہ محفوظ کے بارے میں ہے۔ и .
روٹنگ کی کارکردگی بھی محدود ہے. ڈاٹ کلاؤڈ روٹنگ میش میں، تمام ٹریفک کو وقف شدہ روٹنگ نوڈس کے جھرمٹ سے گزرنا پڑتا تھا۔ اس کا مطلب ممکنہ طور پر متعدد AZ (Availability Zone) کی حدود کو عبور کرنا اور نمایاں طور پر تاخیر میں اضافہ کرنا تھا۔ مجھے ٹربل شوٹنگ کوڈ یاد ہے جو فی صفحہ سو سے زیادہ SQL سوالات کر رہا تھا اور ہر سوال کے لیے SQL سرور سے ایک نیا کنکشن کھول رہا تھا۔ مقامی طور پر چلنے پر، صفحہ فوری طور پر لوڈ ہوتا ہے، لیکن ڈاٹ کلاؤڈ میں اسے لوڈ ہونے میں چند سیکنڈ لگتے ہیں کیونکہ ہر TCP کنکشن (اور اس کے بعد کی SQL استفسار) دسیوں ملی سیکنڈ لیتا ہے۔ اس خاص معاملے میں، مستقل رابطوں نے مسئلہ حل کر دیا۔
جدید سروس میش اس طرح کے مسائل سے نمٹنے میں بہتر ہیں۔ سب سے پہلے، وہ چیک کرتے ہیں کہ کنکشن روٹ ہوئے ہیں۔ ماخذ میں. منطقی بہاؤ ایک ہی ہے: клиент → меш → сервис، لیکن اب میش مقامی طور پر کام کرتا ہے اور ریموٹ نوڈس پر نہیں، لہذا کنکشن клиент → меш مقامی اور بہت تیز ہے (ملی سیکنڈ کے بجائے مائکرو سیکنڈز)۔
جدید سروس میشز زیادہ ہوشیار لوڈ بیلنسنگ الگورتھم کو بھی نافذ کرتی ہیں۔ بیک اینڈز کی صحت کی نگرانی کرکے، وہ تیز رفتار بیک اینڈ پر زیادہ ٹریفک بھیج سکتے ہیں، جس کے نتیجے میں مجموعی کارکردگی بہتر ہوتی ہے۔
سیکورٹی بہتر بھی. ڈاٹ کلاؤڈ روٹنگ میش مکمل طور پر EC2 کلاسک پر چلتا ہے اور ٹریفک کو انکرپٹ نہیں کرتا تھا (اس مفروضے کی بنیاد پر کہ اگر کوئی EC2 نیٹ ورک ٹریفک پر سنیفر لگانے میں کامیاب ہو گیا تو آپ پہلے ہی بڑی مصیبت میں تھے)۔ جدید سروس میشز شفاف طریقے سے ہمارے تمام ٹریفک کی حفاظت کرتی ہیں، مثال کے طور پر باہمی TLS تصدیق اور بعد میں خفیہ کاری کے ساتھ۔
پلیٹ فارم کی خدمات کے لیے روٹنگ ٹریفک
ٹھیک ہے، ہم نے ایپلی کیشنز کے درمیان ٹریفک پر تبادلہ خیال کیا ہے، لیکن خود ڈاٹ کلاؤڈ پلیٹ فارم کا کیا ہوگا؟
پلیٹ فارم میں تقریباً سو مائیکرو سروسز شامل تھیں جو مختلف افعال کے لیے ذمہ دار تھیں۔ کچھ نے دوسروں کی طرف سے درخواستیں قبول کیں، اور کچھ پس منظر کے کارکن تھے جو دوسری خدمات سے جڑے تھے لیکن خود کنکشن قبول نہیں کرتے تھے۔ کسی بھی صورت میں، ہر سروس کو ان پتوں کے اختتامی نقطوں کا علم ہونا چاہیے جن سے اسے جڑنے کی ضرورت ہے۔
بہت سی اعلیٰ سطحی خدمات اوپر بیان کردہ روٹنگ میش استعمال کر سکتی ہیں۔ درحقیقت، ڈاٹ کلاؤڈ کی سو سے زیادہ مائیکرو سروسز میں سے بہت سے ڈاٹ کلاؤڈ پلیٹ فارم پر ہی باقاعدہ ایپلی کیشنز کے طور پر تعینات کیے گئے ہیں۔ لیکن نچلی سطح کی خدمات کی ایک چھوٹی سی تعداد (خاص طور پر وہ جو اس روٹنگ میش کو نافذ کرتی ہیں) کو کچھ آسان کی ضرورت تھی، کم انحصار کے ساتھ (چونکہ وہ کام کرنے کے لیے خود پر انحصار نہیں کر سکتے تھے - اچھے پرانے چکن اور انڈے کا مسئلہ)۔
یہ نچلی سطح کی، مشن کی اہم خدمات کو چند کلیدی نوڈس پر براہ راست کنٹینرز چلا کر تعینات کیا گیا تھا۔ اس معاملے میں، معیاری پلیٹ فارم کی خدمات استعمال نہیں کی گئیں: لنکر، شیڈیولر اور رنر۔ اگر آپ جدید کنٹینر پلیٹ فارمز سے موازنہ کرنا چاہتے ہیں، تو یہ ایک کنٹرول ہوائی جہاز چلانے کی طرح ہے۔ 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 کنفیگریشن کو کنٹرول کیا جا سکتا ہے۔ ، آپ کو بیک اینڈ کی معلومات کو etcd یا قونصل میں ذخیرہ کرنے کی اجازت دیتا ہے اور ضرورت پڑنے پر خود بخود اپڈیٹ شدہ کنفیگریشن کو HAProxy میں دھکیل دیتا ہے۔
یہ بہت زیادہ ہے کہ کس طرح Istio کام کرتا ہے! لیکن کچھ اختلافات کے ساتھ:
- استعمال کرتا ہے۔ HAProxy کے بجائے۔
- بیک اینڈ کنفیگریشن کو etcd یا Consul کے بجائے Kubernetes API کے ذریعے اسٹور کرتا ہے۔
- سروسز کو 127.0.0.0/8 کے بجائے اندرونی سب نیٹ (Kubernetes ClusterIP ایڈریس) پر ایڈریس مختص کیے گئے ہیں۔
- کلائنٹ اور سرورز کے درمیان باہمی TLS تصدیق شامل کرنے کے لیے ایک اضافی جزو (Citadel) ہے۔
- نئی خصوصیات جیسے سرکٹ بریکنگ، ڈسٹری بیوٹڈ ٹریسنگ، کینری تعیناتی وغیرہ کو سپورٹ کرتا ہے۔
آئیے کچھ اختلافات پر ایک سرسری نظر ڈالتے ہیں۔
ایلچی پراکسی
Envoy Proxy کو Lyft [ٹیکسی مارکیٹ میں Uber کے حریف - تقریباً۔ لین]۔ یہ بہت سے طریقوں سے دیگر پراکسیز (جیسے HAProxy, Nginx, Traefik...) سے ملتا جلتا ہے، لیکن Lyft نے ان کو لکھا کیونکہ انہیں ایسی خصوصیات کی ضرورت تھی جن کی دیگر پراکسیوں میں کمی تھی، اور یہ موجودہ کو بڑھانے کے بجائے ایک نیا بنانا بہتر لگتا ہے۔
ایلچی اپنے طور پر استعمال کیا جا سکتا ہے۔ اگر میرے پاس کوئی مخصوص سروس ہے جس کو دوسری سروسز سے منسلک کرنے کی ضرورت ہے، تو میں اسے ایلچی سے منسلک کرنے کے لیے کنفیگر کر سکتا ہوں، اور پھر متحرک طور پر اینوائے کو دوسری سروسز کے مقام کے ساتھ کنفیگر اور ری کنفیگر کر سکتا ہوں، جبکہ بہت زیادہ اضافی فعالیت، جیسے مرئیت حاصل کر رہا ہوں۔ اپنی مرضی کے مطابق کلائنٹ لائبریری یا کوڈ میں کال ٹریس لگانے کے بجائے، ہم ایلچی کو ٹریفک بھیجتے ہیں، اور یہ ہمارے لیے میٹرکس اکٹھا کرتا ہے۔
لیکن ایلچی کے طور پر بھی کام کرنے کی صلاحیت رکھتا ہے۔ ڈیٹا ہوائی جہاز (ڈیٹا طیارہ) سروس میش کے لیے۔ اس کا مطلب ہے کہ ایلچی اب اس سروس میش کے لیے کنفیگر ہو گیا ہے۔ کنٹرول ہوائی جہاز (کنٹرول طیارہ)
کنٹرول طیارہ
کنٹرول طیارے کے لیے، Istio Kubernetes API پر انحصار کرتا ہے۔ یہ confd استعمال کرنے سے بہت مختلف نہیں ہے۔، جو ڈیٹا اسٹور میں کلیدوں کے سیٹ کو دیکھنے کے لیے etcd یا قونصل پر انحصار کرتا ہے۔ Istio Kubernetes وسائل کا ایک سیٹ دیکھنے کے لیے Kubernetes API کا استعمال کرتا ہے۔
اس کے درمیان اور پھر: میں نے ذاتی طور پر یہ مفید پایا جس میں لکھا ہے:
Kubernetes API سرور ایک "گونگا سرور" ہے جو API وسائل کے لیے اسٹوریج، ورژننگ، توثیق، اپ ڈیٹ اور سیمنٹکس پیش کرتا ہے۔
Istio Kubernetes کے ساتھ کام کرنے کے لیے ڈیزائن کیا گیا ہے۔ اور اگر آپ اسے Kubernetes سے باہر استعمال کرنا چاہتے ہیں، تو آپ کو Kubernetes API سرور (اور etcd مددگار سروس) کی مثال چلانے کی ضرورت ہے۔
سروس کے پتے
Istio ClusterIP پتوں پر انحصار کرتا ہے جو Kubernetes مختص کرتا ہے، لہذا Istio سروسز کو اندرونی پتہ موصول ہوتا ہے (حد میں نہیں 127.0.0.0/8).
Istio کے بغیر Kubernetes کلسٹر میں کسی مخصوص سروس کے لیے ClusterIP ایڈریس کی ٹریفک کو kube-proxy کے ذریعے روکا جاتا ہے اور اس پراکسی کے بیک اینڈ پر بھیجا جاتا ہے۔ اگر آپ تکنیکی تفصیلات میں دلچسپی رکھتے ہیں تو، kube-proxy iptables کے قواعد (یا IPVS لوڈ بیلنسرز، اس بات پر منحصر ہے کہ یہ کس طرح ترتیب دیا گیا ہے) سیٹ اپ کرتا ہے تاکہ کلسٹر آئی پی ایڈریس پر جانے والے کنکشنز کے آئی پی ایڈریس کو دوبارہ لکھیں۔
Kubernetes کلسٹر پر Istio انسٹال ہوجانے کے بعد، اس وقت تک کچھ بھی تبدیل نہیں ہوتا جب تک کہ اسے کسی کنٹینر کو متعارف کروا کر کسی صارف، یا یہاں تک کہ پوری نام کی جگہ کے لیے واضح طور پر فعال نہ کر دیا جائے۔ sidecar اپنی مرضی کے پھلیوں میں. یہ کنٹینر ایلچی کی ایک مثال کو گھمائے گا اور دوسری سروسز کی طرف جانے والی ٹریفک کو روکنے اور اس ٹریفک کو ایلچی کی طرف ری ڈائریکٹ کرنے کے لیے iptables کے قواعد کا ایک سیٹ ترتیب دے گا۔
Kubernetes DNS کے ساتھ مربوط ہونے پر، اس کا مطلب یہ ہے کہ ہمارا کوڈ سروس کے نام اور ہر چیز "بس کام کرتا ہے۔" دوسرے لفظوں میں، ہمارا کوڈ سوالات جیسے مسائل کو جاری کرتا ہے۔ http://api/v1/users/4242پھر api کے لئے درخواست کو حل کریں 10.97.105.48، iptables کے قواعد 10.97.105.48 سے کنکشن کو روکیں گے اور انہیں مقامی ایلچی پراکسی کو بھیجیں گے، اور وہ مقامی پراکسی درخواست کو اصل بیک اینڈ API کو بھیجے گی۔ افف!
اضافی frills
Istio mTLS (باہمی TLS) کے ذریعے اینڈ ٹو اینڈ انکرپشن اور تصدیق بھی فراہم کرتا ہے۔ ایک جزو کہا جاتا ہے۔ درگ.
ایک جزو بھی ہے۔ مکسرجس کے لیے ایلچی درخواست کر سکتا ہے۔ ہر ایک مختلف عوامل جیسے ہیڈر، بیک اینڈ لوڈ، وغیرہ پر منحصر ہو کر اس درخواست کے بارے میں خصوصی فیصلہ کرنے کی درخواست کریں... ایک پراکسی کے طور پر ٹھیک ہے)۔
اور، یقینا، ہم نے مرئیت کا ذکر کیا: ایلچی تقسیم شدہ ٹریسنگ فراہم کرتے ہوئے میٹرکس کی ایک بڑی مقدار جمع کرتا ہے۔ مائیکرو سروسز آرکیٹیکچر میں، اگر ایک API کی درخواست کو مائیکرو سروسز A، B، C، اور D سے گزرنا ضروری ہے، تو لاگ ان ہونے پر، تقسیم شدہ ٹریسنگ درخواست میں ایک منفرد شناخت کنندہ کا اضافہ کرے گی اور اس شناخت کنندہ کو ان تمام مائیکرو سروسز کی ذیلی درخواستوں کے ذریعے اسٹور کرے گی، تمام متعلقہ کالز کیپچر کی جانی ہیں۔ تاخیر وغیرہ۔
تیار کریں یا خریدیں۔
Istio پیچیدہ ہونے کی شہرت رکھتا ہے۔ اس کے برعکس، روٹنگ میش کی تعمیر جو میں نے اس پوسٹ کے شروع میں بیان کی ہے موجودہ ٹولز کا استعمال کرتے ہوئے نسبتاً آسان ہے۔ تو، کیا اس کے بجائے اپنی سروس میش بنانا کوئی معنی رکھتا ہے؟
اگر ہماری معمولی ضروریات ہیں (ہمیں مرئیت، ایک سرکٹ بریکر اور دیگر باریکیوں کی ضرورت نہیں ہے)، تو سوچیں اپنے آلے کو تیار کرنے کے لیے آئیں۔ لیکن اگر ہم Kubernetes استعمال کرتے ہیں، تو شاید اس کی ضرورت بھی نہ پڑے کیونکہ Kubernetes پہلے سے ہی سروس کی دریافت اور لوڈ بیلنسنگ کے لیے بنیادی ٹولز فراہم کرتا ہے۔
لیکن اگر ہمارے پاس جدید تقاضے ہیں، تو سروس میش کی "خریداری" ایک بہت بہتر آپشن معلوم ہوتی ہے۔ (یہ ہمیشہ "خرید" نہیں ہوتا ہے کیونکہ اسٹیو اوپن سورس ہے، لیکن ہمیں اسے سمجھنے، تعینات کرنے اور اس کا نظم کرنے کے لیے اب بھی انجینئرنگ میں وقت لگانے کی ضرورت ہے۔)
کیا مجھے Istio، Linkerd یا Consul Connect کا انتخاب کرنا چاہیے؟
اب تک ہم نے صرف Istio کے بارے میں بات کی ہے، لیکن یہ واحد سروس میش نہیں ہے۔ مقبول متبادل - ، اور زیادہ ہے .
کیا انتخاب کرنا ہے؟
سچ میں، میں نہیں جانتا. اس وقت میں اپنے آپ کو اس سوال کا جواب دینے کا اہل نہیں سمجھتا۔ ایسے چند ہی ہیں ان ٹولز کے موازنہ کے ساتھ اور یہاں تک کہ .
ایک امید افزا نقطہ نظر ایک ٹول جیسے استعمال کرنا ہے۔ . یہ سروس میشز کے ذریعے سامنے آنے والے APIs کو آسان اور متحد کرنے کے لیے ایک تجریدی پرت کو لاگو کرتا ہے۔ مختلف سروس میشز کے مخصوص (اور، میری رائے میں، نسبتاً پیچیدہ) APIs کو سیکھنے کے بجائے، ہم SuperGloo کے آسان کنسٹرکٹس کو استعمال کر سکتے ہیں - اور آسانی سے ایک سے دوسرے میں سوئچ کر سکتے ہیں، گویا ہمارے پاس ایک انٹرمیڈیٹ کنفیگریشن فارمیٹ ہے جس میں HTTP انٹرفیس اور بیک اینڈز کو بیان کرنے کے قابل ہے۔ Nginx، HAProxy، Traefik، Apache کے لیے اصل کنفیگریشن تیار کرنے کی...
میں نے Istio اور SuperGloo کے ساتھ تھوڑا سا کام کیا ہے، اور اگلے مضمون میں میں یہ دکھانا چاہتا ہوں کہ کس طرح Istio یا Linkerd کو SuperGloo کا استعمال کرتے ہوئے موجودہ کلسٹر میں شامل کیا جائے، اور بعد میں کام کیسے ہوتا ہے، یعنی آپ کو اس سے سوئچ کرنے کی اجازت دیتا ہے۔ کنفیگریشنوں کو اوور رائٹ کیے بغیر ایک سروس دوسرے کو میش کرتی ہے۔
ماخذ: www.habr.com