Saluton, Habr. Hodiaŭ mi daŭrigas serion da publikaĵoj, kiujn mi verkis specife por la komenco de nova fluo de la kurso. .
Enkonduko
La elekto de arkitektura stilo estas unu el la fundamentaj teknikaj decidoj dum konstruado de informsistemo. En ĉi tiu serio de artikoloj, mi proponas analizi la plej popularajn arkitekturajn stilojn por konstrui aplikojn kaj respondi la demandon, kiam kiu arkitektura stilo estas plej preferinda. En la procezo de prezento, mi provos desegni logikan ĉenon, kiu klarigas la evoluon de arkitekturaj stiloj de monolitoj ĝis mikroservoj.
В ni traktis la monoliton kaj venis al la konkludo, ke la monolito havas kelkajn problemojn: grandeco, konektebleco, deplojo, skaleblo, fidindeco kaj rigideco.
Ĉi-foje mi proponas paroli pri la ebloj organizi sistemon kiel aro de moduloj/bibliotekoj (komponent-orientita arkitekturo) aŭ servoj (servo-orientita arkitekturo).
Komponento-orientita arkitekturo
Komponent-orientita arkitekturo implikas efektivigi sistemon kiel aro de komponentoj kiuj povas esti uzitaj en kaj nunaj kaj estontaj projektoj. Dum malkonstruo de sistemo en komponantojn, la jenaj estas konsiderataj: ilia reuzebleco, ilia anstataŭigebleco, kunteksta sendependeco, etendebleco, enkapsuligo kaj sendependeco.
Kun taŭga uzo de komponentoj, la problemo de la "granda pilko de malpuraĵo" (granda grandeco + alta kuplado) estas solvita, kaj la komponantoj mem povas reprezenti kaj kunigunuojn (moduloj, bibliotekoj) kaj deplojajn unuojn (servoj). Deplojaj unuoj ne ĉiam estas mapitaj al la funkcianta procezo: ekzemple, retejo-aplikaĵo kaj datumbazo estas deplojitaj kune.
Plej ofte, monolitoj estas evoluigitaj kiel aro de moduloj. Tiu aliro kondukas al sendependa evoluo, sed la problemoj de sendependa skalo kaj deplojo, faŭltoleremo kaj sendependeco de la totala teknologia stako restas. Tial la modulo estas parte sendependa komponanto.
La plej granda problemo kun tia monolito estas, ke la divido en modulojn estas pure logika kaj povas esti facile malobservita de programistoj. Povas aperi kerna modulo, kiu iom post iom iĝas rubujo, la grafikaĵo de dependecoj inter moduloj povas kreski, ktp. Por eviti tiajn problemojn, disvolviĝo devas esti farita aŭ de tre matura teamo, aŭ sub la gvido de "arkitekto", kiu okupiĝas pri plentempa koda revizio kaj batas la manojn de programistoj, kiuj malobservas la logikan strukturon.
La "ideala" monolito estas aro de logike apartigitaj moduloj, ĉiu el kiuj rigardas en sian propran datumbazon.
Servo-orientita arkitekturo
Se la sistemo supozeble estas organizita en la formo de aro da servoj, tiam ni parolas pri serva arkitekturo. Ĝiaj principoj estas uzant-centra aplikaĵo-kunfunkciebleco, komerca servo reuzo, teknologia staksendependeco, kaj aŭtonomio (sendependa evoluo, skaleblo, kaj deplojo).
Servo-orientita arkitekturo (SOA = serva orientita arkitekturo) solvas ĉiujn identigitajn problemojn de monolito: nur unu servo estas trafita kiam ŝanĝo okazas, kaj bone difinita API apogas bonan enkapsuligon de komponentoj.
Sed ne ĉio estas tiel glata: SOA kreas novajn problemojn. Foraj vokoj estas pli multekostaj ol lokaj, kaj redistribuado de respondecoj inter komponentoj fariĝis signife pli multekosta.
Cetere, la ebleco de sendependa deplojo estas tre grava trajto de la servo. Se servoj devas esti deplojitaj kune aŭ, krome, en certa sinsekvo, tiam la sistemo ne povas esti konsiderita servorientita. En ĉi tiu kazo, ili parolas pri distribuita monolito (konsiderata kontraŭ-ŝablono ne nur el la vidpunkto de SOA, sed ankaŭ el la vidpunkto de mikroserva arkitekturo).
Servo-orientita arkitekturo estas bone subtenata de la arkitektura komunumo kaj vendistoj. Ĉi tio implicas la ĉeeston de multaj kursoj kaj atestiloj, bone evoluintaj ŝablonoj. Ĉi-lasta inkluzivas, ekzemple, la konatan entreprenan servobuson (ESB = entreprena servobuso). Samtempe, ESB estas bagaĝo de vendistoj; ĝi ne nepre devas esti uzata en SOA.
La populareco de serv-orientita arkitekturo pintis ĉirkaŭ 2008, post kiu ĝi komencis malkreski, kiu iĝis signife pli drameca post la apero de mikroservoj (~2015).
konkludo
Post kiam ni diskutis pri la eblecoj organizi informsistemojn en formo de servoj kaj moduloj, mi proponas finfine transiri al la principoj de mikroserva arkitekturo kaj atenti speciale la diferencon inter mikroserva arkitekturo kaj serva arkitekturo en la sekva parto.
fonto: www.habr.com
