Hello, Habr. Ngayon ay nagpapatuloy ako ng isang serye ng mga publikasyon na partikular kong isinulat para sa pagsisimula ng isang bagong stream ng kurso. .
Pagpapakilala
Ang pagpili ng istilo ng arkitektura ay isa sa mga pangunahing teknikal na desisyon kapag nagtatayo ng isang sistema ng impormasyon. Sa seryeng ito ng mga artikulo, iminumungkahi kong pag-aralan ang pinakasikat na istilo ng arkitektura para sa pagbuo ng mga aplikasyon at sagutin ang tanong kung kailan kung aling istilo ng arkitektura ang pinakagusto. Sa proseso ng pagtatanghal, susubukan kong gumuhit ng isang lohikal na kadena na nagpapaliwanag sa pagbuo ng mga istilo ng arkitektura mula sa mga monolith hanggang sa mga microservice.
В nakipag-usap kami sa monolith at napagpasyahan na ang monolith ay may ilang mga problema: laki, pagkakakonekta, pag-deploy, scalability, pagiging maaasahan at katigasan.
Sa pagkakataong ito, iminumungkahi kong pag-usapan ang mga posibilidad ng pag-aayos ng isang sistema bilang isang hanay ng mga module/library (component-oriented architecture) o mga serbisyo (service-oriented architecture).
Component-oriented na arkitektura
Ang arkitektura na nakatuon sa bahagi ay nagsasangkot ng pagpapatupad ng isang sistema bilang isang hanay ng mga bahagi na maaaring magamit sa kasalukuyan at sa hinaharap na mga proyekto. Kapag hinahati-hati ang isang system sa mga bahagi, ang mga sumusunod ay isinasaalang-alang: ang kanilang muling paggamit, ang kanilang kakayahang palitan, pagsasarili sa konteksto, pagpapalawig, encapsulation at kalayaan.
Sa wastong paggamit ng mga bahagi, ang problema ng "malaking bola ng dumi" (malaking sukat + mataas na pagkabit) ay malulutas, at ang mga bahagi mismo ay maaaring parehong mga yunit ng pagpupulong (mga module, mga aklatan) at mga yunit ng pag-deploy (mga serbisyo). Ang mga deployment unit ay hindi palaging nakamapa sa tumatakbong proseso: halimbawa, isang web application at isang database ay naka-deploy nang magkasama.
Kadalasan, ang mga monolith ay binuo bilang isang hanay ng mga module. Ang diskarte na ito ay humahantong sa independiyenteng pag-unlad, ngunit ang mga problema ng independiyenteng scaling at deployment, fault tolerance at kalayaan mula sa pangkalahatang stack ng teknolohiya ay nananatili. Kaya naman ang modyul ay isang bahagyang independiyenteng bahagi.
Ang pinakamalaking problema sa naturang monolith ay ang paghahati sa mga module ay purong lohikal at madaling nilabag ng mga developer. Maaaring lumitaw ang isang pangunahing module, na unti-unting nagiging basurahan, maaaring lumaki ang graph ng mga dependency sa pagitan ng mga module, at iba pa. Upang maiwasan ang mga ganitong problema, dapat isagawa ang pagbuo ng alinman sa isang napaka-mature na koponan, o sa ilalim ng gabay ng isang "arkitekto" na nakikibahagi sa full-time na pagsusuri ng code at tinatalo ang mga kamay ng mga developer na lumalabag sa lohikal na istraktura.
Ang "ideal" na monolith ay isang hanay ng mga lohikal na pinaghihiwalay na mga module, na bawat isa ay tumitingin sa sarili nitong database.
Arkitekturang nakatuon sa serbisyo
Kung ang sistema ay dapat na isinaayos sa anyo ng isang hanay ng mga serbisyo, kung gayon ang pinag-uusapan natin ay isang arkitektura na nakatuon sa serbisyo. Ang mga prinsipyo nito ay user-centric application interoperability, business service reuse, technology stack independence, at autonomy (independent evolution, scalability, at deployment).
Ang arkitektura na nakatuon sa serbisyo (SOA = arkitektura na nakatuon sa serbisyo) ay nilulutas ang lahat ng natukoy na problema ng isang monolith: isang serbisyo lamang ang apektado kapag may pagbabago, at ang isang mahusay na tinukoy na API ay sumusuporta sa mahusay na encapsulation ng mga bahagi.
Ngunit hindi lahat ay napakakinis: Lumilikha ang SOA ng mga bagong problema. Ang mga malalayong tawag ay mas mahal kaysa sa mga lokal, at ang muling pamamahagi ng mga responsibilidad sa pagitan ng mga bahagi ay naging mas mahal.
Sa pamamagitan ng paraan, ang posibilidad ng independiyenteng pag-deploy ay isang napakahalagang tampok ng serbisyo. Kung ang mga serbisyo ay dapat na i-deploy nang magkasama o, bukod dito, sa isang tiyak na pagkakasunud-sunod, kung gayon ang system ay hindi maituturing na nakatuon sa serbisyo. Sa kasong ito, pinag-uusapan nila ang tungkol sa isang ibinahagi na monolith (itinuring na isang anti-pattern hindi lamang mula sa punto ng view ng SOA, kundi pati na rin mula sa punto ng view ng microservice architecture).
Ang arkitektura na nakatuon sa serbisyo ay mahusay na sinusuportahan ng komunidad ng arkitektura at mga vendor. Ito ay nagpapahiwatig ng pagkakaroon ng maraming mga kurso at sertipikasyon, mahusay na binuo pattern. Kasama sa huli, halimbawa, ang kilalang enterprise service bus (ESB = enterprise service bus). Kasabay nito, ang ESB ay isang bagahe mula sa mga vendor; hindi ito kinakailangang gamitin sa SOA.
Ang katanyagan ng arkitektura na nakatuon sa serbisyo ay sumikat noong 2008, pagkatapos nito ay nagsimula itong bumaba, na naging mas dramatiko pagkatapos ng pagdating ng mga microservice (~2015).
Konklusyon
Matapos nating talakayin ang mga posibilidad ng pag-aayos ng mga sistema ng impormasyon sa anyo ng mga serbisyo at module, iminumungkahi kong sa wakas ay lumipat sa mga prinsipyo ng arkitektura ng microservice at bigyang-pansin ang pagkakaiba sa pagitan ng arkitektura ng microservice at arkitektura na nakatuon sa serbisyo sa susunod na bahagi.
Pinagmulan: www.habr.com