Тархсан систем дэх найдвартай мессеж

Давхар бичих асуудал Найдвартай, өндөр хүртээмжтэй, өргөтгөх боломжтой тархсан системийг бий болгох нь тодорхой техник, зарчим, хэв маягийг дагаж мөрдөхийг шаарддаг. Ийм системийг зохион бүтээхэд олон тооны сорилтуудыг шийдвэрлэх шаардлагатай байдаг. Хамгийн түгээмэл бөгөөд үндсэн асуудлуудын нэг нь юм. давхар бичих асуудал ихэвчлэн синхрончлолд байх шаардлагатай олон мэдээллийн эх сурвалж эсвэл мэдээллийн сантай ажиллах үед тархсан системд үүсдэг сорилт юм. Энэ нь өгөгдлийн үл нийцэл, зөрчил, гүйцэтгэлийн саатал зэрэг асуудлуудыг оруулалгүйгээр өгөгдлийн өөрчлөлтийг өгөгдлийн сан, кэш гэх мэт янз бүрийн өгөгдлийн дэлгүүрт тогтмол бичиж байх хүндрэлийг хэлнэ. "Хос бичих асуудал" нь Үйлчилгээ тус бүрийн бичил үйлчилгээний архитектур болон загварын мэдээллийн сан нь бие даасан байршуулалт, масштаб, тусгаарлагдсан алдаа, хөгжлийн хурдыг нэмэгдүүлэх зэрэг олон давуу талыг авчирдаг. Гэсэн хэдий ч үйл ажиллагаа нь олон микро үйлчилгээний хооронд өөрчлөлт хийхийг шаарддаг бөгөөд энэ асуудлыг шийдвэрлэх найдвартай шийдлийн талаар бодоход хүргэдэг. Бараг бодит жишээ Манай домэйн зээлийн өргөдлийг хүлээн авч, тэдгээрийг үнэлж, дараа нь харилцагчдад мэдэгдлийн дохио илгээдэг хувилбарыг авч үзье. Нэг хариуцлагын зарчим, Конвейн хууль, домэйн дээр суурилсан дизайны аргын сүнсээр хэд хэдэн үйл явдалтай холбоотой сессийн дараа бүх домэйн нь тодорхой хил хязгаар, домэйн загвар, хаа сайгүй түгээмэл хэлээр тодорхойлогдсон хязгаарлагдмал контекст бүхий гурван дэд домэйнд хуваагдсан. зээлийн хүсэлтийг шинээр авах, эмхэтгэх үүрэгтэй. систем нь эдгээр өргөдлийг үнэлж, өгсөн өгөгдөл дээр үндэслэн шийдвэр гаргадаг. KYC/KYB, залилангийн эсрэг, зээлийн эрсдэлийн шалгалт зэрэг энэхүү үнэлгээний үйл явц нь цаг хугацаа их шаарддаг тул олон мянган програмыг нэгэн зэрэг зохицуулах чадварыг шаарддаг. Тиймээс энэ функцийг өөрийн мэдээллийн сантай тусгай бичил үйлчилгээнд шилжүүлж, бие даан масштаблах боломжийг олгосон. Эхнийх нь Хоёрдахь Цаашилбал, эдгээр дэд системүүдийг хоёр өөр баг удирддаг бөгөөд тус бүр өөрийн хувилбарын мөчлөг, үйлчилгээний түвшний гэрээ (SLA), өргөтгөх чадварын шаардлагуудтай байдаг. үйлчлүүлэгчдэд сэрэмжлүүлэг илгээх тусгай мэдэгдлийн үйлчилгээ байдаг. Эцэст нь Системийн үндсэн хэрэглээний талаар нарийвчилсан тайлбарыг энд оруулав. Үйлчлүүлэгч зээлийн өргөдөл гаргаж байна. Зээлийн өргөдлийн үйлчилгээ нь шинэ өргөдлийг "Хүлээгдэж буй" статустай бүртгэж, өргөдлийг Үнэлгээний үйлчилгээнд шилжүүлэх замаар үнэлгээний үйл явцыг эхлүүлдэг. Үнэлгээний алба нь ирж буй зээлийн өргөдлийг үнэлж, шийдвэрийн талаар Зээлийн өргөдлийн үйлчилгээнд мэдэгдэнэ. Шийдвэрийг хүлээн авмагц Зээлийн өргөдлийн үйлчилгээ нь зээлийн өргөдлийн статусыг шинэчилж, үр дүнгийн талаар харилцагчид мэдэгдэхийн тулд Мэдэгдэлийн үйлчилгээг идэвхжүүлдэг. Мэдэгдлийн үйлчилгээ нь энэхүү хүсэлтийг боловсруулж, харилцагчийн тохиргооны дагуу имэйл, SMS эсвэл бусад сонгосон харилцааны аргуудаар дамжуулан мэдэгдлийг илгээдэг. Энэ нь эхлээд харахад маш энгийн бөгөөд энгийн систем боловч Зээлийн өргөдлийн үйлчилгээ зээлийн өргөдөл гаргах командыг хэрхэн боловсруулдаг талаар сонирхоцгооё. Үйлчилгээний харилцан үйлчлэлийн хоёр аргыг бид авч үзэж болно: Энэ аргын хувьд үйлчилгээ нь өөрийн локал мэдээллийн баазыг шинэчилж (амлалт), дараа нь үйл явдал эсвэл мессежийг бусад үйлчилгээнд нийтэлдэг. Эхлээд-Орон нутгийн-Үүрэг-Дараа нь-Хэвлэн нийтлэх: Эсрэгээр, энэ арга нь орон нутгийн мэдээллийн санд өөрчлөлт оруулахаас өмнө үйл явдал эсвэл мессежийг нийтлэх явдал юм. Эхлээд-Хэвлэн нийтлэх-Дараа нь-Орон нутгийн-Үүрэгжүүлэх: Энэ хоёр арга нь сул талуудтай бөгөөд тархсан систем дэх харилцаа холбоонд зөвхөн хэсэгчлэн аюулгүй байдаг. Энэ бол эхний аргыг хэрэглэх дарааллын схем юм. Энэ хувилбарт Зээлийн өргөдлийн үйлчилгээ нь эхлээд гүйлгээ хийж, дараа нь өөр систем рүү мэдэгдэл илгээх оролдлого хийх аргыг ашигладаг. Гэсэн хэдий ч, жишээ нь сүлжээний асуудал гарсан, Үнэлгээний үйлчилгээ боломжгүй эсвэл Зээлийн өргөдлийн үйлчилгээ нь санах ойгүй (OOM) алдаатай тулгараад гацсан тохиолдолд энэ процесс бүтэлгүйтэх магадлалтай. Ийм тохиолдолд нэмэлт арга хэмжээ авахгүй бол шинэ зээлийн өргөдлийн талаар мэдэгдэлгүйгээр Үнэлгээг орхиж, мессеж алга болно. "Эхлээд орон нутагтаа үйлдэх-дараа нь нийтлэх" Тэгээд хоёр дахь нь. хувилбарт Зээлийн өргөдлийн үйлчилгээ илүү их эрсдэлтэй тулгардаг. Энэ нь Үнэлгээний үйлчилгээнд шинэ програмын талаар мэдээлж болох боловч мэдээллийн сангийн асуудал, санах ойн алдаа, кодын алдаа зэрэг асуудлаас болж энэ шинэчлэлтийг дотооддоо хадгалж чадахгүй. Энэ арга нь Зээлийн хянан шалгах үйлчилгээ нь ирж буй өргөдлийг хэрхэн зохицуулж байгаагаас шалтгаалж ноцтой асуудал үүсгэж болзошгүй өгөгдөлд ихээхэн зөрчилд хүргэж болзошгүй юм. "Эхлээд нийтлэх-дараа нь орон нутаг-хамгалах" Тиймээс бид гадны хэрэглэгчдэд үйл явдлыг нийтлэх хүчирхэг механизмыг санал болгодог шийдлийг тодорхойлох ёстой. Гэхдээ боломжит шийдлүүдийг судлахын өмнө бид тараасан системд хүрч болох мессеж дамжуулах баталгааны төрлийг тодруулах хэрэгтэй. Зурвас хүргэх баталгаа Бидний хүрч чадах дөрвөн төрлийн баталгаа бий. Ямар ч баталгаа байхгүй Мессежийг очих газарт нь хүргэх баталгаа байхгүй. гэсэн хандлага нь яг энэ тухай юм. Хэрэглэгчид мессежийг нэг удаа, олон удаа эсвэл огт хүлээж авах боломжтой. "Эхлээд орон нутагтай-харилцаж-дараа нь хэвлэ" Хамгийн ихдээ нэг удаа хүргэлт хийнэ Хамгийн ихдээ нэг удаа хүргэлт гэдэг нь мессежийг очих газартаа хамгийн ихдээ 1 удаа хүргэнэ гэсэн үг. хандлагыг нэг утгатай оролдлогыг дахин оролдох бодлогыг ийм байдлаар хэрэгжүүлж болно. Эхлээд-Орон нутгийн-Үүрэг-Дараа нь-Хэвлэн нийтлэх Наад зах нь нэг удаа хүргэлт\Хэрэглэгчид мессеж бүрийг хүлээн авч боловсруулах боловч нэг мессежийг нэгээс олон удаа хүлээн авч болно. Яг нэг удаа хүргэлт\Яг нэг удаа хүргэнэ гэдэг нь хэрэглэгч мессежийг нэг удаа үр дүнтэй хүлээн авна гэсэн үг. Техникийн хувьд Кафкагийн гүйлгээ, үйлдвэрлэгч, хэрэглэгчийн тодорхой idempotent хэрэгжилтээр хүрэх боломжтой. Ихэнх тохиолдолд хүргэх баталгаа нь мессежийг дор хаяж нэг удаа хүргэх замаар олон асуудлыг шийдэж өгдөг боловч хэрэглэгчид үл мэдэгдэх чадвартай байх ёстой. Гэсэн хэдий ч сүлжээний зайлшгүй доголдлыг харгалзан үйлдвэрлэгчийн баталгаанаас үл хамааран давхардсан мессежийг боловсруулахаас зайлсхийхийн тулд хэрэглэгчийн бүх логик idempotent байх ёстой. Тиймээс энэ шаардлага нь бодит байдлыг тусгахаасаа илүү сул тал биш юм. "дор хаяж нэг удаа" Шийдэл Энэ асуудлыг шийдэх олон шийдэл байдаг бөгөөд тэдгээр нь давуу болон сул талуудтай байдаг. Хоёр үе шаттай амлалт Wikipedia-д бичсэнээр, Хоёр үе шаттай үүрэг хариуцлага (2PC) нь тархсан гүйлгээний тууштай, найдвартай байдлыг хангахын тулд компьютерийн шинжлэх ухаан, мэдээллийн сангийн удирдлагын системд ашиглагддаг тархсан гүйлгээний протокол юм. Энэ нь олон нөөц (жишээ нь, мэдээллийн сан) нэг гүйлгээнд оролцох шаардлагатай нөхцөл байдалд зориулагдсан бөгөөд тэдгээр нь бүгд гүйлгээг хийх эсвэл бүгд цуцлах, ингэснээр өгөгдлийн тогтвортой байдлыг хадгалах боломжийг олгодог. Энэ нь бидэнд яг хэрэгтэй зүйл мэт санагдаж байгаа ч Хоёр үе шаттай үүрэг хариуцлага нь хэд хэдэн сул талуудтай: Хэрэв нэг оролцогч эх сурвалж хариу өгөхгүй эсвэл бүтэлгүйтсэн бол асуудлыг шийдэх хүртэл процессыг бүхэлд нь хааж болно. Энэ нь боломжит гүйцэтгэл, хүртээмжтэй холбоотой асуудалд хүргэж болзошгүй юм. Хоёр үе шаттай үүрэг хариуцлага нь алдааг тэсвэрлэх механизмаар хангадаггүй. Энэ нь бүтэлгүйтлийг арилгахын тулд гадны механизм эсвэл гарын авлагын оролцоонд тулгуурладаг. Орчин үеийн бүх мэдээллийн сан нь хоёр үе шаттай үйлдлийг дэмждэггүй. Хуваалцсан мэдээллийн сан Микро үйлчилгээний архитектурын хамгийн тод шийдэл бол нийтлэг мэдээллийн сан болох загвар (эсвэл заримдаа эсрэг загвар) ашиглах явдал юм. Хэрэв танд өөр өгөгдлийн сангийн олон хүснэгтийн хооронд гүйлгээний уялдаа холбоотой байх шаардлагатай бол эдгээр микро үйлчилгээнд нэг хуваалцсан мэдээллийн санг ашиглахад л энэ арга нь маш ойлгомжтой юм. Энэ аргын сул тал нь алдааны нэг цэгийг нэвтрүүлэх, өгөгдлийн сангийн бие даасан масштабыг хориглох, тодорхой шаардлага, ашиглалтын тохиолдлуудад хамгийн тохиромжтой мэдээллийн сангийн өөр өөр шийдлүүдийг ашиглах боломжийг хязгаарлах явдал юм. Нэмж дурдахад ийм төрлийн тархсан гүйлгээг дэмжихийн тулд микро үйлчилгээний кодын санд өөрчлөлт оруулах шаардлагатай болно. Гүйлгээний гадагшаа хайрцаг " " нь найдваргүй мессежийн системтэй байсан ч найдвартай мессеж түгээх боломжийг хангах үүднээс тархсан системд ашигладаг загварын загвар юм. Энэ нь үйлдлүүдийг тухайн үйл ажиллагаатай ижил гүйлгээний хүрээнд тусгайлсан 'OutboxEvents' хүснэгтэд хадгалахыг хамардаг. Энэ арга нь харилцааны мэдээллийн сангийн ACID шинж чанаруудтай сайн нийцдэг. Үүний эсрэгээр олон No-SQL өгөгдлийн сан нь ACID шинж чанарыг бүрэн дэмждэггүй бөгөөд үүний оронд CAP теорем болон BASE философийн зарчмуудыг сонгодог бөгөөд энэ нь хатуу тууштай байхаас илүү хүртээмжтэй байдал, эцсийн тогтвортой байдлыг чухалчилдаг. Гүйлгээний гадагшаа хайрцаг Гүйлгээний гадагшаа хайрцаг нь өгдөг бөгөөд үүнийг хэд хэдэн аргаар хэрэгжүүлж болно: дор хаяж нэг удаа баталгаа Гүйлгээний бүртгэлийн хаягдал Санал асуулгын нийтлэгч арга нь CDC (Өгөгдлийн бичлэгийг өөрчлөх) гэх мэт өгөгдлийн сангийн тусгай шийдлүүдийг ашиглахыг хэлнэ. Энэ аргын гол сул талууд нь: Гүйлгээний бүртгэлийн хаягдлын Өгөгдлийн сангийн тусгай шийдлүүд CDC-ийн хэрэгжилтийн онцлогоос шалтгаалан саатал нэмэгдсэн Өөр нэг арга бол бөгөөд энэ нь гадагшаа илгээсэн хайрцгийн хүснэгтээс санал асуулга авах замаар гадагшаа илгээх хайрцгийг буулгахад хялбар болгодог. Энэ аргын гол сул тал нь мэдээллийн баазын ачааллыг нэмэгдүүлэх боломжтой бөгөөд энэ нь илүү өндөр зардалд хүргэж болзошгүй юм. Цаашилбал, бүх No-SQL өгөгдлийн сан нь тодорхой баримт бичгийн сегментийн үр ашигтай хайлтыг дэмждэггүй. Тиймээс баримт бичгийг бүхэлд нь задлах нь гүйцэтгэлийн бууралтад хүргэж болзошгүй юм. Санал асуулгын нийтлэгч Энэ нь хэрхэн ажилладагийг тайлбарласан жижиг дарааллын диаграмм юм. Өөрийгөө сонс Transaction Outbox загварын гол бэрхшээл нь мэдээллийн сангийн ACID шинж чанараас хамааралтай байдаг. Энэ нь ердийн OLTP өгөгдлийн санд энгийн байж болох ч NoSQL талбарт бэрхшээл учруулдаг. Үүнийг шийдвэрлэхийн тулд хүсэлтийн боловсруулалтыг эхлүүлэхээс өмнө нэмэлт бүртгэлийг (жишээлбэл, Кафка) ашиглах нь боломжит шийдэл юм. "Зээлийн өргөдөл илгээх" командыг шууд боловсруулахын оронд бид Кафкагийн дотоод сэдэв рүү шууд илгээж, дараа нь үйлчлүүлэгчид "хүлээн зөвшөөрсөн" үр дүнг буцаана. Гэсэн хэдий ч, энэ тушаалыг боловсруулах шаардлагатай хэвээр байгаа тул бид үр дүнгийн талаар хэрэглэгчдэд шууд мэдэгдэх боломжгүй юм. Энэхүү эцсийн тогтвортой байдлыг зохицуулахын тулд бид урт хугацааны санал асуулга, үйлчлүүлэгчийн санаачилсан санал асуулга, UI-ийн өөдрөг шинэчлэлтүүд эсвэл WebSockets эсвэл Серверээс илгээсэн үйл явдлуудыг мэдэгдэлд ашиглах зэрэг арга техникийг ашиглаж болно. Гэсэн хэдий ч энэ бол бүхэлдээ тусдаа сэдэв тул анхны сэдэв рүүгээ буцъя. Бид Кафкагийн дотоод сэдвээр мессеж илгээсэн. Зээлийн өргөдлийн үйлчилгээ нь үйлчлүүлэгчээс хүлээн авсан тушаалтай ижил мессежийг хэрэглэж, боловсруулж эхэлнэ. Нэгдүгээрт, энэ нь зарим бизнесийн логикийг гүйцэтгэдэг; Энэ логик амжилттай хэрэгжиж, үр дүн нь хадгалагдсны дараа л Кафкагийн олон нийтийн сэдвээр шинэ мэдээ нийтэлдэг. Ингээд псевдокодыг жаахан харцгаая. 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(); } Санаа зоволтгүй, офсет хараахан хийгдээгүй байгаа тул мессежийг дахин оролдох болно. Бизнесийн логик боловсруулалт амжилтгүй болвол яах вэ? Санаа зоволтгүй, учир нь бизнесийн логик нь үл нийцэх тул давхардсан зээлийн өргөдөл үүсгэхгүй. Үүний оронд Кафкагийн олон нийтийн сэдэв рүү мессеж илгээхийг оролдох болно. Кафка руу шинэ үйл явдлуудыг илгээж чадахгүй бол яах вэ? Санаа зоволтгүй, учир нь бизнесийн логик нь идэвхгүй тул давхардсан зээлийн өргөдөл үүсгэхгүй. Үүний оронд Кафкагийн олон нийтийн сэдэв рүү мессеж илгээх бөгөөд энэ удаад офсет амлалт амжилттай болно гэж найдаж байна. Кафка руу мессеж илгээсэн ч офсетийн үүрэг амжилтгүй болвол яах вэ? Энэ аргын гол сул тал нь шинэ програмчлалын хэв маягтай холбоотой нэмэлт төвөгтэй байдал, эцсийн тогтвортой байдал (үйлчлүүлэгч үр дүнг шууд мэдэхгүй тул) болон бизнесийн бүх логикийг үл тоомсорлох шаардлага орно. Үйл явдлын эх сурвалж Үйл явдлын эх сурвалж гэж юу вэ, үүнийг энд хэрхэн ашиглах вэ? Үйл явдлын эх сурвалж нь системийн төлөв байдлыг загварчлахад ашигладаг програм хангамжийн архитектурын загвар бөгөөд түүний өгөгдөлд гарсан бүх өөрчлөлтийг өөрчлөгдөшгүй үйл явдлуудын цуваа болгон авч болно. Эдгээр үйл явдлууд нь баримтууд эсвэл төлөв байдлын шилжилтийг төлөөлдөг бөгөөд системийн өнөөгийн байдлын үнэний цорын ганц эх сурвалж болдог. Техникийн хувьд, үйл явдлын эх сурвалжийн системийг хэрэгжүүлснээр бид EventStore-д бүх үйл явдлуудыг аль хэдийн эзэмшсэн бөгөөд энэхүү EventStore-г хэрэглэгчид юу болсон талаар үнэний цорын ганц эх сурвалж болгон ашиглаж болно. Захиалга хийхтэй холбоотой бүх өөрчлөлт, санаа зовоосон асуудлуудыг хянахын тулд мэдээллийн сангийн тусгай шийдэл шаардлагагүй, цорын ганц асуудал бол унших тал дээр суух явдал юм, учир нь бүх үйл явдлыг дахин тоглуулахын тулд байгууллагын бодит байдлыг олж авах боломжтой байх шаардлагатай. Дүгнэлт Энэ нийтлэлд бид тархсан системд найдвартай мессежийг бий болгох хэд хэдэн аргыг авч үзсэн. Эдгээр шинж чанаруудтай системийг барьж байгуулахдаа хэд хэдэн зөвлөмжийг анхаарч үзэх хэрэгтэй Сүлжээний эвдрэлээс зайлсхийх боломжгүй тул чадваргүй хэрэглэгчдийг үргэлж хөгжүүл. Баталгаажуулалтын шаардлагуудын талаар тодорхой ойлголттойгоор болгоомжтой ашиглана уу. Эхлээд-Орон нутгийн-Үүрэг-Дараа нь-Хэвлэн нийтлэх-ийг Таны системд өгөгдлийн ноцтой зөрчилд хүргэж болзошгүй тул аргыг хэзээ ч бүү ашигла. "Эхлээд нийтлэх-дараа нь-орон нутгийн үйл ажиллагаа явуулах" Хэрэв одоо байгаа өгөгдлийн сангийн сонголтын шийдвэр өөрчлөгдөх магадлалтай эсвэл техникийн стратеги нь асуудлыг шийдвэрлэх хамгийн сайн хадгалах шийдлийг сонгохыг шаарддаг бол гэх мэт өгөгдлийн сангийн шийдлүүдийг холбох замаар дундын номын санг бүү байгуул. CDC Ядаж нэг удаа баталгааг хангахын тулд аргыг стандарт шийдэл болгон ашигла. Transactional Outbox No-SQL мэдээллийн санг ашиглах үед аргыг ашиглах талаар бодож үзээрэй. өөрийгөө сонсох Дараагийн удаа бид Transaction Outbox-г хэрэгжүүлэх илүү практик жишээг авч үзэх болно. Харна уу чи!