Í kraftmiklum heimi örþjónustunnar getur allt breyst - hvaða íhlut sem er er hægt að endurskrifa á öðru tungumáli með því að nota mismunandi ramma og arkitektúr. Aðeins samningar ættu að vera óbreyttir svo hægt sé að hafa samskipti við örþjónustuna utan frá á einhverjum varanlegum grundvelli, óháð innri myndbreytingum. Og í dag munum við tala um vandamál okkar við að velja snið til að lýsa samningum og deila gripunum sem við fundum.
Færsla undirbúin и
Örþjónusta. Við þróun Acronis Cyber Cloud áttuðum við okkur á því að við gátum ekki sloppið frá þeim. Og það er ómögulegt að hanna örþjónustu án þess að formfesta samninginn, sem táknar viðmót örþjónustunnar.
En þegar vara inniheldur fleiri en einn íhlut og samningagerð verður að reglulegri starfsemi, geturðu ekki annað en farið að hugsa um hagræðingu ferla. Það verður augljóst að viðmótið (samningurinn) og framkvæmdin (örþjónustan) verða að passa hvort við annað, að mismunandi hlutir verða að gera sömu hlutina á sama hátt og að án miðlægrar ákvarðanatöku allra þessara ákvarðana neyðist hvert lið til að eyða tíma aftur og aftur til að fá þá.
Amazon microservices skýringarmynd frá Werner Vogelis, tæknistjóri Amazon
Hvað er vandamálið? Reyndar eru tvær leiðir til að hafa samskipti við örþjónustur - HTTP Rest og gRPC frá Google. Þar sem við vildum ekki festast í tæknistafla Google, völdum við HTTP Rest. HTTP REST samningaskýringum er oftast lýst á einu af tveimur sniðum: RAML og OAS, áður þekkt sem Swagger.Þess vegna stendur hvert þróunarteymi frammi fyrir því að þurfa að velja einn af stöðlunum. En eins og það kemur í ljós getur verið mjög erfitt að velja þetta.
Af hverju er þörf á athugasemdum?
Skýringin er nauðsynleg svo að utanaðkomandi notandi geti auðveldlega fundið út hvað er hægt að gera við þjónustuna þína í gegnum HTTP viðmótið. Það er að segja að á grunnstigi verður skýringin að innihalda að minnsta kosti lista yfir tiltæk tilföng, HTTP-aðferðir þeirra, beiðnastofna, skráningu færibreyta, vísbendingu um nauðsynlega og studda hausa, svo og skilkóða og svarsnið. Afar mikilvægur þáttur í samningsskýringunni er munnleg lýsing þeirra ("hvað mun gerast ef þú bætir þessari fyrirspurnarfæribreytu við beiðnina?", "Í hvaða tilfelli verður kóða 400 skilað?")
Hins vegar, þegar það kemur að því að þróa mikinn fjölda örþjónustu, viltu draga viðbótargildi úr skrifuðu athugasemdunum. Til dæmis, byggt á RAML/Swagger, geturðu búið til bæði biðlara- og netþjónakóða á miklum fjölda forritunarmála. Þú getur líka sjálfkrafa fengið skjöl fyrir örþjónustuna og hlaðið því upp á þróunargáttina þína :).
Dæmi um skipulagða samningslýsingu
Sjaldgæfara er sú framkvæmd að prófa örþjónustur byggðar á samningslýsingum. Ef þú hefur skrifað bæði athugasemd og íhlut, þá getur þú búið til sjálfvirkt próf sem athugar hvort þjónustan sé fullnægjandi með ýmsum gerðum inntaksgagna. Skilar þjónustan svarkóða sem ekki er lýst í athugasemdinni? Mun það geta unnið rétt úr augljóslega röngum gögnum?
Þar að auki, hágæða útfærsla á ekki aðeins samningunum sjálfum, heldur einnig verkfærunum til að sjá skýringar, gerir það mögulegt að einfalda vinnuna með örþjónustunni. Það er að segja, ef arkitektinn lýsti samningnum á vandaðan hátt, út frá honum, munu hönnuðir og verktaki innleiða þjónustuna í aðrar vörur án viðbótartímakostnaðar.
Til að virkja viðbótarverkfæri hafa bæði RAML og OAS getu til að bæta við lýsigögnum sem ekki er kveðið á um í staðlinum ().
Almennt séð er svigrúmið fyrir sköpunargáfu í notkun samninga um smáþjónustu gríðarlegt... að minnsta kosti í orði.
Samanburður á broddgelti við snák
Eins og er er forgangsþróunarsvæðið hjá Acronis þróun Acronis Cyber Platform. Acronis Cyber Platform er nýr samþættingarstaður þriðja aðila þjónustu við Acronis Cyber Cloud og umboðsaðilahlutann. Þrátt fyrir að við værum ánægð með innri API sem lýst er í RAML, vakti þörfin á að birta API aftur spurninguna um val: hvaða athugasemdastaðal er best að nota fyrir vinnu okkar?
Upphaflega virtist sem það væru tvær lausnir - algengustu þróunin voru RAML og Swagger (eða OAS). En í rauninni kom í ljós að það eru að minnsta kosti ekki 2 kostir, heldur 3 eða fleiri.
Annars vegar er RAML - öflugt og skilvirkt tungumál. Það útfærir stigveldi og erfðir vel, þannig að þetta snið hentar betur fyrir stór fyrirtæki sem þurfa mikið af lýsingum - það er, ekki eina vöru, heldur margar örþjónustur sem hafa sameiginlega hluta samninga - auðkenningarkerfi, sömu gagnategundir, villueiningar .
En verktaki RAML, Mulesoft, hefur gengið til liðs við Open API hópinn, sem er að þróa . Því stöðvaði RAML þróun sína. Til að ímynda sér sniðið á viðburðinum, ímyndaðu þér að umsjónarmenn helstu Linux íhlutanna hafi farið að vinna hjá Microsoft. Þetta ástand skapar forsendur fyrir því að nota Swagger, sem er að þróast á kraftmikinn hátt og í nýjustu - þriðju útgáfunni - nær nánast upp á RAML hvað varðar sveigjanleika og virkni.
Ef ekki fyrir eitt...
Eins og það kemur í ljós hafa ekki öll opinn hugbúnaður verið uppfærður í OAS 3.0. Fyrir örþjónustur í Go mun það mikilvægasta vera skortur á aðlögun fyrir nýjustu útgáfu staðalsins. Hins vegar er munurinn á Swagger 2 og Swagger 3 . Til dæmis, í þriðju útgáfunni:
- bætt lýsing á auðkenningarkerfum
- JSON Schema stuðningur
- uppfærði getu til að bæta við dæmum
Staðan er fyndin: þegar þú velur staðal þarftu að íhuga RAML, Swagger 2 og Swagger 3 sem aðskilda valkosti. Hins vegar, aðeins Swagger 2 hefur góðan stuðning fyrir OpenSource verkfæri. RAML er mjög sveigjanlegt...og flókið, og Swagger 3 er illa studd af samfélaginu, svo þú verður að nota sértæk verkfæri eða viðskiptalausnir, sem hafa tilhneigingu til að vera frekar dýrar.
Þar að auki, ef það eru margir fínir eiginleikar í Swagger, svo sem tilbúna vefsíðu , þar sem þú getur hlaðið upp athugasemdum og fengið myndgerð þess með nákvæmri lýsingu, tenglum og tengingum, þá er ekkert slíkt tækifæri fyrir hið grundvallaratriði og minna vinalega RAML. Já, þú getur leitað að einhverju meðal verkefna á GitHub, fundið hliðstæðu þar og sett það upp sjálfur. Hins vegar, í öllum tilvikum, einhver verður að viðhalda gáttinni, sem er ekki svo þægilegt fyrir grunnnotkun eða prófunarþarfir. Að auki er swagger „reglulausari“ eða frjálslyndari - það er hægt að búa til úr athugasemdum í kóðanum, sem gengur auðvitað gegn API fyrstu reglunni og er ekki studd af neinum RAML tólum.
Á sínum tíma fórum við að vinna með RAML sem sveigjanlegra tungumál og þar af leiðandi þurftum við að gera ýmislegt sjálf. Til dæmis, eitt af verkefnum notar veituna í einingaprófum, sem styður aðeins RAML 0.8. Svo við urðum að bæta við hækjum svo að tólið gæti „borðað“ RAML útgáfu 1.0.
Þarftu að velja?
Eftir að hafa unnið að því að klára vistkerfi lausna fyrir RAML komumst við að þeirri niðurstöðu að við þurfum að breyta RAML í Swagger 2 og framkvæma alla sjálfvirkni, sannprófun, prófun og síðari hagræðingu í því. Þetta er góð leið til að nýta bæði sveigjanleika RAML og stuðning samfélagsins frá Swagger.
Til að leysa þetta vandamál eru tvö OpenSource verkfæri sem ættu að veita samningsumbreytingu:
- er óstudd tól sem stendur. Þegar við unnum með það komumst við að því að það hefur ýmis vandamál með flókin RAML sem er „dreift“ yfir mikinn fjölda skráa. Þetta forrit er skrifað í JavaScript og framkvæmir endurkvæma yfirferð á setningafræðitré. Vegna kraftmikillar vélritunar verður erfitt að skilja þennan kóða, svo við ákváðum að eyða ekki tíma í að skrifa plástra fyrir deyjandi tól.
- - tól frá sama fyrirtæki sem segist vera tilbúið til að breyta hverju sem er og í hvaða átt sem er. Hingað til hefur verið tilkynnt um stuðning fyrir RAML 0.8, RAML 1.0 og Swagger 2.0. Hins vegar, á þeim tíma sem rannsóknir okkar, var gagnsemi enn rakt og ónothæft. Hönnuðir búa til eins konar , sem gerir þeim kleift að bæta við nýjum stöðlum fljótt í framtíðinni. En hingað til gengur það bara ekki.
Og þetta eru ekki allir erfiðleikarnir sem við höfum lent í. Eitt af skrefunum í pípunni okkar er að sannreyna að RAML frá geymslunni sé rétt miðað við forskriftina. Við prófuðum nokkur tól. Það kemur á óvart að þeir blótuðu allir í athugasemdum okkar á mismunandi stöðum og með allt öðrum slæmum orðum. Og ekki alltaf til marks :).
Á endanum settumst við á nú úrelt verkefni, sem einnig hefur ýmis vandamál (stundum hrynur það út í bláinn, á í vandræðum þegar unnið er með regluleg segð). Þannig fundum við ekki leið til að leysa vandamálin við löggildingu og umbreytingu á grundvelli ókeypis verkfæra og ákváðum að nota viðskiptatól. Í framtíðinni, eftir því sem OpenSource verkfæri verða þroskaðri, gæti þetta vandamál orðið auðveldara að leysa. Í millitíðinni fannst okkur vinnu- og tímakostnaðurinn við að „fráganga“ mikilvægari en kostnaður við viðskiptaþjónustu.
Ályktun
Eftir allt þetta vildum við deila reynslu okkar og athuga að áður en þú velur verkfæri til að lýsa samningum þarftu að skilgreina skýrt hvað þú vilt af því og hvaða fjárhagsáætlun þú ert tilbúinn að fjárfesta. Ef við gleymum OpenSource, þá er nú þegar mikill fjöldi þjónustu og vara sem mun hjálpa þér að athuga, umbreyta og staðfesta. En þeir eru dýrir og stundum mjög dýrir. Fyrir stórt fyrirtæki er slíkur kostnaður þolanlegur, en fyrir gangsetningu getur hann orðið mikil byrði.
Ákvarðaðu verkfærasettið sem þú munt nota síðar. Til dæmis, ef þú þarft bara að sýna samning, þá verður auðveldara að nota Swagger 2, sem er með fallegt API, því í RAML verður þú að byggja upp og viðhalda þjónustunni sjálfur.
Því fleiri verkefni sem þú hefur, því víðtækari verður þörfin fyrir verkfæri, og þau eru mismunandi fyrir mismunandi vettvang, og það er betra að kynna þér strax tiltækar útgáfur til að velja sem lágmarkar kostnað þinn í framtíðinni.
En það er þess virði að viðurkenna að öll vistkerfi sem eru til í dag eru ófullkomin. Þess vegna, ef það eru aðdáendur í fyrirtækinu sem vilja vinna í RAML vegna þess að „það gerir þér kleift að tjá hugsanir á sveigjanlegri hátt,“ eða þvert á móti, kjósa Swagger vegna þess að „það er skýrara,“ er best að láta þá vinna í því sem þau eru. Þeir eru vanir því og vilja það, vegna þess að verkfæri hvers konar sniða þurfa að breyta með skrá.
Hvað reynslu okkar varðar, í eftirfarandi færslum munum við tala um hvaða kyrrstöðu og kraftmikil athuganir við framkvæmum út frá RAML-Swagger arkitektúr okkar, sem og hvaða skjöl við búum til úr samningum og hvernig þetta virkar allt saman.
Aðeins skráðir notendur geta tekið þátt í könnuninni. , takk.
Hvaða tungumál notar þú til að skrifa um smáþjónustusamninga?
-
RAML 0.8
-
RAML 1.0
-
Swagger 2
-
OAS3 (aka)
-
Teikning
-
Annað
-
Notar ekki
100 notendur greiddu atkvæði. 24 notendur sátu hjá.
Heimild: www.habr.com