Mikrozerbitzuen mundu dinamikoan, edozer alda daiteke; edozein osagai beste hizkuntza batean berridatzi daiteke, esparru eta arkitektura desberdinak erabiliz. Kontratuak soilik mantendu behar dira aldatu gabe, mikrozerbitzuarekin kanpotik modu iraunkorrean elkarrekintzan egon dadin, barne metamorfosiak gorabehera. Eta gaur kontratuak deskribatzeko formatua aukeratzeko eta aurkitu ditugun artefaktuak partekatzeko dugun arazoari buruz hitz egingo dugu.
Posta prestatuta ΠΈ
Mikrozerbitzuak. Acronis Cyber ββββCloud garatzean, konturatu ginen ezin genuela ihes egin. Eta mikrozerbitzu bat diseinatzea ezinezkoa da kontratua formalizatu gabe, mikrozerbitzuaren interfazea adierazten duena.
Baina produktu batek osagai bat baino gehiago dituenean eta kontratuaren garapena ohiko jarduera bihurtzen denean, ezin duzu prozesuen optimizazioan pentsatzen hasi. Bistakoa da interfazea (kontratua) eta inplementazioa (mikrozerbitzua) bata bestearekin bat egin behar dutela, osagai ezberdinek gauza berdinak egin behar dituztela modu berean, eta erabaki horiek guztiak zentralizatuta hartu gabe, talde bakoitza behartuta egongo dela. denbora pasa behin eta berriro horiek lortzeko.
Amazon mikrozerbitzuen diagrama Werner Vogelis, Amazoneko zuzendaria
Zein da dilema? Izan ere, mikrozerbitzuekin elkarreragiteko bi modu daude: HTTP Rest eta Google-ren gRPC. Google-ren teknologia-pilak harrapatu nahi ez genuenez, HTTP Rest aukeratu genuen. HTTP REST kontratuaren oharrak bi formatuetako batean deskribatzen dira gehienetan: RAML eta OAS, lehen Swagger izenez ezagutzen zirenak.Hori dela eta, garapen-talde bakoitzak estandarren bat aukeratu beharraren aurrean dago. Baina itxura denez, aukeraketa hau egitea oso zaila izan daiteke.
Zergatik behar dira oharrak?
Oharpena beharrezkoa da kanpoko erabiltzaile batek zure zerbitzuarekin zer egin daitekeen bere HTTP interfazearen bidez erraz jakin dezan. Hau da, oinarrizko mailan, oharrak, gutxienez, baliabide erabilgarrien zerrenda, haien HTTP metodoak, eskaera-gorputzak, parametroen zerrenda, beharrezko eta onartzen diren goiburuen adierazpena eta itzulera kodeak eta erantzun-formatuak izan behar ditu. Kontratuaren oharpenaren elementu oso garrantzitsu bat haien hitzezko deskribapena da ("zer gertatzen da eskaerari kontsulta-parametro hau gehitzen badiozu?", "zein kasutan itzuliko da 400 kodea?")
Hala ere, mikrozerbitzu ugari garatzeko orduan, idatzizko oharpenetatik balio gehigarria atera nahi duzu. Adibidez, RAML/Swagger-en oinarrituta, bezero zein zerbitzari-kodeak sor ditzakezu programazio-lengoaia ugaritan. Automatikoki ere jaso dezakezu mikrozerbitzuaren dokumentazioa eta zure garatzaile-atarian kargatu :).
Kontratu egituratuaren deskribapenaren adibidea
Ez da hain ohikoa kontratuen deskribapenetan oinarritutako mikrozerbitzuak probatzeko praktika. Oharpen bat eta osagai bat idatzi badituzu, zerbitzuaren egokitasuna egiaztatzen duen autotest bat sor dezakezu sarrerako hainbat datu motarekin. Zerbitzuak oharpenean deskribatzen ez den erantzun-kode bat itzultzen al du? Okerrak diren datuak behar bezala prozesatu ahal izango al ditu?
Gainera, kontratuen ez ezik, oharrak ikusteko tresnek ere kalitate handiko ezarpenak mikrozerbitzuarekin lana erraztea ahalbidetzen du. Hau da, arkitektoak kontratua kualitatiboki deskribatzen badu, horretan oinarrituta, diseinatzaileek eta garatzaileek zerbitzua beste produktu batzuetan ezarriko dute denbora kostu gehigarririk gabe.
Tresna osagarriak gaitzeko, RAML eta OASek estandarrak ematen ez dituen metadatuak gehitzeko gaitasuna dute ().
Orokorrean, mikrozerbitzuetarako kontratuak erabiltzeko sormenerako aukera handia da... teorian behintzat.
Triku bat suge batekin alderatzea
Gaur egun, Acronis-en lehentasunezko garapen-eremua Acronis Cyber ββββPlatform garapena da. Acronis Cyber ββββPlatform hirugarrenen zerbitzuen integrazio puntu berriak da Acronis Cyber ββββCloud eta agentearen zatiarekin. RAML-en deskribatutako gure barneko APIekin pozik geunden arren, APIa argitaratu beharrak berriro aukeraren galdera planteatu zuen: zein da komeni da komenigarria gure lanerako erabiltzea?
Hasieran, bazirudien bi irtenbide zeudela: garapen ohikoenak RAML eta Swagger (edo OAS) ziren. Baina egia esan, gutxienez ez daude 2 alternatiba, 3 edo gehiago baizik.
Alde batetik RAML dago, hizkuntza indartsu eta eraginkorra. Hierarkia eta herentzia ondo inplementatzen ditu, beraz, formatu hau aproposagoa da deskribapen asko behar dituzten enpresa handientzat - hau da, ez produktu bat, baizik eta kontratuen zati komunak dituzten mikrozerbitzu asko - autentifikazio-eskemak, datu-mota berdinak, akats-gorputzak. .
Baina RAML-ren garatzailea, Mulesoft, garatzen ari den Open API partzuergoan sartu da . Horregatik, RAML-k bere garapena eten zuen. Ekitaldiaren formatua imajinatzeko, imajinatu Linux osagai nagusien mantentzaileek Microsoft-en lanera utzi zutela. Egoera honek Swagger erabiltzeko aurrebaldintzak sortzen ditu, dinamikoki garatzen ari dena eta azkenekoan -hirugarren bertsioan- ia-ia malgutasunari eta funtzionaltasunari dagokionez RAML-rekin harrapatzen du.
Gauza bategatik ez bada...
Ikusten denez, kode irekiko utilitate guztiak ez dira OAS 3.0ra eguneratu. Go-ko mikrozerbitzuetarako, kritikoena egokitzapen eza izango da estandarraren azken bertsiorako. Hala ere, Swagger 2 eta Swagger 3-ren arteko aldea da . Adibidez, hirugarren bertsioan garatzaileek:
- autentifikazio-eskemen deskribapen hobetua
- JSON eskemaren euskarria
- adibideak gehitzeko gaitasuna berritu du
Egoera barregarria da: estandar bat aukeratzerakoan, RAML, Swagger 2 eta Swagger 3 alternatiba bereizi gisa hartu behar dituzu kontuan. Hala ere, Swagger 2-k soilik onartzen du OpenSource tresnetarako. RAML oso malgua da... eta konplexua, eta Swagger 3 komunitateak gaizki onartzen du, beraz, jabedun tresnak edo irtenbide komertzialak erabili beharko dituzu, nahiko garestiak izan ohi direnak.
Gainera, Swagger-en ezaugarri polit asko badaude, hala nola, prest egindako atari bat , zeinetan oharpen bat igo dezakezu eta bere bistaratzea deskribapen zehatz batekin, estekekin eta konexioekin lor dezakezu, gero RAML oinarrizkoagoa eta hain atseginagoa denarentzat ez dago horrelako aukerarik. Bai, GitHub-eko proiektuen artean zerbait bila dezakezu, bertan analogo bat aurkitu eta zuk zeuk zabaldu. Hala ere, edonola ere, norbaitek ataria mantendu beharko du, ez baita hain erosoa oinarrizko erabilerarako edo proba beharretarako. Horrez gain, swagger "printzipiorik gabekoa" edo liberalagoa da - kodean iruzkinetatik sor daiteke, noski, APIaren lehen printzipioaren aurka doa eta RAML utilitate batek ez du onartzen.
Garai batean RAML-rekin lanean hasi ginen hizkuntza malguago gisa, eta, ondorioz, guk geuk egin behar izan genituen gauza asko. Adibidez, proiektuetako batek erabilgarritasuna erabiltzen du unitate-probetan, RAML 0.8 bakarrik onartzen duena. Beraz, makuluak gehitu behar izan genituen, utilitateak RAML 1.0 bertsioa "jan" zezan.
Aukeratu behar al duzu?
RAMLrako soluzioen ekosistema osatzeko lan egin ondoren, RAML Swagger 2 bihurtu behar dugula eta bertan automatizazio, egiaztapen, proba eta ondorengo optimizazio guztiak egin behar ditugula ondorioztatu dugu. Modu ona da RAML-ren malgutasuna eta Swagger-en komunitateko tresnen laguntza aprobetxatzeko.
Arazo hau konpontzeko, OpenSource bi tresna daude kontratu bihurketa eman beharko luketenak:
- Gaur egun onartzen ez den erabilgarritasun bat da. Berarekin lan egiten ari ginen bitartean, fitxategi kopuru handi batean "hedatuta" dauden RAML konplexuekin arazo ugari dituela ikusi genuen. Programa hau JavaScript-en idatzita dago eta sintaxi-zuhaitz baten zeharkatze errekurtsiboa egiten du. Idazketa dinamikoa dela eta, kode hau ulertzea zaila egiten da, beraz, hilzorian dagoen utilitate baterako adabakiak idazten denbora ez galtzea erabaki genuen.
- - edozer eta dena bihurtzeko prest dagoela dioen enpresa bereko tresna, eta edozein norabidetan. Orain arte, RAML 0.8, RAML 1.0 eta Swagger 2.0rako laguntza iragarri da. Hala ere, gure ikerketaren garaian, erabilgarritasuna oraindik zegoen hezea eta erabilezina. Garatzaileek mota bat sortzen dute , etorkizunean estandar berriak azkar gehitzeko aukera emanez. Baina orain arte ez du funtzionatzen.
Eta hori ez da izan ditugun zailtasunak. Gure kanaleko urratsetako bat biltegiko RAML zehaztapenarekiko zuzena dela egiaztatzea da. Hainbat utilitate probatu ditugu. Harrigarria bada ere, denek zin egin zituzten gure oharrak leku ezberdinetan eta guztiz bestelako hitz txarrekin. Eta ez beti punturaino :).
Azkenean, orain zaharkituta dagoen proiektu batean finkatu ginen, eta horrek ere hainbat arazo ditu (batzuetan huts egiten du, esamolde erregularrak lantzerakoan arazoak ditu). Hala, tresna libreetan oinarritutako baliozkotze- eta bihurtze-arazoak konpontzeko modurik ez genuen aurkitu, eta erabilgarritasun komertzial bat erabiltzea erabaki genuen. Etorkizunean, OpenSource tresnak helduagoak diren heinean, arazo hau errazago konpon daiteke. Bitartean, βamaitzekoβ lan eta denbora kostuak merkataritza zerbitzu baten kostua baino esanguratsuagoak iruditu zitzaizkigun.
Ondorioa
Honen guztiaren ondoren, gure esperientzia partekatu nahi izan dugu, eta ohartarazi dugu kontratuak deskribatzeko tresna bat aukeratu aurretik argi eta garbi zehaztu behar duzula bertatik zer nahi duzun eta zer aurrekontu inbertitzeko prest zauden. OpenSourcez ahazten bagara, dagoeneko egiaztatu, bihurtzen eta balioztatzen lagunduko dizuten zerbitzu eta produktu ugari daude. Baina garestiak dira, eta batzuetan oso garestiak dira. Enpresa handi batentzat, horrelako kostuak jasangarriak dira, baina startup batentzat zama handia izan daiteke.
Zehaztu geroago erabiliko duzun tresna multzoa. Esaterako, kontratu bat bistaratu behar baduzu, errazagoa izango da Swagger 2 erabiltzea, API ederra duena, RAML-en zerbitzua zuk zeuk eraiki eta mantendu beharko duzulako.
Zenbat eta zeregin gehiago izan, orduan eta zabalagoa izango da tresnen beharra, eta desberdinak dira plataforma desberdinetarako, eta hobe da berehala ezagutzea eskuragarri dauden bertsioekin, etorkizunean kostuak murrizten dituen aukera bat egiteko.
Baina merezi du aitortzea gaur egun dauden ekosistema guztiak inperfektuak direla. Horregatik, enpresan badaude RAML-en lan egitea gustuko duten zaleak, βpentsamenduak malgutasun handiagoz adierazteko aukera ematen dizulakoβ, edo, aitzitik, Swagger nahiago dutelako βargiagoa delakoβ, hobe da lanean uztea. zertan dauden Ohituta daude eta nahi dute, edozein formatutako tresnek fitxategi batekin aldatzea eskatzen dutelako.
Gure esperientziari dagokionez, hurrengo argitalpenetan gure RAML-Swagger arkitekturan oinarrituta zer egiaztapen estatiko eta dinamiko egiten ditugun hitz egingo dugu, baita kontratuetatik sortzen dugun zer dokumentazio eta nola funtzionatzen duen ere.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Zein hizkuntza erabiltzen duzu mikrozerbitzuen kontratuak idazteko?
-
RAML 0.8
-
RAML 1.0
-
Harragia 2
-
OAS3 (aka)
-
Blueprint
-
beste
-
Ez erabiltzea
100 erabiltzailek eman dute botoa. 24 erabiltzaile abstenitu ziren.
Iturria: www.habr.com