Сигурно испраќање пораки во дистрибуирани системи

Проблем со двојно пишување Изградбата на доверлив, високо достапен, скалабилен дистрибуиран систем бара придржување до специфични техники, принципи и модели. Дизајнот на таквите системи вклучува решавање на огромен број предизвици. Меѓу најраспространетите и најосновните прашања е . проблемот со двојното пишување е предизвик што се јавува во дистрибуираните системи, главно кога се работи со повеќе извори на податоци или бази на податоци кои треба да се чуваат синхронизирани. Тоа се однесува на тешкотијата да се осигури дека промените на податоците постојано се запишуваат во различни складишта на податоци, како што се бази на податоци или кешови, без да се воведуваат прашања како што се недоследности на податоците, конфликти или тесни грла во изведбата. „Проблемот со двојно пишување“ Архитектурата на микросервисите и базата на податоци за модели по услуга ви носи многу придобивки, како што се независно распоредување и скалирање, изолирани неуспеси и потенцијално зголемување на брзината на развој. Сепак, операциите бараат промени меѓу повеќе микросервиси, принудувајќи ве да размислите за сигурно решение за да се справите со овој проблем. Речиси вистински пример Ајде да разгледаме сценарио во кое нашиот домен вклучува прифаќање апликации за заем, нивно оценување и потоа испраќање известувања за известување до клиентите. Во духот на принципот на единствена одговорност, законот на Конвеј и пристапот на дизајн управуван од доменот, по неколку сесии со бура од настани, целиот домен беше поделен на три поддомени со дефинирани ограничени контексти со јасни граници, модели на домени и сеприсутен јазик. има задача да вклучува и составува нови апликации за заем. систем ги оценува овие апликации и донесува одлуки врз основа на дадените податоци. Овој процес на проценка, вклучувајќи ги проверките на KYC/KYB, антиизмама и кредитен ризик, може да одземе многу време, поради што е потребна способност за ракување со илјадници апликации истовремено. Следствено, оваа функционалност е делегирана на посветен микросервис со своја база на податоци, што овозможува независно скалирање. Првиот Вториот Понатаму, овие потсистеми се управувани од два различни тима, секој со свои циклуси на издавање, договори за ниво на услуги (SLA) и барања за приспособливост. , постои специјализирана услуга за известување за испраќање предупредувања до клиентите. И на крај Еве префинет опис на примарната употреба на системот: Клиентот поднесува барање за заем. Службата за аплицирање за заем ја евидентира новата апликација со статус „Во тек“ и го започнува процесот на проценка со проследување на апликацијата до Службата за проценка. Службата за проценка ја оценува пристигнатата апликација за заем и последователно ја известува Службата за аплицирање за заем за одлуката. По добивањето на одлуката, Услугата за апликација за заем соодветно го ажурира статусот на апликацијата за заем и ја активира службата за известувања да го информира клиентот за исходот. Услугата за известувања го обработува ова барање и испраќа известувања до клиентот преку е-пошта, СМС или други претпочитани методи на комуникација, во согласност со поставките на клиентот. Тоа е прилично едноставен и примитивен систем на прв поглед, но ајде да се нурнеме во тоа како услугата за апликација за заем ја обработува командата за поднесување апликација за заем. Можеме да разгледаме два пристапи за интеракции со услуги: Во овој пристап, услугата ја ажурира својата локална база на податоци (обврзува) и потоа објавува настан или порака до други услуги. First-Local-Commit-Then-Publish: обратно, овој метод вклучува објавување на настан или порака пред да се извршат промените во локалната база на податоци. First-Publish-Then-Local-Commit: И двата методи имаат свои недостатоци и се само делумно безбедни за неуспех за комуникација во дистрибуирани системи. Ова е низа дијаграм на примена на првиот пристап. Во ова сценарио, Услугата за апликација за заем го користи пристапот , каде што прво извршува трансакција, а потоа се обидува да испрати известување до друг систем. Сепак, овој процес е подложен на неуспех ако, на пример, има проблеми со мрежата, Услугата за проценка е недостапна или услугата за апликација за заем наиде на грешка без меморија (OOM) и се урна. Во такви случаи, пораката би се изгубила, оставајќи ја Проценката без известување за новото барање за заем, освен ако не се спроведат дополнителни мерки. First-Local-Commit-Then-Publish И вториот. Во сценариото , Услугата за аплицирање за заем се соочува со позначајни ризици. Може да ја информира службата за проценка за нова апликација, но нема да успее да го зачува ова ажурирање локално поради проблеми како што се проблеми со базата на податоци, грешки во меморијата или грешки во кодот. Овој пристап може да доведе до значителни недоследности во податоците, што може да предизвика сериозни проблеми, во зависност од тоа како Службата за преглед на заеми се справува со дојдовните апликации. „Прво објавување, потоа локално, обврзување“ Затоа, мора да идентификуваме решение кое нуди робустен механизам за објавување настани на надворешни потрошувачи. Но, пред да истражуваме во потенцијалните решенија, прво треба да ги разјасниме видовите гаранции за испорака на пораки што може да се постигнат во дистрибуираните системи. Гаранции за испорака на пораки Постојат четири типа на гаранции што би можеле да ги постигнеме. Нема гаранции Нема гаранција дека пораката ќе биде доставена до дестинацијата. Пристапот е токму за ова. Потрошувачите може да примаат пораки еднаш, повеќе пати или воопшто никогаш. First-Local-Commit-Pas-Publish Најмногу еднаш испорака Доставувањето најмногу еднаш значи дека пораката ќе биде доставена до дестинацијата најмногу 1 пат. Пристапот може да се имплементира и на овој начин со политиката за повторно обиди за обиди со вредност еден. First-Local-Commit-Then-Publish Барем еднаш испорака\Потрошувачите ќе ја примат и обработат секоја порака, но може да ја добијат истата порака повеќе од еднаш. Точно еднаш испорака\Токму еднаш испорака значи дека потрошувачот ќе ја прими пораката ефективно еднаш. Технички, тоа е можно да се постигне со трансакции на Кафка и специфична идемпотентна имплементација на производителот и потрошувачот. Во повеќето случаи, гаранциите за испорака се справуваат со многу прашања со тоа што ќе се осигураат дека пораките се испорачуваат барем еднаш, но потрошувачите мора да бидат немоќни. Меѓутоа, со оглед на неизбежните мрежни дефекти, целата логика на потрошувачите мора да биде немоќна за да се избегне обработка на дупликат пораки, без оглед на гаранциите на производителот. Затоа, ова барање не е толку недостаток колку што ја одразува реалноста. „барем еднаш“ Решенија Има многу решенија за овој проблем, кои имаат свои предности и недостатоци. Двофазно извршување Според Википедија, обврзувањето со две фази (2PC) е протокол за дистрибуирана трансакција што се користи во компјутерските науки и системите за управување со бази на податоци за да се обезбеди конзистентност и доверливост на дистрибуираните трансакции. Дизајниран е за ситуации каде што повеќе ресурси (на пример, бази на податоци) треба да учествуваат во една трансакција и осигурува дека или сите ќе ја извршат трансакцијата или сите ја прекинуваат, со што се одржува конзистентноста на податоците. Звучи токму она што ни треба, но Двофазното извршување има неколку недостатоци: Ако еден ресурс што учествува не реагира или доживее неуспех, целиот процес може да се блокира додека не се реши проблемот. Ова може да доведе до потенцијални проблеми со перформансите и достапноста. Двофазното извршување не обезбедува вградени механизми за толеранција на грешки. Се потпира на надворешни механизми или рачна интервенција за справување со неуспесите. Не сите модерни бази на податоци поддржуваат обврзување со две фази. Заедничка база на податоци Најочигледното решение за архитектурата на микросервисите е да се примени шема (или понекогаш и анти-шаблон) - споделена база на податоци. Овој пристап е многу интуитивен ако ви треба трансакциска конзистентност низ повеќе табели во различни бази на податоци, само користете една споделена база на податоци за овие микроуслуги. Недостатоците на овој пристап вклучуваат воведување единствена точка на неуспех, инхибиција на независното скалирање на базата на податоци и ограничување на способноста за користење на различни решенија за бази на податоци кои се најпогодни за специфични барања и случаи на употреба. Дополнително, модификациите на базите на кодови на микроуслугите би биле неопходни за поддршка на таков облик на дистрибуирана трансакција. Трансакциско појдовно сандаче „ “ е дизајн шема што се користи во дистрибуирани системи за да се обезбеди сигурно ширење на пораките, дури и во услови на несигурни системи за пораки. Тоа вклучува складирање на настани во одредена табела „OutboxEvents“ во рамките на истата трансакција како и самата операција. Овој пристап добро се усогласува со ACID својствата на релационите бази на податоци. Спротивно на тоа, многу No-SQL бази на податоци не поддржуваат целосно ACID својства, наместо тоа се определуваат за принципите на теоремата CAP и филозофијата BASE, кои даваат приоритет на достапноста и евентуалната конзистентност пред строгата конзистентност. Трансакциското појдовно сандаче Трансакциското појдовно сандаче обезбедува и може да се имплементира со неколку пристапи: барем еднаш гаранција Јаловина на дневникот на трансакции Издавач на анкети Пристапот подразбира користење решенија специфични за базата на податоци како CDC (Change Data Capture). Главните недостатоци на тој пристап се: за пополнување на евиденцијата на трансакции Специфични решенија за бази на податоци Зголемена латентност поради спецификите на имплементацијата на ЦДЦ Друг метод е , кој го олеснува истоварувањето на појдовното сандаче со анкетирање на табелата за излезни сандачиња. Примарниот недостаток на овој пристап е потенцијалот за зголемено оптоварување на базата на податоци, што може да доведе до повисоки трошоци. Понатаму, не сите No-SQL бази на податоци поддржуваат ефикасно барање за одредени сегменти на документи. Оттука, вадењето цели документи може да резултира со влошување на перформансите. Polling Publisher Еве мал дијаграм со низа што објаснува како функционира. Слушајте се себеси Примарниот предизвик со моделот на трансакциско појдовно сандаче лежи во неговата зависност од својствата на ACID на базата на податоци. Тоа може да биде едноставно во типични OLTP бази на податоци, но претставува предизвици во областа NoSQL. За да се реши ова, потенцијално решение е да се искористи дневникот за додатоци (на пример, Кафка) веднаш од започнувањето на обработката на барањата. Наместо директно да ја обработуваме командата „поднеси барање за заем“, веднаш ја испраќаме на внатрешна тема на Кафка и потоа му враќаме „прифатен“ резултат на клиентот. Сепак, бидејќи е голема веројатноста дека командата сè уште треба да се обработи, не можеме веднаш да го информираме клиентот за резултатот. За да управуваме со оваа евентуална конзистентност, можеме да користиме техники како што се долги анкети, анкети иницирани од клиент, оптимистички ажурирања на интерфејсот или користење на 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 може да се користи од потрошувачите како единствен извор на вистината за тоа што се случило. Нема потреба од специфично решение за базата на податоци за следење на сите промени или грижи за нарачката, единствениот проблем е да седи на страната за читање бидејќи за да може да се добие вистинската состојба на ентитетот потребно е да се репродуцираат сите настани. Заклучок Во оваа статија, разгледавме неколку пристапи за градење доверливи пораки во дистрибуирани системи. Постојат неколку препораки што би можеле да ги земеме во предвид додека градиме системи со овие карактеристики Секогаш развивајте немоќни потрошувачи бидејќи неуспехот на мрежата е неизбежен. Внимателно користете со јасно разбирање на барањата за гаранција. го First-Local-Commit-Then-Publish Никогаш не користете го пристапот бидејќи тоа може да доведе до сериозна недоследност на податоците во вашиот систем. Прво објавување-потоа-локално обврзување Ако одлуката за избор на постоечка база на податоци многу веројатно може да се промени или техничката стратегија подразбира да се избере најдоброто решение за складирање на проблемот - немојте да градите споделени библиотеки со поврзување со решенија за бази на податоци како . CDC Користете го пристапот како стандардно решение за постигнување барем еднаш гаранции. на трансакциско излезно сандаче Размислете за користење на пристапот кога се користат бази на податоци No-SQL. „Слушај се себеси“ Следниот пат, ќе погледнеме попрактичен пример за имплементација на Трансакциско излезно сандаче. Види ти!