Kuchagua mtindo wa usanifu (sehemu ya 2)

Habari, Habr. Leo ninaendelea na mfululizo wa machapisho ambayo niliandika mahsusi kwa ajili ya kuanza kwa mkondo mpya wa kozi hiyo. "Msanifu wa programu".

Utangulizi

Uchaguzi wa mtindo wa usanifu ni mojawapo ya maamuzi ya msingi ya kiufundi wakati wa kujenga mfumo wa habari. Katika mfululizo huu wa makala, napendekeza kuchambua mitindo maarufu ya usanifu kwa ajili ya maombi ya ujenzi na kujibu swali la ni wakati gani mtindo wa usanifu unapendekezwa zaidi. Katika mchakato wa uwasilishaji, nitajaribu kuteka mlolongo wa mantiki unaoelezea maendeleo ya mitindo ya usanifu kutoka kwa monoliths hadi microservices.

В mara ya mwisho tulishughulikia monolith na tukafikia hitimisho kwamba monolith ina idadi ya matatizo: ukubwa, uunganisho, kupelekwa, scalability, kuegemea na rigidity.

Wakati huu ninapendekeza kuzungumza juu ya uwezekano wa kupanga mfumo kama seti ya moduli/maktaba (usanifu unaoelekezwa kwa sehemu) au huduma (usanifu unaoelekezwa kwa huduma).

Usanifu unaozingatia vipengele

Usanifu unaozingatia vipengele unahusisha kutekeleza mfumo kama seti ya vipengele vinavyoweza kutumika katika miradi ya sasa na ya baadaye. Wakati wa kuvunja mfumo katika vipengele, zifuatazo zinazingatiwa: reusability yao, uingizwaji wao, uhuru wa mazingira, upanuzi, encapsulation na uhuru.

Kwa matumizi sahihi ya vipengele, tatizo la "mpira mkubwa wa uchafu" (ukubwa mkubwa + kuunganisha juu) hutatuliwa, na vipengele vyenyewe vinaweza kuwa vitengo vya mkutano (moduli, maktaba) na vitengo vya kupeleka (huduma). Vitengo vya upelekaji si mara zote vinaratibiwa kwa mchakato unaoendelea: kwa mfano, programu ya wavuti na hifadhidata huwekwa pamoja.

Mara nyingi, monoliths hutengenezwa kama seti ya moduli. Njia hii inaongoza kwa maendeleo ya kujitegemea, lakini matatizo ya kuongeza na kupelekwa kwa kujitegemea, uvumilivu wa makosa na uhuru kutoka kwa stack ya teknolojia ya jumla hubakia. Ndio maana moduli ni sehemu inayojitegemea.

Shida kubwa na monolith kama hiyo ni kwamba mgawanyiko katika moduli ni wa kimantiki na unaweza kukiukwa kwa urahisi na watengenezaji. Moduli ya msingi inaweza kuonekana, ambayo hatua kwa hatua inageuka kuwa takataka, grafu ya utegemezi kati ya moduli inaweza kukua, na kadhalika. Ili kuepuka matatizo hayo, maendeleo yanapaswa kufanywa ama na timu ya watu wazima sana, au chini ya uongozi wa "mbunifu" ambaye anajishughulisha na ukaguzi wa wakati wote wa kanuni na hupiga mikono ya watengenezaji wanaokiuka muundo wa mantiki.

Monolith "bora" ni seti ya moduli zilizotenganishwa kimantiki, ambayo kila moja inaonekana kwenye hifadhidata yake.

Usanifu unaozingatia huduma

Ikiwa mfumo unatakiwa kupangwa kwa namna ya seti ya huduma, basi tunazungumzia usanifu unaozingatia huduma. Kanuni zake ni utengamano wa programu unaozingatia mtumiaji, utumiaji tena wa huduma ya biashara, uhuru wa msururu wa teknolojia, na uhuru (mabadiliko huru, uwazi, na utumiaji).

Usanifu unaozingatia huduma (SOA = usanifu unaoelekezwa kwa huduma) hutatua matatizo yote yaliyotambuliwa ya monolith: huduma moja tu huathiriwa wakati mabadiliko yanapotokea, na API iliyoelezwa vizuri inasaidia encapsulation nzuri ya vipengele.

Lakini si kila kitu ni laini sana: SOA inajenga matatizo mapya. Simu za mbali ni ghali zaidi kuliko za ndani, na ugawaji wa majukumu kati ya vipengele umekuwa ghali zaidi.

Kwa njia, uwezekano wa kupelekwa kwa kujitegemea ni kipengele muhimu sana cha huduma. Ikiwa huduma lazima zitumike pamoja au, zaidi ya hayo, katika mlolongo fulani, basi mfumo hauwezi kuchukuliwa kuwa unazingatia huduma. Katika kesi hii, wanazungumza juu ya monolith iliyosambazwa (kuchukuliwa kuwa muundo wa kupinga sio tu kutoka kwa mtazamo wa SOA, lakini pia kutoka kwa mtazamo wa usanifu wa microservice).

Usanifu unaoelekezwa kwa huduma unaungwa mkono vyema na jamii ya usanifu na wachuuzi. Hii ina maana ya kuwepo kwa kozi nyingi na vyeti, mifumo iliyoendelezwa vizuri. Mwisho ni pamoja na, kwa mfano, basi inayojulikana ya huduma ya biashara (ESB = basi ya huduma ya biashara). Wakati huo huo, ESB ni mizigo kutoka kwa wauzaji; si lazima itumike katika SOA.

Umaarufu wa usanifu unaozingatia huduma ulifikia kilele karibu 2008, baada ya hapo ulianza kupungua, ambayo ikawa ya kushangaza zaidi baada ya ujio wa huduma ndogo (~2015).

Hitimisho

Baada ya kujadili uwezekano wa kuandaa mifumo ya habari kwa namna ya huduma na moduli, napendekeza hatimaye kuendelea na kanuni za usanifu wa microservice na kulipa kipaumbele maalum kwa tofauti kati ya usanifu wa microservice na usanifu unaozingatia huduma katika sehemu inayofuata.

Chanzo: mapenzi.com