د مایکرو خدماتو په متحرک نړۍ کې، هر څه بدلیدلی شي - هره برخه په مختلف ژبه کې بیا لیکل کیدی شي، د مختلف چوکاټونو او جوړښتونو په کارولو سره. یوازې قراردادونه باید بدله پاتې شي ترڅو د داخلي میټامورفوسس په پام کې نیولو پرته د مایکروسافټ خدمت په یو دایمي اساس له بهر څخه اړیکه ونیول شي. او نن به موږ د قراردادونو د بیانولو لپاره د شکل غوره کولو په اړه زموږ د ستونزې په اړه وغږیږو او هغه اثار چې موږ موندلي شریک کړو.
پوسټ چمتو شوی и
کوچني خدمتونه. کله چې د Acronis Cyber Cloud وده کول، موږ پوهیږو چې موږ نشو کولی له دوی څخه تیښته وکړو. او د مایکروسافټ ډیزاین کول د تړون له رسمي کولو پرته ناممکن دي ، کوم چې د مایکرو سرویس انٹرفیس استازیتوب کوي.
مګر کله چې یو محصول له یو څخه ډیر برخې ولري، او د قرارداد پراختیا یو منظم فعالیت شي، تاسو نشئ کولی مرسته وکړئ مګر د پروسې د اصلاح کولو په اړه فکر پیل کړئ. دا څرګنده شوه چې انٹرفیس (قرارداد) او پلي کول (مایروسروسس) باید یو له بل سره سمون ولري، دا چې مختلف برخې باید ورته شیان په ورته ډول ترسره کړي، او دا چې د دې ټولو پریکړو مرکزي پریکړې کولو پرته، هر ټیم به مجبور شي د دوی د ترلاسه کولو لپاره بیا بیا وخت مصرف کړئ.
د ایمیزون مایکرو سرویسس ډیاګرام څخه ورنر ووګیلس، CTO ایمیزون
مشکوکه څه ده؟ په حقیقت کې، د مایکرو خدماتو سره د متقابل عمل کولو دوه لارې شتون لري - د ګوګل څخه HTTP آرام او gRPC. نه غواړي چې د ګوګل په ټیکنالوژۍ سټیک کې راګیر شي، موږ د HTTP آرام غوره کړ. د HTTP REST قرارداد تشریحات اکثرا په دوو شکلونو کې تشریح شوي: RAML او OAS، چې پخوا د سویګر په نوم پیژندل شوي، له همدې امله، هر پرمختیایي ټیم د یو معیارونو غوره کولو اړتیا سره مخ کیږي. مګر لکه څنګه چې دا معلومه شوه، دا انتخاب کول خورا ستونزمن کیدی شي.
ولې تشریحاتو ته اړتیا ده؟
تشریح ته اړتیا ده ترڅو یو بهرنی کاروونکي په اسانۍ سره معلومه کړي چې ستاسو د خدماتو سره د دې HTTP انٹرفیس له لارې څه ترسره کیدی شي. دا، په بنسټیزه کچه، تشریح باید لږترلږه د شته سرچینو لیست، د دوی HTTP میتودونه، د غوښتنې بنسټونه، د پیرامیټونو لیست، د اړتیا وړ او ملاتړ شوي سرلیکونو نښه، او همدارنګه د بیرته راستنیدو کوډونه او د ځواب فارمیټونه ولري. د تړون د تشریح یو خورا مهم عنصر د دوی لفظي توضیحات دي ("څه به پیښ شي که تاسو د دې پوښتنې پیرامیټر په غوښتنې کې اضافه کړئ؟"، "په کوم حالت کې به کوډ 400 بیرته راشي؟")
په هرصورت، کله چې دا د لوی شمیر مایکرو خدماتو رامینځته کولو خبره راځي، تاسو غواړئ د لیکل شوي تشریحاتو څخه اضافي ارزښت استخراج کړئ. د مثال په توګه، د RAML/Swagger پر بنسټ، تاسو کولی شئ د ډیری پروګرامینګ ژبو کې د مراجعینو او سرور کوډ دواړه تولید کړئ. تاسو کولی شئ په اوتومات ډول د مایکرو سرویس لپاره اسناد ترلاسه کړئ او خپل پراختیا کونکي پورټل ته یې اپلوډ کړئ :).
د جوړ شوي قرارداد توضیح مثال
لږ عام د قرارداد توضیحاتو پراساس د مایکرو خدماتو ازموینې تمرین دی. که تاسو دواړه تشریحات او یوه برخه لیکلې وي، نو تاسو کولی شئ یو اتوماتیک ازموینه جوړه کړئ چې د مختلف ډول ان پټ ډیټا سره د خدماتو کافي اندازه چک کوي. ایا خدمت د ځواب کوډ بیرته راګرځوي چې په تشریح کې ندي تشریح شوي؟ ایا دا به وکولی شي په سمه توګه په ښکاره ډول غلط معلومات پروسس کړي؟
سربیره پردې ، نه یوازې پخپله د قراردادونو لوړ کیفیت پلي کول ، بلکه د توضیحاتو لید لپاره وسیلې هم دا امکان ورکوي چې د مایکرو سرویس سره کار ساده کړي. دا دی، که معمار په کیفیت سره قرارداد تشریح کړي، د هغې پر بنسټ، ډیزاینران او پراختیا کونکي به د اضافي وخت لګښت پرته په نورو محصولاتو کې خدمت پلي کړي.
د اضافي وسیلو فعالولو لپاره ، RAML او OAS دواړه د میټاډاټا اضافه کولو وړتیا لري چې د معیار لخوا ندي چمتو شوي ().
په عموم کې، د مایکرو خدماتو لپاره د قراردادونو کارولو کې د خلاقیت ساحه خورا لویه ده ... لږترلږه په تیوري کې.
د مار سره د هیج هاګ پرتله کول
اوس مهال، په اکرونیس کې د لومړیتوب پراختیا ساحه د اکرونیس سایبر پلیټ فارم پراختیا ده. د اکرونیس سایبر پلیټ فارم د اکرونیس سایبر کلاوډ او اجنټ برخې سره د دریمې ډلې خدماتو ادغام نوي ټکي دي. که څه هم موږ په RAML کې تشریح شوي زموږ د داخلي APIs څخه خوښ یو، د API خپرولو اړتیا بیا د انتخاب پوښتنه راپورته کړه: زموږ د کار لپاره د کوم تشریح معیار غوره دی؟
په پیل کې، داسې بریښي چې دوه حلونه شتون لري - ترټولو عام پرمختګونه RAML او Swagger (یا OAS) وو. مګر په حقیقت کې دا معلومه شوه چې لږترلږه 2 بدیلونه شتون نلري، مګر 3 یا ډیر.
له یوې خوا RAML شتون لري - یوه پیاوړې او اغیزمنه ژبه. دا درجه بندي او میراث په ښه توګه پلي کوي، نو دا بڼه د لوی شرکتونو لپاره خورا مناسبه ده چې ډیری توضیحاتو ته اړتیا لري - دا یو محصول نه دی، مګر ډیری کوچني خدمتونه چې د قراردادونو مشترکه برخې لري - د تصدیق سکیمونه، د ورته معلوماتو ډولونه، د غلطۍ بنسټونه .
مګر د RAML پراختیا کونکی، Mulesoft، د Open API کنسورشیم سره یوځای شوی، کوم چې وده کوي . له همدې امله، RAML خپل پراختیا وځنډوله. د پیښې ب formatه تصور کولو لپاره ، تصور وکړئ چې د اصلي لینکس اجزاو ساتونکي په مایکروسافټ کې کار کولو ته پاتې شوي. دا وضعیت د سویګر کارولو لپاره شرایط رامینځته کوي ، کوم چې په متحرک ډول وده کوي او په وروستي - دریم نسخه کې - په عملي ډول د انعطاف او فعالیت شرایطو کې د RAML سره یوځای کیږي.
که د یوې شی لپاره نه ...
لکه څنګه چې دا معلومه شوه، د خلاصې سرچینې ټولې اسانتیاوې OAS 3.0 ته نوي شوي ندي. په Go کې د مایکرو خدماتو لپاره، ترټولو مهم شی به د تطبیق نشتوالی وي د معیاري وروستي نسخې لپاره. په هرصورت، د سویګر 2 او سویګر 3 ترمنځ توپیر دی . د مثال په توګه، په دریمه نسخه کې پراختیا کونکي:
- د تصدیق کولو سکیمونو ښه توضیحات
- د JSON سکیما ملاتړ
- د مثالونو اضافه کولو وړتیا لوړول
وضعیت مسخره دی: کله چې یو معیار غوره کړئ، تاسو اړتیا لرئ چې RAML، Swagger 2 او Swagger 3 د جلا بدیلونو په توګه په پام کې ونیسئ. په هرصورت، یوازې سویګر 2 د OpenSource وسیلو لپاره ښه ملاتړ لري. RAML خورا انعطاف منونکی او پیچلی دی، او سویګر 3 د ټولنې لخوا په کمزوري ډول ملاتړ کیږي، نو تاسو باید د ملکیت وسیلې یا سوداګریز حلونه وکاروئ، کوم چې خورا ګران وي.
سربیره پردې ، که چیرې په سویګر کې ډیری ښې ځانګړتیاوې شتون ولري ، لکه چمتو شوی پورټل ، په کوم کې چې تاسو کولی شئ یو تشریح اپلوډ کړئ او د مفصل توضیحاتو ، لینکونو او ارتباطاتو سره یې لید ترلاسه کړئ ، بیا د ډیر بنسټیز او لږ دوستانه RAML لپاره داسې فرصت شتون نلري. هو ، تاسو کولی شئ په GitHub کې د پروژو په مینځ کې یو څه وپلټئ ، هلته یو انلاګ ومومئ او پخپله یې ځای په ځای کړئ. په هرصورت ، په هر حالت کې ، یو څوک باید پورټل وساتي ، کوم چې د لومړني کارونې یا ازموینې اړتیاو لپاره دومره مناسب ندي. سربیره پردې ، سویګر ډیر "غیر اصولي" ، یا ډیر لیبرال دی - دا په کوډ کې د نظرونو څخه رامینځته کیدی شي ، کوم چې البته د API لومړي اصول خلاف ځي او د هیڅ RAML اسانتیاوو لخوا نه ملاتړ کیږي.
په یو وخت کې موږ د RAML سره د ډیرې انعطاف وړ ژبې په توګه کار پیل کړ، او په پایله کې موږ باید پخپله ډیری شیان ترسره کړو. د مثال په توګه، یو له پروژو څخه کار اخلي په واحد ازموینو کې، کوم چې یوازې د RAML 0.8 ملاتړ کوي. نو موږ باید کرچچونه اضافه کړو ترڅو افادیت د RAML نسخه 1.0 "خوري" شي.
ایا تاسو اړتیا لرئ غوره کړئ؟
د RAML لپاره د حلونو د ایکوسیستم بشپړولو په اړه کار کولو سره، موږ دې پایلې ته ورسیدو چې موږ اړتیا لرو چې RAML په سویګر 2 کې بدل کړو او ټول اتوماتیک، تایید، ازموینې او ورپسې اصلاح ترسره کړو. دا د RAML انعطاف او د سویګر څخه د ټولنې وسیلې ملاتړ دواړو څخه ګټه پورته کولو لپاره یوه ښه لار ده.
د دې ستونزې د حل لپاره، د OpenSource دوه وسیلې شتون لري چې باید د قرارداد تبادله چمتو کړي:
- اوس مهال نه ملاتړ شوی یوټیلیټ دی. پداسې حال کې چې د دې سره کار کوي، موږ وموندله چې دا د پیچلو RAMLs سره یو شمیر ستونزې لري چې په لوی شمیر فایلونو کې "پراخ شوي" دي. دا برنامه په جاواسکریپټ کې لیکل شوې او د ترکیب ونې تکراري لیږد ترسره کوي. د متحرک ټایپ کولو له امله، د دې کوډ پوهیدل ستونزمن کیږي، نو موږ پریکړه وکړه چې د مړینې کارونې لپاره د پیچونو لیکلو وخت ضایع نکړو.
- - د ورته شرکت یوه وسیله چې ادعا کوي د هر څه او هرڅه بدلولو لپاره چمتو دی، او په هر لوري کې. تر اوسه پورې، د RAML 0.8، RAML 1.0 او سویګر 2.0 لپاره ملاتړ اعلان شوی. په هرصورت، زموږ د څیړنې په وخت کې، ګټورتیا لاهم وه لندبل او د کارولو وړ نه وي. پراختیا کونکي یو ډول رامینځته کوي ، دوی ته اجازه ورکوي چې ژر تر ژره په راتلونکي کې نوي معیارونه اضافه کړي. مګر تر دې دمه دا کار نه کوي.
او دا ټول هغه مشکلات ندي چې موږ ورسره مخ شوي یو. زموږ په پایپ لاین کې یو له مرحلو څخه دا تصدیق کول دي چې د ذخیره کولو څخه RAML د توضیحاتو سره سم سم دی. موږ ډیری اسانتیاوې هڅه کړې. په حیرانتیا سره، دوی ټول زموږ په تشریحاتو کې په مختلفو ځایونو او په بشپړ ډول په مختلفو بدو الفاظو قسم خوړل. او تل دې ټکي ته نه :).
په نهایت کې ، موږ په یوه پخوانۍ پروژه کې میشته شو ، کوم چې یو شمیر ستونزې هم لري (کله ناکله دا له نیلي څخه راوتلې ، د منظم بیان سره کار کولو پرمهال ستونزې لري). په دې توګه، موږ د وړیا وسیلو پراساس د اعتبار او تبادلې ستونزې حل کولو لپاره لاره ونه موندله، او پریکړه یې وکړه چې د سوداګریزې ګټې اخیستنې څخه کار واخلو. په راتلونکي کې، لکه څنګه چې د OpenSource وسایل ډیر بالغ کیږي، دا ستونزه ممکن د حل کولو لپاره اسانه شي. په ورته وخت کې، د "بشپړ کولو" لپاره د کار او وخت لګښتونه موږ ته د سوداګریزې خدماتو لګښت په پرتله خورا مهم ښکاري.
پایلې
له دې ټولو وروسته، موږ غوښتل خپله تجربه شریکه کړو او یادونه وکړو چې د قراردادونو تشریح کولو لپاره د یوې وسیلې غوره کولو دمخه، تاسو اړتیا لرئ په واضح ډول تعریف کړئ چې تاسو له دې څخه څه غواړئ او کومه بودیجه چې تاسو پانګه اچولو ته لیواله یاست. که موږ د OpenSource په اړه هیر کړو، دلته دمخه یو لوی شمیر خدمتونه او محصولات شتون لري چې تاسو سره به په چک کولو، بدلولو، او اعتبار کې مرسته وکړي. مګر دوی ګران دي، او ځینې وختونه خورا ګران دي. د لوی شرکت لپاره، دا ډول لګښتونه د زغم وړ دي، مګر د پیل لپاره دوی کولی شي لوی بار شي.
د وسیلو سیټ مشخص کړئ چې تاسو به یې وروسته کاروئ. د مثال په توګه ، که تاسو یوازې یو تړون ښودلو ته اړتیا لرئ ، نو د سویګر 2 کارول به اسانه وي ، کوم چې یو ښکلی API لري ، ځکه چې په RAML کې تاسو باید پخپله خدمت رامینځته او وساتئ.
څومره چې تاسو ډیر کارونه لرئ، د وسیلو اړتیا به پراخه وي، او دوی د مختلفو پلیټ فارمونو لپاره توپیر لري، او دا به غوره وي چې سمدلاسه د شته نسخو سره ځان وپیژني ترڅو داسې انتخاب وکړي چې په راتلونکي کې ستاسو لګښتونه کم کړي.
مګر دا د پیژندلو وړ ده چې ټول ایکوسیستمونه چې نن شتون لري نیمګړي دي. له همدې امله ، که چیرې په شرکت کې داسې مینه وال شتون ولري چې په RAML کې کار کول خوښوي ځکه چې "دا تاسو ته اجازه درکوي فکرونه په ډیر انعطاف سره څرګند کړئ" ، یا ، برعکس ، سویګر غوره کړئ ځکه چې "دا روښانه ده" ، نو غوره به وي چې دوی کار کولو ته پریږدئ. په هغه څه کې چې دوی دي ورسره عادت شوي او دا غواړي ، ځکه چې د هر ډول فارمیټ وسیلې د فایل سره ترمیم ته اړتیا لري.
زموږ د تجربې لپاره ، په لاندې پوسټونو کې به موږ د دې په اړه وغږیږو چې کوم جامد او متحرک چیکونه زموږ د RAML-Swagger جوړښت پراساس ترسره کوو ، او همدارنګه کوم اسناد چې موږ د تړونونو څخه تولید کوو ، او دا ټول څنګه کار کوي.
یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. مهرباني وکړئ
تاسو د مایکرو سرویس قراردادونو تشریح کولو لپاره کومه ژبه کاروئ؟
-
RAML 0.8
-
RAML 1.0
-
سوګند 2
-
OAS3 (اکا)
-
بلیو چاپ
-
نور
-
نه کارول
100 کاروونکو رایه ورکړه. 24 کاروونکي منع شوي.
سرچینه: www.habr.com