Кош жазуу көйгөйү
Ишенимдүү, жеткиликтүү, масштабдуу бөлүштүрүлгөн системаны түзүү белгилүү бир ыкмаларды, принциптерди жана үлгүлөрдү сактоону талап кылат. Мындай системаларды долбоорлоо көптөгөн көйгөйлөрдү чечүүнү камтыйт. Эң кеңири таралган жана негизги маселелердин арасында кош жазуу маселеси бар.
"Кош жазуу көйгөйү" бөлүштүрүлгөн системаларда, негизинен, синхрондоштурууну талап кылган бир нече маалымат булактары же маалымат базалары менен иштөөдө пайда болгон көйгөй. Бул маалыматтардын ырааттуулугу, карама-каршылыктары же иштешине тоскоолдуктар сыяктуу маселелерди киргизбестен, маалыматтар базасына же кэштерге маалыматтарды өзгөртүүлөр ырааттуу түрдө жазылышын камсыз кылуу кыйынчылыгын билдирет.
Микросервистердин архитектурасы жана ар бир кызматтын үлгүлөрүнүн маалымат базасы сизге көз карандысыз жайылтуу жана масштабдоо, обочолонгон каталар жана өнүгүү ылдамдыгынын потенциалдуу өсүшү сыяктуу көптөгөн артыкчылыктарды алып келет. Бирок, операциялар бир нече микросервистердин арасында өзгөрүүлөрдү талап кылат, бул көйгөйдү чечүү үчүн ишенимдүү чечим жөнүндө ойлонууга мажбурлайт.
Дээрлик реалдуу мисал
Келгиле, биздин домен кредиттик арыздарды кабыл алууну, аларды баалоону жана андан кийин кардарларга эскертме эскертүүлөрүн жөнөтүүнү камтыган сценарийди карап көрөлү.
Бирдиктүү жоопкерчилик принцибинин, Конвей мыйзамынын жана доменге негизделген дизайн мамилесинин духунда, бир нече окуя-штурмандык сессиялардан кийин бүт домен үч субдоменге бөлүнгөн, так чектери, домен моделдери жана бардык жерде колдонулуучу тилге ээ болгон аныкталган чектелген контексттери бар.
Биринчиси , жаңы кредиттик арыздарды кабыл алуу жана түзүү тапшырмасы. Экинчи система бул арыздарды баалайт жана берилген маалыматтардын негизинде чечим кабыл алат. Бул баалоо процесси, анын ичинде 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 маалымат базалары иштетилгенде , өзүңүздү угуңуз ыкмасын колдонууну карап көрүңүз.
Кийинки жолу транзакциялык чыгуу кутусун ишке ашыруунун практикалык мисалын карап чыгабыз. Караңыз
сен!
