In mundo dynamico microservorum, aliquid mutare potest - quaelibet pars alia lingua innovari potest, diversis compagibus et architectura adhibitis. Solus contractus immutatus manere debet ut microservio ab extrinseco aliqua permanenti fundamento, cuiuscumque metamorphoseon internae, internecari possit. Hodieque loquemur de problemate nostro eligendo formam contractuum describendi et artificiorum quae invenimus communicanda.
Post paravit и
Micro-services. Cum Acronis Cyberum Nubem evolveret, intelleximus nos illos effugere non posse. Et designans microserviam impossibilis est sine contractu formalising, quod interfacies microserviae repraesentat.
Sed cum productum plus quam unum continet, et progressus contractus fit actio regularis, non potes adiuvare non incipere cogitationem de processu optimizationis. Patet perspicuum est interfaciem (contract) et exsecutionem (microservice) inter se aequare debere, partes diversas eodem modo facere debere, et sine decisione centrali omnium harum decisionum faciendarum, singulae turmae cogentur. terere etiam atque etiam capere.
Amazon Microservices tabula e Werner Vogelis, CTO Amazon
Quid est dilemma? De facto duo modi sunt microservices mutuas - HTTP Requiem et gRPC a Google. Non defuit ut in acervum technologiae Google raptum, HTTP Requiem elegimus. HTTP CETERA annotationes contractae saepissime in una duarum formarum descripti sunt: RAML et OAS, quae olim Swagger notae sunt. Sed ut evenit, haec electio difficillima esse potest.
Cur annotationes opus sunt?
Annotatione opus est ut usor externus facile exstirpare possit quid cum tuo servitio per HTTP interface fieri possit. Hoc est, in gradu fundamentali, adnotatio saltem indicem copiarum promptarum, methodorum HTTP eorum, petitio corporum, enumeratio parametri, indicata capitis requisiti et fulciendi, necnon notarum reditus ac formarum responsionum. Elementum contractus magni ponderis annotationis est eorum verborum descriptio ("quid accidit si interrogationem hanc parametri petitioni addideris?", "quo casu codice 400 reddetur?")
Attamen, cum magnum numerum microservices augendum advenerit, valorem additum ex annotationibus scriptis extrahere vis. Exempli gratia, secundum RAML/Swagger, tum clientem et servitorem codicem generare potes in numero programmandi linguarum. Etiam automatice documenta recipere potes pro microservio et id in vitreo portal tuo imposuisti :).
Exemplum contractus descriptionis exstructa
Minus communis est usus microservices probatio quae in descriptionibus contractibus fundatur. Si utrumque annotationem et partem scripseris, tunc autotest testem creare potes qui adaequationem ministerii cum variis speciebus input datarum inhibet. Num officium respondet codicem qui in annotatione non descriptus est? Poteritne recte procedere, ut patet, falsa notitia?
Praeterea, summus qualitas exsecutionis non solum contractuum, sed etiam instrumenta ad annotationes visualisandum efficit ut opus faciliorem reddant cum microservio. Hoc est, si architectus qualitatem contractum descripsit, ex eo innixus, designatores et tincidunt ministerium in aliis productis sine additis temporis sumptibus efficiet.
Ut instrumenta accessoria, RAML et OAS facultatem metadatam addere non per vexillum provideantur ().
In genere, ingens scopus creativity in contractibus pro microserviis, saltem in theoria.
Comparatio ericius cum angue
In statu, prioritas evolutionis areae Acronis est evolutio Acronis Cyberis in rostris. Acronis Cyber Platform est ite- rum integrationis tertiae partis officia cum Acronis Cyberia Cloud et parte agentis. Etsi laeti essemus cum APIs internis nostris in RAML descriptis, necessitas API denuo quaestionem electionis evulgandi excitavit: quae norma annotationis optima est ad opus nostrum utendum?
Initio visum est duas solutiones - frequentissimas esse RAML et Swagger (vel OAS). Sed revera evenit ut non sint 2 alternativa, sed 3 vel plura.
Ex altera parte est RAML - Lingua potens et efficax. Hierarchiam et hereditatem bene instruit, ut haec forma aptior sit magnis societatibus quae multa descriptione indigent — id est, non unum productum, sed multae parvae operae, quae communes habent partes contractuum — machinas authenticas, eadem notitia typi, errorum corporum. .
Elit autem RAML, Mulesoft, apertum API consortium coniunxit, quod est developing . Ideo raml suspensa eius processit. Formam eventus fingere, finge assertores components Linux principalis laborando Microsoft relictas esse. Haec condicio praebet requisita usus Swagger, quae dynamically et in novissima tertia versione enucleatur - paene comprehendit cum RAML secundum flexibilitatem et functionem.
Nisi unum...
Cum evenit, non omnes utilitates fontanae apertae ad OAS 3.0 renovatae sunt. Pro microservices in Go, res critica maxime defectus adaptationis erit ad novissimam versionem vexillum. Discrimen tamen inter Swagger 2 et Swagger 3 est . Exempli gratia in tertia versione tincidunt:
- meliorem descriptionem authenticas consilia
- JSON Schema subsidium
- upgraded ad facultatem addere exempla
Locus ridiculus est: vexillum eligens, debes considerare RAML, Swagger 2 et Swagger 3 singulas condiciones. Nihilominus, solus Swagger 2 instrumenta subsidia bona habet ad OpenSource. RAML flexibilis est ... et multiplex, et Swagger 3 communitati male fulciuntur, sic habebis utendum instrumentis proprietariis vel solutionibus mercatorum, quae satis pretiosa tendunt.
Praeterea, si multae notae pulcrae sunt in Swagger, sicut portae promptae factae , in qua annotationem inserere potes et eius visualizationem cum accuratiore descriptione, nexus et nexus acquirere potes, tum pro potioribus et minus amicabilibus RAML nulla talis opportunitas est. Imo, potes aliquid quaerere inter opera in GitHub, analogum ibi reperi et te ipsum explica. Attamen, in omni casu, aliquis portal ponere debebit, quod non ita convenit ad usus praecipuas vel probationes necessitates. Praeterea suggillatio magis est "inignitio" vel liberalior - ex commentis in codice generari potest, quae utique contra API primum principium obvenit nec nullis RAML utilitatibus sustinetur.
Uno tempore RAML ut flexibiliori sermone laborare coepimus, et inde nobis ipsis multum facere debebamus. Exempli gratia, una inceptis utilitate utitur in unitate probat, quod solum sustinet RAML 0.8. Ita fusum addere debebamus ut utilitas "comedere" posset RAML versionis 1.0.
Ecquid opus est eligere?
Cum ecosystematis solutionum pro RAML perficiendo perfecissemus, ad conclusionem devenimus nos RAML in Swagger 2 convertendi et omnem automationem, verificationem, probationem ac optimam in eo perficiendam. Haec bona via est ad levandam flexibilitatem RAML et communitatis instrumentorum sustentationem ab Swagger.
Ad hanc quaestionem solvendam duo instrumenta OpenSource solvenda sunt quae conversionem contractum praebere debent;
- est currently sine utilitate. Dum opus cum eo, permultas difficultates RAMLs implicatas habere per magnum numerum imaginum per "expandi" deprehendimus. Haec progressio in JavaScript scripta est et in syntaxi arbore recursive peragens. Ob typing dynamicam, difficilis fit hunc codicem intellegere, itaque decrevimus non inutiles mori scribendo tempus terere.
- — Instrumentum ab eodem comitatu, qui se profitetur paratum esse ad omnia et singula convertendos, et ad quamlibet partem. Ad diem, subsidium RAML 0.8 nuntiatum est, RAML 1.0 et Swagger 2.0. Sed tempore investigationis nostrae utilitas adhuc fuit humidum et inutile. Tincidunt quaedam celeriter nova signa in futurum permittens. Sed hoc modo non operatur.
Non omnes difficultates et id. Unus gradus in nostro pipelino est cognoscere RAML e promptuario esse verum relativum ad specificationem. Pluribus utilitatibus conati sumus. Omnes mire iuraverunt ad nostras annotationes in diversis locis et dissimiles malas voces. Nec semper ad rem :).
Ad extremum in nunc iam iamque consilium consedimus, quod etiam nonnullas difficultates habet (interdum e caeruleo fragosus, difficultates habet cum regularibus expressionibus laborat). Sic viam sanationis et conversionis liberis instrumentis innixam solvendis difficultatibus non invenimus et utilitate commerciali uti decrevimus. In futurum, ut instrumenta OpenSource maturiora fiant, haec quaestio facilior ad solvendum fiet. Interim labor et tempus impensae pro "finiendi" nobis significantius videbantur quam sumptus serviendi commercii.
conclusio,
Post haec omnia, experientiam nostram communicare voluimus et notare quod antequam instrumentum ad contractuum describendum eligendum sit, debes clare definire quid ex eo velis et quid praevisiones disponere velis. Si de OpenSource obliviscamur, iam magnus numerus officiorum et fructuum quae te adiuvabit ad reprimendum, convertendum, adiuvandum. Sed et facilisis orci, ac interdum orci. Magna societas, tantae sumptuum tolerabiles sunt, sed pro magno onere startup fieri possunt.
Constitue instrumenta instrumentorum quibus postea uteris. Exempli causa, si tantum opus est ut contractum exhibeas, facilius erit Swagger 2 uti, qui pulchram API habet, quia in RAML habebis te ipsum servitium aedificare et conservare.
Quo plura negotia habes, eo amplior opus erit instrumentorum, et diversae sunt in diversis suggestis, et melius est te statim cum versionibus promptis consuescere ut electionem efficias quae tua in futuro sumptuum ampliat.
Sed agnoscendum est omnes oecosystematis, quae hodie exstant, imperfectas esse. Si ergo alit in comitatu qui in RAML operari volunt quia "permittit te mollius cogitationes exprimere," vel e contra, potius Swagger quia "clarius est", melius est eas relinquere ad operandum. in eo quod sunt Adhibentur et desiderant, quia instrumenta quaevis formarum cum lima modificationem requirunt.
Quod ad nostram experientiam, in sequentibus postibus loquemur de iis quae static et dynamica compescunt quae agimus in architectura nostra RAML-Swagger, itemque documenta quae ex contractibus generamus et quomodo omnia opera.
Tantum usores descripserunt in aliquet participare possunt. Te gratissimum esse.
Qua lingua uteris ad contractus microservice annotare?
-
RAML 0.8
-
RAML 1.0
-
Swagger 2
-
OAS3 (aka)
-
Blueprint
-
alium
-
Non utens
100 utentes censuerunt. 24 utentes abstinuerunt.
Source: www.habr.com