Таратылған жүйелердегі сенімді хабар алмасу

Қосарлы жазу мәселесі

Сенімді, жоғары қолжетімді, масштабталатын үлестірілген жүйені құру нақты әдістерді, принциптерді және үлгілерді сақтауды талап етеді. Мұндай жүйелерді жобалау көптеген мәселелерді шешуді қамтиды. Ең кең таралған және негізгі мәселелердің бірі - қосарлы жазу мәселесі .

«Қос жазу мәселесі» негізінен синхрондауды қажет ететін бірнеше деректер көздерімен немесе дерекқорлармен жұмыс істегенде, таратылған жүйелерде туындайтын қиындық болып табылады. Бұл деректер сәйкессіздіктері, қайшылықтар немесе өнімділік кедергілері сияқты мәселелерді енгізбестен, деректер өзгерістерінің дерекқорлар немесе кэштер сияқты әртүрлі деректер қоймаларына дәйекті түрде жазылуын қамтамасыз ету қиындығын білдіреді.

Микросервистердің архитектурасы және әр қызметке арналған үлгі дерекқоры тәуелсіз орналастыру және масштабтау, оқшауланған сәтсіздіктер және даму жылдамдығының ықтимал артуы сияқты көптеген артықшылықтар береді. Дегенмен, операциялар бірнеше микросервистердің арасында өзгерістерді талап етеді, бұл сізді осы мәселені шешу үшін сенімді шешім туралы ойлауға мәжбүр етеді.

Нақты мысал дерлік

Біздің домен несиелік өтінімдерді қабылдауды, оларды бағалауды, содан кейін тұтынушыларға ескерту ескертулерін жіберуді қамтитын сценарийді қарастырайық.

Бірыңғай жауапкершілік принципі, Конуэй заңы және доменге негізделген дизайн тәсілі рухында, бірнеше оқиғаға қарсы сеанстардан кейін бүкіл домен анық шекаралары, домен үлгілері және барлық жерде қолданылатын тілі бар анықталған шектелген контексттері бар үш ішкі доменге бөлінді.

Біріншісіне жаңа несиелік өтінімдерді қабылдау және құрастыру тапсырылады. Екінші жүйе бұл өтінімдерді бағалайды және берілген деректер негізінде шешім қабылдайды. KYC/KYB, алаяқтыққа қарсы және несиелік тәуекелді тексеруді қоса алғанда, бұл бағалау процесі мыңдаған қосымшаларды бір уақытта өңдеу мүмкіндігін қажет ететін уақытты қажет етуі мүмкін. Демек, бұл функция тәуелсіз масштабтауға мүмкіндік беретін жеке дерекқоры бар арнайы микросервиске берілген.

Оған қоса, бұл ішкі жүйелерді әрқайсысының жеке шығару циклдері, қызмет деңгейі келісімдері (SLA) және масштабтау талаптары бар екі түрлі топ басқарады.

Ақырында , тұтынушыларға ескертулер жіберу үшін арнайы хабарландыру қызметі бар.

Мұнда жүйенің негізгі пайдалану жағдайының нақтыланған сипаттамасы берілген:

1. Клиент несиеге өтініш береді.
2. Қарызға өтініш беру қызметі жаңа өтінімді «Күтудегі» күйімен тіркейді және өтінімді бағалау қызметіне жіберу арқылы бағалау процесін бастайды.
3. Бағалау қызметі келіп түскен несиелік өтінімді бағалайды және кейіннен шешім туралы Несиелік өтінімдер қызметіне хабарлайды.
4. Шешімді алғаннан кейін Несиеге өтінім беру қызметі несиеге өтінімнің күйін сәйкесінше жаңартады және клиентті нәтиже туралы хабардар ету үшін Хабарландырулар қызметін іске қосады.
5. Хабарландырулар қызметі осы сұрауды өңдейді және тұтынушыға электрондық пошта, SMS немесе басқа таңдаулы байланыс әдістері арқылы хабарландыруларды тұтынушының параметрлеріне сәйкес жібереді.

Бұл бір қарағанда қарапайым және қарапайым жүйе, бірақ несиеге өтінім беру қызметі несиеге өтінім беру пәрменін қалай өңдейтініне тоқталайық.

Қызметтік өзара әрекеттесу үшін екі тәсілді қарастыруға болады:

1. Бірінші-Жергілікті-Тапсырыс-сосын-Жариялау: Бұл тәсілде қызмет өзінің жергілікті дерекқорын жаңартады (міндеттейді), содан кейін оқиғаны немесе хабарды басқа қызметтерге жариялайды.

2. Алдымен-жариялау-сосын-жергілікті-тапсыру: Керісінше, бұл әдіс жергілікті дерекқорға өзгертулерді енгізбес бұрын оқиғаны немесе хабарды жариялауды қамтиды.

   
   

Екі әдістің де кемшіліктері бар және бөлінген жүйелерде байланыс үшін жартылай ғана қауіпсіз.

Бұл бірінші тәсілді қолданудың реттілік диаграммасы.

Бұл сценарийде несиеге өтінім беру қызметі алдымен транзакцияны орындайтын, содан кейін басқа жүйеге хабарландыру жіберу әрекетін жасайтын Бірінші-Жергілікті-Тапсырыс-Сосын-Жариялау тәсілін қолданады. Дегенмен, бұл процесс, мысалы, желі ақаулары болса, бағалау қызметі қолжетімсіз болса немесе несиеге өтініш беру қызметі жад таусылған (OOM) қатесіне тап болса және бұзылса, сәтсіздікке ұшырауы мүмкін. Мұндай жағдайларда хабарлама жоғалып, егер қосымша шаралар орындалмаса, Бағалауды жаңа несие өтінімі туралы ескертусіз қалдырады.

Ал екіншісі.

Бірінші-жариялау-сосын-жергілікті міндеттеу сценарийінде несиеге өтінім беру қызметі маңыздырақ тәуекелдерге тап болады. Ол бағалау қызметіне жаңа қолданба туралы хабарлауы мүмкін, бірақ дерекқор мәселелері, жад қателері немесе код қателері сияқты мәселелерге байланысты бұл жаңартуды жергілікті түрде сақтамауы мүмкін. Бұл тәсіл Кредитті қарау қызметінің кіріс өтінімдерін өңдеу әдісіне байланысты елеулі мәселелер тудыруы мүмкін деректердегі елеулі сәйкессіздіктерге әкелуі мүмкін.

Сондықтан біз оқиғаларды сыртқы тұтынушыларға жариялаудың сенімді механизмін ұсынатын шешімді анықтауымыз керек. Бірақ, әлеуетті шешімдерді қарастырмас бұрын, алдымен таратылған жүйелерде қол жеткізуге болатын хабарламаларды жеткізу кепілдіктерінің түрлерін нақтылау керек.

Хабарламаны жеткізу кепілдігі

Біз қол жеткізе алатын кепілдіктердің төрт түрі бар.

1. Кепілдіктер жоқ
   Хабарламаның межелі жерге жеткізілуіне кепілдік жоқ. Алдымен-Жергілікті-Тапсырыс-Сосын-Жариялау тәсілі дәл осыған байланысты. Тұтынушылар хабарламаларды бір рет, бірнеше рет немесе мүлде алуы мүмкін.

2. Ең көбі бір рет жеткізу
   Ең көп дегенде бір рет жеткізілуі хабардың межелі жерге ең көбі 1 рет жеткізілетінін білдіреді. Бірінші-Жергілікті-Тапсырыс-Сосын-Жариялау тәсілін осы жолмен, сондай-ақ бірінші мәнге ие әрекеттерді қайталау саясатымен іске асыруға болады.

3. Кем дегенде бір рет жеткізу\Тұтынушылар әрбір хабарламаны алады және өңдейді, бірақ бір хабарды бірнеше рет қабылдай алады.

4. Дәл бір рет жеткізу\Дәл бір рет жеткізу тұтынушының хабарламаны бір рет тиімді қабылдайтынын білдіреді.
   Техникалық тұрғыдан алғанда, Кафка транзакцияларымен және өндіруші мен тұтынушының нақты идемпотентті іске асыруымен қол жеткізуге болады.

   
   

Көп жағдайда «кем дегенде бір рет» жеткізу кепілдігі хабарлардың кем дегенде бір рет жеткізілуін қамтамасыз ету арқылы көптеген мәселелерді шешеді, бірақ тұтынушылар идемпотентті болуы керек. Дегенмен, желінің сөзсіз ақауларын ескере отырып, өндірушінің кепілдіктеріне қарамастан, қайталанатын хабарламаларды өңдеуді болдырмау үшін барлық тұтынушылық логика идемпотентті болуы керек. Сондықтан, бұл талап шындықты көрсететін кемшілік емес.

Шешімдер

Бұл мәселені шешудің көптеген шешімдері бар, олардың артықшылықтары мен кемшіліктері бар.

Екі фазалы міндеттеме

Википедияға сәйкес, екі фазалық міндеттеме (2PC) - таратылған транзакциялардың дәйектілігі мен сенімділігін қамтамасыз ету үшін информатикада және дерекқорды басқару жүйелерінде қолданылатын бөлінген транзакция протоколы. Ол бірнеше ресурстардың (мысалы, дерекқорлар) бір транзакцияға қатысуы қажет болатын жағдайларға арналған және ол олардың барлығының транзакцияны жасауын немесе барлығының оны тоқтатуын қамтамасыз етеді, осылайша деректер сәйкестігін сақтайды. Бұл бізге қажет сияқты, бірақ екі фазалық міндеттеменің бірнеше кемшіліктері бар:

• Бір қатысушы ресурс жауап бермей қалса немесе сәтсіздікке ұшыраса, мәселе шешілгенше бүкіл процесті блоктауға болады. Бұл ықтимал өнімділік пен қолжетімділік мәселелеріне әкелуі мүмкін.
• Екі фазалық міндеттеме кіріктірілген ақауларға төзімділік механизмдерін қамтамасыз етпейді. Ол ақауларды жою үшін сыртқы механизмдерге немесе қолмен араласуға негізделген.
• Барлық заманауи дерекқорлар екі фазалық тапсырманы қолдамайды.

Ортақ деректер базасы

Микросервис архитектурасы үшін ең айқын шешім үлгіні (немесе тіпті кейде антипаттернді) қолдану болып табылады - ортақ дерекқор. Әртүрлі дерекқорлардағы бірнеше кестелер бойынша транзакциялық үйлесімділік қажет болса, бұл тәсіл өте интуитивті, осы микросервистерге бір ортақ дерекқорды ғана пайдаланыңыз.

Бұл тәсілдің кемшіліктері бір сәтсіздік нүктесін енгізуді, дерекқордың тәуелсіз масштабтауын тежеуді және нақты талаптар мен пайдалану жағдайлары үшін ең қолайлы әртүрлі дерекқор шешімдерін пайдалану мүмкіндігін шектеуді қамтиды. Сонымен қатар, таратылған транзакцияның мұндай түрін қолдау үшін микросервистердің кодтық базаларына өзгертулер енгізу қажет болады.

Транзакциялық шығыс жәшігі

« Транзакциялық шығыс жәшігі » - тіпті сенімсіз хабар алмасу жүйелері жағдайында да хабардың сенімді таралуын қамтамасыз ету үшін таратылған жүйелерде қолданылатын дизайн үлгісі. Ол оқиғаларды операцияның өзі сияқты бір транзакция ішінде тағайындалған «Шығыс оқиғалары» кестесінде сақтауды қамтиды. Бұл тәсіл реляциялық дерекқорлардың ACID қасиеттеріне жақсы сәйкес келеді. Керісінше, көптеген No-SQL дерекқорлары ACID сипаттарын толық қолдамайды, оның орнына қатаң сәйкестіктен гөрі қол жетімділік пен ақырғы келісімділікке басымдық беретін CAP теоремасының және BASE философиясының принциптерін таңдайды.

Транзакциялық шығыс жәшігі кемінде бір рет кепілдік береді және оны бірнеше тәсілмен жүзеге асыруға болады:

1. Транзакция журналының қалдығы

2. Сауалнама жариялаушысы

   
   

Транзакция журналын қалдыру тәсілі CDC (Деректерді түсіруді өзгерту) сияқты дерекқорға тән шешімдерді пайдалануды білдіреді. Бұл тәсілдің негізгі кемшіліктері:

• Мәліметтер қорының арнайы шешімдері

• CDC енгізу ерекшеліктеріне байланысты кідірістің артуы

  
  

Басқа әдіс - шығыс жәшігінің кестесін сұрау арқылы шығыс жәшігін түсіруді жеңілдететін сұрау жариялаушысы . Бұл тәсілдің негізгі кемшілігі - жоғары шығындарға әкелуі мүмкін дерекқор жүктемесінің жоғарылау мүмкіндігі. Сонымен қатар, барлық No-SQL дерекқорлары нақты құжат сегменттері үшін тиімді сұрауды қолдамайды. Бүкіл құжаттарды шығарып алу өнімділіктің төмендеуіне әкелуі мүмкін.

Мұнда оның қалай жұмыс істейтінін түсіндіретін шағын реттілік диаграммасы берілген.

Өзіңізді тыңдаңыз

Транзакциялық шығыс жәшігі үлгісімен негізгі қиындық оның дерекқор 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-ды тұтынушылар болған оқиға туралы шындықтың жалғыз көзі ретінде пайдалана алады. Барлық өзгерістерді немесе тапсырыс беруге қатысты алаңдаушылықтарды қадағалау үшін нақты дерекқор шешімін қажет етпейді, жалғыз мәселе оқу жағында отырады, өйткені нысанның нақты күйін алу үшін барлық оқиғаларды қайталау қажет.

Қорытынды

Бұл мақалада біз таратылған жүйелерде сенімді хабар алмасуды құрудың бірнеше тәсілдерін қарастырдық. Осы сипаттамаларға ие жүйелерді құру кезінде ескеретін бірнеше ұсыныстар бар

1. Әрқашан идемпотентті тұтынушыларды дамытыңыз, өйткені желінің бұзылуы сөзсіз.
2. Кепілдік талаптарын нақты түсіне отырып , Бірінші-Жергілікті-Тапсырыс-Сосын-Жариялауды мұқият пайдаланыңыз.
3. Ешқашан «Алғашында жариялау-сосын-жергілікті-тапсыру» әдісін қолданбаңыз, себебі ол жүйеңіздегі деректердің қатты сәйкессіздігіне әкелуі мүмкін.
4. Егер бар дерекқорды таңдау шешімі өзгеруі мүмкін болса немесе техникалық стратегия мәселе үшін ең жақсы сақтау шешімін таңдауды білдірсе — CDC сияқты дерекқор шешімдерімен байланыстыру арқылы ортақ кітапханаларды құрмаңыз.
5. Кемінде бір рет кепілдіктерге қол жеткізу үшін стандартты шешім ретінде транзакциялық шығыс жәшігі тәсілін пайдаланыңыз.
6. No-SQL дерекқорлары пайдаланылған кезде «Өзіңді тыңда» әдісін қолдануды қарастырыңыз.

Келесі жолы транзакциялық шығыс жәшігін енгізудің практикалық мысалын қарастырамыз. Қараңыз

сен!