Ujumbe wa Kuaminika katika Mifumo Inayosambazwa

Tatizo la kuandika mara mbili

Kuunda mfumo unaotegemewa, unaopatikana sana, unaosambazwa kwa kiasi kikubwa kunahitaji uzingatiaji wa mbinu, kanuni na mifumo mahususi. Ubunifu wa mifumo kama hii inahusisha kushughulikia changamoto nyingi. Miongoni mwa masuala yaliyoenea zaidi na ya msingi ni tatizo la kuandika mara mbili .

"Tatizo la kuandika mara mbili" ni changamoto inayojitokeza katika mifumo iliyosambazwa, hasa inaposhughulikia vyanzo vingi vya data au hifadhidata zinazohitaji kusawazishwa. Inarejelea ugumu wa kuhakikisha kwamba mabadiliko ya data yanaandikwa kila mara kwa hifadhi mbalimbali za data, kama vile hifadhidata au kache, bila kuwasilisha masuala kama vile kutofautiana kwa data, migongano, au vikwazo vya utendakazi.

Usanifu wa huduma ndogo ndogo na hifadhidata ya muundo kwa kila huduma inakuletea manufaa mengi, kama vile uwekaji huru na kuongeza, kushindwa kutengwa, na uwezekano wa kuongeza kasi ya maendeleo. Hata hivyo, shughuli zinahitaji mabadiliko kati ya microservices nyingi, na kukulazimisha kufikiri juu ya suluhisho la kuaminika ili kukabiliana na tatizo hili.

Karibu mfano halisi

Hebu tuzingatie hali ambayo kikoa chetu kinahusisha kukubali maombi ya mkopo, kuyatathmini, na kisha kutuma arifa za arifa kwa wateja.

Kwa mtazamo wa kanuni ya uwajibikaji mmoja, sheria ya Conway, na mbinu ya kubuni inayoendeshwa na kikoa, baada ya vipindi kadhaa vya dhoruba ya matukio, kikoa kizima kiligawanywa katika vikoa vitatu vilivyo na miktadha iliyoainishwa iliyo na mipaka iliyo wazi, miundo ya kikoa, na lugha inayoenea kila mahali.

Ya kwanza ina jukumu la kuingia na kuandaa maombi mapya ya mkopo. Mfumo wa pili hutathmini maombi haya na kufanya maamuzi kulingana na data iliyotolewa. Mchakato huu wa tathmini, ikiwa ni pamoja na KYC/KYB, udhibiti wa ulaghai na ukaguzi wa hatari za mikopo, unaweza kuchukua muda, na hivyo kuhitaji uwezo wa kushughulikia maelfu ya maombi kwa wakati mmoja. Kwa hivyo, utendakazi huu umekabidhiwa kwa huduma ndogo iliyojitolea iliyo na hifadhidata yake yenyewe, ikiruhusu kuongeza kiwango huru.

Zaidi ya hayo, mifumo hii ndogo inadhibitiwa na timu mbili tofauti, kila moja ikiwa na mizunguko yake ya utoaji, makubaliano ya kiwango cha huduma (SLA) na mahitaji ya hatari.

Mwishowe , huduma maalum ya arifa iko tayari kutuma arifa kwa wateja.

Hapa kuna maelezo yaliyosafishwa ya kesi ya msingi ya matumizi ya mfumo:

1. Mteja anawasilisha maombi ya mkopo.
2. Huduma ya Maombi ya Mkopo hurekodi ombi jipya kwa hali ya "Inasubiri" na huanzisha mchakato wa tathmini kwa kupeleka maombi kwa Huduma ya Tathmini.
3. Huduma ya Tathmini hutathmini ombi la mkopo unaoingia na baadaye kufahamisha Huduma ya Ombi la Mkopo kuhusu uamuzi huo.
4. Baada ya kupokea uamuzi huo, Huduma ya Maombi ya Mkopo husasisha hali ya ombi la mkopo ipasavyo na huanzisha Huduma ya Arifa kumfahamisha mteja kuhusu matokeo.
5. Huduma ya Arifa huchakata ombi hili na kutuma arifa kwa mteja kupitia barua pepe, SMS, au njia zingine za mawasiliano zinazopendekezwa, kulingana na mipangilio ya mteja.

Ni mfumo rahisi sana na wa zamani kwa mtazamo wa kwanza, lakini hebu tuzame jinsi huduma ya kutuma ombi la Mkopo huchakata amri ya kutuma maombi ya mkopo.

Tunaweza kuzingatia njia mbili za mwingiliano wa huduma:

1. First-Local-Commit-Then-Publish: Katika mbinu hii, huduma husasisha hifadhidata yake ya ndani (inajitolea) na kisha kuchapisha tukio au ujumbe kwa huduma zingine.

2. First-Publish-Then-Local-Commit: Kinyume chake, mbinu hii inahusisha kuchapisha tukio au ujumbe kabla ya kufanya mabadiliko kwenye hifadhidata ya ndani.

   
   

Njia zote mbili zina vikwazo vyake na ni sehemu tu ya kushindwa-salama kwa mawasiliano katika mifumo iliyosambazwa.

Huu ni mchoro wa mlolongo wa kutumia mbinu ya kwanza.

Katika hali hii, Huduma ya Maombi ya Mkopo hutumia mbinu ya Kwanza-Ya-Mitaa-Kisha-Kuchapisha , ambapo kwanza hufanya muamala na kisha kujaribu kutuma arifa kwa mfumo mwingine. Hata hivyo, mchakato huu unaweza kukabiliwa na kushindwa ikiwa, kwa mfano, kuna matatizo ya mtandao, Huduma ya Tathmini haipatikani, au Huduma ya Ombi la Mkopo inakumbana na hitilafu ya Nje ya Kumbukumbu (OOM) na kuacha kufanya kazi. Katika hali kama hizi, ujumbe utapotea, na kuacha Tathmini bila taarifa ya maombi mapya ya mkopo, isipokuwa hatua za ziada zitekelezwe.

Na ya pili.

Katika hali ya Ahadi ya Kwanza-Chapisha-Kisha-Ndani , Huduma ya Ombi la Mkopo inakabiliwa na hatari kubwa zaidi. Huenda ikafahamisha Huduma ya Tathmini kuhusu programu mpya lakini ikashindwa kuhifadhi sasisho hili ndani ya nchi kwa sababu ya matatizo kama vile masuala ya hifadhidata, hitilafu za kumbukumbu au hitilafu za msimbo. Mbinu hii inaweza kusababisha kutofautiana kwa data kubwa, jambo ambalo linaweza kusababisha matatizo makubwa, kulingana na jinsi Huduma ya Ukaguzi wa Mikopo inavyoshughulikia maombi yanayoingia.

Kwa hiyo, lazima tutambue suluhisho ambalo linatoa utaratibu thabiti wa kuchapisha matukio kwa watumiaji wa nje. Lakini, kabla ya kuangazia suluhu zinazowezekana, tunapaswa kwanza kufafanua aina za uhakikisho wa uwasilishaji ujumbe unaoweza kufikiwa katika mifumo inayosambazwa.

Dhamana za uwasilishaji ujumbe

Kuna aina nne za dhamana ambazo tunaweza kufikia.

1. Hakuna dhamana
   Hakuna hakikisho kwamba ujumbe utawasilishwa kwa lengwa. Mbinu ya First-Local-Commit-Kisha-Chapisha inahusu hili haswa. Wateja wanaweza kupokea ujumbe mara moja, mara nyingi, au kutopokea kabisa.

2. Mara moja utoaji
   Mara moja uwasilishaji humaanisha kuwa ujumbe utawasilishwa lengwa kwa zaidi ya mara 1. Mbinu ya First-Local-Commit-Then-Publish inaweza kutekelezwa kwa njia hii pamoja na sera ya kujaribu tena ya majaribio yenye thamani ya kwanza.

3. Angalau mara moja uwasilishaji\Wateja watapokea na kuchakata kila ujumbe lakini wanaweza kupokea ujumbe sawa zaidi ya mara moja.

4. Mara moja tu uwasilishaji\Hasa mara tu uwasilishaji unamaanisha kuwa mtumiaji atapokea ujumbe kwa ufanisi mara moja.
   Kitaalam, inawezekana kufikia kwa miamala ya Kafka na utekelezaji mahususi usio na uwezo wa mzalishaji na mtumiaji.

   
   

Katika hali nyingi, dhamana ya uwasilishaji ya 'angalau mara moja' hushughulikia masuala mengi kwa kuhakikisha kuwa ujumbe unawasilishwa angalau mara moja, lakini watumiaji lazima wasiwe na uwezo. Hata hivyo, kutokana na hitilafu za mtandao zinazoweza kuepukika, mantiki yote ya watumiaji lazima isiwe na uwezo ili kuepuka kuchakata ujumbe unaorudiwa, bila kujali dhamana za mtayarishaji. Kwa hivyo, hitaji hili sio kikwazo sana kwani linaonyesha ukweli.

Ufumbuzi

Kuna mengi ya ufumbuzi wa tatizo hili, ambayo ina faida na hasara zao.

Ahadi ya awamu mbili

Kulingana na Wikipedia, Tume ya Awamu Mbili (2PC) ni itifaki ya shughuli iliyosambazwa inayotumiwa katika sayansi ya kompyuta na mifumo ya usimamizi wa hifadhidata ili kuhakikisha uthabiti na kutegemewa kwa miamala iliyosambazwa. Imeundwa kwa ajili ya hali ambapo rasilimali nyingi (kwa mfano, hifadhidata) zinahitaji kushiriki katika shughuli moja, na inahakikisha kwamba zote zinafanya muamala huo au zote zinaighairi, na hivyo kudumisha uthabiti wa data. Inasikika kile tunachohitaji, lakini Ahadi ya Awamu Mbili ina shida kadhaa:

• Rasilimali moja inayoshiriki ikikosa kuitikia au ikipata kushindwa, mchakato mzima unaweza kuzuiwa hadi suala hilo litatuliwe. Hii inaweza kusababisha uwezekano wa matatizo ya utendaji na upatikanaji.
• Ahadi ya Awamu Mbili haitoi mifumo iliyojengewa ndani ya kustahimili makosa. Inategemea mbinu za nje au uingiliaji kati wa mikono ili kushughulikia kushindwa.
• Sio hifadhidata zote za kisasa zinazotumia Ahadi ya Awamu Mbili.

Hifadhidata iliyoshirikiwa

Suluhisho la wazi zaidi la usanifu wa huduma ndogo ni kutumia muundo (au hata wakati mwingine anti-muundo) - hifadhidata iliyoshirikiwa. Mbinu hii ni angavu sana ikiwa unahitaji uthabiti wa shughuli kwenye jedwali nyingi katika hifadhidata tofauti, tumia tu hifadhidata moja iliyoshirikiwa kwa huduma ndogo hizi.

Vikwazo vya mbinu hii ni pamoja na kuanzisha hatua moja ya kutofaulu, kuzuia uongezaji wa hifadhidata huru, na kupunguza uwezo wa kutumia suluhu tofauti za hifadhidata zinazofaa zaidi kwa mahitaji maalum na kesi za utumiaji. Zaidi ya hayo, marekebisho kwa misingi ya huduma ndogo ndogo yangekuwa muhimu ili kusaidia aina kama hiyo ya shughuli iliyosambazwa.

Kikasha toezi cha shughuli

' kisanduku tokezi cha shughuli ' ni muundo wa muundo unaotumika katika mifumo iliyosambazwa ili kuhakikisha uenezaji wa ujumbe unaotegemewa, hata katika mifumo isiyotegemewa ya ujumbe. Inajumuisha kuhifadhi matukio katika jedwali mahususi la 'OutboxEvents' ndani ya muamala sawa na operesheni yenyewe. Mbinu hii inalingana vyema na sifa za ACID za hifadhidata za uhusiano. Kinyume chake, hifadhidata nyingi za No-SQL haziauni kikamilifu sifa za ACID, zikichagua kanuni za nadharia ya CAP na falsafa ya BASE, ambayo hutanguliza upatikanaji na uthabiti hatimaye kuliko uthabiti thabiti.

Kikasha toezi cha shughuli hutoa hakikisho angalau mara moja na kinaweza kutekelezwa kwa mbinu kadhaa:

1. Uwekaji wa kumbukumbu ya shughuli

2. Mchapishaji wa kura

   
   

Mbinu ya uwekaji mkia wa logi ya muamala inamaanisha kutumia masuluhisho mahususi ya hifadhidata kama vile CDC (Badilisha Ukamataji Data). Vikwazo kuu vya njia hiyo ni:

• Ufumbuzi maalum wa hifadhidata

• Kuchelewa kwa muda kumeongezeka kutokana na maelezo mahususi ya utekelezaji wa CDC

  
  

Njia nyingine ni Mchapishaji wa Kura , ambayo hurahisisha upakiaji wa kisanduku toezi kwa kupigia kura jedwali la kisanduku toezi. Upungufu wa msingi wa njia hii ni uwezekano wa kuongezeka kwa mzigo wa database, ambayo inaweza kusababisha gharama kubwa. Zaidi ya hayo, sio hifadhidata zote za No-SQL zinaauni uulizaji bora wa sehemu mahususi za hati. Kuchimba hati nzima kunaweza, kwa hivyo, kusababisha uharibifu wa utendaji.

Hapa kuna mchoro mdogo wa mlolongo unaoelezea jinsi inavyofanya kazi.

Sikiliza mwenyewe

Changamoto kuu ya muundo wa Kikasha Toezi cha Muamala iko katika utegemezi wake kwenye sifa za hifadhidata za ACID. Inaweza kuwa moja kwa moja katika hifadhidata za kawaida za OLTP lakini inaleta changamoto katika eneo la NoSQL. Ili kushughulikia hili, suluhisho linalowezekana ni kuongeza kumbukumbu ya kiambatisho (kwa mfano, Kafka) kutoka kwa kuanzisha usindikaji wa ombi.

Badala ya kuchakata moja kwa moja amri ya 'tuma ombi la mkopo', tunaituma mara moja kwa mada ya ndani ya Kafka na kisha kurudisha matokeo 'yaliyokubaliwa' kwa mteja. Hata hivyo, kwa kuwa kuna uwezekano mkubwa kwamba amri bado inahitaji kuchakatwa, hatuwezi kumjulisha mteja matokeo mara moja. Ili kudhibiti uthabiti huu, tunaweza kutumia mbinu kama vile upigaji kura mrefu, upigaji kura unaoanzishwa na mteja, masasisho ya UI yenye matumaini, au kutumia WebSockets au Matukio Yanayotumwa Na Seva kwa arifa. Walakini, hii ni mada tofauti kabisa, kwa hivyo wacha turudi kwenye somo letu la kwanza.

Tulituma ujumbe kwenye mada ya ndani ya Kafka. Huduma ya Maombi ya Mkopo kisha hutumia ujumbe huu - amri sawa na iliyopokea kutoka kwa mteja - na huanza kuchakata. Kwanza, inatekeleza mantiki fulani ya biashara; baada tu ya mantiki hii kutekelezwa kwa ufanisi na matokeo kuendelezwa, inachapisha ujumbe mpya kwenye mada ya umma ya Kafka.

Hebu tuangalie kidogo ya pseudo-code.

 public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); }

Je, ikiwa usindikaji wa mantiki ya biashara utashindwa? Hakuna wasiwasi, kwa kuwa urekebishaji bado haujatekelezwa, ujumbe utajaribiwa tena.

Je, ikiwa kutuma matukio mapya kwa Kafka kutashindikana? Hakuna wasiwasi, kwa kuwa mantiki ya biashara haina nguvu, haitaunda ombi la mkopo linalorudiwa. Badala yake, itajaribu kutuma tena ujumbe kwa mada ya umma ya Kafka.

Je, ikiwa ujumbe utatumwa kwa Kafka, lakini ahadi ya kukabiliana itashindwa? Hakuna wasiwasi, kwa kuwa mantiki ya biashara haina uwezo, haitaunda ombi la mkopo linalorudiwa. Badala yake, itatuma ujumbe kwa mada ya umma ya Kafka na kutumaini kwamba ahadi ya kukabiliana itafaulu wakati huu.

Vikwazo kuu vya mbinu hii ni pamoja na ugumu ulioongezwa unaohusishwa na mtindo mpya wa upangaji, uthabiti wa baadaye (kwa kuwa mteja hatajua matokeo mara moja), na hitaji la mantiki yote ya biashara kuwa duni.

Upatikanaji wa tukio

Utafutaji wa matukio ni nini, na unawezaje kutumika hapa? Upatikanaji wa matukio ni muundo wa usanifu wa programu unaotumiwa kuiga hali ya mfumo kwa kunasa mabadiliko yote kwenye data yake kama mfululizo wa matukio yasiyobadilika. Matukio haya yanawakilisha ukweli au mabadiliko ya serikali na hutumika kama chanzo kimoja cha ukweli kwa hali ya sasa ya mfumo. Kwa hivyo, kitaalamu, kwa kutekeleza mfumo wa kutoa matukio, tayari tuna matukio yote katika EventStore, na EventStore hii inaweza kutumiwa na watumiaji kama chanzo kimoja cha ukweli kuhusu kile kilichotokea. Hakuna haja ya suluhisho maalum la hifadhidata kwa ajili ya kufuatilia mabadiliko yote au wasiwasi kuhusu kuagiza, tatizo pekee ni kukaa upande wa kusoma kwani ili kuweza kupata hali halisi ya chombo inahitajika ili kucheza tena matukio yote.

Hitimisho

Katika makala hii, tulipitia mbinu kadhaa za kujenga ujumbe wa kuaminika katika mifumo iliyosambazwa. Kuna mapendekezo kadhaa ambayo tunaweza kuzingatia tunapojenga mifumo yenye sifa hizi

1. Daima tengeneza watumiaji wasio na uwezo kwani kushindwa kwa mtandao hakuwezi kuepukika.
2. Tumia kwa uangalifu First-Local-Commit-Kisha-Chapisha kwa ufahamu wazi wa mahitaji ya dhamana.
3. Kamwe usitumie mbinu ya First-Publish-An-Local-Commit kwani inaweza kusababisha utofauti mkubwa wa data katika mfumo wako.
4. Iwapo uamuzi uliopo wa chaguo la hifadhidata unaweza kubadilika au mkakati wa kiufundi unamaanisha kuchagua suluhisho bora zaidi la uhifadhi kwa tatizo - usijenge maktaba zinazoshirikiwa kwa kushurutisha kwenye suluhu za hifadhidata kama vile CDC .
5. Tumia mbinu ya Muamala wa Kikasha toezi kama suluhu la kawaida la kupata angalau dhamana mara moja.
6. Zingatia kutumia mbinu ya Sikiliza mwenyewe wakati hifadhidata za No-SQL zinatumiwa.

Wakati ujao, tutaangalia mfano wa vitendo zaidi wa kutekeleza Kikasha Toezi cha Shughuli. Tazama

wewe!