Mikroservislarning dinamik dunyosida hamma narsa o'zgarishi mumkin - har qanday komponent boshqa tilda, turli ramkalar va arxitekturadan foydalangan holda qayta yozilishi mumkin. Faqat shartnomalar o'zgarishsiz qolishi kerak, shunda mikroservis ichki metamorfozalardan qat'i nazar, tashqi tomondan doimiy ravishda o'zaro ta'sir qilishi mumkin. Va bugun biz shartnomalarni tavsiflash formatini tanlash muammosi haqida gaplashamiz va topilgan artefaktlarni baham ko'ramiz.
Post tayyorlandi и
Mikroservislar. Acronis Cyber Cloud-ni ishlab chiqishda biz ulardan qochib qutula olmasligimizni angladik. Mikroservisni loyihalash esa mikroservis interfeysini ifodalovchi shartnomani rasmiylashtirmasdan mumkin emas.
Ammo mahsulot tarkibida bir nechta komponentlar mavjud bo‘lsa va shartnomani ishlab chiqish muntazam faoliyatga aylanib qolsa, jarayonni optimallashtirish haqida o‘ylashdan boshqa ilojingiz yo‘q. Ko'rinib turibdiki, interfeys (shartnoma) va amalga oshirish (mikroservis) bir-biriga mos kelishi kerak, turli komponentlar bir xil ishlarni bir xil tarzda bajarishi kerak va bu qarorlarning barchasini markazlashtirilgan holda qabul qilmasdan, har bir jamoa majbur bo'ladi. ularni olish uchun yana va yana vaqt sarflash.
Amazon mikroxizmatlari diagrammasidan Verner Vogelis, Amazon texnik direktori
Dilemma nima? Haqiqatan ham, mikroservislar bilan o'zaro ishlashning ikkita usuli mavjud - HTTP Rest va Google'dan gRPC. Google texnologiya stekiga tushib qolishni istamay, biz HTTP Rest-ni tanladik. HTTP REST kontrakt annotatsiyalari ko'pincha ikkita formatdan birida tavsiflanadi: RAML va OAS, ilgari Swagger nomi bilan tanilgan.Shuning uchun har bir ishlab chiqish guruhi standartlardan birini tanlash zarurati bilan duch keladi. Ammo ma'lum bo'lishicha, bu tanlovni amalga oshirish juda qiyin bo'lishi mumkin.
Nima uchun izohlar kerak?
Izoh tashqi foydalanuvchi HTTP interfeysi orqali xizmatingiz bilan nima qilish mumkinligini osongina aniqlashi uchun kerak. Ya'ni, asosiy darajada, izoh kamida mavjud resurslar ro'yxatini, ularning HTTP usullarini, so'rov organlarini, parametrlar ro'yxatini, kerakli va qo'llab-quvvatlanadigan sarlavhalarni ko'rsatishni, shuningdek, qaytarish kodlari va javob formatlarini o'z ichiga olishi kerak. Shartnoma annotatsiyasining o'ta muhim elementi ularning og'zaki tavsifi ("agar siz ushbu so'rov parametrini so'rovga qo'shsangiz nima bo'ladi?", "qaysi holatda 400 kodi qaytariladi?")
Biroq, ko'p sonli mikroservislarni ishlab chiqish haqida gap ketganda, siz yozma izohlardan qo'shimcha qiymat olishni xohlaysiz. Masalan, RAML/Swagger asosida siz juda ko'p dasturlash tillarida mijoz va server kodlarini yaratishingiz mumkin. Shuningdek, siz mikroservis uchun hujjatlarni avtomatik ravishda olishingiz va uni dasturchi-portalingizga yuklashingiz mumkin :).
Strukturaviy shartnoma tavsifiga misol
Shartnoma tavsiflari asosida mikroservislarni sinovdan o'tkazish amaliyoti kamroq tarqalgan. Agar siz ham izoh, ham komponentni yozgan bo'lsangiz, unda siz xizmatning har xil turdagi kirish ma'lumotlari bilan muvofiqligini tekshiradigan avtotest yaratishingiz mumkin. Xizmat izohda tasvirlanmagan javob kodini qaytaradimi? U aniq noto'g'ri ma'lumotlarni to'g'ri qayta ishlay oladimi?
Bundan tashqari, nafaqat shartnomalarning o'zini, balki izohlarni vizualizatsiya qilish vositalarini ham yuqori sifatli amalga oshirish mikroservis bilan ishlashni soddalashtirishga imkon beradi. Ya'ni, agar me'mor shartnomani sifatli tasvirlab bergan bo'lsa, unga asoslanib, dizaynerlar va ishlab chiquvchilar xizmatni boshqa mahsulotlarda qo'shimcha vaqt sarfisiz amalga oshiradilar.
Qo'shimcha vositalarni yoqish uchun RAML ham, OAS ham standartda ko'zda tutilmagan metama'lumotlarni qo'shish imkoniyatiga ega ().
Umuman olganda, mikroservislar bo'yicha shartnomalardan foydalanishda ijodkorlik imkoniyatlari juda katta... hech bo'lmaganda nazariy jihatdan.
Kirpi bilan ilonni solishtirish
Hozirgi vaqtda Acronis-ni rivojlantirishning ustuvor yo'nalishi Acronis Cyber Platformasini ishlab chiqishdir. Acronis Cyber Platform - bu uchinchi tomon xizmatlarini Acronis Cyber Cloud va agent qismi bilan integratsiyalashning yangi nuqtalari. Biz RAMLda tasvirlangan ichki API-larimizdan mamnun bo'lsak-da, API-ni nashr qilish zarurati yana tanlov savolini tug'dirdi: ishimiz uchun qaysi annotatsiya standartidan foydalanish yaxshiroq?
Dastlab, ikkita yechim bordek tuyuldi - eng keng tarqalgan ishlanmalar RAML va Swagger (yoki OAS). Ammo, aslida, kamida 2 ta emas, balki 3 yoki undan ko'p alternativa borligi ma'lum bo'ldi.
Bir tomondan RAML - kuchli va samarali til. U ierarxiya va merosni yaxshi amalga oshiradi, shuning uchun bu format juda ko'p tavsiflarga muhtoj bo'lgan yirik kompaniyalar uchun ko'proq mos keladi - ya'ni bitta mahsulot emas, balki shartnomalarning umumiy qismlariga ega bo'lgan ko'plab mikroservislar - autentifikatsiya sxemalari, bir xil ma'lumotlar turlari, xato organlari. .
Ammo RAML ishlab chiqaruvchisi Mulesoft rivojlanayotgan Open API konsorsiumiga qo'shildi. . Shuning uchun RAML o'z rivojlanishini to'xtatdi. Tadbirning formatini tasavvur qilish uchun, asosiy Linux komponentlarini qo'llab-quvvatlovchilar Microsoft uchun ishlash uchun ketishganini tasavvur qiling. Bu holat Swagger-dan foydalanish uchun zarur shart-sharoitlarni yaratadi, u dinamik rivojlanmoqda va so'nggi - uchinchi versiyada - moslashuvchanlik va funksionallik nuqtai nazaridan RAMLni amalda ushlab turadi.
Agar bitta narsa bo'lmasa ...
Ma'lum bo'lishicha, barcha ochiq manbali yordamchi dasturlar OAS 3.0 ga yangilanmagan. Go'dagi mikroservislar uchun eng muhim narsa moslashuvning etishmasligi bo'ladi standartning so'nggi versiyasi uchun. Biroq, Swagger 2 va Swagger 3 o'rtasidagi farq . Masalan, uchinchi versiyada ishlab chiquvchilar:
- autentifikatsiya sxemalarining takomillashtirilgan tavsifi
- JSON sxemasini qo'llab-quvvatlash
- misollar qo'shish qobiliyatini oshirdi
Vaziyat kulgili: standartni tanlashda siz RAML, Swagger 2 va Swagger 3 ni alohida alternativa sifatida ko'rib chiqishingiz kerak. Biroq, faqat Swagger 2 OpenSource vositalarini yaxshi qo'llab-quvvatlaydi. RAML juda moslashuvchan... va murakkab va Swagger 3 hamjamiyat tomonidan kam qo'llab-quvvatlanadi, shuning uchun siz juda qimmatga tushadigan xususiy vositalar yoki tijorat echimlaridan foydalanishingiz kerak bo'ladi.
Bundan tashqari, agar Swagger-da juda ko'p yoqimli xususiyatlar mavjud bo'lsa, masalan, tayyor portal , unda siz izohni yuklashingiz va uning vizualizatsiyasini batafsil tavsif, havolalar va ulanishlar bilan olishingiz mumkin, keyin yanada fundamental va kamroq qulay RAML uchun bunday imkoniyat yo'q. Ha, siz GitHub-da loyihalar orasida biror narsani qidirishingiz, u erda analogni topishingiz va uni o'zingiz joylashtirishingiz mumkin. Biroq, har qanday holatda, kimdir asosiy foydalanish yoki sinov ehtiyojlari uchun unchalik qulay bo'lmagan portalni saqlab turishi kerak bo'ladi. Bundan tashqari, shafqatsizlik ko'proq "prinsipsiz" yoki ko'proq liberaldir - uni koddagi sharhlardan yaratish mumkin, bu, albatta, API birinchi printsipiga zid keladi va RAML yordam dasturlarining hech biri tomonidan qo'llab-quvvatlanmaydi.
Bir vaqtlar biz RAML bilan yanada moslashuvchan til sifatida ishlay boshladik va natijada biz ko'p narsalarni o'zimiz qilishimiz kerak edi. Misol uchun, loyihalardan biri yordamchi dasturdan foydalanadi faqat RAML 0.8 ni qo'llab-quvvatlaydigan birlik testlarida. Shunday qilib, yordamchi dastur RAML 1.0 versiyasini "yeyishi" uchun tayoqchalarni qo'shishimiz kerak edi.
Tanlash kerakmi?
RAML uchun echimlar ekotizimini to'ldirish ustida ish olib borganimizdan so'ng, biz RAMLni Swagger 2 ga aylantirishimiz va undagi barcha avtomatlashtirish, tekshirish, test va keyingi optimallashtirishni amalga oshirishimiz kerak degan xulosaga keldik. Bu RAMLning moslashuvchanligi va Swagger tomonidan jamoaviy vositalarni qo'llab-quvvatlashning yaxshi usuli.
Ushbu muammoni hal qilish uchun shartnoma konvertatsiyasini ta'minlaydigan ikkita OpenSource vositasi mavjud:
- hozirda qo‘llab-quvvatlanmaydigan yordamchi dastur hisoblanadi. U bilan ishlashda biz uning ko'p sonli fayllarga "tarqalgan" murakkab RAMLlar bilan bog'liq bir qator muammolari borligini aniqladik. Ushbu dastur JavaScript-da yozilgan va sintaksis daraxtining rekursiv o'tishini amalga oshiradi. Dinamik terish tufayli ushbu kodni tushunish qiyin bo'ladi, shuning uchun biz o'layotgan yordamchi dastur uchun yamoqlarni yozishga vaqt sarflamaslikka qaror qildik.
- - har qanday narsani va hamma narsani va har qanday yo'nalishda aylantirishga tayyor ekanligini da'vo qiladigan xuddi shu kompaniyaning vositasi. Bugungi kunga kelib, RAML 0.8, RAML 1.0 va Swagger 2.0 uchun qo'llab-quvvatlash e'lon qilindi. Biroq, bizning tadqiqotimiz vaqtida yordamchi dastur hali ham edi nam va foydalanishga yaroqsiz. Ishlab chiquvchilar bir turdagi yaratadilar , ularga kelajakda yangi standartlarni tezda qo'shish imkonini beradi. Lekin hozircha u shunchaki ishlamayapti.
Va bu biz duch kelgan barcha qiyinchiliklar emas. Bizning quvurimizdagi qadamlardan biri bu ombordagi RAML spetsifikatsiyaga nisbatan to'g'ri ekanligini tekshirishdir. Biz bir nechta yordamchi dasturlarni sinab ko'rdik. Ajablanarlisi shundaki, ularning barchasi bizning annotatsiyalarimizni turli joylarda va butunlay boshqacha yomon so'zlar bilan so'kishdi. Va har doim ham nuqtaga emas :).
Oxir-oqibat, biz eskirgan loyihaga qaror qildik, u ham bir qator muammolarga ega (ba'zida u kutilmaganda ishdan chiqadi, oddiy iboralar bilan ishlashda muammolar mavjud). Shunday qilib, biz bepul vositalar asosida tekshirish va konvertatsiya qilish muammolarini hal qilish yo'lini topa olmadik va tijorat yordam dasturidan foydalanishga qaror qildik. Kelajakda, OpenSource vositalari yanada etuklashgani sayin, bu muammoni hal qilish osonroq bo'lishi mumkin. Ayni paytda, "tugatish" uchun mehnat va vaqt xarajatlari bizga tijorat xizmatining narxidan ko'ra muhimroq bo'lib tuyuldi.
xulosa
Bularning barchasidan so'ng, biz o'z tajribamiz bilan o'rtoqlashmoqchi bo'ldik va shartnomalarni tavsiflash uchun vositani tanlashdan oldin, siz undan nimani xohlayotganingizni va qaysi byudjetga sarmoya kiritishga tayyor ekanligingizni aniq belgilashingiz kerakligini ta'kidlamoqchimiz. Agar biz OpenSource haqida unutsak, tekshirish, konvertatsiya qilish va tasdiqlashga yordam beradigan ko'plab xizmatlar va mahsulotlar allaqachon mavjud. Lekin ular qimmat, ba'zan esa juda qimmat. Katta kompaniya uchun bunday xarajatlarga chidash mumkin, biroq startap uchun ular katta yuk bo'lishi mumkin.
Keyinchalik foydalanadigan vositalar to'plamini aniqlang. Misol uchun, agar siz shunchaki shartnomani ko'rsatishingiz kerak bo'lsa, chiroyli API-ga ega Swagger 2-dan foydalanish osonroq bo'ladi, chunki RAML-da siz o'zingiz xizmatni yaratishingiz va unga xizmat ko'rsatishingiz kerak bo'ladi.
Vazifalaringiz qanchalik ko'p bo'lsa, asboblarga bo'lgan ehtiyoj shunchalik keng bo'ladi va ular turli platformalar uchun farq qiladi va kelajakda xarajatlaringizni minimallashtiradigan tanlov qilish uchun darhol mavjud versiyalar bilan tanishib chiqish yaxshiroqdir.
Ammo shuni tan olish kerakki, bugungi kunda mavjud bo'lgan barcha ekotizimlar nomukammaldir. Shuning uchun, agar kompaniyada RAMLda ishlashni yoqtiradigan muxlislar bo'lsa, chunki "bu sizga fikrlarni yanada moslashuvchan ifodalashga imkon beradi" yoki aksincha, "aniqroq" bo'lgani uchun Swaggerni afzal ko'rsa, ularni ishlashga qoldirish yaxshidir. Ular nima bo'lsa, ular bunga o'rganib qolgan va buni xohlashadi, chunki har qanday formatning vositalari fayl bilan o'zgartirishni talab qiladi.
Tajribamizga kelsak, keyingi postlarda biz RAML-Swagger arxitekturamiz asosida qanday statik va dinamik tekshiruvlar o'tkazishimiz, shuningdek, shartnomalardan qanday hujjatlarni yaratishimiz va bularning barchasi qanday ishlashi haqida gaplashamiz.
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Mikroservis shartnomalariga izoh berish uchun qaysi tildan foydalanasiz?
-
RAML 0.8
-
RAML 1.0
-
Swagger 2
-
OAS3 (aka)
-
loyiha
-
Boshqa
-
Foydalanilmayapti
100 nafar foydalanuvchi ovoz berdi. 24 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com