Pagpili sa usa ka estilo sa arkitektura (bahin 2)

Hello, Habr. Karon nagpadayon ako sa usa ka serye sa mga publikasyon nga akong gisulat alang sa pagsugod sa usa ka bag-ong stream sa kurso. "Arkitekto sa Software".

Pasiuna

Ang pagpili sa istilo sa arkitektura usa sa sukaranan nga teknikal nga mga desisyon kung magtukod usa ka sistema sa kasayuran. Sa kini nga serye sa mga artikulo, akong gisugyot nga analisahon ang labing inila nga istilo sa arkitektura alang sa mga aplikasyon sa pagtukod ug tubagon ang pangutana kung kanus-a kung unsang istilo sa arkitektura ang labing gusto. Sa proseso sa presentasyon, sulayan nako ang pagdrowing og usa ka lohikal nga kadena nga nagpatin-aw sa pagpalambo sa mga estilo sa arkitektura gikan sa monoliths ngadto sa microservices.

Π’ katapusan nga panahon among giatubang ang monolith ug nakahinapos nga ang monolith adunay daghang mga problema: gidak-on, koneksyon, pag-deploy, scalability, kasaligan ug rigidity.

Niining higayona akong gisugyot nga hisgutan ang mga posibilidad sa pag-organisar sa usa ka sistema ingon usa ka hugpong sa mga modules/library (component-oriented architecture) o mga serbisyo (service-oriented architecture).

Component-oriented nga arkitektura

Component-oriented nga arkitektura naglakip sa pagpatuman sa usa ka sistema isip usa ka hugpong sa mga sangkap nga mahimong magamit sa karon ug sa umaabot nga mga proyekto. Kung gibuak ang usa ka sistema sa mga sangkap, ang mga musunud gikonsiderar: ang ilang magamit pag-usab, ang ilang pagkapuli, independensya sa konteksto, pagkalapad, encapsulation ug independensya.

Uban sa husto nga paggamit sa mga sangkap, ang problema sa "dako nga bola sa hugaw" (dako nga gidak-on + taas nga pagdugtong) masulbad, ug ang mga sangkap mismo mahimong mga yunit sa asembliya (mga module, librarya) ug mga yunit sa pag-deploy (mga serbisyo). Ang mga yunit sa pag-deploy dili kanunay nga mapa sa proseso sa pagdagan: pananglitan, usa ka aplikasyon sa web ug usa ka database ang gi-deploy nga magkauban.

Kasagaran, ang mga monolith gihimo ingon usa ka hugpong sa mga module. Kini nga pamaagi modala ngadto sa independente nga kalamboan, apan ang mga problema sa independente nga scaling ug deployment, fault tolerance ug kagawasan gikan sa kinatibuk-ang teknolohiya stack nagpabilin. Mao nga ang module usa ka partially independent component.

Ang pinakadako nga problema sa ingon nga usa ka monolith mao nga ang pagbahin sa mga module lunsay lohikal ug dali nga malapas sa mga developer. Ang usa ka kinauyokan nga module mahimong motungha, nga anam-anam nga nahimo nga basurahan, ang graph sa mga dependency tali sa mga module mahimong motubo, ug uban pa. Aron malikayan ang ingon nga mga problema, ang pag-uswag kinahanglan nga himuon bisan sa usa ka hamtong nga grupo, o ubos sa paggiya sa usa ka "arkitekto" nga nag-apil sa full-time nga pagrepaso sa code ug gibunalan ang mga kamot sa mga developer nga naglapas sa lohikal nga istruktura.

Ang "ideal" nga monolith usa ka set sa mga modulo nga gibulag sa lohikal, nga ang matag usa nagtan-aw sa kaugalingon nga database.

Ang arkitektura nga nakabase sa serbisyo

Kung ang sistema kinahanglan nga organisado sa porma sa usa ka hugpong sa mga serbisyo, nan naghisgot kami bahin sa usa ka arkitektura nga nakabase sa serbisyo. Ang mga prinsipyo niini mao ang user-centric application interoperability, business service reuse, technology stack independence, ug autonomy (independent evolution, scalability, ug deployment).

Ang arkitektura nga nakabase sa serbisyo (SOA = arkitektura nga nakapunting sa serbisyo) nagsulbad sa tanan nga nahibal-an nga mga problema sa usa ka monolith: usa ra ka serbisyo ang maapektuhan kung adunay pagbag-o, ug ang usa ka maayo nga gipasabut nga API nagsuporta sa maayo nga encapsulation sa mga sangkap.

Apan dili kaayo hapsay ang tanan: Ang SOA nagmugna og bag-ong mga problema. Ang layo nga mga tawag mas mahal kaysa lokal, ug ang pag-apod-apod sa mga responsibilidad tali sa mga sangkap nahimong labi ka mahal.

Pinaagi sa dalan, ang posibilidad sa independente nga pag-deploy usa ka hinungdanon nga bahin sa serbisyo. Kung ang mga serbisyo kinahanglan nga i-deploy nga magkauban o, dugang pa, sa usa ka piho nga pagkasunod-sunod, nan ang sistema dili makonsiderar nga service-oriented. Sa kini nga kaso, naghisgot sila bahin sa usa ka giapod-apod nga monolith (gikonsiderar nga usa ka anti-pattern dili lamang gikan sa punto sa panglantaw sa SOA, kondili usab gikan sa punto sa panglantaw sa microservice architecture).

Ang arkitektura nga nakabase sa serbisyo maayo nga gisuportahan sa komunidad sa arkitektura ug mga tigbaligya. Kini nagpasabot sa presensya sa daghang mga kurso ug mga sertipikasyon, maayo nga naugmad nga mga sumbanan. Ang ulahi naglakip, pananglitan, ang iladong bus nga serbisyo sa negosyo (ESB = bus nga serbisyo sa negosyo). Sa samang higayon, ang ESB usa ka bagahe gikan sa mga tigbaligya; dili kinahanglan nga gamiton kini sa SOA.

Ang pagkapopular sa arkitektura nga nakabase sa serbisyo nag-una sa palibot sa 2008, pagkahuman nagsugod kini sa pagkunhod, nga nahimong labi ka labi ka katingad-an pagkahuman sa pag-abut sa mga microservice (~ 2015).

konklusyon

Human nato nahisgutan ang mga posibilidad sa pag-organisar sa mga sistema sa impormasyon sa porma sa mga serbisyo ug mga module, akong gisugyot nga sa katapusan mobalhin ngadto sa mga prinsipyo sa microservice nga arkitektura ug paghatag og espesyal nga pagtagad sa kalainan tali sa microservice nga arkitektura ug service-oriented nga arkitektura sa sunod nga bahin.

Pagpili sa usa ka estilo sa arkitektura (bahin 2)

Source: www.habr.com

Idugang sa usa ka comment