Бөлүштүрүлгөн системаларда ишенимдүү билдирүү

Кош жазуу көйгөйү Ишенимдүү, жеткиликтүү, масштабдуу бөлүштүрүлгөн системаны түзүү белгилүү бир ыкмаларды, принциптерди жана үлгүлөрдү сактоону талап кылат. Мындай системаларды долбоорлоо көптөгөн көйгөйлөрдү чечүүнү камтыйт. Эң кеңири таралган жана негизги маселелердин арасында бар. кош жазуу маселеси бөлүштүрүлгөн системаларда, негизинен, синхрондоштурууну талап кылган бир нече маалымат булактары же маалымат базалары менен иштөөдө пайда болгон көйгөй. Бул маалыматтардын ырааттуулугу, карама-каршылыктары же иштешине тоскоолдуктар сыяктуу маселелерди киргизбестен, маалыматтар базасына же кэштерге маалыматтарды өзгөртүүлөр ырааттуу түрдө жазылышын камсыз кылуу кыйынчылыгын билдирет. "Кош жазуу көйгөйү" Микросервистердин архитектурасы жана ар бир кызматтын үлгүлөрүнүн маалымат базасы сизге көз карандысыз жайылтуу жана масштабдоо, обочолонгон каталар жана өнүгүү ылдамдыгынын потенциалдуу өсүшү сыяктуу көптөгөн артыкчылыктарды алып келет. Бирок, операциялар бир нече микросервистердин арасында өзгөрүүлөрдү талап кылат, бул көйгөйдү чечүү үчүн ишенимдүү чечим жөнүндө ойлонууга мажбурлайт. Дээрлик реалдуу мисал Келгиле, биздин домен кредиттик арыздарды кабыл алууну, аларды баалоону жана андан кийин кардарларга эскертме эскертүүлөрүн жөнөтүүнү камтыган сценарийди карап көрөлү. Бирдиктүү жоопкерчилик принцибинин, Конвей мыйзамынын жана доменге негизделген дизайн мамилесинин духунда, бир нече окуя-штурмандык сессиялардан кийин бүт домен үч субдоменге бөлүнгөн, так чектери, домен моделдери жана бардык жерде колдонулуучу тилге ээ болгон аныкталган чектелген контексттери бар. , жаңы кредиттик арыздарды кабыл алуу жана түзүү тапшырмасы. система бул арыздарды баалайт жана берилген маалыматтардын негизинде чечим кабыл алат. Бул баалоо процесси, анын ичинде KYC/KYB, алдамчылыкка каршы жана кредиттик тобокелдиктерди текшерүү көп убакытты талап кылышы мүмкүн, бул бир эле учурда миңдеген тиркемелерди иштетүү мүмкүнчүлүгүн талап кылат. Демек, бул функция өздүк маалымат базасы бар атайын микросервиске өткөрүлүп берилген, бул көз карандысыз масштабга мүмкүнчүлүк берет. Биринчиси Экинчи Андан тышкары, бул подсистемаларды эки башка команда башкарат, алардын ар бири өзүнүн релиз циклдери, тейлөө деңгээлинин макулдашуулары (SLA) жана масштабдуулук талаптары бар. , кардарларга эскертүүлөрдү жөнөтүү үчүн атайын кабарлоо кызматы бар. Акырында Бул жерде системанын негизги колдонуу учурунун такталган сүрөттөлүшү: Кардар насыя алуу үчүн арыз берет. Насыяга арыз берүү кызматы жаңы арызды "Күтүүдө" статусу менен жазып алат жана арызды Баалоо кызматына жөнөтүү аркылуу баалоо процессин баштайт. Баалоо кызматы келип түшкөн кредиттик өтүнмөнү баалайт жана андан кийин чечим жөнүндө Кредиттик өтүнмө боюнча кызматка кабарлайт. Чечимди алгандан кийин Насыяга арыз берүү кызматы кредитке өтүнмөнүн статусун жаңыртат жана Кардарга натыйжа жөнүндө кабарлоо үчүн Кабарлоо кызматын ишке киргизет. Кабарлоо кызматы бул суроону иштеп чыгат жана кардардын жөндөөлөрүнө ылайык электрондук почта, SMS же башка артыкчылыктуу байланыш ыкмалары аркылуу кардарга эскертмелерди жөнөтөт. Бул бир караганда абдан жөнөкөй жана примитивдүү система, бирок келгиле, Насыяга арыз берүү кызматы насыяга арыз тапшыруу буйругун кантип иштетээрин карап көрөлү. Кызматтын өз ара аракеттенүүсү үчүн биз эки ыкманы карап чыгабыз: Бул ыкмада кызмат жергиликтүү маалымат базасын жаңыртат (милдеттендирет), андан кийин окуяны же билдирүүнү башка кызматтарга жарыялайт. Адегенде-Жергиликтүү-милдеттүү-анан-жарыялоо: Тескерисинче, бул ыкма жергиликтүү маалымат базасына өзгөртүүлөрдү киргизүүдөн мурун окуяны же билдирүүнү жарыялоону камтыйт. Биринчи-Жарыялоо-Андан-Жергиликтүү-милдеттүү: Эки ыкманын тең кемчиликтери бар жана бөлүштүрүлгөн системаларда байланыш үчүн жарым-жартылай гана коопсуз. Бул биринчи ыкманы колдонуунун ырааттуу диаграммасы. Бул сценарийде Насыяга арыз берүү кызматы ыкмасын колдонот, мында ал адегенде транзакцияны жасап, андан кийин башка системага билдирүү жөнөтүүгө аракет кылат. Бирок, бул процесс, мисалы, тармак көйгөйлөрү бар болсо, Баалоо кызматы жеткиликсиз болсо, же Насыяга арыз берүү кызматы эстутумда (OOM) катага туш болуп, иштебей калышы мүмкүн. Мындай учурларда, кошумча чаралар көрүлбөсө, Баалоо жаңы кредиттик өтүнмөнү эскертүүсүз калтырып, билдирүү жоголот. Биринчи-Жергиликтүү-милдеттүү-Андан кийин-Жарыялоо Ал эми экинчиси. сценарийинде, Насыяга арыз берүү кызматы олуттуу тобокелчиликтерге дуушар болот. Ал жаңы тиркеме тууралуу Баалоо кызматына кабарлашы мүмкүн, бирок маалымат базасынын көйгөйлөрү, эстутум каталары же код мүчүлүштүктөрү сыяктуу көйгөйлөрдөн улам бул жаңыртууну жергиликтүү түрдө сактай албайт. Бул ыкма Кредиттерди карап чыгуу кызматы келген арыздарды кантип иштетээрине жараша олуттуу көйгөйлөрдү жаратышы мүмкүн болгон маалыматтардагы олуттуу дал келбестикке алып келиши мүмкүн. Биринчи-Жарыялоо-Анан-Жергиликтүү-милдеттүү Ошондуктан, биз тышкы керектөөчүлөргө окуяларды жарыялоо үчүн күчтүү механизмди сунуштай турган чечимди аныкташыбыз керек. Бирок, потенциалдуу чечимдерди изилдөөдөн мурун, биз таралган системаларда жетүүгө мүмкүн болгон билдирүүлөрдү жеткирүү кепилдиктеринин түрлөрүн такташыбыз керек. Кабарды жеткирүү кепилдиктери Биз жете турган кепилдиктердин төрт түрү бар. Эч кандай кепилдик жок Билдирүүнүн көздөгөн жерине жеткирилерине кепилдик жок. ыкмасы так ушул жөнүндө. Керектөөчүлөр билдирүүлөрдү бир, бир нече жолу же такыр кабыл ала алышат. Биринчи-Жергиликтүү-Комитет-Андан-Жарыялоо Эң көп дегенде бир жолу жеткирүү Эң көп дегенде бир жолу жеткирүү билдирүү көздөгөн жерге эң көп 1 жолу жеткирилет дегенди билдирет. ыкмасын ушундай жол менен, ошондой эле бир мааниге ээ болгон аракеттерди кайталап көрүү саясаты менен ишке ашырууга болот. Биринчи-Жергиликтүү-милдеттүү-Андан-Жарыялоо Жок дегенде бир жолу жеткирүү\Керектөөчүлөр ар бир билдирүүнү кабыл алышат жана иштетишет, бирок бир эле билдирүүнү бир нече жолу кабыл алышы мүмкүн. Так бир жолу жеткирүү\Так жолу жеткирүү керектөөчү билдирүүнү бир жолу эффективдүү кабыл алат дегенди билдирет. Техникалык жактан алганда, Кафка транзакциялары жана өндүрүүчүнүн жана керектөөчүнүн конкреттүү идемпотенттүү ишке ашыруусу менен жетишүүгө болот. Көпчүлүк учурларда, жеткирүү кепилдиги билдирүүлөрдүн жок дегенде бир жолу жеткирилишин камсыз кылуу менен көптөгөн маселелерди чечет, бирок керектөөчүлөр идемпотенттүү болушу керек. Бирок, кутулбогон тармак каталарын эске алуу менен, бардык керектөөчүнүн логикасы өндүрүүчүнүн кепилдиктерине карабастан, кайталанма билдирүүлөрдү иштетүүнү болтурбоо үчүн идемпотенттүү болушу керек. Демек, бул талап өтө эле кемчилик эмес, чындыкты чагылдырат. "жок дегенде бир жолу" Чечимдер Бул көйгөйдү чечүүнүн көптөгөн жолдору бар, алардын артыкчылыктары жана кемчиликтери бар. Эки фазалуу милдеттенме Wikipedia ылайык, эки фазалуу Commit (2PC) бөлүштүрүлгөн транзакциялардын ырааттуулугун жана ишенимдүүлүгүн камсыз кылуу үчүн информатика жана маалымат базасын башкаруу системаларында колдонулган бөлүштүрүлгөн транзакция протоколу. Ал бир нече ресурстар (мисалы, маалымат базалары) бир транзакцияга катышуусу керек болгон жагдайлар үчүн иштелип чыккан жана алардын бардыгы транзакцияны жасашын же анын баарын токтотуп, ошону менен берилиштердин ырааттуулугун сактайт. Бул так бизге керек угулат, бирок эки фазалуу Commit бир нече кемчиликтери бар: Катышуучу ресурстун бири жооп бербесе же катачылыкка дуушар болсо, маселе чечилмейинче бүт процессти бөгөттөп коюуга болот. Бул мүмкүн болгон аткаруу жана жеткиликтүүлүк көйгөйлөрүнө алып келиши мүмкүн. Эки фазалуу Commit орнотулган катага чыдамдуу механизмдерди камсыз кылбайт. Ал кемчиликтерди чечүү үчүн тышкы механизмдерге же кол менен кийлигишүүгө таянат. Бардык заманбап маалымат базалары эки фазалуу Commitти колдой бербейт. Жалпы маалымат базасы Микросервистердин архитектурасы үчүн эң көрүнүктүү чечим - бул үлгүнү (же кээде анти-үлгү) колдонуу - жалпы маалымат базасы. Бул ыкма абдан интуитивдүү, эгерде сизге ар кандай маалымат базаларындагы бир нече таблицаларда транзакциялык ырааттуулук керек болсо, бул микросервистер үчүн бир эле жалпы маалымат базасын колдонуңуз. Бул ыкманын кемчиликтери болуп, бир эле иштебей калган чекитти киргизүү, маалымат базасынын көз карандысыз масштабын чектөө жана белгилүү бир талаптарга жана колдонуу учурларына эң ылайыктуу болгон ар кандай маалымат базасынын чечимдерин колдонуу мүмкүнчүлүгүн чектөө кирет. Кошумчалай кетсек, бөлүштүрүлгөн транзакциянын мындай формасын колдоо үчүн микросервистердин код базасына өзгөртүүлөрдү киргизүү зарыл. Транзакциянын чыгыш кутусу " " - бул ишенимсиз билдирүү тутумдарына карабастан, билдирүүнүн ишенимдүү таралышын камсыз кылуу үчүн бөлүштүрүлгөн системаларда колдонулган дизайн үлгүсү. Ал окуяларды операциянын өзү сыяктуу эле транзакциянын ичинде дайындалган "OutboxEvents" таблицасында сактоону камтыйт. Бул ыкма реляциялык маалымат базаларынын ACID касиеттери менен жакшы шайкеш келет. Ал эми көптөгөн No-SQL маалымат базалары ACID касиеттерин толук колдобойт, анын ордуна CAP теоремасынын жана BASE философиясынын принциптерин тандашат, алар жеткиликтүүлүктү жана ырааттуулукту катуу ырааттуулукка артыкчылык беришет. Транзакциялык чыгуучу куту Транзакциянын чыгыш кутусу берет жана бир нече ыкмалар менен ишке ашырылышы мүмкүн: жок дегенде бир жолу кепилдик Транзакциялар журналынын калдыктары Сурамжылоонун жарыялоочусу ыкмасы CDC (Change Data Capture) сыяктуу маалымат базасына тиешелүү чечимдерди колдонууну билдирет. Бул ыкманын негизги кемчиликтери болуп төмөнкүлөр саналат: Транзакциялар журналынын калдыктарын сактоо Берилиштер базасы үчүн атайын чечимдер CDC ишке ашыруунун өзгөчөлүктөрүнөн улам көбөйгөн кечигүү Дагы бир ыкма - , ал чыгуучу каттын таблицасын сурамжылоо аркылуу чыгуучу каттарды түшүрүүнү жеңилдетет. Бул ыкманын негизги жетишпеген жагы - бул маалымат базасынын жүгүн көбөйтүү, бул жогорку чыгымдарга алып келиши мүмкүн. Андан тышкары, бардык No-SQL маалымат базалары белгилүү бир документ сегменттери үчүн эффективдүү суроону колдой бербейт. Ошентип, документтерди толугу менен чыгарып алуу, иштин начарлашына алып келиши мүмкүн. Сурамжылоо Жарыялоочусу Бул жерде анын кантип иштээрин түшүндүргөн кичинекей ырааттуулук диаграммасы. Өзүңдү ук Transaction Outbox үлгүсүндөгү негизги көйгөй анын маалымат базасынын ACID касиеттерине көз карандылыгында. Бул типтүү OLTP маалымат базаларында жөнөкөй болушу мүмкүн, бирок NoSQL чөйрөсүндө кыйынчылыктарды жаратат. Муну чечүү үчүн, мүмкүн болгон чечим - өтүнүчтү иштетүүнү баштоодон баштап эле тиркеме журналын (мисалы, Кафка) колдонуу. "Кредитке арыз тапшыруу" буйругун түздөн-түз иштетүүнүн ордуна, биз аны дароо Кафканын ички темасына жөнөтөбүз жана андан кийин кардарга "кабыл алынган" жыйынтыкты кайтарабыз. Бирок, буйруктун дагы эле иштетилиши керек болушу ыктымал болгондуктан, биз кардарга натыйжа жөнүндө дароо кабарлай албайбыз. Бул ырааттуулукту башкаруу үчүн биз узакка созулган сурамжылоо, кардар тарабынан демилгеленген сурамжылоо, оптимисттик UI жаңыртуулары же WebSockets же Server-Sent Events билдирүүлөр үчүн колдонуу сыяктуу ыкмаларды колдоно алабыз. Бирок, бул таптакыр өзүнчө тема, андыктан, келгиле, баштапкы темабызга кайрылалы. Биз кабарды ички Кафка темасына жөнөттүк. Андан кийин Насыяга арыз берүү кызматы бул билдирүүнү - кардардан алган буйрукту - жалмап, иштеп баштайт. Биринчиден, ал кээ бир бизнес логикасын аткарат; Бул логика ийгиликтүү аткарылып, натыйжалар сакталгандан кийин гана, ал коомдук Кафка темасында жаңы билдирүүлөрдү жарыялайт. Келгиле, бир аз псевдокодду карап көрөлү. 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 маалымат базалары иштетилгенде ыкмасын колдонууну карап көрүңүз. , өзүңүздү угуңуз Кийинки жолу транзакциялык чыгуу кутусун ишке ашыруунун практикалык мисалын карап чыгабыз. Караңыз сен!