مائڪرو سروسز جي متحرڪ دنيا ۾، ڪا به شيءِ تبديل ٿي سگهي ٿي- ڪنهن به جزو کي مختلف فريم ورڪ ۽ فن تعمير استعمال ڪندي، مختلف ٻولي ۾ ٻيهر لکي سگهجي ٿو. صرف معاهدن کي تبديل نه ٿيڻ گهرجي ته جيئن مائڪرو سروس ٻاهران ڪجهه مستقل بنيادن تي رابطو ڪري سگهجي، اندروني ميٽامورفوسس کان سواءِ. ۽ اڄ اسان اسان جي مسئلي جي باري ۾ ڳالهائينداسين هڪ فارميٽ چونڊڻ جي معاهدي کي بيان ڪرڻ لاء ۽ حصيداري ڪريو جيڪي اسان مليا آهن.
پوسٽ تيار и
Microservices. جڏهن Acronis سائبر ڪلائوڊ کي ترقي ڪندي، اسان محسوس ڪيو ته اسان انهن کان بچي نه سگهنداسين. ۽ هڪ microservice ڊزائين ڪرڻ ناممڪن آهي بغير معاهدي کي رسمي ڪرڻ کان سواء، جيڪو مائڪرو سروس جي انٽرفيس جي نمائندگي ڪري ٿو.
پر جڏهن هڪ پراڊڪٽ هڪ کان وڌيڪ جزن تي مشتمل هجي، ۽ ڪانٽريڪٽ ڊولپمينٽ هڪ باقاعده سرگرمي بڻجي وڃي، ته توهان مدد نٿا ڪري سگهو پر عمل جي اصلاح بابت سوچڻ شروع ڪريو. اهو واضح ٿئي ٿو ته انٽرفيس (معاهدو) ۽ عمل درآمد (مائڪرو سروس) هڪ ٻئي سان ملن ٿا، مختلف حصن کي ساڳئي طريقي سان ساڳيو ڪم ڪرڻ گهرجي، ۽ انهن سڀني فيصلن جي مرڪزي فيصلي جي بغير، هر ٽيم کي مجبور ڪيو ويندو. ان کي حاصل ڪرڻ لاء بار بار وقت گذاريو.
Amazon microservices diagram from ورنر ووگلس، CTO Amazon
dilema ڇا آهي؟ حقيقت ۾، مائڪرو سروسز سان رابطو ڪرڻ جا ٻه طريقا آهن - گوگل کان HTTP باقي ۽ gRPC. گوگل جي ٽيڪنالاجي اسٽيڪ ۾ پڪڙڻ نه چاهيو، اسان چونڊيو HTTP باقي. HTTP REST معاهدي جون تشريحون اڪثر ڪري بيان ڪيون وينديون آھن ھڪڙي ٻن فارميٽ ۾: RAML ۽ OAS، اڳ ۾ سوگر جي نالي سان سڃاتل آھن، تنھنڪري، ھر ڊولپمينٽ ٽيم کي ھڪڙي معيار کي چونڊڻ جي ضرورت آھي. پر جيئن اهو نڪتو، اهو انتخاب ڪرڻ تمام ڏکيو ٿي سگهي ٿو.
تشريح جي ضرورت ڇو آهي؟
تشريح جي ضرورت آهي ته جيئن هڪ خارجي صارف آساني سان اهو معلوم ڪري سگهي ته توهان جي خدمت سان ان جي HTTP انٽرفيس ذريعي ڇا ڪري سگهجي ٿو. اهو آهي، بنيادي سطح تي، تشريح ۾ گهٽ ۾ گهٽ موجود وسيلن جي هڪ فهرست، انهن جي HTTP طريقن، درخواستن جي باڊي، پيرا ميٽرن جي لسٽ، گهربل ۽ سپورٽ ڪيل هيڊرز جو اشارو، گڏوگڏ واپسي جا ڪوڊ ۽ جوابي فارميٽ شامل هجڻ گهرجن. معاهدي جي تشريح جو هڪ انتهائي اهم عنصر انهن جي زباني وضاحت آهي (“ڇا ٿيندو جيڪڏهن توهان هن سوال جي پيٽرولر کي درخواست ۾ شامل ڪيو؟”، “ڪهڙي صورت ۾ ڪوڊ 400 واپس ڪيو ويندو؟”)
تنهن هوندي، جڏهن اهو اچي ٿو ته وڏي تعداد ۾ مائڪرو سروسز کي ترقي ڪرڻ لاء، توهان لکڻ چاهيو ٿا اضافي قيمت لکڻ جي تشريح مان. مثال طور، RAML/Swagger جي بنياد تي، توھان ٺاھي سگھوٿا ڪلائنٽ ۽ سرور ڪوڊ ٻئي وڏي تعداد ۾ پروگرامنگ ٻولين ۾. توھان پڻ حاصل ڪري سگھوٿا مائيڪرو سروس لاءِ دستاويز پاڻمرادو ۽ ان کي اپلوڊ ڪريو پنھنجي ڊولپر-پورٽل تي :).
هڪ منظم معاهدي جي وضاحت جو مثال
گهٽ عام آهي جانچڻ جو رواج مائڪرو سروسز جي بنياد تي معاهدي جي وضاحتن تي. جيڪڏهن توهان هڪ تشريح ۽ جزو ٻنهي لکيو آهي، ته پوءِ توهان هڪ خودڪار ٽيسٽ ٺاهي سگهو ٿا جيڪو مختلف قسم جي ان پٽ ڊيٽا سان خدمت جي مناسبيت کي چيڪ ڪري ٿو. ڇا خدمت هڪ جوابي ڪوڊ واپس ڏئي ٿو جيڪو تشريح ۾ بيان نه ڪيو ويو آهي؟ ڇا اهو صحيح طريقي سان عمل ڪرڻ جي قابل هوندو واضح طور تي غلط ڊيٽا؟
ان کان علاوه، نه رڳو پاڻ کي معاهدي جي اعلي معيار تي عمل درآمد، پر تجزيي کي ڏسڻ لاء اوزار پڻ مائڪرو سروس سان ڪم کي آسان بڻائي ٿو. اهو آهي، جيڪڏهن معمار هڪ اعلي معيار جي انداز ۾ معاهدي کي بيان ڪيو آهي، ان جي بنياد تي، ڊزائنر ۽ ڊولپرز اضافي وقت جي قيمت کان سواء ٻين شين ۾ خدمت لاڳو ڪندا.
اضافي اوزار کي فعال ڪرڻ لاء، RAML ۽ OAS ٻنهي کي ميٽاداٽ شامل ڪرڻ جي صلاحيت آهي جيڪا معيار طرفان فراهم نه ڪئي وئي آهي ().
عام طور تي، مائڪرو سروسز لاءِ معاهدو استعمال ڪرڻ ۾ تخليقيت جو دائرو تمام وڏو آهي... گهٽ ۾ گهٽ نظريي ۾.
نانگ سان هيج هاگ جو مقابلو
في الحال، Acronis تي ترجيحي ترقي وارو علائقو Acronis سائبر پليٽ فارم جي ترقي آهي. Acronis سائبر پليٽ فارم Acronis Cyber Cloud ۽ ايجنٽ حصو سان ٽئين پارٽي جي خدمتن جي انضمام جا نوان نقطا آهن. جيتوڻيڪ اسان RAML ۾ بيان ڪيل اسان جي اندروني APIs سان خوش هئاسين، API کي شايع ڪرڻ جي ضرورت ٻيهر چونڊ جو سوال اٿاريو: اسان جي ڪم لاءِ ڪهڙي تشريح جو معيار استعمال ڪرڻ بهتر آهي؟
شروعات ۾، اهو لڳي ٿو ته اتي ٻه حل هئا - سڀ کان وڌيڪ عام ترقيات RAML ۽ Swagger (يا OAS) هئا. پر حقيقت ۾ اهو ظاهر ٿيو ته گهٽ ۾ گهٽ 2 متبادل نه آهن، پر 3 يا وڌيڪ.
هڪ پاسي تي RAML آهي - هڪ طاقتور ۽ موثر ٻولي. اهو درجه بندي ۽ وراثت کي چڱي طرح لاڳو ڪري ٿو، تنهنڪري هي فارميٽ وڏين ڪمپنين لاءِ وڌيڪ موزون آهي جن کي تمام گهڻي وضاحت جي ضرورت آهي - اهو آهي، هڪ پراڊڪٽ نه، پر ڪيتريون ئي مائڪرو سروسز جن ۾ معاهدن جا عام حصا آهن - تصديق واري اسڪيم، ساڳي ڊيٽا جا قسم، غلطيون جسم .
پر RAML جو ڊولپر، Mulesoft، Open API ڪنسورشيم ۾ شامل ٿيو، جيڪو ترقي ڪري رهيو آهي . تنهن ڪري، RAML ان جي ترقي کي معطل ڪيو. واقعي جي شڪل کي تصور ڪرڻ لاء، تصور ڪريو ته مکيه لينڪس اجزاء جي سنڀاليندڙن کي Microsoft تي ڪم ڪرڻ لاء ڇڏي ويو. اها صورتحال سويگر استعمال ڪرڻ لاءِ شرطون پيدا ڪري ٿي، جيڪا متحرڪ طور تي ترقي ڪري رهي آهي ۽ جديد - ٽيون نسخو - عملي طور تي RAML سان لچڪدار ۽ ڪارڪردگي جي لحاظ کان پڪڙي ٿي.
جيڪڏهن هڪ شيء لاء نه ...
جيئن ته اهو نڪتو، سڀني اوپن سورس افاديت کي اپڊيٽ نه ڪيو ويو آهي OAS 3.0 ڏانهن. Go ۾ مائڪرو سروسز لاءِ ، سڀ کان وڌيڪ نازڪ شيءِ موافقت جي کوٽ هوندي معيار جي جديد ورزن لاءِ. بهرحال، Swagger 2 ۽ Swagger 3 جي وچ ۾ فرق آهي . مثال طور، ٽئين ورزن ۾ ڊولپرز:
- تصديق جي اسڪيمن جي بهتر وضاحت
- JSON اسڪيما سپورٽ
- مثال شامل ڪرڻ جي صلاحيت کي وڌايو
صورتحال عجيب آهي: جڏهن هڪ معيار چونڊيو، توهان کي غور ڪرڻو پوندو RAML، Swagger 2 ۽ Swagger 3 الڳ الڳ متبادل طور. بهرحال، صرف Swagger 2 وٽ OpenSource Tools لاءِ سٺي مدد آهي. RAML تمام لچڪدار ۽ پيچيده آھي، ۽ Swagger 3 ناقص طور تي ڪميونٽي جي مدد سان آھي، تنھنڪري توھان کي ملڪيت جا اوزار يا تجارتي حل استعمال ڪرڻا پوندا، جيڪي گھڻو قيمتي ھوندا آھن.
ان کان علاوه، جيڪڏهن سويگر ۾ ڪيتريون ئي سٺيون خاصيتون آهن، جهڙوڪ هڪ تيار ڪيل پورٽل ، جنهن تي توهان هڪ تشريح اپلوڊ ڪري سگهو ٿا ۽ تفصيلي وضاحت سان ان جو نقشو حاصل ڪري سگهو ٿا، لنڪس ۽ ڪنيڪشن، پوءِ وڌيڪ بنيادي ۽ گهٽ دوستانه RAML لاءِ اهڙو ڪو موقعو ناهي. ها، توهان GitHub تي منصوبن جي وچ ۾ ڪجهه ڳولي سگهو ٿا، اتي هڪ اينالاگ ڳوليو ۽ ان کي پنهنجو پاڻ کي ترتيب ڏيو. بهرحال، ڪنهن به صورت ۾، ڪنهن کي پورٽل کي برقرار رکڻو پوندو، جيڪو بنيادي استعمال يا جانچ جي ضرورتن لاء ايترو آسان ناهي. ان کان علاوه، swagger وڌيڪ "غير اصولي"، يا وڌيڪ لبرل آهي - اهو ڪوڊ ۾ تبصرن مان پيدا ٿي سگهي ٿو، جيڪو، يقينا، API جي پهرين اصول جي خلاف آهي ۽ ڪنهن به RAML افاديت جي حمايت نه ڪئي وئي آهي.
هڪ دفعي اسان هڪ وڌيڪ لچڪدار ٻولي طور RAML سان ڪم ڪرڻ شروع ڪيو، ۽ نتيجي طور اسان کي پنهنجو پاڻ کي گهڻو ڪجهه ڪرڻو پيو. مثال طور، ھڪڙو منصوبو استعمال ڪري ٿو افاديت يونٽ ٽيسٽ ۾، جيڪو صرف RAML 0.8 کي سپورٽ ڪري ٿو. تنهن ڪري اسان کي بيچين کي شامل ڪرڻو پيو ته جيئن افاديت RAML ورزن 1.0 کي ”کائي“ سگهي.
ڇا توهان کي چونڊڻ جي ضرورت آهي؟
RAML لاءِ حلن جي ماحولياتي نظام کي مڪمل ڪرڻ تي ڪم ڪرڻ کان پوءِ، اسان ان نتيجي تي پهتاسين ته اسان کي RAML کي Swagger 2 ۾ تبديل ڪرڻو پوندو ۽ ان ۾ سڀ آٽوميشن، تصديق، جاچ ۽ بعد ۾ اصلاح ڪرڻ جي ضرورت آهي. هي RAML جي لچڪ ۽ سوگر کان ڪميونٽي ٽولنگ سپورٽ ٻنهي جو فائدو وٺڻ جو هڪ سٺو طريقو آهي.
هن مسئلي کي حل ڪرڻ لاء، اتي ٻه OpenSource اوزار آهن جن کي معاهدو تبديل ڪرڻ گهرجي:
- هڪ في الحال اڻ سڌريل افاديت آهي. ان سان گڏ ڪم ڪرڻ دوران، اسان دريافت ڪيو ته ان ۾ پيچيده RAMLs سان گڏ ڪيترائي مسئلا آھن جيڪي وڏي تعداد ۾ فائلن تي "پکڙيل" آھن. هي پروگرام جاوا اسڪرپٽ ۾ لکيو ويو آهي ۽ هڪ نحوي وڻ جي ٻيهر ورجائي ٿو. متحرڪ ٽائپنگ جي ڪري، هن ڪوڊ کي سمجهڻ ڏکيو ٿي پوي ٿو، تنهنڪري اسان فيصلو ڪيو آهي ته وقت ضايع نه ڪيو وڃي هڪ مرڻ واري يوٽيلٽي لاءِ پيچ لکڻ ۾.
- - ساڳئي ڪمپني مان هڪ اوزار جيڪو دعوي ڪري ٿو ته هر شيء ۽ هر شيء کي تبديل ڪرڻ لاء تيار آهي، ۽ ڪنهن به طرف. تاريخ تائين، RAML 0.8، RAML 1.0 ۽ Swagger 2.0 لاءِ سپورٽ جو اعلان ڪيو ويو آھي. بهرحال، اسان جي تحقيق جي وقت تي، افاديت اڃا تائين هئي نم ۽ ناقابل استعمال. ڊولپرز هڪ قسم ٺاهي انهن کي جلدي مستقبل ۾ نوان معيار شامل ڪرڻ جي اجازت ڏئي ٿي. پر هينئر تائين اهو صرف ڪم نٿو ڪري.
۽ اهي سڀ مشڪلاتون نه آهن جن جو اسان سامنا ڪيو. اسان جي پائپ لائن ۾ قدمن مان هڪ تصديق ڪرڻ آهي ته مخزن مان RAML صحيح آهي تفصيل سان لاڳاپيل. اسان ڪيترن ئي افاديت جي ڪوشش ڪئي. حيرت انگيز طور تي، اهي سڀئي اسان جي تشريح تي مختلف هنڌن تي ۽ مڪمل طور تي مختلف خراب لفظن سان قسم کڻندا هئا. ۽ نه هميشه نقطي تي :).
آخر ۾، اسان هڪ پراڻي منصوبي تي آباد ٿيا، جنهن ۾ پڻ ڪيترائي مسئلا آهن (ڪڏهن ڪڏهن اهو نيري مان حادثو ٿيندو آهي، مسئلا آهن جڏهن باقاعده اظهار سان ڪم ڪري رهيا آهن). ان ڪري، اسان مفت اوزار جي بنياد تي تصديق ۽ تبادلي جي مسئلن کي حل ڪرڻ جو ڪو طريقو نه ڳولي ورتو، ۽ هڪ تجارتي افاديت کي استعمال ڪرڻ جو فيصلو ڪيو. مستقبل ۾، جيئن OpenSource اوزار وڌيڪ بالغ ٿي ويندا آهن، اهو مسئلو حل ڪرڻ آسان ٿي سگهي ٿو. ساڳئي وقت ۾، "ختم ڪرڻ" لاء محنت ۽ وقت جي قيمت اسان کي تجارتي خدمت جي قيمت کان وڌيڪ اهم لڳي ٿي.
ٿڪل
ان کان پوءِ، اسان چاهيون ٿا ته پنهنجو تجربو شيئر ڪريو ۽ ياد رکو ته معاهدن جي وضاحت لاءِ هڪ اوزار چونڊڻ کان اڳ، توهان کي واضح طور تي بيان ڪرڻ جي ضرورت آهي ته توهان ان مان ڇا چاهيو ٿا ۽ توهان ڪهڙي بجيٽ ۾ سيڙپڪاري ڪرڻ چاهيو ٿا. جيڪڏهن اسان OpenSource جي باري ۾ وساري ويٺا آهيون، اتي اڳ ۾ ئي خدمتون ۽ پراڊڪٽس جو هڪ وڏو تعداد موجود آهي جيڪي توهان کي چيڪ ڪرڻ، تبديل ڪرڻ، ۽ تصديق ڪرڻ ۾ مدد ڪندا. پر اهي قيمتي آهن، ۽ ڪڏهن ڪڏهن تمام قيمتي. هڪ وڏي ڪمپني لاءِ، اهڙيون قيمتون قابل برداشت آهن، پر شروعاتي لاءِ اهي هڪ وڏو بوجھ بڻجي سگهن ٿا.
اوزار جي سيٽ جو اندازو لڳايو جيڪو توهان بعد ۾ استعمال ڪندا. مثال طور، جيڪڏهن توهان کي صرف هڪ معاهدو ظاهر ڪرڻ جي ضرورت آهي، اهو استعمال ڪرڻ آسان ٿيندو Swagger 2، جنهن ۾ هڪ خوبصورت API آهي، ڇاڪاڻ ته RAML ۾ توهان کي خدمت پاڻ ٺاهڻ ۽ برقرار رکڻو پوندو.
توهان وٽ جيترا وڌيڪ ڪم هوندا، اوترو وڌيڪ اوزارن جي ضرورت هوندي، ۽ اهي مختلف پليٽ فارمن لاءِ مختلف هوندا، ۽ اهو بهتر آهي ته فوري طور تي دستياب نسخن سان پاڻ کي واقف ڪيو وڃي ته جيئن مستقبل ۾ توهان جي قيمتن کي گهٽائي سگهجي.
پر اهو سمجهڻ جي قابل آهي ته سڀ ماحولياتي نظام جيڪي اڄ موجود آهن ناقص آهن. تنهن ڪري، جيڪڏهن ڪمپني ۾ اهڙا مداح آهن جيڪي RAML ۾ ڪم ڪرڻ پسند ڪن ٿا ڇاڪاڻ ته "اهو توهان کي وڌيڪ لچڪدار خيالن جو اظهار ڪرڻ جي اجازت ڏئي ٿو،" يا، ان جي برعڪس، ترجيح ڏيو Swagger ڇاڪاڻ ته "اهو صاف آهي،" اهو بهتر آهي ته انهن کي ڪم ڪرڻ لاء ڇڏي ڏيو. ان ۾ جيڪي اھي آھن اھي ان لاءِ استعمال ڪيا ويا آھن ۽ اھو چاھيو ٿا، ڇاڪاڻ ته ڪنھن به فارميٽ جا اوزار فائل سان تبديل ڪرڻ جي ضرورت آھي.
جيئن اسان جي تجربي لاءِ، هيٺ ڏنل پوسٽن ۾ اسين ڳالهائينداسين ته اسان ڪهڙي جامد ۽ متحرڪ چيڪ ڪندا آهيون اسان جي RAML-Swagger آرڪيٽيڪچر جي بنياد تي، انهي سان گڏ اسان ڪهڙي دستاويز ٺاهيندا آهيون معاهدن مان، ۽ اهو سڀ ڪيئن ڪم ڪري ٿو.
صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. ، توهان جي مهرباني.
microservice ٺيڪيدارن کي بيان ڪرڻ لاءِ توهان ڪهڙي ٻولي استعمال ڪندا آهيو؟
-
RAML 0.8
-
RAML 1.0
-
ٻرندڙ 2
-
OAS3 (اڪا)
-
بلڊنگ
-
ٻيا
-
استعمال نه ڪرڻ
100 صارفين ووٽ ڪيو. 24 استعمال ڪندڙن کي روڪيو ويو.
جو ذريعو: www.habr.com