Habari Habr!

Kwa kuzingatia matukio ya sasa kutokana na coronavirus, idadi ya huduma za mtandao zimeanza kupokea mzigo ulioongezeka. Kwa mfano, Moja ya minyororo ya rejareja ya Uingereza ilisimamisha tovuti yake ya kuagiza mtandaoni., kwa sababu hakukuwa na uwezo wa kutosha. Na si mara zote inawezekana kuharakisha seva kwa kuongeza tu vifaa vyenye nguvu zaidi, lakini maombi ya mteja lazima yashughulikiwe (au wataenda kwa washindani).

Katika makala hii nitazungumzia kwa ufupi kuhusu mazoea maarufu ambayo yatakuwezesha kuunda huduma ya haraka na isiyo na makosa. Hata hivyo, kutoka kwa mipango ya maendeleo inayowezekana, nilichagua tu ambayo ni sasa rahisi kutumia. Kwa kila kitu, unaweza kuwa na maktaba yaliyotengenezwa tayari, au una fursa ya kutatua tatizo kwa kutumia jukwaa la wingu.

Kuongeza usawa

Hatua rahisi na inayojulikana zaidi. Kwa kawaida, mipango miwili ya kawaida ya usambazaji wa mzigo ni upanuzi wa usawa na wima. Katika kesi ya kwanza unaruhusu huduma kukimbia sambamba, na hivyo kusambaza mzigo kati yao. Katika pili unaagiza seva zenye nguvu zaidi au kuboresha msimbo.

Kwa mfano, nitachukua hifadhi ya faili ya wingu isiyoeleweka, yaani, analog fulani ya OwnCloud, OneDrive, na kadhalika.

Picha ya kawaida ya mzunguko kama huo iko chini, lakini inaonyesha tu ugumu wa mfumo. Baada ya yote, tunahitaji kwa namna fulani kusawazisha huduma. Ni nini hufanyika ikiwa mtumiaji atahifadhi faili kutoka kwa kompyuta kibao na kisha anataka kuitazama kutoka kwa simu?

Tofauti kati ya mbinu: katika kuongeza wima, tuko tayari kuongeza nguvu za nodes, na kwa usawa wa usawa, tuko tayari kuongeza nodes mpya ili kusambaza mzigo.

CQRS

Kutenganisha Wajibu wa Swali la Amri Mchoro muhimu zaidi, kwa kuwa inaruhusu wateja tofauti sio tu kuunganishwa na huduma tofauti, lakini pia kupokea mitiririko ya tukio sawa. Faida zake sio dhahiri kwa programu rahisi, lakini ni muhimu sana (na rahisi) kwa huduma yenye shughuli nyingi. Kiini chake: mtiririko wa data zinazoingia na zinazotoka hazipaswi kuingiliana. Hiyo ni, huwezi kutuma ombi na kutarajia jibu; badala yake, unatuma ombi kwa huduma A, lakini unapokea jibu kutoka kwa huduma B.

Bonasi ya kwanza ya njia hii ni uwezo wa kuvunja unganisho (kwa maana pana ya neno) wakati wa kutekeleza ombi refu. Kwa mfano, hebu tuchukue zaidi au chini ya mlolongo wa kawaida:

1. Mteja alituma ombi kwa seva.
2. Seva ilianza muda mrefu wa kuchakata.
3. Seva ilijibu mteja na matokeo.

Hebu fikiria kwamba katika hatua ya 2 uunganisho ulivunjwa (au mtandao uliunganishwa tena, au mtumiaji alikwenda kwenye ukurasa mwingine, akivunja uhusiano). Katika kesi hii, itakuwa vigumu kwa seva kutuma jibu kwa mtumiaji na taarifa kuhusu nini hasa kilichakatwa. Kutumia CQRS, mlolongo utakuwa tofauti kidogo:

1. Mteja amejiandikisha kupokea sasisho.
2. Mteja alituma ombi kwa seva.
3. Seva ilijibu "ombi limekubaliwa."
4. Seva ilijibu na matokeo kupitia kituo kutoka kwa uhakika "1".

Kama unaweza kuona, mpango huo ni ngumu zaidi. Zaidi ya hayo, mbinu angavu ya kujibu ombi haipo hapa. Walakini, kama unavyoona, kukatika kwa muunganisho wakati wa kusindika ombi hakutasababisha hitilafu. Zaidi ya hayo, ikiwa kwa kweli mtumiaji ameunganishwa na huduma kutoka kwa vifaa kadhaa (kwa mfano, kutoka kwa simu ya mkononi na kutoka kwa kibao), unaweza kuhakikisha kuwa majibu huja kwa vifaa vyote viwili.

Inafurahisha, msimbo wa kuchakata ujumbe unaoingia unakuwa sawa (si 100%) kwa matukio ambayo yaliathiriwa na mteja mwenyewe, na kwa matukio mengine, ikiwa ni pamoja na yale kutoka kwa wateja wengine.

Hata hivyo, kwa kweli tunapata ziada ya ziada kutokana na ukweli kwamba mtiririko wa unidirectional unaweza kushughulikiwa kwa mtindo wa kazi (kwa kutumia RX na sawa). Na hii tayari ni pamoja na kubwa, kwani kwa asili maombi yanaweza kufanywa tendaji kabisa, na pia kwa kutumia mbinu ya kufanya kazi. Kwa programu za mafuta, hii inaweza kuokoa kwa kiasi kikubwa rasilimali za maendeleo na msaada.

Ikiwa tutachanganya mbinu hii na kuongeza mlalo, basi kama bonasi tunapata uwezo wa kutuma maombi kwa seva moja na kupokea majibu kutoka kwa nyingine. Kwa hivyo, mteja anaweza kuchagua huduma ambayo ni rahisi kwake, na mfumo wa ndani bado utaweza kushughulikia matukio kwa usahihi.

Upataji wa Tukio

Kama unavyojua, moja ya sifa kuu za mfumo uliosambazwa ni kutokuwepo kwa wakati wa kawaida, sehemu muhimu ya kawaida. Kwa mchakato mmoja, unaweza kufanya maingiliano (kwenye bubu sawa), ambayo una uhakika kuwa hakuna mtu mwingine anayetekeleza nambari hii. Hata hivyo, hii ni hatari kwa mfumo uliosambazwa, kwa kuwa itahitaji overhead, na pia itaua uzuri wote wa kuongeza - vipengele vyote bado vitasubiri moja.

Kuanzia hapa tunapata ukweli muhimu - mfumo uliosambazwa haraka hauwezi kusawazishwa, kwa sababu basi tutapunguza utendaji. Kwa upande mwingine, mara nyingi tunahitaji uwiano fulani kati ya vipengele. Na kwa hili unaweza kutumia mbinu na hatimaye uthabiti, ambapo imethibitishwa kuwa ikiwa hakuna mabadiliko ya data kwa muda fulani baada ya sasisho la mwisho ("hatimaye"), hoja zote zitarudisha thamani iliyosasishwa ya mwisho.

Ni muhimu kuelewa kwamba kwa hifadhidata za kawaida hutumiwa mara nyingi uthabiti wenye nguvu, ambapo kila nodi ina taarifa sawa (hii mara nyingi hupatikana katika kesi ambapo shughuli inachukuliwa kuwa imara tu baada ya kujibu seva ya pili). Kuna kupumzika hapa kwa sababu ya viwango vya kutengwa, lakini wazo la jumla linabaki sawa - unaweza kuishi katika ulimwengu uliounganishwa kabisa.

Walakini, wacha turudi kwenye kazi ya asili. Ikiwa sehemu ya mfumo inaweza kujengwa na hatimaye uthabiti, basi tunaweza kuunda mchoro ufuatao.

Vipengele muhimu vya mbinu hii:

• Kila ombi linaloingia huwekwa kwenye foleni moja.
• Wakati wa kushughulikia ombi, huduma inaweza pia kuweka kazi katika foleni zingine.
• Kila tukio linaloingia lina kitambulisho (ambacho ni muhimu kwa upunguzaji wa nakala).
• Foleni hufanya kazi kimawazo kulingana na mpango wa "ambatisha pekee". Huwezi kuondoa vipengele kutoka kwake au kuvipanga upya.
• Foleni inafanya kazi kulingana na mpango wa FIFO (samahani kwa tautology). Ikiwa unahitaji kufanya utekelezaji sambamba, basi kwa hatua moja unapaswa kuhamisha vitu kwenye foleni tofauti.

Acha nikukumbushe kwamba tunazingatia kesi ya kuhifadhi faili mtandaoni. Katika kesi hii, mfumo utaonekana kama hii:

Ni muhimu kwamba huduma kwenye mchoro haimaanishi seva tofauti. Hata mchakato unaweza kuwa sawa. Jambo lingine ni muhimu: kiitikadi, vitu hivi vinatenganishwa kwa njia ambayo kiwango cha usawa kinaweza kutumika kwa urahisi.

Na kwa watumiaji wawili mchoro utaonekana kama hii (huduma zilizokusudiwa kwa watumiaji tofauti zimeonyeshwa kwa rangi tofauti):

Bonasi kutoka kwa mchanganyiko kama huu:

• Huduma za usindikaji wa habari zimetenganishwa. Foleni pia zimetenganishwa. Ikiwa tunahitaji kuongeza upitishaji wa mfumo, basi tunahitaji tu kuzindua huduma zaidi kwenye seva zaidi.
• Tunapopokea taarifa kutoka kwa mtumiaji, hatuhitaji kusubiri hadi data ihifadhiwe kabisa. Kinyume chake, tunahitaji tu kujibu "sawa" na kisha hatua kwa hatua kuanza kufanya kazi. Wakati huo huo, foleni hupunguza kilele, kwani kuongeza kitu kipya hutokea haraka, na mtumiaji hawana haja ya kusubiri kupita kamili kupitia mzunguko mzima.
• Kama mfano, niliongeza huduma ya uondoaji ambayo inajaribu kuunganisha faili zinazofanana. Ikiwa inafanya kazi kwa muda mrefu katika 1% ya kesi, mteja hatatambua (tazama hapo juu), ambayo ni pamoja na kubwa, kwani hatuhitaji tena kuwa kasi ya XNUMX% na ya kuaminika.

Walakini, ubaya unaonekana mara moja:

• Mfumo wetu umepoteza uthabiti wake madhubuti. Hii ina maana kwamba ikiwa, kwa mfano, unajiunga na huduma tofauti, basi kinadharia unaweza kupata hali tofauti (kwa kuwa moja ya huduma inaweza kuwa na muda wa kupokea taarifa kutoka kwa foleni ya ndani). Kama matokeo mengine, mfumo sasa hauna wakati wa kawaida. Hiyo ni, haiwezekani, kwa mfano, kupanga matukio yote kwa wakati wa kuwasili tu, kwa kuwa saa kati ya seva inaweza kuwa si synchronous (zaidi ya hayo, wakati huo huo kwenye seva mbili ni utopia).
• Hakuna matukio sasa yanayoweza kurudishwa nyuma (kama inavyoweza kufanywa na hifadhidata). Badala yake, unahitaji kuongeza tukio jipya - tukio la fidia, ambayo itabadilisha hali ya mwisho kuwa inayohitajika. Kama mfano kutoka kwa eneo kama hilo: bila historia ya kuandika tena (ambayo ni mbaya katika hali zingine), huwezi kurudisha ahadi kwenye git, lakini unaweza kufanya maalum. ahadi ya kurudisha nyuma, ambayo kimsingi inarudisha hali ya zamani. Walakini, ahadi potofu na urejeshaji utabaki katika historia.
• Ratiba ya data inaweza kubadilika kutoka kutolewa hadi kutolewa, lakini matukio ya zamani hayataweza tena kusasishwa hadi kiwango kipya (kwa kuwa matukio hayawezi kubadilishwa kimsingi).

Kama unavyoona, Upataji wa Tukio hufanya kazi vizuri na CQRS. Kwa kuongezea, kutekeleza mfumo ulio na foleni nzuri na rahisi, lakini bila kutenganisha mtiririko wa data, tayari ni ngumu yenyewe, kwa sababu itabidi uongeze alama za maingiliano ambazo zitapunguza athari nzuri ya foleni. Kutumia njia zote mbili mara moja, ni muhimu kurekebisha msimbo wa programu. Kwa upande wetu, wakati wa kutuma faili kwa seva, jibu linakuja tu "sawa", ambayo inamaanisha tu kwamba "operesheni ya kuongeza faili ilihifadhiwa." Hapo awali, hii haimaanishi kuwa data tayari inapatikana kwenye vifaa vingine (kwa mfano, huduma ya uondoaji inaweza kuunda upya index). Walakini, baada ya muda, mteja atapokea arifa katika mtindo wa "faili X imehifadhiwa."

Matokeo yake:

• Idadi ya hali za kutuma faili inaongezeka: badala ya "faili iliyotumwa" ya kawaida, tunapata mbili: "faili imeongezwa kwenye foleni kwenye seva" na "faili imehifadhiwa kwenye hifadhi." Mwisho unamaanisha kuwa vifaa vingine vinaweza tayari kuanza kupokea faili (iliyorekebishwa kwa ukweli kwamba foleni zinafanya kazi kwa kasi tofauti).
• Kwa sababu ya ukweli kwamba maelezo ya uwasilishaji sasa yanakuja kupitia njia tofauti, tunahitaji kuja na suluhisho ili kupokea hali ya uchakataji wa faili. Kama matokeo ya hii: tofauti na jibu la ombi la kawaida, mteja anaweza kuwashwa upya wakati wa kuchakata faili, lakini hali ya uchakataji huu yenyewe itakuwa sahihi. Kwa kuongeza, bidhaa hii inafanya kazi, kimsingi, nje ya boksi. Kama matokeo: sasa tunavumilia zaidi kushindwa.

Kuogopa

Kama ilivyoelezwa hapo juu, mifumo ya kutafuta matukio haina uthabiti madhubuti. Hii inamaanisha kuwa tunaweza kutumia hifadhi kadhaa bila maingiliano yoyote kati yao. Kukaribia shida yetu, tunaweza:

• Tenganisha faili kwa aina. Kwa mfano, picha/video zinaweza kutatuliwa na umbizo la ufanisi zaidi linaweza kuchaguliwa.
• Tenganisha akaunti kwa nchi. Kutokana na sheria nyingi, hii inaweza kuhitajika, lakini mpango huu wa usanifu hutoa fursa hiyo moja kwa moja

Ikiwa unataka kuhamisha data kutoka kwa hifadhi moja hadi nyingine, basi njia za kawaida hazitoshi tena. Kwa bahati mbaya, katika kesi hii, unahitaji kuacha foleni, fanya uhamiaji, na kisha uanze. Katika hali ya jumla, data haiwezi kuhamishwa "kwa kuruka", hata hivyo, ikiwa foleni ya tukio imehifadhiwa kabisa, na una picha za majimbo ya awali ya hifadhi, basi tunaweza kucheza tena matukio kama ifuatavyo:

• Katika Chanzo cha Tukio, kila tukio lina kitambulisho chake (kimsingi, kisichopungua). Hii inamaanisha kuwa tunaweza kuongeza sehemu kwenye hifadhi - kitambulisho cha kipengele kilichochakatwa mwisho.
• Tunarudia foleni ili matukio yote yaweze kusindika kwa hifadhi kadhaa za kujitegemea (ya kwanza ni ile ambayo data tayari imehifadhiwa, na ya pili ni mpya, lakini bado tupu). Foleni ya pili, bila shaka, haijachakatwa bado.
• Tunazindua foleni ya pili (yaani, tunaanza kucheza tena matukio).
• Wakati foleni mpya ni tupu (hiyo ni, tofauti ya wastani ya wakati kati ya kuongeza kipengee na kuirejesha inakubalika), unaweza kuanza kubadili visomaji hadi kwenye hifadhi mpya.

Kama unavyoona, hatukuwa na, na bado hatuna, uthabiti mkali katika mfumo wetu. Kuna uthabiti tu hatimaye, yaani, hakikisho kwamba matukio yanachakatwa kwa mpangilio sawa (lakini ikiwezekana na ucheleweshaji tofauti). Na, kwa kutumia hii, tunaweza kuhamisha data kwa urahisi bila kusimamisha mfumo hadi upande mwingine wa ulimwengu.

Kwa hivyo, kuendelea na mfano wetu juu ya uhifadhi mkondoni wa faili, usanifu kama huo tayari unatupa mafao kadhaa:

• Tunaweza kusogeza vitu karibu na watumiaji kwa njia inayobadilika. Kwa njia hii unaweza kuboresha ubora wa huduma.
• Tunaweza kuhifadhi baadhi ya data ndani ya makampuni. Kwa mfano, watumiaji wa Enterprise mara nyingi huhitaji data zao kuhifadhiwa katika vituo vya data vinavyodhibitiwa (ili kuepuka uvujaji wa data). Kupitia kugawanyika tunaweza kuunga mkono hii kwa urahisi. Na kazi ni rahisi zaidi ikiwa mteja ana wingu inayolingana (kwa mfano, Azure ni mwenyeji bingwa).
• Na jambo muhimu zaidi ni kwamba hatupaswi kufanya hivi. Baada ya yote, kwa kuanzia, tutafurahiya kabisa na hifadhi moja kwa akaunti zote (ili kuanza kufanya kazi haraka). Na sifa kuu ya mfumo huu ni kwamba ingawa inaweza kupanuliwa, katika hatua ya awali ni rahisi sana. Sio lazima uandike msimbo mara moja ambao hufanya kazi na foleni huru milioni moja, nk. Ikiwa ni lazima, hii inaweza kufanywa katika siku zijazo.

Upangishaji wa Maudhui tuli

Hoja hii inaweza kuonekana wazi kabisa, lakini bado ni muhimu kwa programu iliyopakiwa zaidi au chini ya kiwango. Kiini chake ni rahisi: maudhui yote tuli yanasambazwa sio kutoka kwa seva moja ambapo programu iko, lakini kutoka kwa maalum maalum kwa kazi hii. Matokeo yake, shughuli hizi zinafanywa kwa kasi (nginx ya masharti hutumikia faili kwa haraka zaidi na kwa gharama nafuu kuliko seva ya Java). Usanifu wa pamoja wa CDN (Content Delivery Network) inatuwezesha kupata faili zetu karibu na watumiaji wa mwisho, ambayo ina athari nzuri kwa urahisi wa kufanya kazi na huduma.

Mfano rahisi na wa kawaida zaidi wa maudhui tuli ni seti ya hati na picha za tovuti. Kila kitu ni rahisi nao - wanajulikana mapema, kisha kumbukumbu hupakiwa kwa seva za CDN, kutoka ambapo zinasambazwa kwa watumiaji wa mwisho.

Walakini, kwa ukweli, kwa yaliyomo tuli, unaweza kutumia mbinu inayofanana na usanifu wa lambda. Hebu turudi kwenye kazi yetu (hifadhi ya faili mtandaoni), ambayo tunahitaji kusambaza faili kwa watumiaji. Suluhisho rahisi zaidi ni kuunda huduma ambayo, kwa kila ombi la mtumiaji, hufanya hundi zote muhimu (idhini, nk), na kisha kupakua faili moja kwa moja kutoka kwenye hifadhi yetu. Ubaya kuu wa njia hii ni kwamba yaliyomo tuli (na faili iliyo na marekebisho fulani, kwa kweli, yaliyomo tuli) inasambazwa na seva sawa ambayo ina mantiki ya biashara. Badala yake, unaweza kutengeneza mchoro ufuatao:

• Seva hutoa URL ya upakuaji. Inaweza kuwa ya ufunguo wa faili_id +, ambapo ufunguo ni sahihi ya dijitali ndogo ambayo inatoa haki ya kufikia rasilimali kwa saa XNUMX zijazo.
• Faili inasambazwa na nginx rahisi na chaguzi zifuatazo:
  • Uhifadhi wa maudhui. Kwa kuwa huduma hii inaweza kuwa kwenye seva tofauti, tumejiacha hifadhi kwa siku zijazo na uwezo wa kuhifadhi faili zote zilizopakuliwa hivi karibuni kwenye diski.
  • Kuangalia ufunguo wakati wa kuunda muunganisho
• Hiari: usindikaji wa maudhui ya utiririshaji. Kwa mfano, ikiwa tunapunguza faili zote kwenye huduma, basi tunaweza kufanya unzipping moja kwa moja kwenye moduli hii. Kama matokeo: Operesheni za IO hufanyika mahali zinapostahili. Kihifadhi kumbukumbu katika Java kitatenga kwa urahisi kumbukumbu nyingi za ziada, lakini kuandika upya huduma yenye mantiki ya biashara katika masharti ya Rust/C++ kunaweza pia kukosa ufanisi. Kwa upande wetu, michakato tofauti (au hata huduma) hutumiwa, na kwa hivyo tunaweza kutenganisha kwa ufanisi mantiki ya biashara na shughuli za IO.

Mpango huu haufanani sana na kusambaza maudhui tuli (kwa kuwa hatupakii kifurushi chote tuli mahali fulani), lakini kwa kweli, mbinu hii inahusika haswa na kusambaza data isiyoweza kubadilika. Zaidi ya hayo, mpango huu unaweza kujumuishwa katika hali nyingine ambapo maudhui si tuli tu, lakini yanaweza kuwakilishwa kama seti ya vizuizi visivyoweza kubadilika na visivyoweza kufutwa (ingawa vinaweza kuongezwa).

Kama mfano mwingine (kwa uimarishaji): ikiwa umefanya kazi na Jenkins/TeamCity, basi unajua kuwa suluhisho zote mbili zimeandikwa katika Java. Zote mbili ni mchakato wa Java ambao hushughulikia utayarishaji wa muundo na usimamizi wa yaliyomo. Hasa, wote wawili wana kazi kama "kuhamisha faili/folda kutoka kwa seva." Kama mfano: kutoa mabaki, kuhamisha msimbo wa chanzo (wakati wakala hajapakua nambari moja kwa moja kutoka kwa hazina, lakini seva inamfanyia), ufikiaji wa kumbukumbu. Kazi hizi zote hutofautiana katika mzigo wao wa IO. Hiyo ni, zinageuka kuwa seva inayohusika na mantiki ngumu ya biashara lazima wakati huo huo iweze kusukuma kwa ufanisi mtiririko mkubwa wa data kupitia yenyewe. Na kinachovutia zaidi ni kwamba operesheni kama hiyo inaweza kukabidhiwa kwa nginx sawa kulingana na mpango sawa (isipokuwa kwamba ufunguo wa data unapaswa kuongezwa kwa ombi).

Walakini, ikiwa tunarudi kwenye mfumo wetu, tunapata mchoro sawa:

Kama unaweza kuona, mfumo umekuwa ngumu zaidi. Sasa sio mchakato mdogo tu ambao huhifadhi faili ndani. Sasa kinachohitajika sio msaada rahisi zaidi, udhibiti wa toleo la API, nk. Kwa hivyo, baada ya michoro yote kuchorwa, ni bora kutathmini kwa undani ikiwa upanuzi unastahili gharama. Hata hivyo, ikiwa unataka kuwa na uwezo wa kupanua mfumo (ikiwa ni pamoja na kufanya kazi na idadi kubwa zaidi ya watumiaji), basi utakuwa na kwenda kwa ufumbuzi sawa. Lakini, kwa sababu hiyo, mfumo huo uko tayari kwa usanifu kwa mzigo ulioongezeka (karibu kila sehemu inaweza kuunganishwa kwa usawa wa usawa). Mfumo unaweza kusasishwa bila kuusimamisha (baadhi ya shughuli zitapunguzwa kidogo).

Kama nilivyosema mwanzoni, sasa huduma kadhaa za mtandao zimeanza kupokea mzigo ulioongezeka. Na baadhi yao walianza tu kuacha kufanya kazi kwa usahihi. Kwa kweli, mifumo ilishindwa kwa usahihi wakati ambapo biashara ilipaswa kupata pesa. Hiyo ni, badala ya utoaji ulioahirishwa, badala ya kupendekeza kwa wateja "panga uwasilishaji wako kwa miezi ijayo," mfumo ulisema tu "nenda kwa washindani wako." Kwa kweli, hii ni bei ya uzalishaji mdogo: hasara itatokea kwa usahihi wakati faida itakuwa kubwa zaidi.

Hitimisho

Mbinu hizi zote zilijulikana hapo awali. VK hiyo hiyo kwa muda mrefu imekuwa ikitumia wazo la Kukaribisha Maudhui Tuli kuonyesha picha. Michezo mingi ya mtandaoni hutumia mpango wa Sharding kugawanya wachezaji katika maeneo au kutenganisha maeneo ya mchezo (ikiwa ulimwengu wenyewe ni mmoja). Mbinu ya Upataji wa Tukio inatumika kikamilifu katika barua pepe. Programu nyingi za biashara ambapo data inapokelewa kila mara hujengwa kwa mbinu ya CQRS ili kuweza kuchuja data iliyopokelewa. Kweli, kuongeza usawa kumetumika katika huduma nyingi kwa muda mrefu sana.

Hata hivyo, muhimu zaidi, mifumo hii yote imekuwa rahisi sana kutumia katika maombi ya kisasa (ikiwa ni sahihi, bila shaka). Clouds hutoa Sharding na kuongeza mlalo mara moja, ambayo ni rahisi zaidi kuliko kuagiza seva tofauti zilizojitolea katika vituo tofauti vya data wewe mwenyewe. CQRS imekuwa rahisi zaidi, ikiwa tu kwa sababu ya maendeleo ya maktaba kama vile RX. Karibu miaka 10 iliyopita, tovuti adimu inaweza kusaidia hii. Upataji wa Matukio pia ni rahisi sana kusanidi shukrani kwa vyombo vilivyotengenezwa tayari na Apache Kafka. Miaka 10 iliyopita huu ungekuwa uvumbuzi, sasa ni jambo la kawaida. Ni sawa na Static Content Hosting: kutokana na teknolojia rahisi zaidi (ikiwa ni pamoja na ukweli kwamba kuna nyaraka za kina na hifadhidata kubwa ya majibu), mbinu hii imekuwa rahisi zaidi.

Kama matokeo, utekelezaji wa idadi ya mifumo ngumu ya usanifu sasa imekuwa rahisi zaidi, ambayo inamaanisha ni bora kuiangalia kwa karibu mapema. Ikiwa katika maombi ya umri wa miaka kumi moja ya suluhisho hapo juu iliachwa kwa sababu ya gharama kubwa ya utekelezaji na uendeshaji, sasa, katika programu mpya, au baada ya kurekebisha tena, unaweza kuunda huduma ambayo tayari itakuwa ya usanifu wote kupanuka ( kwa suala la utendakazi) na tayari kufanywa kwa maombi mapya kutoka kwa wateja (kwa mfano, kubinafsisha data ya kibinafsi).

Na muhimu zaidi: tafadhali usitumie njia hizi ikiwa una programu rahisi. Ndiyo, ni nzuri na ya kuvutia, lakini kwa tovuti yenye ziara ya kilele cha watu 100, unaweza kupata mara nyingi kwa monolith ya classic (angalau nje, kila kitu ndani kinaweza kugawanywa katika modules, nk).

Chanzo: mapenzi.com