په توزیع شوي سیسټمونو کې د باور وړ پیغام رسول

د دوه ګوني لیکلو ستونزه

د باور وړ، خورا موجود، د توزیع وړ توزیع شوي سیسټم رامینځته کول د ځانګړو تخنیکونو، اصولو او نمونو تعقیب ته اړتیا لري. د دې ډول سیسټمونو ډیزاین د بې شمیره ننګونو په نښه کول شامل دي. د ډیرو عامو او بنسټیزو مسلو څخه د دوه ګوني لیکلو ستونزه ده.

د "دوه ګونې لیکلو ستونزه" یوه ننګونه ده چې په ویشل شوي سیسټمونو کې رامینځته کیږي، په ځانګړې توګه کله چې د ډیری ډیټا سرچینو یا ډیټابیسونو سره معامله کوي چې باید په همغږۍ کې وساتل شي. دا د ډاډ ترلاسه کولو ستونزې ته اشاره کوي چې د معلوماتو بدلونونه په دوامداره توګه مختلف ډیټا پلورنځیو ته لیکل شوي ، لکه ډیټابیس یا کیچ ، پرته له دې چې د ډیټا متضادیت ، شخړې ، یا د فعالیت خنډونه معرفي کړي.

په هر خدمت کې د مایکرو خدماتو جوړښت او نمونې ډیټابیس تاسو ته ډیری ګټې راوړي ، لکه خپلواک ګمارنه او اندازه کول ، جلا ناکامي ، او د پراختیا سرعت احتمالي وده. په هرصورت، عملیات د ډیری مایکرو خدماتو ترمنځ بدلونونو ته اړتیا لري، تاسو دې ته اړ باسي چې د دې ستونزې حل کولو لپاره د باور وړ حل په اړه فکر وکړئ.

تقریبا یو ریښتینی مثال

راځئ چې یوه سناریو په پام کې ونیسو په کوم کې چې زموږ ډومین د پور غوښتنلیکونو منل ، د دوی ارزونه ، او بیا پیرودونکو ته د خبرتیا خبرتیا لیږل شامل دي.

د واحد مسؤلیت اصل په روح کې، د کانوی قانون، او د ډومین لخوا پرمخ وړل شوي ډیزاین طریقه، د ډیری پیښو طوفان غونډو وروسته، ټول ډومین په دریو فرعي ډومینونو ویشل شوی و چې د واضح سرحدونو، ډومین ماډلونو، او هر اړخیزه ژبې سره د ټاکل شوي محدود شرایطو سره ویشل شوی و.

لومړی د پورونو نوي غوښتنلیکونو ته د ننوتلو او راټولولو دنده په غاړه لري. دوهم سیسټم دا غوښتنلیکونه ارزوي او د چمتو شوي معلوماتو پراساس پریکړې کوي. د ارزونې دا پروسه، په شمول د KYC/KYB، درغلۍ ضد، او د کریډیټ خطر چکونه، د وخت ضایع کول کیدی شي، په ورته وخت کې د زرګونو غوښتنلیکونو اداره کولو وړتیا ته اړتیا لري. په پایله کې، دا فعالیت د خپل ډیټابیس سره وقف شوي مایکرو سرویس ته سپارل شوی، د خپلواک اندازه کولو لپاره اجازه ورکوي.

سربیره پردې ، دا فرعي سیسټمونه د دوه مختلف ټیمونو لخوا اداره کیږي ، هر یو د خپل خوشې کولو دورې ، د خدماتو کچې موافقتنامې (SLA) ، او د توزیع کولو اړتیاو سره.

په نهایت کې ، پیرودونکو ته د خبرتیاو لیږلو لپاره یو ځانګړی خبرتیا خدمت شتون لري.

دلته د سیسټم د لومړني کارونې قضیې اصالح توضیح دی:

1. یو پیرودونکی د پور غوښتنلیک وړاندې کوي.
2. د پور غوښتنلیک خدمت نوی غوښتنلیک د "انتقال" حالت سره ثبتوي او د ارزونې خدمت ته غوښتنلیک لیږلو سره د ارزونې پروسه پیل کوي.
3. د ارزونې خدمت د راتلونکي پور غوښتنلیک ارزوي او وروسته د پور غوښتنلیک خدمت ته د پریکړې په اړه خبر ورکوي.
4. د پریکړې په ترلاسه کولو سره، د پور غوښتنلیک خدمت د پور غوښتنلیک حالت د دې مطابق تازه کوي او د خبرتیا خدمت هڅوي ترڅو پیرودونکي ته د پایلو خبر ورکړي.
5. د خبرتیا خدمت دا غوښتنه پروسس کوي او پیرودونکي ته د بریښنالیک ، ایس ایم ایس یا نورو غوره اړیکو میتودونو له لارې خبرتیاوې لیږي ، د پیرودونکي ترتیباتو سره سم.

دا په لومړي نظر کې یو خورا ساده او ابتدايي سیسټم دی، مګر راځئ چې په دې کې ډوب وکړو چې څنګه د پور غوښتنلیک خدمت د سپارلو پور غوښتنلیک کمانډ پروسس کوي.

موږ کولی شو د خدماتو متقابل عمل لپاره دوه لارې په پام کې ونیسو:

1. لومړی-محلي-ژمنه-بیا-خپرول: په دې طریقه کې، خدمت خپل محلي ډیټابیس (ژمنې) تازه کوي او بیا نورو خدماتو ته یوه پیښه یا پیغام خپروي.

2. لومړی-خپروئ-بیا-ځایی-ژمنه: برعکس، دا طریقه په محلي ډیټابیس کې د بدلونونو د ترسره کولو دمخه د پیښې یا پیغام خپرول شامل دي.

   
   

دواړه میتودونه خپل نیمګړتیاوې لري او په ویشل شوي سیسټمونو کې د مخابراتو لپاره یوازې یو څه ناکامه خوندي دي.

دا د لومړۍ کړنلارې پلي کولو یو ترتیب ډیاګرام دی.

په دې سناریو کې، د پور غوښتنلیک خدمت د لومړي-محلي-کمیټ-بیا-پبلش طریقه کاروي، چیرته چې دا لومړی معامله کوي او بیا بل سیسټم ته د خبرتیا لیږلو هڅه کوي. په هرصورت، دا پروسه د ناکامۍ لپاره حساسه ده که چیرې، د بیلګې په توګه، د شبکې مسلې شتون لري، د ارزونې خدمت شتون نلري، یا د پور غوښتنلیک خدمت د حافظې څخه بهر (OOM) تېروتنې سره مخ کیږي او خرابیږي. په داسې حاالتو کې، پیغام به ورک شي، پرته له دې چې اضافي اقدامات پلي شي، د نوي پور غوښتنلیک خبرتیا پرته ارزونه پریږدي.

او دوهم یو.

په لومړي خپرونه کې بیا د محلي کمیټې سناریو کې، د پور غوښتنلیک خدمت د ډیرو پام وړ خطرونو سره مخ دی. دا ممکن د ارزونې خدماتو ته د نوي غوښتنلیک په اړه خبر ورکړي مګر د ډیټابیس مسلو ، حافظې غلطیو ، یا کوډ بګونو په څیر ستونزو له امله په محلي ډول د دې تازه معلوماتو خوندي کولو کې پاتې راغلی. دا طریقه کولی شي په ډیټا کې د پام وړ توپیرونو لامل شي، کوم چې کولی شي جدي ستونزې رامینځته کړي، پدې پورې اړه لري چې د پور بیاکتنې خدمت څنګه راتلونکی غوښتنلیکونه اداره کوي.

له همدې امله، موږ باید یو داسې حل وپیژنو چې بهرني مصرف کونکو ته د پیښو خپرولو لپاره قوي میکانیزم وړاندې کوي. مګر، مخکې له دې چې احتمالي حلونو ته لاړ شو، موږ باید لومړی د پیغام رسولو تضمین ډولونه روښانه کړو چې په ویشل شوي سیسټمونو کې د لاسته راوړلو وړ دي.

د پیغام رسولو تضمین

دلته څلور ډوله تضمینونه شتون لري چې موږ یې ترلاسه کولی شو.

1. هیڅ تضمین نشته
   هیڅ تضمین شتون نلري چې پیغام به منزل ته ورسوي. لومړی - محلي - کمیټه - بیا - خپرول په دې اړه دقیقا دي. پیرودونکي ممکن یو ځل، څو ځله، یا هیڅکله هیڅکله پیغامونه ترلاسه کړي.

2. لږترلږه یوځل تحویلي
   لږترلږه یو ځل تحویلي پدې معنی ده چې پیغام به په 1 وخت کې منزل ته وسپارل شي. لومړی-محلي-ژمنه-بیا-خپرول طریقه په دې ډول پلي کیدی شي او همدارنګه د یو ارزښت سره د هڅو بیا هڅه کولو پالیسي سره.

3. لږترلږه یو ځل تحویلي\ مصرف کونکي به هر پیغام ترلاسه او پروسس کړي مګر ممکن ورته پیغام له یو ځل څخه ډیر ترلاسه کړي.

4. په دقیق ډول یوځل تحویلي \ دقیقا یوځل تحویلي پدې معنی چې پیرودونکي به یوځل پیغام په مؤثره توګه ترلاسه کړي.
   په تخنیکي توګه، دا ممکنه ده چې د کافکا د معاملو او د تولیدونکي او مصرف کونکي په ځانګړي ډول د پام وړ تطبیق سره ترلاسه شي.

   
   

په ډیری حاالتو کې، 'لږترلږه یو ځل' تحویلي تضمین ډیری مسلې په ګوته کوي ترڅو ډاډ ترلاسه کړي چې پیغامونه لږترلږه یو ځل تحویل شوي، مګر مصرف کونکي باید بې کفایته وي. په هرصورت، د نه منلو وړ شبکې ناکامیو ته په پام سره، د مصرف کونکي ټول منطق باید د تولیدونکي تضمین په پام کې نیولو پرته، د نقل پیغامونو پروسس کولو څخه مخنیوي لپاره قوي وي. له همدې امله، دا اړتیا دومره نیمګړتیا نه ده ځکه چې دا واقعیت منعکس کوي.

د حل لارې

د دې ستونزې لپاره ډیری حلونه شتون لري، چې د دوی ګټې او زیانونه لري.

دوه مرحلې ژمنې

د ویکیپیډیا په وینا، د دوه پړاوونو کمیټه (2PC) د توزیع شوي لیږد پروتوکول دی چې د کمپیوټر ساینس او ډیټابیس مدیریت سیسټمونو کې کارول کیږي ترڅو د ویشل شوي لیږدونو ثبات او اعتبار یقیني کړي. دا د داسې شرایطو لپاره ډیزاین شوی چیرې چې ډیری سرچینې (د بیلګې په توګه، ډیټابیس) په یوه لیږد کې برخه اخیستلو ته اړتیا لري، او دا ډاډ ورکوي چې یا ټول یې معامله کوي یا ټول یې لغوه کوي، په دې توګه د معلوماتو ثبات ساتل. دا دقیقا هغه څه ښکاري چې موږ ورته اړتیا لرو ، مګر د دوه مرحلې کمیټې ډیری نیمګړتیاوې لري:

• که چیرې یوه برخه اخیستونکې سرچینه غیر ځواب ویونکي شي یا د ناکامۍ تجربه وکړي، ټوله پروسه بنده کیدی شي تر هغه چې مسله حل شي. دا کولی شي د احتمالي فعالیت او شتون ستونزې رامینځته کړي.
• د دوه مرحلې کمیټه د غلطۍ زغملو میکانیزمونه نه وړاندې کوي. دا د ناکامیو اداره کولو لپاره په بهرني میکانیزمونو یا لاسي مداخلې تکیه کوي.
• ټول عصري ډیټابیسونه د دوه مرحلې کمیټې ملاتړ نه کوي.

شریک شوی ډیټابیس

د مایکرو خدماتو جوړښت لپاره خورا څرګند حل دا دی چې یو نمونه پلي کړئ (یا حتی ځینې وختونه ضد نمونه) - یو ګډ ډیټابیس. دا طریقه ډیره هوښیاره ده که تاسو په مختلفو ډیټابیسونو کې د ډیری جدولونو په اوږدو کې د لیږد دوام ته اړتیا لرئ، یوازې د دې مایکرو خدماتو لپاره یو ګډ ډیټابیس وکاروئ.

د دې کړنلارې نیمګړتیاوې د ناکامۍ د یوې نقطې معرفي کول، د خپلواک ډیټابیس اندازه کولو مخه نیسي، او د ډیټابیس مختلف حلونو کارولو وړتیا محدودوي چې د ځانګړو اړتیاو او کارولو قضیو لپاره غوره دي. برسیره پردې، د مایکرو سرویسس کوډبیسونو کې تعدیلات به اړین وي چې د ویشل شوي لیږد ډول ډول مالتړ وکړي.

د راکړې ورکړې بهر بکس

د راکړې ورکړې بهر بکس د ډیزاین نمونه ده چې په ویشل شوي سیسټمونو کې کارول کیږي ترڅو د باور وړ پیغام تبلیغ یقیني کړي، حتی د غیر باوري پیغام رسولو سیسټمونو سره مخ کې. پدې کې د پیښو ذخیره کول شامل دي په ټاکل شوي 'OutboxEvents' جدول کې د ورته لیږد دننه د عملیاتو په څیر. دا طریقه د اړونده ډیټابیسونو د ACID ملکیتونو سره ښه سمون لري. په مقابل کې، ډیری No-SQL ډیټابیسونه په بشپړ ډول د ACID ملکیتونو ملاتړ نه کوي، د CAP تیورم او BASE فلسفې اصولو لپاره غوره کوي، کوم چې شتون او حتمي ثبات ته د سخت ثبات په پرتله لومړیتوب ورکوي.

د راکړې ورکړې بهر بکس لږترلږه یو ځل تضمین چمتو کوي او د څو لارو سره پلي کیدی شي:

1. د راکړې ورکړې log tailing

2. د رای ورکولو خپرونکی

   
   

د راکړې ورکړې لاګ ټیلینګ طریقه د ډیټابیس ځانګړي حلونو لکه CDC (د ډیټا نیول بدلول) کارول معنی لري. د دې طریقې اصلي نیمګړتیاوې په لاندې ډول دي:

• د ډیټابیس ځانګړي حلونه

• د CDC پلي کولو ځانګړتیاو له امله د ځنډ زیاتوالی

  
  

بله طریقه د رای ورکولو خپرونکی دی، کوم چې د آوټ بکس میز ته د رای ورکولو له لارې د آوټ بکس آفلوډ کول اسانه کوي. د دې تګلارې لومړنۍ نیمګړتیا د ډیټابیس بار زیاتوالي احتمال دی، کوم چې کولی شي د لوړ لګښتونو المل شي. سربیره پردې ، ټول No-SQL ډیټابیسونه د ځانګړي سند برخو لپاره د مؤثره پوښتنو ملاتړ نه کوي. د ټولو اسنادو استخراج کولی شي د فعالیت د خرابیدو پایله ولري.

دلته یو کوچنی ترتیب ډیاګرام دی چې تشریح کوي چې دا څنګه کار کوي.

خپل ځان واورئ

د لیږد آوټ بکس نمونې سره لومړنۍ ننګونه د ډیټابیس ACID ملکیتونو پورې تړاو لري. دا ممکن په عادي OLTP ډیټابیسونو کې مستقیم وي مګر په NoSQL سیمه کې ننګونې رامینځته کوي. د دې د حل لپاره، یو احتمالي حل دا دی چې د ضمیمې لاګ (د مثال په توګه، کافکا) د غوښتنې پروسس کولو پیل کولو څخه ګټه پورته کړي.

د مستقیم پروسس کولو پرځای د پور غوښتنلیک سپارلو کمانډ، موږ سمدلاسه دا د کافکا داخلي موضوع ته لیږو او بیا یې پیرودونکي ته 'منلې شوې' پایله بیرته ورکوو. په هرصورت، ځکه چې دا خورا احتمال لري چې قوماندې لاهم پروسس کولو ته اړتیا لري، موږ نشو کولی سمدلاسه پیرودونکي ته د پایلې خبر ورکړو. د دې پیښې دوامدارۍ اداره کولو لپاره ، موږ کولی شو تخنیکونه وکاروو لکه اوږده رایه ورکول ، د پیرودونکي لخوا پیل شوي رای ورکول ، د UI امید لرونکي تازه معلومات ، یا د خبرتیاو لپاره د ویب ساکټس یا سرور لخوا لیږل شوي پیښې کارول. په هرصورت، دا په بشپړه توګه جلا موضوع ده، نو راځئ چې خپل لومړني موضوع ته راستون شو.

موږ پیغام د کافکا داخلي موضوع ته واستاوه. د پور غوښتنلیک خدمت بیا دا پیغام مصرفوي - ورته کمانډ چې دا د پیرودونکي څخه ترلاسه شوی - او پروسس پیل کوي. لومړی، دا یو څه سوداګریز منطق اجرا کوي؛ یوازې وروسته له دې چې دا منطق په بریالیتوب سره اجرا شي او پایلې یې دوام ومومي، دا د کافکا په عامه موضوع کې نوي پیغامونه خپروي.

راځئ چې یو څه سیډو کوډ ته وګورو.

 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 د مصرف کونکو لخوا د څه پیښ شوي په اړه د ریښتیني سرچینې په توګه کارول کیدی شي. د امر کولو په اړه د ټولو بدلونونو یا اندیښنو تعقیب لپاره ځانګړي ډیټابیس حل ته اړتیا نشته ، یوازینۍ ستونزه د لوستلو اړخ ته ناست ده ځکه چې د دې وړتیا لپاره د ادارې ریښتیني حالت ترلاسه کولو لپاره د ټولو پیښو بیا پیلولو ته اړتیا ده.

پایله

په دې مقاله کې، موږ په ویشل شوي سیسټمونو کې د باور وړ پیغام رسولو لپاره ډیری طریقې بیاکتنه کړې. ډیری سپارښتنې شتون لري چې موږ یې د دې ځانګړتیاوو سره د سیسټمونو جوړولو په وخت کې په پام کې نیسو

1. تل بې کفایته مصرف کونکي رامینځته کړئ ځکه چې د شبکې ناکامي د نه منلو وړ ده.
2. د تضمین اړتیاو په روښانه پوهیدو سره لومړی - محلي - کمیټه - بیا - خپرول په احتیاط سره وکاروئ.
3. هیڅکله د لومړي-خپرولو-بیا-محلي-کمیټ طریقه مه کاروئ ځکه چې دا ممکن ستاسو په سیسټم کې د ډیټا جدي متقابل عمل لامل شي.
4. که چیرې د موجوده ډیټابیس انتخاب پریکړه خورا احتمال ولري بدلون ومومي یا تخنیکي ستراتیژي د ستونزې لپاره د ذخیره کولو غوره حل غوره کولو معنی لري - د ډیټابیس حلونو لکه CDC سره تړلو سره ګډ کتابتونونه مه جوړوئ.
5. لږترلږه یو ځل تضمین ترلاسه کولو لپاره د معیاري حل په توګه د لیږد آوټ بکس طریقه وکاروئ.
6. کله چې د No-SQL ډیټابیسونه ګټه پورته کیږي د ځان سره د اوریدلو طریقې کارولو ته پام وکړئ.

بل ځل، موږ به د لیږد آوټ بکس پلي کولو یو ډیر عملي مثال وګورو. وګورئ

ته!