Saluton al ĉiuj! Ni havas bonegajn novaĵojn, OTUS denove lanĉas la kurson en junio , rilate al kiu ni tradicie dividas utilan materialon kun vi.
Se vi trovis ĉi tiun tutan aferon pri mikroservoj sen ia ajn kunteksto, vi pardonus, ke vi opinias, ke ĝi estas iom stranga. Dividi aplikaĵon en fragmentojn ligitajn per reto nepre signifas aldoni kompleksajn faŭltoleremo-reĝimojn al la rezulta distribuita sistemo.
Kvankam ĉi tiu aliro implikas malkonstrui ĝin en multajn sendependajn servojn, la fina celo estas multe pli ol nur havi tiujn servojn funkcii per malsamaj maŝinoj. Ni parolas ĉi tie pri interago kun la ekstera mondo, kiu ankaŭ estas distribuita en sia esenco. Ne en la teknika senco, sed prefere en la senco de ekosistemo kiu konsistas el multaj homoj, teamoj, programoj, kaj ĉiu el ĉi tiuj partoj iel devas fari sian laboron.
Firmaoj, ekzemple, estas kolekto de distribuitaj sistemoj kiuj kolektive kontribuas al la atingo de iu celo. Ni ignoras ĉi tiun fakton dum jardekoj, provante atingi unuiĝon per FTP-aj dosieroj aŭ uzante entreprenajn integrigajn ilojn dum ni koncentriĝas pri niaj propraj izolitaj celoj. Sed kun la alveno de servoj, ĉio ŝanĝiĝis. Servoj helpis nin rigardi preter la horizonto kaj vidi mondon de interdependaj programoj kiuj funkcias kune. Tamen, por sukcese labori, necesas rekoni kaj desegni du esence malsamajn mondojn: la ekstera mondo, kie ni vivas en ekosistemo de multaj aliaj servoj, kaj nia persona, interna mondo, kie ni regas sole.
Ĉi tiu distribuita mondo diferencas de tiu, en kiu ni kreskis kaj al kiu ni kutimas. La principoj de konstruado de tradicia monolita arkitekturo ne eltenas kritikon. Do atingi ĉi tiujn sistemojn ĝuste temas pri pli ol krei bonegan blanktabulo-diagramon aŭ bonegan pruvon de koncepto. La afero estas certigi, ke tia sistemo funkcias sukcese dum longa tempo. Feliĉe, la servoj ekzistas de sufiĉe da tempo, kvankam ili aspektas malsamaj. estas ankoraŭ trafaj, eĉ spicitaj kun Docker, Kubernetes kaj iomete mizeraj hipsterbarboj.
Do hodiaŭ ni rigardos kiel la reguloj ŝanĝiĝis, kial ni devas repripensi la manieron kiel ni alproksimiĝas al servoj kaj la datumojn, kiujn ili transdonas unu al la alia, kaj kial ni bezonos tute malsamajn ilojn por fari ĝin.
Enkapsuligo ne ĉiam estos via amiko
Mikroservoj povas funkcii sendepende unu de la alia. Estas ĉi tiu posedaĵo kiu donas al ili la plej grandan valoron. Ĉi tiu sama posedaĵo permesas al servoj grimpi kaj kreski. Ne tiom en la senco de grimpi al kvarilionoj da uzantoj aŭ petabajtoj da datumoj (kvankam tiuj ankaŭ povas helpi tie), sed en la signifo de grimpi laŭ homoj, ĉar teamoj kaj organizoj kreskas senĉese.
Tamen sendependeco estas dutranĉa glavo. Tio estas, la servo mem povas funkcii facile kaj nature. Sed se funkcio estas efektivigita ene de servo kiu postulas la uzon de alia servo, tiam ni finas devante fari ŝanĝojn al ambaŭ servoj preskaŭ samtempe. En monolito ĉi tio estas facile fari, vi simple faras ŝanĝon kaj sendas ĝin al liberigo, sed en la kazo de sinkronigado de sendependaj servoj estos pli da problemoj. Kunordigo inter teamoj kaj eldoncikloj detruas lertecon.
Kiel parto de la norma aliro, ili simple provas eviti ĝenajn fin-al-finajn ŝanĝojn, klare dividante funkciecon inter servoj. Ununura ensaluta servo povas esti bona ekzemplo ĉi tie. Ĝi havas klare difinitan rolon, kiu diferencigas ĝin de aliaj servoj. Ĉi tiu klara disiĝo signifas, ke en mondo de rapide ŝanĝiĝantaj postuloj pri la servoj ĉirkaŭ ĝi, la ununura ensaluta servo verŝajne ne ŝanĝiĝos. Ĝi ekzistas ene de strikte limigita kunteksto.
La problemo estas, ke en la reala mondo, komercaj servoj ne povas konservi la saman puran apartigon de roloj la tutan tempon. Ekzemple, la samaj komercaj servoj funkcias en pli granda mezuro kun datumoj venantaj de aliaj similaj servoj. Se vi okupiĝas pri reta podetala komerco, tiam prilaborado de mendofluo, produkta katalogo aŭ uzantinformoj fariĝos postulo por multaj el viaj servoj. Ĉiu el la servoj bezonos aliron al ĉi tiuj datumoj por funkcii.
Plej multaj komercaj servoj dividas la saman datumfluon, do ilia laboro estas senescepte interplektita.
Tiel ni venas al grava punkto pri kiu valoras paroli. Dum servoj funkcias bone por infrastrukturaj komponantoj, kiuj funkcias plejparte izole, plej multaj komercaj servoj finas esti interplektitaj multe pli proksime.
Datuma dikotomio
Servo-orientitaj aliroj eble jam ekzistas, sed al ili ankoraŭ mankas kompreno pri kiel dividi grandajn kvantojn da datumoj inter servoj.
La ĉefa problemo estas, ke datumoj kaj servoj estas nedisigeblaj. Unuflanke, enkapsuligo instigas nin kaŝi datumojn por ke servoj povas esti apartigitaj unu de la alia kaj faciligi ilian kreskon kaj pliajn ŝanĝojn. Aliflanke, ni devas povi libere dividi kaj konkeri komunajn datumojn, same kiel ajnajn aliajn datumojn. La afero estas povi ekfunkcii tuj, same libere kiel en ajna alia informsistemo.
Tamen, informsistemoj malmulte rilatas al enkapsulado. Fakte, estas tute male. Datumbazoj faras ĉion kion ili povas por disponigi aliron al la datumoj kiujn ili stokas. Ili venas kun potenca deklara interfaco, kiu ebligas al vi modifi la datumojn laŭ via bezono. Tia funkcieco estas grava en la prepara esplorstadio, sed ne por administri la kreskantan kompleksecon de konstante evoluanta servo.
Kaj ĉi tie ekestas dilemo. Kontraŭdiro. Dikotomio. Post ĉio, informsistemoj temas pri liverado de datumoj, kaj servoj temas pri kaŝado.
Ĉi tiuj du fortoj estas fundamentaj. Ili subtenas grandan parton de nia laboro, konstante batalante por plejboneco en la sistemoj, kiujn ni konstruas.
Dum servosistemoj kreskas kaj evoluas, ni vidas la sekvojn de datumkotomio en multaj manieroj. Aŭ la serva interfaco kreskos por provizi ĉiam pli larĝan gamon da funkcieco kaj komencos aspekti kiel tre ŝika hejma datumbazo, aŭ ni frustriĝos kaj efektivigos ian manieron reakiri aŭ movi amase tutajn arojn da datumoj de servo al servo.
Siavice, krei ion, kio aspektas kiel ŝika hejma datumbazo, kondukos al tuta amaso da problemoj. Ni ne eniros detalojn pri kial ĝi estas danĝera komuna datumbazo, ni nur diru, ke ĝi reprezentas signifan multekostan inĝenieristikon kaj funkciadon por la firmao kiu provas uzi ĝin.
Kio estas pli malbona estas, ke datumvolumoj pligrandigas servolimajn problemojn. Ju pli dividitaj datumoj kuŝas ene de servo, des pli kompleksa fariĝos la interfaco kaj des pli malfacila estos kombini datumseriojn de malsamaj servoj.
La alternativa aliro ĉerpi kaj movi tutajn datumajn arojn ankaŭ havas siajn problemojn. Ofta aliro al ĉi tiu demando aspektas kiel simple reakiro kaj stokado de la tuta datumaro, kaj poste konservi ĝin loke en ĉiu konsumanta servo.
La problemo estas, ke malsamaj servoj interpretas la datumojn, kiujn ili konsumas alimaniere. Ĉi tiuj datumoj ĉiam estas ĉe mano. Ili estas modifitaj kaj prilaboritaj loke. Sufiĉe rapide ili ĉesas havi ion komunan kun la datumoj en la fonto.
Ju pli ŝanĝeblaj la kopioj, des pli la datumoj varias laŭlonge de la tempo.
Por plimalbonigi la aferojn, tiaj datumoj estas malfacile korekteblaj retrospektive ( Ĉi tie ĝi vere povas veni al la savo). Fakte, iuj el la nesolveblaj teknologiaj problemoj, kiujn alfrontas entreprenoj, ekestiĝas de la malsimilaj datumoj, kiuj multiĝas de aplikaĵo al aplikaĵo.
Por trovi solvon al ĉi tiu problemo, ni devas pensi alimaniere pri komunaj datumoj. Ili devas fariĝi unuaklasaj objektoj en la arkitekturoj, kiujn ni konstruas. nomas tiajn datumojn "eksteraj", kaj ĉi tio estas tre grava trajto. Ni bezonas enkapsuligon, por ke ni ne elmontru la internan funkciadon de servo, sed ni devas faciligi al servoj aliri komunajn datumojn por ke ili povu fari siajn laborojn ĝuste.
La problemo estas, ke neniu aliro estas trafa hodiaŭ, ĉar nek la servaj interfacoj, nek la mesaĝado, nek la Kundividita Datumaro ofertas bonan solvon por labori kun eksteraj datumoj. Servaj interfacoj estas malbone taŭgaj por interŝanĝo de datumoj je ajna skalo. Mesaĝado movas datumojn sed ne konservas ĝian historion, do datumoj koruptiĝas kun la tempo. Komunaj datumbazoj tro fokusiĝas al unu punkto, kiu bremsas la progreson. Ni neeviteble blokiĝas en ciklo de datuma fiasko:
Ciklo de fiasko de datumoj
Fluoj: malcentralizita aliro al datumoj kaj servoj
Ideale, ni devas ŝanĝi la manieron kiel servoj funkcias kun komunaj datumoj. Je ĉi tiu punkto, ambaŭ aliroj alfrontas la menciitan dikotomion, ĉar ekzistas neniu magia polvo kiu povas esti aspergita sur ĝin por malaperi ĝin. Tamen ni povas repripensi la problemon kaj atingi kompromison.
Ĉi tiu kompromiso implikas certan gradon da centralizo. Ni povas uzi la distribuan protokolon ĉar ĝi provizas fidindajn, skaleblajn fluojn. Ni nun volas, ke servoj povu aliĝi kaj funkcii per ĉi tiuj komunaj fadenoj, sed ni volas eviti kompleksajn centralizitajn Diajn Servojn, kiuj faras ĉi tiun prilaboradon. Tial, la plej bona elekto estas enkonstrui fluo-pretigon en ĉiun konsuman servon. Tiel, servoj povos kombini datumajn arojn de malsamaj fontoj kaj labori kun ili kiel ili bezonas.
Unu maniero atingi ĉi tiun aliron estas per la uzo de fluanta platformo. Estas multaj ebloj, sed hodiaŭ ni rigardos Kafka, ĉar la uzo de ĝia Stateful Stream Processing permesas al ni efike solvi la prezentitan problemon.
Uzado de distribuita registra mekanismo ebligas al ni sekvi la tre paŝitan vojon kaj uzi mesaĝadon por labori . Tiu aliro estas konsiderita havigi pli bonan skalon kaj dispartigo ol la peto-responda mekanismo ĉar ĝi donas kontrolon de la fluo al la ricevilo prefere ol la sendinto. Tamen, por ĉio en ĉi tiu vivo vi devas pagi, kaj ĉi tie vi bezonas makleriston. Sed por grandaj sistemoj, la kompromiso valoras ĝin (kio eble ne estas la kazo por via averaĝa TTT-aplikaĵo).
Se makleristo respondecas pri distribuita registrado prefere ol tradicia mesaĝa sistemo, vi povas utiligi pliajn funkciojn. La transporto povas skali linie preskaŭ same kiel distribuita dosiersistemo. Datumoj povas esti konservitaj en protokoloj dum sufiĉe longa tempo, do ni ricevas ne nur mesaĝan interŝanĝon, sed ankaŭ informan konservadon. Skalebla stokado sen la timo de ŝanĝebla komuna stato.
Vi povas tiam uzi ŝtatan fluon por aldoni deklarajn datumbazajn ilojn al konsumantaj servoj. Ĉi tio estas tre grava ideo. Dum la datumoj estas konservitaj en komunaj fluoj, kiujn ĉiuj servoj povas aliri, la agregado kaj prilaborado, kiujn la servo faras, estas privataj. Ili trovas sin izolitaj ene de strikte limigita kunteksto.
Forigu datuman dikotomion disigante la neŝanĝeblan ŝtatfluon. Poste aldonu ĉi tiun funkcion al ĉiu servo uzante Stateful Stream Processing.
Tiel, se via servo bezonas labori kun mendoj, produkta katalogo, magazeno, ĝi havos plenan aliron: nur vi decidos kiajn datumojn kombini, kie prilabori ĝin kaj kiel ĝi devus ŝanĝi kun la tempo. Malgraŭ la fakto, ke la datumoj estas dividitaj, laboro kun ĝi estas tute malcentralizita. Ĝi estas produktita ene de ĉiu servo, en mondo kie ĉio iras laŭ viaj reguloj.
Kunhavigu datumojn sen endanĝerigi ĝian integrecon. Enkapsuligu la funkcion, ne la fonton, en ĉiu servo, kiu bezonas ĝin.
Okazas, ke datumoj devas esti movitaj amase. Kelkfoje servo postulas lokan historian datumaron en la elektita datumbaza motoro. La lertaĵo estas, ke vi povas garantii, ke, se necese, kopio povas esti restarigita de la fonto per aliro al la distribuita registra mekanismo. Konektiloj en Kafka bonege faras ĉi tion.
Do, la aliro diskutita hodiaŭ havas plurajn avantaĝojn:
- Datumoj estas uzataj en la formo de komunaj fluoj, kiuj povas esti konservitaj en protokoloj dum longa tempo, kaj la mekanismo por labori kun komunaj datumoj estas fiksita en ĉiu individua kunteksto, kio permesas al servoj funkcii facile kaj rapide. Tiamaniere, la dikotomio de la datumoj povas esti ekvilibrigita.
- Datumoj venantaj de malsamaj servoj povas esti facile kombinitaj en arojn. Ĉi tio simpligas interagadon kun komunaj datumoj kaj forigas la bezonon konservi lokajn datumarojn en la datumbazo.
- Stateful Stream Processing nur konservas datumojn, kaj la fonto de vero restas la ĝeneralaj protokoloj, do la problemo de datuma korupto laŭlonge de la tempo ne estas tiel akra.
- En sia kerno, servoj estas datumaj, kio signifas, ke malgraŭ la ĉiam kreskantaj volumoj de datumoj, servoj ankoraŭ povas respondi rapide al komercaj eventoj.
- Skaleblaj problemoj falas sur la makleristo, ne la servoj. Ĉi tio signife reduktas la kompleksecon de skribservoj, ĉar ne necesas pensi pri skaleblo.
- Aldoni novajn servojn ne postulas ŝanĝi malnovajn, do konekti novajn servojn fariĝas pli facila.
Kiel vi povas vidi, ĉi tio estas pli ol nur REST. Ni ricevis aron da iloj, kiuj permesas vin labori kun komunaj datumoj malcentra maniero.
Ne ĉiuj aspektoj estis kovritaj en la hodiaŭa artikolo. Ni ankoraŭ bezonas eltrovi kiel ekvilibrigi inter la peto-responda paradigmo kaj la okazaĵ-movita paradigmo. Sed ni traktos ĉi tion venontfoje. Estas temoj, kiujn vi bezonas pli bone koni, ekzemple, kial Stateful Stream Processing estas tiel bona. Pri tio ni parolos en la tria artikolo. Kaj estas aliaj potencaj konstrukcioj, kiujn ni povas utiligi se ni recurre al ili, ekzemple, . Ĝi estas ludŝanĝilo por distribuitaj komercaj sistemoj ĉar ĝi provizas transakciajn garantiojn por en skalebla formo. Ĉi tio estos diskutita en la kvara artikolo. Fine, ni devos trarigardi la efektivigajn detalojn de ĉi tiuj principoj.
Sed nuntempe, nur memoru ĉi tion: la datuma dikotomio estas forto, kiun ni alfrontas dum konstruado de komercaj servoj. Kaj ni devas memori ĉi tion. La lertaĵo estas turni ĉion kaj komenci trakti komunajn datumojn kiel bonegajn objektojn. Stateful Stream Processing provizas unikan kompromison por ĉi tio. Ĝi evitas centralizitajn "Diajn Komponentojn", kiuj bremsas progreson. Krome, ĝi certigas la facilmovecon, skaleblon kaj fortikecon de datumfluaj duktoj kaj aldonas ilin al ĉiu servo. Tial ni povas koncentriĝi pri la ĝenerala fluo de konscio, al kiu iu ajn servo povas konekti kaj labori kun siaj datumoj. Ĉi tio igas servojn pli skaleblaj, interŝanĝeblaj kaj aŭtonomaj. Do ili ne nur aspektos bone sur blanktabuloj kaj hipotezaj testoj, sed ili ankaŭ funkcios kaj evoluos dum jardekoj.
fonto: www.habr.com