Saluton, habr. Aliĝo por nova kursfluo estas malfermita nun ĉe OTUS . Antaŭtagmeze de la komenco de la kurso, mi volas dividi kun vi mian originalan artikolon.
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.
Iom da historio
Se vi provas demandi programistojn: "Kial ni bezonas mikroservojn?", vi ricevos diversajn respondojn. Vi aŭdos, ke mikroservoj plibonigas skaleblon, faciligas kodon kompreneblan, plibonigas misfunkciadon, kaj foje vi aŭdos, ke ili permesas al vi "purigi vian kodon". Ni rigardu historion por kompreni la celon malantaŭ la apero de mikroservoj.
Resume, mikroservoj laŭ nia nuna kompreno aperis jene: en 2011, James Lewis, analizante la laboron de diversaj kompanioj, atentigis pri la apero de nova "mikro-apo" ŝablono, kiu optimumigis SOA rilate al akcelo de la disvastigo de servoj. Iom poste, en 2012, ĉe arkitektura pintkunveno, la ŝablono estis renomita mikroservo. Tiel, la komenca celo de enkonduko de mikroservoj estis plibonigi la fifaman tempo por merkati.
Mikroservoj estis en la ondo en 2015. Laŭ iuj studoj, eĉ ne unu konferenco estis kompleta sen raporto pri la temo de mikroservoj. Krome, kelkaj konferencoj estis dediĉitaj ekskluzive al mikroservoj. Nuntempe, multaj projektoj komencas uzi ĉi tiun arkitekturan stilon, kaj se la projekto enhavas tunojn da hereda kodo, tiam migrado al mikroservoj verŝajne aktive efektiviĝas.
Malgraŭ ĉio ĉi-supra, sufiĉe malgranda nombro da programistoj ankoraŭ povas difini la koncepton de "mikroservo". Sed pri tio ni parolos iom poste...
Monolito
La arkitektura stilo, kiu kontrastas mikroservojn, estas la monolito (aŭ ĉio-en-unu). Verŝajne ne havas sencon diri, kio estas monolito, do mi tuj listigos la malavantaĝojn de ĉi tiu arkitektura stilo, kiu iniciatis la pluan disvolviĝon de arkitekturaj stiloj: grandeco, konektebleco, disvastiĝo, skalebleco, fidindeco kaj rigideco. Malsupre mi proponas rigardi ĉiun el la mankoj aparte.
grandeco
La monolito estas tre granda. Kaj ĝi kutime komunikas kun tre granda datumbazo. La aplikaĵo fariĝas tro granda por ke unu programisto entute komprenu. Nur tiuj, kiuj pasigis multan tempon laborante pri ĉi tiu kodo, povas bone labori kun la monolito, dum komencantoj pasigos multan tempon provante eltrovi la monoliton kaj ne garantias, ke ili eltrovos ĝin. Kutime, kiam oni laboras kun monolito, ĉiam estas iu "kondiĉa" maljunulo, kiu pli-malpli bone konas la monoliton kaj batas la manojn de aliaj novaj programistoj ene de jaro kaj duono. Nature, tia kondiĉa maljunulo estas ununura punkto de fiasko, kaj lia foriro povas konduki al la morto de la monolito.
Konekto
La monolito estas "granda pilko de koto", ŝanĝoj en kiuj povas konduki al neantaŭvideblaj sekvoj. Farante ŝanĝojn en unu loko, vi povas damaĝi la monoliton en alia (la sama "vi gratis vian orelon, *@ defalis"). Ĉi tio estas pro la fakto, ke la komponantoj en la monolito havas tre kompleksajn kaj, plej grave, ne-evidentajn rilatojn.
Deplojo
Deploji monoliton, pro la kompleksaj rilatoj inter ĝiaj komponantoj, estas longa procezo kun sia propra rito. Tia rito kutime ne estas tute normigita kaj estas transdonita "buŝe".
Skalebleco
Monolitmoduloj povas havi konfliktantajn rimedbezonojn, postulante kompromison esti farita laŭ aparataro. Imagu, ke vi havas monoliton konsistantan el servoj A kaj B. Servo A postulas la grandecon de la malmola disko, kaj servo B postulas RAM. En ĉi tiu kazo, aŭ la maŝino sur kiu la monolito estas instalita devas subteni la postulojn de ambaŭ servoj, aŭ vi devos mane, artefarite malŝalti unu el la servoj.
Alia ekzemplo (pli klasika): servo A estas multe pli populara ol servo B, do vi volas, ke estu 100 servoj A, kaj 10 servoj B. Denove, du ebloj: aŭ ni deplojas 100 plenrajtajn monolitojn, aŭ sur iuj tiam. servoj B devos esti malŝaltitaj permane.
Fidindeco
Ĉar ĉiuj servoj situas kune, se la monolito falas, tiam ĉiuj servoj falas samtempe. Fakte, ĉi tio eble ne estas tiel malbona, almenaŭ ne estos partaj misfunkciadoj en distribuita sistemo, sed aliflanke, pro cimo en funkcieco, kiu estas uzata de 0.001% de uzantoj, vi povas perdi ĉiujn uzantojn. de via sistemo.
Inercio
Pro la grandeco de la monolito, estas malfacile ŝanĝi al novaj teknologioj. Kiel rezulto, reteni tiun saman aĝulon estas aparta tasko. La teknologia stako elektita ĉe la komenco de projekto povas fariĝi bloko kiu malhelpas la disvolviĝon de la produkto.
konkludo
Venontfoje ni parolos pri kiel homoj provis solvi ĉi tiujn problemojn moviĝante al komponantoj kaj SOA.
Legu pli:
fonto: www.habr.com