Jinsi ya Kukabiliana na Utata Wakati wa Kubuni Mifumo ya Programu

Yote yanahusu nini?

Kila siku, kila wakati wakati wa kazi yetu ya uhandisi, tunakutana na shida nyingi tofauti za ugumu na hali tofauti ambapo tunahitaji kufanya uamuzi au kuahirisha kwa sababu ya ukosefu wa data. Wakati wowote tunapounda huduma mpya, kujenga miundombinu, au hata kuunda michakato ya maendeleo, tunagusa ulimwengu mkubwa wa changamoto mbalimbali.

Ni changamoto, na pengine hata haiwezekani, kuorodhesha matatizo yote. Utakutana na baadhi ya masuala haya tu ikiwa unafanya kazi katika niche maalum. Kwa upande mwingine, kuna mengi ambayo sote lazima tuelewe jinsi ya kutatua, kwani ni muhimu kwa kujenga mifumo ya TEHAMA. Kwa uwezekano mkubwa, utakutana nao katika miradi yote.

Katika makala hii, nitashiriki uzoefu wangu na baadhi ya matatizo ambayo nimekutana nayo wakati wa kuunda programu za programu.

Wasiwasi wa Kukata Mtambuka ni Nini?

Tukiangalia katika Wikipedia, tutapata ufafanuzi ufuatao

Katika maendeleo ya programu yenye mwelekeo wa kipengele, wasiwasi wa kukata mtambuka ni vipengele vya programu vinavyoathiri moduli kadhaa, bila uwezekano wa kuingizwa katika mojawapo yao. Hoja hizi mara nyingi haziwezi kuoza kutoka kwa mfumo mzima katika muundo na utekelezaji, na zinaweza kusababisha kutawanyika (kurudia msimbo), kugongana (tegemezi kubwa kati ya mifumo), au zote mbili.

Inaelezea sana ni nini, lakini ninataka kupanua na kurahisisha kidogo:

Wasiwasi mtambuka ni dhana au sehemu ya mfumo/shirika inayoathiri (au 'kukata') sehemu nyingine nyingi.

Mifano bora zaidi ya maswala kama haya ni usanifu wa mfumo, ukataji miti, usalama, usimamizi wa shughuli, telemetry, muundo wa hifadhidata na kuna zingine nyingi. Tutaelezea mengi yao baadaye katika makala hii.

Kwenye kiwango cha msimbo, masuala mtambuka mara nyingi hutekelezwa kwa kutumia mbinu kama vile Aspect-Oriented Programming (AOP) , ambapo masuala haya yanapangwa katika vipengele tofauti vinavyoweza kutumika katika programu yote. Hii huweka mantiki ya biashara kutengwa na masuala haya, na kufanya msimbo kusomeka zaidi na kudumishwa.

Uainishaji wa Vipengele

Kuna njia nyingi zinazowezekana za jinsi ya kuainisha vipengele kwa kuvitenga na sifa tofauti kama vile upeo, saizi, utendakazi, umuhimu, lengo, na vingine, lakini katika makala haya, nitatumia uainishaji rahisi wa upeo. Kwa hili, ninamaanisha pale ambapo kipengele hiki mahususi kinaelekezwa iwe ni shirika zima, mfumo fulani, au kipengele maalum cha mfumo huo.

Kwa hivyo, nitagawanya vipengele kuwa Macro na Micro .

Kwa kipengele cha Macro ninamaanisha hasa mambo tunayofuata kwa mfumo mzima kama vile usanifu wa mfumo uliochaguliwa na muundo wake (monolithic, huduma ndogo, usanifu unaolenga huduma), mrundikano wa teknolojia, muundo wa shirika, n.k. Vipengele vingi vinahusiana hasa na kimkakati na kiwango cha juu. maamuzi.

Wakati huo huo, kipengele cha Micro kiko karibu zaidi na kiwango cha msimbo na maendeleo. Kwa mfano, ni mfumo gani unatumika kuingiliana na hifadhidata, muundo wa mradi wa folda na madarasa, au hata muundo maalum wa kitu.

Ingawa uainishaji huu si bora, husaidia kupanga uelewa wa matatizo yanayoweza kutokea na umuhimu na athari za suluhu tunazozitumia.

Katika nakala hii, lengo langu kuu litakuwa juu ya mambo ya jumla.

Vipengele vya Macro

Muundo wa shirika

Nilipoanza tu kujifunza kuhusu usanifu wa programu, nilisoma makala nyingi za kuvutia kuhusu sheria ya Conway na athari zake kwa muundo wa shirika. Hasa huyu . Kwa hiyo, sheria hii inasema hivyo

Shirika lolote linalounda mfumo (unaofafanuliwa kwa upana) litatoa muundo ambao muundo wake ni nakala ya muundo wa mawasiliano wa shirika.

Sikuzote nimeamini kwamba dhana hii ni ya ulimwengu wote na inawakilisha Kanuni ya Dhahabu.

Kisha nikaanza kujifunza mbinu ya Eric Evans's Domain-Driven Design (DDD) ya mifumo ya modeli. Eric Evans anasisitiza umuhimu wa kitambulisho cha Muktadha Wenye Mipaka. Dhana hii inahusisha kugawanya muundo changamano wa kikoa katika sehemu ndogo, zinazoweza kudhibitiwa zaidi, kila moja ikiwa na maarifa yake machache. Mbinu hii husaidia katika mawasiliano bora ya timu, kwani inapunguza hitaji la maarifa ya kina ya kikoa kizima na kupunguza ubadilishaji wa muktadha, na hivyo kufanya mazungumzo kuwa bora zaidi. Kubadilisha muktadha ndio jambo baya zaidi na linalotumia rasilimali zaidi kuwahi kutokea. Hata kompyuta zinapambana nayo. Ingawa hakuna uwezekano wa kufikia kutokuwepo kabisa kwa ubadilishaji wa muktadha, nadhani hiyo ndio tunapaswa kujitahidi.

Kurudi kwa Sheria ya Conway, nimepata maswala kadhaa nayo.

Toleo la kwanza ambalo nimekumbana nalo na Sheria ya Conway, ambayo inapendekeza kwamba muundo wa mfumo unaonyesha muundo wa shirika, ni uwezekano wa kuunda Muktadha wenye Mipaka ngumu na wa kina. Utata huu hutokea wakati muundo wa shirika haujaoanishwa na mipaka ya kikoa, na hivyo kusababisha Miktadha yenye Mipaka ambayo inategemeana kwa kiasi kikubwa na iliyosheheni taarifa. Husababisha kubadili-muktadha mara kwa mara kwa timu ya ukuzaji.

Suala jingine ni kwamba istilahi za shirika huvuja hadi kiwango cha msimbo. Wakati miundo ya shirika inabadilika, inahitaji marekebisho ya codebase, kuteketeza rasilimali muhimu.

Kwa hivyo, kufuata Inverse Conway Maneuver husaidia kujenga mfumo na shirika linalohimiza usanifu wa programu unaohitajika. Walakini, ni muhimu kusema kwamba mbinu hii haitafanya kazi vizuri katika usanifu na miundo iliyotengenezwa tayari kwani mabadiliko katika hatua hii ni ya muda mrefu, lakini inafanya kazi sana katika uanzishaji kwani wao ni wepesi wa kuanzisha mabadiliko yoyote.

Mpira Mkubwa wa Matope

Mchoro huu au "anti-pattern" huendesha ujenzi wa mfumo bila usanifu wowote. Hakuna sheria, hakuna mipaka, na hakuna mkakati wa jinsi ya kudhibiti ugumu unaoepukika unaokua. Utata ni adui mkubwa zaidi katika safari ya kujenga mifumo ya programu.

Ili kuepuka kuunda aina hiyo ya mfumo, tunahitaji kufuata sheria na vikwazo maalum.

Usanifu wa mfumo

Kuna ufafanuzi mwingi wa Usanifu wa Programu. Ninawapenda wengi wao kwani wanashughulikia nyanja tofauti zake. Walakini, ili kuweza kufikiria juu ya usanifu, tunahitaji kuunda baadhi yao katika akili zetu. Na ni vyema kusema kwamba ufafanuzi huu unaweza kubadilika. Kwa hivyo, angalau kwa sasa, nina maelezo yafuatayo kwangu.

Usanifu wa Programu ni kuhusu maamuzi na chaguo unazofanya kila siku zinazoathiri mfumo uliojengwa.

Ili kufanya maamuzi unayohitaji kuwa nayo katika kanuni na mifumo ya "mfuko" wako wa kutatua matatizo yanayotokea, ni muhimu pia kusema kwamba kuelewa mahitaji ni muhimu katika kujenga kile ambacho biashara inahitaji. Hata hivyo, wakati mwingine mahitaji si ya uwazi au hata haijafafanuliwa, katika kesi hii, ni bora kusubiri kupata ufafanuzi zaidi au kutegemea uzoefu wako na kuamini intuition yako. Lakini hata hivyo, huwezi kufanya maamuzi ipasavyo ikiwa huna kanuni na mifumo ya kutegemea. Hapo ndipo ninapokuja kwa ufafanuzi wa Mtindo wa Usanifu wa Programu.

Mtindo wa Usanifu wa Programu ni seti ya kanuni na mifumo inayobainisha jinsi ya kuunda programu.

Kuna mitindo mingi tofauti ya usanifu inayozingatia pande tofauti za usanifu uliopangwa, na kutumia nyingi mara moja ni hali ya kawaida.

Kwa mfano, kama vile:

1. Usanifu wa monolithic

2. Muundo unaoendeshwa na kikoa

3. Kipengele-msingi

4. Huduma ndogo ndogo

5. Bomba na vichungi

6. Inaendeshwa na tukio

7. Microkernel

8. Inayoelekezwa kwa huduma

   
   

na kadhalika...

Bila shaka, wana faida na hasara zao, lakini jambo muhimu zaidi ambalo nimejifunza ni kwamba usanifu hubadilika hatua kwa hatua huku ukitegemea matatizo halisi. Kuanzia na usanifu wa monolithic ni chaguo bora kwa kupunguza matatizo ya uendeshaji, kuna uwezekano mkubwa kwamba usanifu huu utafaa mahitaji yako hata baada ya kufikia hatua ya Bidhaa-soko ya Fit (PMI) ya kujenga bidhaa. Kwa kiwango kikubwa, unaweza kufikiria kuelekea mbinu inayoendeshwa na tukio na huduma ndogo ndogo za kufikia utumaji huru, mazingira ya mrundikano wa teknolojia tofauti tofauti, na usanifu uliounganishwa kidogo (na uwazi kidogo kwa wakati huu kwa sababu ya asili ya mbinu zinazoendeshwa na tukio na ndogo ikiwa hizi zimepitishwa). Urahisi na ufanisi ni karibu na una athari kubwa kwa kila mmoja. Kwa kawaida, usanifu changamano huathiri kasi ya ukuzaji wa vipengele vipya, kuunga mkono na kudumisha vilivyopo, na kutoa changamoto kwa mageuzi asilia ya mfumo.

Hata hivyo, mifumo ngumu mara nyingi inahitaji usanifu tata na wa kina, ambao hauepukiki.

Kwa kweli, hii ni mada pana sana, na kuna mawazo mengi mazuri kuhusu jinsi ya kuunda na kujenga mifumo ya mageuzi ya asili. Kulingana na uzoefu wangu, nimepanga njia ifuatayo:

1. Karibu kila mara huanza na mtindo wa usanifu wa monolithic kwani huondoa shida nyingi zinazotokea kwa sababu ya asili ya mifumo iliyosambazwa. Pia ni mantiki kufuata monolith ya msimu ili kuzingatia vipengele vya kujenga na mipaka iliyo wazi. Kutumia mkabala unaotegemea vipengele kunaweza kuwasaidia kuwasiliana wao kwa wao kwa kutumia matukio, lakini kuwa na simu za moja kwa moja (aka RPC) hurahisisha mambo mwanzoni. Walakini, ni muhimu kufuatilia utegemezi kati ya vijenzi kwani ikiwa kijenzi A kinajua mengi juu ya sehemu B, labda, inaeleweka kuviunganisha kuwa kimoja.
2. Unapokaribia hali unapohitaji kuongeza usanidi na mfumo wako, unaweza kuzingatia kufuata muundo wa Stangler ili kutoa vipengele ambavyo vinahitaji kutumwa kwa kujitegemea au hata kuongezwa kwa mahitaji mahususi.
3. Sasa, ikiwa una maono wazi ya siku zijazo, ambayo ni bahati nzuri sana, unaweza kuamua juu ya usanifu unaohitajika. Kwa wakati huu, unaweza kuamua kuelekea usanifu wa huduma ndogo kwa kutumia mbinu za Ochestration na Choreografia, ikijumuisha muundo wa CQRS wa shughuli za uandishi na usomaji huru, au hata kuamua kushikamana na usanifu wa monolithic ikiwa inafaa mahitaji yako.

Pia ni muhimu kuelewa nambari na vipimo kama vile DAU (Watumiaji Wanaotumika Kila Siku), MAU (Watumiaji Wanaotumika Kila Mwezi), RPC (Ombi kwa Sekunde), na TPC (Muamala kwa Sekunde) kwani inaweza kukusaidia kufanya chaguo kwa sababu usanifu wa Watumiaji 100 wanaofanya kazi na watumiaji milioni 100 wanaofanya kazi ni tofauti.

Kama dokezo la mwisho, ningesema kwamba usanifu una athari kubwa kwa mafanikio ya bidhaa. Usanifu ulioundwa vibaya kwa bidhaa unahitajika katika kuongeza, ambayo inaweza kusababisha kutofaulu kwani wateja hawatasubiri unapoongeza mfumo, watachagua mshindani, kwa hivyo tunahitaji kuwa mbele ya kuongeza uwezo. Ingawa ninakubali kuwa wakati mwingine haiwezi kuwa njia konda, wazo ni kuwa na mfumo mbaya lakini ambao haujapimwa tayari. Kwa upande mwingine, kuwa na mfumo mgumu sana na ambao tayari umekuzwa bila wateja au mipango ya kupata wengi wao itakugharimu pesa kwenye biashara yako bure.

Uchaguzi wa safu ya teknolojia

Kuchagua mrundikano wa teknolojia pia ni uamuzi wa kiwango kikubwa kwa kuwa huathiri uajiri, mitazamo ya mabadiliko ya asili ya mfumo, uboreshaji, na utendaji wa mfumo.

Hii ndio orodha ya mambo ya msingi ya kuchagua stack ya teknolojia:

• Mahitaji ya mradi na utata. Kwa mfano, programu rahisi ya wavuti inaweza kujengwa na mfumo wa Blazor ikiwa watengenezaji wako wana uzoefu nayo, lakini kwa sababu ya ukosefu wa ukomavu wa WebAssembly, kuchagua React na Typescript kwa mafanikio ya muda mrefu inaweza kuwa uamuzi bora.
• Scalability na Mahitaji ya Utendaji. Ikiwa unatarajia kupokea idadi kubwa ya trafiki, kuchagua ASP.NET Core juu ya Django kunaweza kuwa chaguo la busara kwa sababu ya utendakazi wake bora katika kushughulikia maombi ya wakati mmoja. Walakini, uamuzi huu unategemea ukubwa wa trafiki unayotarajia. Iwapo unahitaji kudhibiti uwezekano wa mabilioni ya maombi ukiwa na muda mdogo wa kusubiri, kuwepo kwa Ukusanyaji wa Taka kunaweza kuwa changamoto.
• Kuajiri, Muda wa Maendeleo, na Gharama. Katika hali nyingi, hizi ndizo sababu tunazohitaji kujali. Muda wa Soko, Gharama ya Matengenezo, na Uthabiti wa Kuajiri huendesha mahitaji ya biashara yako bila vikwazo.
• Utaalam wa Timu na Rasilimali. Seti ya ujuzi wa timu yako ya maendeleo ni jambo muhimu. Kwa ujumla ni bora zaidi kutumia teknolojia ambazo timu yako tayari inazifahamu isipokuwa kama kuna sababu kubwa ya kuwekeza katika kujifunza mkusanyiko mpya.
• Ukomavu. Jumuiya imara na mfumo tajiri wa ikolojia wa maktaba na zana zinaweza kurahisisha sana mchakato wa maendeleo. Teknolojia maarufu mara nyingi huwa na usaidizi bora wa jamii, ambao unaweza kuwa wa thamani sana katika kutatua matatizo na kutafuta rasilimali. Kwa hivyo, unaweza kuokoa rasilimali na kuzingatia zaidi bidhaa.
• Matengenezo na Usaidizi wa Muda Mrefu. Fikiria uwezekano wa muda mrefu wa teknolojia. Teknolojia zinazokubaliwa na kuungwa mkono na watu wengi zina uwezekano mdogo wa kupitwa na wakati na kwa ujumla hupokea masasisho na maboresho ya mara kwa mara.

Je, kuwa na rundo la teknolojia nyingi kunaweza kuathiri ukuaji wa biashara?

Kwa mtazamo mmoja, kuletea rundo moja zaidi kunaweza kuongeza uajiri wako, lakini kwa upande mwingine, huleta gharama za ziada za matengenezo kwa kuwa unahitaji kuhimili rafu zote mbili. Kwa hivyo, kama nilivyosema hapo awali, kwa maoni yangu, hitaji la ziada pekee linapaswa kuwa hoja ya kujumuisha safu nyingi za teknolojia.

Lakini ni nini kuhusu kanuni ya kuchagua chombo bora kwa tatizo fulani?

Wakati mwingine huna chaguo lingine ila kuleta zana mpya za kutatua tatizo fulani kulingana na mazingatio yale yale yaliyotajwa hapo juu, katika hali kama hizi, ni mantiki kuchagua suluhu bora.

Uundaji wa mifumo bila muunganisho wa hali ya juu kwa teknolojia maalum inaweza kuwa changamoto. Bado, ni muhimu kujitahidi kwa hali ambapo mfumo haujaunganishwa sana na teknolojia, na hautakufa ikiwa kesho, mfumo maalum au chombo kitakuwa hatarini au hata kuacha kutumika.

Jambo lingine muhimu la kuzingatia linahusiana na utegemezi wa chanzo-wazi na umiliki wa programu. Programu ya umiliki hukupa kubadilika kidogo na uwezekano wa kubinafsishwa. Bado, sababu hatari zaidi ni kufuli kwa muuzaji, ambapo unakuwa tegemezi kwa bidhaa za muuzaji, bei, masharti na ramani ya barabara. Hii inaweza kuwa hatari ikiwa muuzaji atabadilisha mwelekeo, kuongeza bei, au kuacha bidhaa. Programu huria hupunguza hatari hii, kwani huluki moja haidhibiti. Kuondoa hatua moja ya kushindwa katika ngazi zote ni ufunguo wa kujenga mifumo ya kuaminika ya ukuaji.

Pointi Moja ya Kushindwa (SPOF)

Pointi moja ya kutofaulu (SPOF) inarejelea sehemu yoyote ya mfumo ambayo, ikiwa itashindwa, itasababisha mfumo mzima kuacha kufanya kazi. Kuondoa SPOF katika viwango vyote ni muhimu kwa mfumo wowote unaohitaji upatikanaji wa juu. Kila kitu, ikiwa ni pamoja na ujuzi, wafanyakazi, vipengele vya mfumo, watoa huduma za wingu, na nyaya za mtandao, zinaweza kushindwa.

Kuna mbinu kadhaa za kimsingi ambazo tunaweza kutumia ili kuondoa alama moja za kutofaulu:

1. Upungufu. Tekeleza upungufu kwa vipengele muhimu. Hii inamaanisha kuwa na vipengee vya chelezo ambavyo vinaweza kuchukua nafasi ikiwa kijenzi cha msingi kitashindwa. Upungufu unaweza kutumika katika tabaka tofauti za mfumo, ikijumuisha maunzi (seva, diski), mitandao (viungo, swichi), na programu (hifadhidata, seva za programu). Iwapo unapangisha kila kitu katika Mtoa Huduma wa Wingu mmoja na hata kuwa na hifadhi rudufu hapo, zingatia kuweka nakala ya ziada ya mara kwa mara katika nyingine ili kupunguza gharama yako iliyopotea endapo kutatokea maafa.
2. Vituo vya Data. Sambaza mfumo wako katika maeneo mengi halisi, kama vile vituo vya data au maeneo ya wingu. Mbinu hii hulinda mfumo wako dhidi ya hitilafu maalum za eneo kama vile kukatika kwa umeme au majanga ya asili.
3. Failover. Tumia mbinu ya kutofaulu kwa vipengele vyako vyote (DNS, CDN, Sawazisha Mizigo, Kubernetes, Lango la API, na Hifadhidata). Kwa kuwa maswala yanaweza kutokea bila kutarajiwa, ni muhimu kuwa na mpango wa chelezo wa kubadilisha sehemu yoyote na mshirika wake kama inavyohitajika haraka.
4. Huduma za upatikanaji wa juu. Hakikisha kuwa huduma zako zimeundwa ili ziwe za usawa na zipatikane sana tangu mwanzo kwa kuzingatia kanuni zifuatazo:
   • Fanya mazoezi ya kutokuwa na utaifa wa huduma na epuka kuhifadhi vipindi vya watumiaji kwenye akiba za kumbukumbu. Badala yake, tumia mfumo wa kache uliosambazwa, kama vile Redis.
   • Epuka kutegemea mpangilio wa mpangilio wa matumizi ya ujumbe wakati wa kuunda mantiki.
   • Punguza mabadiliko yanayokiuka ili kuzuia kutatiza watumiaji wa API. Inapowezekana, chagua mabadiliko yanayolingana na kurudi nyuma. Pia, fikiria gharama kwani wakati mwingine, kutekeleza mabadiliko yanayovunja kunaweza kuwa na gharama nafuu zaidi.
   • Jumuisha utekelezaji wa uhamiaji kwenye bomba la kupeleka.
   • Weka mkakati wa kushughulikia maombi ya wakati mmoja.
   • Tekeleza ugunduzi wa huduma, ufuatiliaji, na ukataji miti ili kuimarisha kutegemewa na kuzingatiwa.
   • Tengeneza mantiki ya biashara ili usiwe na uwezo, ukikubali kwamba hitilafu za mtandao haziepukiki.
5. Mapitio ya utegemezi. Kagua mara kwa mara na upunguze utegemezi wa nje. Kila utegemezi wa nje unaweza kuanzisha SPOF zinazowezekana, kwa hivyo ni muhimu kuelewa na kupunguza hatari hizi.
6. Kushiriki maarifa mara kwa mara. Kamwe usisahau umuhimu wa kueneza maarifa ndani ya shirika lako. Watu wanaweza kuwa wasiotabirika, na kumtegemea mtu mmoja ni hatari. Wahimize washiriki wa timu kuweka maarifa yao kwa njia ya kidijitali kupitia uwekaji kumbukumbu. Hata hivyo, kuwa makini na kuandika zaidi. Tumia zana mbalimbali za AI ili kurahisisha mchakato huu.

Hitimisho

Katika nakala hii, tulishughulikia mambo kadhaa muhimu ya Macro na jinsi tunaweza kukabiliana na ugumu wao.

Asante kwa kusoma! Tuonane wakati ujao!