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

Қосарлы жазу мәселесі Сенімді, жоғары қолжетімді, масштабталатын үлестірілген жүйені құру нақты әдістерді, принциптерді және үлгілерді сақтауды талап етеді. Мұндай жүйелерді жобалау көптеген мәселелерді шешуді қамтиды. Ең кең таралған және негізгі мәселелердің бірі - . қосарлы жазу мәселесі негізінен синхрондауды қажет ететін бірнеше деректер көздерімен немесе дерекқорлармен жұмыс істегенде, таратылған жүйелерде туындайтын қиындық болып табылады. Бұл деректер сәйкессіздіктері, қайшылықтар немесе өнімділік кедергілері сияқты мәселелерді енгізбестен, деректер өзгерістерінің дерекқорлар немесе кэштер сияқты әртүрлі деректер қоймаларына дәйекті түрде жазылуын қамтамасыз ету қиындығын білдіреді. «Қос жазу мәселесі» Микросервистердің архитектурасы және әр қызметке арналған үлгі дерекқоры тәуелсіз орналастыру және масштабтау, оқшауланған сәтсіздіктер және даму жылдамдығының ықтимал артуы сияқты көптеген артықшылықтар береді. Дегенмен, операциялар бірнеше микросервистердің арасында өзгерістерді талап етеді, бұл сізді осы мәселені шешу үшін сенімді шешім туралы ойлауға мәжбүр етеді. Нақты мысал дерлік Біздің домен несиелік өтінімдерді қабылдауды, оларды бағалауды, содан кейін тұтынушыларға ескерту ескертулерін жіберуді қамтитын сценарийді қарастырайық. Бірыңғай жауапкершілік принципі, Конуэй заңы және доменге негізделген дизайн тәсілі рухында, бірнеше оқиғаға қарсы сеанстардан кейін бүкіл домен анық шекаралары, домен үлгілері және барлық жерде қолданылатын тілі бар анықталған шектелген контексттері бар үш ішкі доменге бөлінді. жаңа несиелік өтінімдерді қабылдау және құрастыру тапсырылады. жүйе бұл өтінімдерді бағалайды және берілген деректер негізінде шешім қабылдайды. KYC/KYB, алаяқтыққа қарсы және несиелік тәуекелді тексеруді қоса алғанда, бұл бағалау процесі мыңдаған қосымшаларды бір уақытта өңдеу мүмкіндігін қажет ететін уақытты қажет етуі мүмкін. Демек, бұл функция тәуелсіз масштабтауға мүмкіндік беретін жеке дерекқоры бар арнайы микросервиске берілген. Біріншісіне Екінші Оған қоса, бұл ішкі жүйелерді әрқайсысының жеке шығару циклдері, қызмет деңгейі келісімдері (SLA) және масштабтау талаптары бар екі түрлі топ басқарады. , тұтынушыларға ескертулер жіберу үшін арнайы хабарландыру қызметі бар. Ақырында Мұнда жүйенің негізгі пайдалану жағдайының нақтыланған сипаттамасы берілген: Клиент несиеге өтініш береді. Қарызға өтініш беру қызметі жаңа өтінімді «Күтудегі» күйімен тіркейді және өтінімді бағалау қызметіне жіберу арқылы бағалау процесін бастайды. Бағалау қызметі келіп түскен несиелік өтінімді бағалайды және кейіннен шешім туралы Несиелік өтінімдер қызметіне хабарлайды. Шешімді алғаннан кейін Несиеге өтінім беру қызметі несиеге өтінімнің күйін сәйкесінше жаңартады және клиентті нәтиже туралы хабардар ету үшін Хабарландырулар қызметін іске қосады. Хабарландырулар қызметі осы сұрауды өңдейді және тұтынушыға электрондық пошта, SMS немесе басқа таңдаулы байланыс әдістері арқылы хабарландыруларды тұтынушының параметрлеріне сәйкес жібереді. Бұл бір қарағанда қарапайым және қарапайым жүйе, бірақ несиеге өтінім беру қызметі несиеге өтінім беру пәрменін қалай өңдейтініне тоқталайық. Қызметтік өзара әрекеттесу үшін екі тәсілді қарастыруға болады: Бұл тәсілде қызмет өзінің жергілікті дерекқорын жаңартады (міндеттейді), содан кейін оқиғаны немесе хабарды басқа қызметтерге жариялайды. Бірінші-Жергілікті-Тапсырыс-сосын-Жариялау: Керісінше, бұл әдіс жергілікті дерекқорға өзгертулерді енгізбес бұрын оқиғаны немесе хабарды жариялауды қамтиды. Алдымен-жариялау-сосын-жергілікті-тапсыру: Екі әдістің де кемшіліктері бар және бөлінген жүйелерде байланыс үшін жартылай ғана қауіпсіз. Бұл бірінші тәсілді қолданудың реттілік диаграммасы. Бұл сценарийде несиеге өтінім беру қызметі алдымен транзакцияны орындайтын, содан кейін басқа жүйеге хабарландыру жіберу әрекетін жасайтын тәсілін қолданады. Дегенмен, бұл процесс, мысалы, желі ақаулары болса, бағалау қызметі қолжетімсіз болса немесе несиеге өтініш беру қызметі жад таусылған (OOM) қатесіне тап болса және бұзылса, сәтсіздікке ұшырауы мүмкін. Мұндай жағдайларда хабарлама жоғалып, егер қосымша шаралар орындалмаса, Бағалауды жаңа несие өтінімі туралы ескертусіз қалдырады. Бірінші-Жергілікті-Тапсырыс-Сосын-Жариялау Ал екіншісі. сценарийінде несиеге өтінім беру қызметі маңыздырақ тәуекелдерге тап болады. Ол бағалау қызметіне жаңа қолданба туралы хабарлауы мүмкін, бірақ дерекқор мәселелері, жад қателері немесе код қателері сияқты мәселелерге байланысты бұл жаңартуды жергілікті түрде сақтамауы мүмкін. Бұл тәсіл Кредитті қарау қызметінің кіріс өтінімдерін өңдеу әдісіне байланысты елеулі мәселелер тудыруы мүмкін деректердегі елеулі сәйкессіздіктерге әкелуі мүмкін. Бірінші-жариялау-сосын-жергілікті міндеттеу Сондықтан біз оқиғаларды сыртқы тұтынушыларға жариялаудың сенімді механизмін ұсынатын шешімді анықтауымыз керек. Бірақ, әлеуетті шешімдерді қарастырмас бұрын, алдымен таратылған жүйелерде қол жеткізуге болатын хабарламаларды жеткізу кепілдіктерінің түрлерін нақтылау керек. Хабарламаны жеткізу кепілдігі Біз қол жеткізе алатын кепілдіктердің төрт түрі бар. Кепілдіктер жоқ Хабарламаның межелі жерге жеткізілуіне кепілдік жоқ. тәсілі дәл осыған байланысты. Тұтынушылар хабарламаларды бір рет, бірнеше рет немесе мүлде алуы мүмкін. Алдымен-Жергілікті-Тапсырыс-Сосын-Жариялау Ең көбі бір рет жеткізу Ең көп дегенде бір рет жеткізілуі хабардың межелі жерге ең көбі 1 рет жеткізілетінін білдіреді. тәсілін осы жолмен, сондай-ақ бірінші мәнге ие әрекеттерді қайталау саясатымен іске асыруға болады. Бірінші-Жергілікті-Тапсырыс-Сосын-Жариялау Кем дегенде бір рет жеткізу\Тұтынушылар әрбір хабарламаны алады және өңдейді, бірақ бір хабарды бірнеше рет қабылдай алады. Дәл бір рет жеткізу\Дәл бір рет жеткізу тұтынушының хабарламаны бір рет тиімді қабылдайтынын білдіреді. Техникалық тұрғыдан алғанда, Кафка транзакцияларымен және өндіруші мен тұтынушының нақты идемпотентті іске асыруымен қол жеткізуге болады. Көп жағдайда жеткізу кепілдігі хабарлардың кем дегенде бір рет жеткізілуін қамтамасыз ету арқылы көптеген мәселелерді шешеді, бірақ тұтынушылар идемпотентті болуы керек. Дегенмен, желінің сөзсіз ақауларын ескере отырып, өндірушінің кепілдіктеріне қарамастан, қайталанатын хабарламаларды өңдеуді болдырмау үшін барлық тұтынушылық логика идемпотентті болуы керек. Сондықтан, бұл талап шындықты көрсететін кемшілік емес. «кем дегенде бір рет» Шешімдер Бұл мәселені шешудің көптеген шешімдері бар, олардың артықшылықтары мен кемшіліктері бар. Екі фазалы міндеттеме Википедияға сәйкес, екі фазалық міндеттеме (2PC) - таратылған транзакциялардың дәйектілігі мен сенімділігін қамтамасыз ету үшін информатикада және дерекқорды басқару жүйелерінде қолданылатын бөлінген транзакция протоколы. Ол бірнеше ресурстардың (мысалы, дерекқорлар) бір транзакцияға қатысуы қажет болатын жағдайларға арналған және ол олардың барлығының транзакцияны жасауын немесе барлығының оны тоқтатуын қамтамасыз етеді, осылайша деректер сәйкестігін сақтайды. Бұл бізге қажет сияқты, бірақ екі фазалық міндеттеменің бірнеше кемшіліктері бар: Бір қатысушы ресурс жауап бермей қалса немесе сәтсіздікке ұшыраса, мәселе шешілгенше бүкіл процесті блоктауға болады. Бұл ықтимал өнімділік пен қолжетімділік мәселелеріне әкелуі мүмкін. Екі фазалық міндеттеме кіріктірілген ақауларға төзімділік механизмдерін қамтамасыз етпейді. Ол ақауларды жою үшін сыртқы механизмдерге немесе қолмен араласуға негізделген. Барлық заманауи дерекқорлар екі фазалық тапсырманы қолдамайды. Ортақ деректер базасы Микросервис архитектурасы үшін ең айқын шешім үлгіні (немесе тіпті кейде антипаттернді) қолдану болып табылады - ортақ дерекқор. Әртүрлі дерекқорлардағы бірнеше кестелер бойынша транзакциялық үйлесімділік қажет болса, бұл тәсіл өте интуитивті, осы микросервистерге бір ортақ дерекқорды ғана пайдаланыңыз. Бұл тәсілдің кемшіліктері бір сәтсіздік нүктесін енгізуді, дерекқордың тәуелсіз масштабтауын тежеуді және нақты талаптар мен пайдалану жағдайлары үшін ең қолайлы әртүрлі дерекқор шешімдерін пайдалану мүмкіндігін шектеуді қамтиды. Сонымен қатар, таратылған транзакцияның мұндай түрін қолдау үшін микросервистердің кодтық базаларына өзгертулер енгізу қажет болады. Транзакциялық шығыс жәшігі « » - тіпті сенімсіз хабар алмасу жүйелері жағдайында да хабардың сенімді таралуын қамтамасыз ету үшін таратылған жүйелерде қолданылатын дизайн үлгісі. Ол оқиғаларды операцияның өзі сияқты бір транзакция ішінде тағайындалған «Шығыс оқиғалары» кестесінде сақтауды қамтиды. Бұл тәсіл реляциялық дерекқорлардың ACID қасиеттеріне жақсы сәйкес келеді. Керісінше, көптеген No-SQL дерекқорлары ACID сипаттарын толық қолдамайды, оның орнына қатаң сәйкестіктен гөрі қол жетімділік пен ақырғы келісімділікке басымдық беретін CAP теоремасының және BASE философиясының принциптерін таңдайды. Транзакциялық шығыс жәшігі Транзакциялық шығыс жәшігі береді және оны бірнеше тәсілмен жүзеге асыруға болады: кемінде бір рет кепілдік Транзакция журналының қалдығы Сауалнама жариялаушысы тәсілі 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-ды тұтынушылар болған оқиға туралы шындықтың жалғыз көзі ретінде пайдалана алады. Барлық өзгерістерді немесе тапсырыс беруге қатысты алаңдаушылықтарды қадағалау үшін нақты дерекқор шешімін қажет етпейді, жалғыз мәселе оқу жағында отырады, өйткені нысанның нақты күйін алу үшін барлық оқиғаларды қайталау қажет. Қорытынды Бұл мақалада біз таратылған жүйелерде сенімді хабар алмасуды құрудың бірнеше тәсілдерін қарастырдық. Осы сипаттамаларға ие жүйелерді құру кезінде ескеретін бірнеше ұсыныстар бар Әрқашан идемпотентті тұтынушыларды дамытыңыз, өйткені желінің бұзылуы сөзсіз. Кепілдік талаптарын нақты түсіне отырып мұқият пайдаланыңыз. , Бірінші-Жергілікті-Тапсырыс-Сосын-Жариялауды Ешқашан әдісін қолданбаңыз, себебі ол жүйеңіздегі деректердің қатты сәйкессіздігіне әкелуі мүмкін. «Алғашында жариялау-сосын-жергілікті-тапсыру» Егер бар дерекқорды таңдау шешімі өзгеруі мүмкін болса немесе техникалық стратегия мәселе үшін ең жақсы сақтау шешімін таңдауды білдірсе — сияқты дерекқор шешімдерімен байланыстыру арқылы ортақ кітапханаларды құрмаңыз. CDC Кемінде бір рет кепілдіктерге қол жеткізу үшін стандартты шешім ретінде тәсілін пайдаланыңыз. транзакциялық шығыс жәшігі No-SQL дерекқорлары пайдаланылған кезде әдісін қолдануды қарастырыңыз. «Өзіңді тыңда» Келесі жолы транзакциялық шығыс жәшігін енгізудің практикалық мысалын қарастырамыз. Қараңыз сен!