Problema sa dual write  Ang pagbuo ng isang maaasahan, lubos na magagamit, nasusukat na ipinamamahaging sistema ay nangangailangan ng pagsunod sa mga partikular na diskarte, prinsipyo, at pattern. Ang disenyo ng naturang mga sistema ay nagsasangkot ng pagtugon sa napakaraming hamon. Kabilang sa mga pinakalaganap at pangunahing mga isyu ay   . ang dual write problem  Ang   ay isang hamon na lumitaw sa mga distributed system, pangunahin kapag nakikitungo sa maraming data source o database na kailangang panatilihing naka-sync. Ito ay tumutukoy sa kahirapan ng pagtiyak na ang mga pagbabago sa data ay palaging nakasulat sa iba't ibang mga tindahan ng data, tulad ng mga database o cache, nang hindi nagpapakilala ng mga isyu tulad ng mga hindi pagkakapare-pareho ng data, mga salungatan, o mga bottleneck sa pagganap. "dual write problem"  Ang arkitektura ng microservice at pattern ng database sa bawat serbisyo ay nagdudulot sa iyo ng maraming benepisyo, tulad ng independiyenteng pag-deploy at pag-scale, mga nakahiwalay na pagkabigo, at potensyal na pagpapalakas ng bilis ng pag-unlad. Gayunpaman, ang mga operasyon ay nangangailangan ng mga pagbabago sa maraming microservice, na pinipilit kang mag-isip tungkol sa isang maaasahang solusyon upang matugunan ang problemang ito.   Halos isang tunay na halimbawa  Isaalang-alang natin ang isang sitwasyon kung saan ang aming domain ay nagsasangkot ng pagtanggap ng mga aplikasyon ng pautang, pagtatasa sa mga ito, at pagkatapos ay pagpapadala ng mga alerto sa notification sa mga customer.  Sa diwa ng nag-iisang prinsipyo ng responsibilidad, ang batas ng Conway, at ang diskarte sa disenyo na hinimok ng domain, pagkatapos ng ilang session ng pag-atake ng kaganapan, ang buong domain ay nahati sa tatlong subdomain na may tinukoy na mga kontekstong may hangganan na may malinaw na mga hangganan, mga modelo ng domain, at ubiquitous na wika.    ay nakatalaga sa onboarding at pag-compile ng mga bagong aplikasyon ng pautang. Sinusuri   sistema ang mga application na ito at gumagawa ng mga desisyon batay sa ibinigay na data. Ang proseso ng pagtatasa na ito, kabilang ang KYC/KYB, antifraud, at mga pagsusuri sa panganib sa kredito, ay maaaring magtagal, na nangangailangan ng kakayahang pangasiwaan ang libu-libong mga aplikasyon nang sabay-sabay. Dahil dito, ang functionality na ito ay itinalaga sa isang dedikadong microservice na may sarili nitong database, na nagbibigay-daan para sa independiyenteng pag-scale. Ang una ng pangalawang  Higit pa rito, ang mga subsystem na ito ay pinamamahalaan ng dalawang magkaibang koponan, bawat isa ay may sarili nitong mga ikot ng paglabas, mga service level agreement (SLA), at mga kinakailangan sa scalability.    , isang espesyal na serbisyo ng notification ang nakalagay upang magpadala ng mga alerto sa mga customer.  Panghuli Narito ang isang pinong paglalarawan ng pangunahing kaso ng paggamit ng system:  Ang isang customer ay nagsumite ng isang loan application.  Itinatala ng Serbisyo ng Loan Application ang bagong aplikasyon na may katayuang "Nakabinbin" at sinisimulan ang proseso ng pagtatasa sa pamamagitan ng pagpapasa ng aplikasyon sa Serbisyo ng Pagsusuri.  Sinusuri ng Serbisyo ng Pagsusuri ang papasok na aplikasyon ng pautang at pagkatapos ay ipinapaalam sa Serbisyo ng Aplikasyon ng Pautang ang desisyon.  Sa pagtanggap ng desisyon, ang Loan Application Service ay nag-a-update ng loan application status nang naaayon at na-trigger ang Notifications Service upang ipaalam sa customer ang resulta.  Pinoproseso ng Serbisyo ng Mga Notification ang kahilingang ito at nagpapadala ng mga notification sa customer sa pamamagitan ng email, SMS, o iba pang gustong paraan ng komunikasyon, ayon sa mga setting ng customer.  Ito ay isang medyo simple at primitive na sistema sa unang tingin, ngunit tingnan natin kung paano pinoproseso ng serbisyo ng Loan application ang utos ng pagsumite ng loan application.  Maaari naming isaalang-alang ang dalawang diskarte para sa mga pakikipag-ugnayan sa serbisyo:    Sa diskarteng ito, ina-update ng serbisyo ang lokal na database nito (nag-commit) at pagkatapos ay nag-publish ng kaganapan o mensahe sa ibang mga serbisyo. First-Local-Commit-Then-Publish:    Sa kabaligtaran, ang paraang ito ay nagsasangkot ng pag-publish ng isang kaganapan o mensahe bago gawin ang mga pagbabago sa lokal na database. First-Publish-Then-Local-Commit:  Ang parehong mga pamamaraan ay may kanilang mga kakulangan at bahagyang nabigo lamang para sa komunikasyon sa mga distributed system.     Ito ay isang sequence diagram ng paglalapat ng unang diskarte.  Sa sitwasyong ito, ginagamit ng Serbisyo ng Loan Application ang   na diskarte, kung saan una itong gumawa ng transaksyon at pagkatapos ay sumusubok na magpadala ng notification sa ibang system. Gayunpaman, ang prosesong ito ay madaling kapitan ng pagkabigo kung, halimbawa, may mga isyu sa network, ang Serbisyo ng Pagsusuri ay hindi magagamit, o ang Serbisyo ng Loan Application ay nakatagpo ng Out of Memory (OOM) na error at nag-crash. Sa ganitong mga kaso, mawawala ang mensahe, na iniiwan ang Pagsusuri nang walang abiso ng bagong aplikasyon ng pautang, maliban kung ang mga karagdagang hakbang ay ipinatupad. First-Local-Commit-Then-Publish     At ang pangalawa.  Sa senaryo ng   , ang Serbisyo ng Loan Application ay nahaharap sa mas malalaking panganib. Maaaring ipaalam nito sa Assessment Service ang tungkol sa isang bagong application ngunit nabigong i-save ang update na ito nang lokal dahil sa mga problema tulad ng mga isyu sa database, memory error, o code bug. Ang diskarte na ito ay maaaring humantong sa mga makabuluhang hindi pagkakapare-pareho sa data, na maaaring magdulot ng malubhang problema, depende sa kung paano pinangangasiwaan ng Loan Review Service ang mga papasok na aplikasyon. First-Publish-Then-Local-Commit  Samakatuwid, dapat tayong tumukoy ng solusyon na nag-aalok ng matatag na mekanismo para sa pag-publish ng mga kaganapan sa mga external na consumer. Ngunit, bago suriin ang mga potensyal na solusyon, dapat muna nating linawin ang mga uri ng mga garantiya sa paghahatid ng mensahe na makakamit sa mga distributed system.  Mga garantiya sa paghahatid ng mensahe  May apat na uri ng mga garantiya na maaari naming makamit.  Walang mga garantiya  Walang garantiya na maihahatid ang mensahe sa destinasyon. Ang diskarte na   ay tiyak tungkol dito. Maaaring makatanggap ang mga mamimili ng mga mensahe nang isang beses, maraming beses, o hindi kailanman. First-Local-Commit-Then-Publish  Hindi hihigit sa isang beses na paghahatid  Hindi hihigit sa isang beses ang paghahatid ay nangangahulugan na ang mensahe ay maihahatid sa patutunguhan nang hindi hihigit sa 1 beses. Ang diskarte   ay maaaring ipatupad sa ganitong paraan pati na rin sa patakarang muling subukan ng mga pagtatangka na may halaga ng isa. na First-Local-Commit-Then-Publish  Hindi bababa sa isang beses ang paghahatid\Matatanggap at ipoproseso ng mga mamimili ang bawat mensahe ngunit maaaring makatanggap ng parehong mensahe nang higit sa isang beses.  Eksaktong isang beses paghahatid\Eksaktong isang beses paghahatid ay nangangahulugan na ang mamimili ay epektibong makakatanggap ng mensahe nang isang beses.  Sa teknikal, posibleng makamit sa mga transaksyon ng Kafka at partikular na idempotent na pagpapatupad ng producer at consumer.  Sa karamihan ng mga kaso, ang mga garantiya sa paghahatid ng   ay tumutugon sa maraming isyu sa pamamagitan ng pagtiyak na maihahatid ang mga mensahe nang kahit isang beses lang, ngunit ang mga mamimili ay dapat na may kakayahan. Gayunpaman, dahil sa hindi maiiwasang mga pagkabigo sa network, ang lahat ng lohika ng consumer ay dapat na idempotent upang maiwasan ang pagproseso ng mga duplicate na mensahe, anuman ang mga garantiya ng producer. Samakatuwid, ang pangangailangang ito ay hindi masyadong isang sagabal dahil ito ay sumasalamin sa katotohanan. 'kahit isang beses lang'  Mga solusyon  Mayroong maraming mga solusyon sa problemang ito, na may kanilang mga pakinabang at disadvantages.   Dalawang-phase commit  Ayon sa Wikipedia, ang Two-Phase Commit (2PC) ay isang distributed transaction protocol na ginagamit sa computer science at database management system upang matiyak ang pagkakapare-pareho at pagiging maaasahan ng mga ipinamamahaging transaksyon. Idinisenyo ito para sa mga sitwasyon kung saan kailangang lumahok ang maraming mapagkukunan (hal., mga database) sa iisang transaksyon, at tinitiyak nito na ang alinman sa mga ito ay gagawin ang transaksyon o lahat ng mga ito ay i-abort ito, sa gayon ay mapanatili ang pagkakapare-pareho ng data. Mukhang eksakto kung ano ang kailangan natin, ngunit ang Two-Phase Commit ay may ilang mga kakulangan:  Kung ang isang kalahok na mapagkukunan ay naging hindi tumutugon o nakakaranas ng pagkabigo, ang buong proseso ay maaaring i-block hanggang sa malutas ang isyu. Maaari itong humantong sa mga potensyal na problema sa pagganap at pagkakaroon.  Ang Two-Phase Commit ay hindi nagbibigay ng built-in na fault tolerance mechanism. Umaasa ito sa mga panlabas na mekanismo o manu-manong interbensyon upang mahawakan ang mga pagkabigo.  Hindi lahat ng modernong database ay sumusuporta sa Two-Phase Commit.   Nakabahaging database  Ang pinaka-malinaw na solusyon para sa arkitektura ng microservices ay ang paglalapat ng pattern (o kahit minsan ay anti-pattern) — isang nakabahaging database. Napaka-intuitive ng diskarteng ito kung kailangan mo ng transactional consistency sa maraming table sa iba't ibang database, gumamit lang ng isang shared database para sa mga microservice na ito.  Ang mga disbentaha ng diskarteng ito ay kinabibilangan ng pagpapakilala ng isang punto ng pagkabigo, pagpigil sa independiyenteng pag-scale ng database, at paglilimita sa kakayahang gumamit ng iba't ibang mga solusyon sa database na pinakaangkop para sa mga partikular na pangangailangan at mga kaso ng paggamit. Bukod pa rito, ang mga pagbabago sa mga microservices codebase ay kakailanganin upang suportahan ang naturang anyo ng ipinamahagi na transaksyon.   Transaksyonal na outbox  Ang '   ' ay isang pattern ng disenyo na ginagamit sa mga distributed system upang matiyak ang maaasahang pagpapalaganap ng mensahe, kahit na sa harap ng hindi mapagkakatiwalaang mga sistema ng pagmemensahe. Kabilang dito ang pag-iimbak ng mga kaganapan sa isang itinalagang talahanayan ng 'OutboxEvents' sa loob ng parehong transaksyon sa mismong operasyon. Ang diskarte na ito ay mahusay na nakahanay sa mga katangian ng ACID ng mga relational database. Sa kabaligtaran, maraming mga database ng No-SQL ang hindi ganap na sumusuporta sa mga katangian ng ACID, sa halip ay pinipili ang mga prinsipyo ng CAP theorem at BASE philosophy, na inuuna ang availability at sa huli na pagkakapare-pareho kaysa sa mahigpit na pagkakapare-pareho. transactional outbox  Ang isang transactional outbox ay nagbibigay   at maaaring ipatupad sa ilang mga diskarte: ng hindi bababa sa isang beses na garantiya  Tailing ng log ng transaksyon  Publisher ng botohan  Ang diskarte   ay nagpapahiwatig ng paggamit ng mga solusyong partikular sa database tulad ng CDC (Change Data Capture). Ang mga pangunahing kawalan ng pamamaraang ito ay: sa log tailing ng transaksyon  Mga tiyak na solusyon sa database  Tumaas na latency dahil sa mga detalye ng mga pagpapatupad ng CDC  Ang isa pang paraan ay ang   , na pinapadali ang pag-offload ng outbox sa pamamagitan ng pagboto sa outbox table. Ang pangunahing disbentaha ng diskarteng ito ay ang potensyal para sa pagtaas ng pag-load ng database, na maaaring humantong sa mas mataas na mga gastos. Higit pa rito, hindi lahat ng No-SQL database ay sumusuporta sa mahusay na pagtatanong para sa mga partikular na segment ng dokumento. Ang pagkuha ng buong mga dokumento, samakatuwid, ay maaaring magresulta sa pagkasira ng pagganap. Polling Publisher  Narito ang isang maliit na sequence diagram na nagpapaliwanag kung paano ito gumagana.    Makinig ka sa sarili mo  Ang pangunahing hamon sa Transactional Outbox pattern ay nakasalalay sa dependency nito sa mga katangian ng database ng ACID. Maaaring ito ay diretso sa karaniwang mga database ng OLTP ngunit nagdudulot ng mga hamon sa larangan ng NoSQL. Upang matugunan ito, ang isang potensyal na solusyon ay ang paggamit ng append log (halimbawa, Kafka) mula mismo sa pagsisimula ng pagproseso ng kahilingan.  Sa halip na direktang iproseso ang utos na 'magsumite ng aplikasyon sa pautang', agad naming ipinapadala ito sa isang panloob na paksa ng Kafka at pagkatapos ay ibabalik ang isang 'tinanggap' na resulta sa kliyente. Gayunpaman, dahil malaki ang posibilidad na ang utos ay kailangan pa ring iproseso, hindi namin agad na ipaalam sa customer ang resulta. Upang pamahalaan ang tuluyang pagkakapare-parehong ito, maaari kaming gumamit ng mga diskarte gaya ng mahabang botohan, botohan na pinasimulan ng kliyente, mga optimistikong update sa UI, o paggamit ng WebSockets o Server-Sent Events para sa mga notification. Gayunpaman, ito ay isang natatanging paksa sa kabuuan, kaya bumalik tayo sa ating unang paksa.  Ipinadala namin ang mensahe sa isang panloob na paksa ng Kafka. Pagkatapos ay ginagamit ng Serbisyo ng Loan Application ang mensaheng ito — ang parehong utos na natanggap nito mula sa kliyente — at nagsimulang iproseso. Una, nagsasagawa ito ng ilang lohika ng negosyo; pagkatapos lamang na matagumpay na naisakatuparan ang lohika na ito at nagpapatuloy ang mga resulta, naglalathala ito ng mga bagong mensahe sa isang pampublikong paksa ng Kafka.  Tingnan natin ang kaunting 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(); }    Huwag mag-alala, dahil ang offset ay hindi pa nagagawa, ang mensahe ay muling susubukan. Paano kung mabigo ang pagproseso ng lohika ng negosyo?    Huwag mag-alala, dahil ang lohika ng negosyo ay idempotent, hindi ito lilikha ng isang duplicate na aplikasyon sa pautang. Sa halip, susubukan nitong magpadala muli ng mga mensahe sa pampublikong paksa ng Kafka. Paano kung mabigo ang pagpapadala ng mga bagong kaganapan sa Kafka?    Huwag mag-alala, dahil ang lohika ng negosyo ay idempotent, hindi ito gagawa ng duplicate na loan application. Sa halip, magpapadala itong muli ng mga mensahe sa pampublikong paksa ng Kafka at umaasa na magtatagumpay ang offset commit sa pagkakataong ito. Paano kung ang mga mensahe ay ipinadala sa Kafka, ngunit nabigo ang offset commit?  Kabilang sa mga pangunahing disbentaha ng diskarteng ito ang dagdag na pagiging kumplikado na nauugnay sa isang bagong istilo ng programming, sa huli na pagkakapare-pareho (dahil hindi agad malalaman ng kliyente ang resulta), at ang kinakailangan para sa lahat ng lohika ng negosyo na maging idempotent.  Pagkuha ng kaganapan  Ano ang event sourcing, at paano ito mailalapat dito? Ang event sourcing ay isang software architectural pattern na ginagamit upang imodelo ang estado ng isang system sa pamamagitan ng pagkuha ng lahat ng pagbabago sa data nito bilang isang serye ng mga hindi nababagong kaganapan. Ang mga kaganapang ito ay kumakatawan sa mga katotohanan o pagbabago ng estado at nagsisilbing nag-iisang pinagmulan ng katotohanan para sa kasalukuyang estado ng system. Kaya, sa teknikal, sa pamamagitan ng pagpapatupad ng system-sourcing system, mayroon na tayong lahat ng event sa EventStore, at ang EventStore na ito ay magagamit ng mga consumer bilang isang pinagmumulan ng katotohanan tungkol sa nangyari. Walang pangangailangan para sa isang tiyak na solusyon sa database para sa pagsubaybay sa lahat ng mga pagbabago o alalahanin tungkol sa pag-order, ang tanging problema ay nakaupo sa read side dahil upang makakuha ng aktwal na estado ng entity ay kinakailangan upang i-replay ang lahat ng mga kaganapan.  Konklusyon  Sa artikulong ito, sinuri namin ang ilang mga diskarte para sa pagbuo ng maaasahang pagmemensahe sa mga distributed system. Mayroong ilang mga rekomendasyon na maaari naming isaalang-alang habang gumagawa ng mga system na may ganitong mga katangian  Palaging bumuo ng mga idempotent na mamimili dahil hindi maiiwasan ang pagkabigo sa network.  Maingat na gamitin   nang may malinaw na pag-unawa sa mga kinakailangan sa garantiya. ang First-Local-Commit-Then-Publish  Huwag kailanman gamitin   dahil maaari itong humantong sa matinding hindi pagkakapare-pareho ng data sa iyong system. ang diskarteng First-Publish-Then-Local-Commit  Kung ang kasalukuyang desisyon sa pagpili ng database ay malamang na maaaring magbago o ang teknikal na diskarte ay nagpapahiwatig na piliin ang pinakamahusay na solusyon sa storage para sa problema — huwag bumuo ng mga shared library sa pamamagitan ng pag-binding sa mga solusyon sa database tulad ng   . CDC  Gamitin ang   na diskarte bilang karaniwang solusyon para sa pagkamit ng kahit isang beses na mga garantiya. Transactional Outbox  Isaalang-alang ang paggamit ng   na diskarte kapag ang mga database ng Walang-SQL ay ginagamit. Makinig sa iyong sarili  Sa susunod, titingnan natin ang isang mas praktikal na halimbawa ng pagpapatupad ng Transactional Outbox. Tingnan mo  ikaw!

Read My Stories

Ang audio na ito ay ginawa sa orihinal na wika ng kuwento!

Masyadong mahaba; Upang basahin

Make resilience your competitive advantage

Maaasahang Pagmemensahe sa Mga Distributed System

About Author

MGA KOMENTO

HANG TAGS

ANG ARTIKULONG ITO AY IPINAKITA SA

Related Stories

Encrypted Instant Messaging Recommendations January 2017

How I deployed my spark document classification(Logistic Regression) model/s as a standalone app…

Hosting a DNS domain on the blockchain

COVID-19: We Need More Than Data, We Need Insights!

Encrypted Instant Messaging Recommendations January 2017

How I deployed my spark document classification(Logistic Regression) model/s as a standalone app…

Hosting a DNS domain on the blockchain

COVID-19: We Need More Than Data, We Need Insights!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps