Mi volis verki artikolon pri la temo de mikroserva arkitekturo dum longa tempo, sed du aferoj daŭre haltigis min - ju pli mi plonĝis en la temon, des pli ŝajnis al mi, ke tio, kion mi scias, estas evidenta, kaj kion mi scias. t scias necesas studi kaj studi. Aliflanke mi pensas, ke jam estas io por diskuti inter vasta publiko. Do alternativaj opinioj estas bonvenaj.
La Leĝo de Conway kaj la rilato inter komerco, organizo kaj informsistemo
Denove mi permesos al mi citi:
"Ĉiu organizo kiu dizajnas sistemon (en la larĝa signifo) ricevos dezajnon kies strukturo reproduktas la strukturon de la teamoj en tiu organizo."
- Melvyn Conway, 1967
Miaopinie, ĉi tiu leĝo pli verŝajne rilatas al la farebleco organizi komercon, prefere ol rekte al la informsistemo. Mi klarigu per ekzemplo. Ni diru, ke ni havas sufiĉe stabilan komercan ŝancon kun vivociklo de tia longeco, ke havas sencon organizi entreprenon (ĉi tio ne estas tajperaro, sed mi tre ŝatas ĉi tiun terminon, kiun mi ŝtelis). Nature, la subtena sistemo de ĉi tiu komerco organize kaj procece respondas al ĉi tiu komerco.
Komerca orientiĝo de informsistemoj
Mi klarigu per ekzemplo. Ni diru, ke ekzistas komerca ŝanco organizi komercon vendantan picon. En la V1-versio (ni nomu ĝin antaŭinformo), la firmao estis picejo, kasregistrilo kaj liverservo. Tiu versio estis longviva en kondiĉoj de malalta media ŝanĝebleco. Tiam la versio 2 venis anstataŭigi ĝin - pli altnivela kaj kapabla uzi informsistemon ĉe sia kerno por komerco kun monolita arkitekturo. Kaj ĉi tie, laŭ mi, estas simple terura maljusteco rilate al la monolitoj - supozeble monolita arkitekturo ne egalrilatas al la domajna komercmodelo. Jes, se tiel estus, la sistemo tute ne kapablus funkcii – kontraŭe kun la sama leĝo kaj komuna prudento de Conway. Ne, monolita arkitekturo plene kongruas kun la komerca modelo en ĉi tiu etapo de komerca disvolviĝo - mi, kompreneble, celas la etapon, kiam la sistemo jam estas kreita kaj ekfunkciigita. Estas absolute mirinda fakto, ke sendepende de la arkitektura aliro, kaj la servo-orientita arkitekturo versio 3 kaj la mikroservo-arkitektura versio N funkcios same bone. Kio estas la kapto?
Ĉio fluas, ĉio ŝanĝiĝas, aŭ ĉu mikroservoj estas rimedo por batali kompleksecon?
Antaŭ ol ni daŭrigu, ni rigardu kelkajn miskomprenojn pri mikroserva arkitekturo.
Propagandantoj de uzado de mikroserva aliro ofte argumentas ke rompi monoliton en mikroservojn simpligas la evolualiron reduktante la kodbazon de individuaj servoj. Laŭ mi, ĉi tiu aserto estas tute sensencaĵo. Serioze, la evidenta interago ene de monolito kaj homogena kodo ŝajnas komplika? Se ĉi tio estus vere la kazo, ĉiuj projektoj komence estus konstruitaj kiel mikroservoj, dum praktiko montras, ke migrado de monolito al mikroservoj estas multe pli ofta. Komplekseco ne malaperas; ĝi simple moviĝas de individuaj moduloj al interfacoj (ĉu ĝi estas datumbusoj, RPC, APIoj, kaj aliaj protokoloj) kaj orkestraj sistemoj. Kaj ĉi tio estas malfacila!
La avantaĝo uzi heterogenan stakon ankaŭ estas dubinda. Mi ne argumentos, ke ankaŭ tio eblas, sed fakte ĝi malofte okazas (Rigardante antaŭen - tio devus okazi - sed prefere kiel sekvo ol avantaĝo).
Produkta vivociklo kaj serva vivociklo
Rigardu la supran diagramon. Ne estas hazardo, ke mi rimarkis la malkreskantan vivociklon de aparta versio de komerco - en modernaj kondiĉoj, estas la akcelo de la transiro de komerco inter versioj decida por ĝia sukceso. La sukceso de produkto estas determinita de la rapideco de testado de komercaj hipotezoj en ĝi. Kaj ĉi tie, laŭ mi, kuŝas la ŝlosila avantaĝo de mikroserva arkitekturo. Sed ni iru en ordo.
Ni transiru al la sekva etapo en la evoluo de informsistemoj - al la serva arkitekturo de SOA. Do, en iu momento ni reliefigis en nia produkto longdaŭraj servoj - longedaŭra en la senco, ke kiam oni moviĝas inter versioj de produkto, ekzistas ŝanco ke la vivociklo de la servo estos pli longa ol la vivociklo de la sekva versio de la produkto. Estus logike ilin tute ne ŝanĝi — ni Gravas la rapideco de transiro al la sekva versio. Sed ve, ni estas devigitaj fari konstantajn ŝanĝojn al servoj - kaj ĉi tie ĉio funkcias por ni, DevOps-praktikoj, kontenerigo ktp - ĉio, kio venas al la menso. Sed ĉi tiuj ankoraŭ ne estas mikroservoj!
Mikroservoj kiel rimedo por batali kompleksecon... agorda administrado
Kaj ĉi tie ni povas finfine pluiri al la difina rolo de mikroservoj - ĉi tio estas aliro, kiu simpligas produktan agordan administradon. Pli detale, la funkcio de ĉiu mikroservo priskribas ĝuste la komercan funkcion ene de la produkto laŭ la domajna modelo - kaj ĉi tiuj estas aferoj, kiuj vivas ne en mallongdaŭra versio, sed en longdaŭra komerca ŝanco. Kaj la transiro al la sekva versio de la produkto okazas laŭvorte nerimarkite - vi ŝanĝas/aldonas unu mikroservon, kaj eble nur la skemon de ilia interago, kaj subite vi trovas vin en la estonteco, postlasante plorantajn konkurantojn kiuj daŭre saltas inter versioj de la produkto. iliaj monolitoj. Nun imagu, ke ekzistas sufiĉe granda kvanto da mikroservoj kun antaŭdifinitaj interfacoj kaj komercaj kapabloj. Kaj vi venas kaj konstruas la strukturon de via produkto el pretaj mikroservoj - simple desegnante diagramon, ekzemple. Gratulon - vi havas platformon - kaj nun vi povas allogi komercon por vi mem. Sonĝoj Sonĝoj.
trovoj
- La arkitekturo de la sistemo devus esti determinita per la vivociklo de ĝiaj komponentoj. Se komponento vivas ene de produkta versio, ne havas signifon pliigi la kompleksecon de la sistemo uzante mikroservan aliron.
- Mikroserva arkitekturo devus esti bazita sur la domajna modelo - ĉar la komerca ŝanco estas la plej longdaŭra domajno
- Liveraj praktikoj (DevOps-praktikoj) kaj instrumentado estas unu el la plej gravaj por mikroserva arkitekturo - pro tio, ke la pliiĝo en la indico de ŝanĝo de komponantoj pliigas postulojn pri la rapideco kaj kvalito de livero.
fonto: www.habr.com