Хабарлама брокерлерін түсіну. ActiveMQ және Kafka көмегімен хабар алмасу механикасын үйрену. 1-тарау

Привет!

Мен шағын кітапты аударуды бастадым:
«Хабарлама брокерлерін түсіну«
автор: Якуб Кораб, баспагер: O'Reilly Media, Inc., жарияланған күні: маусым 2017 ж., ISBN: 9781492049296.

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

Осы уақытқа дейін аударылған бөліктер:
1-тарау. Кіріспе
3-тарау. Кафка

Аяқталған тарауларды аударылған сайын орналастырамын.

1 тарау

Кіріспе

Жүйеден жүйеге хабар алмасу АТ-тың ең аз түсінілетін салаларының бірі болып табылады. Әзірлеуші ​​немесе сәулетші ретінде сіз әртүрлі фреймворктармен және дерекқорлармен жақсы таныс болуыңыз мүмкін. Дегенмен, сізде брокерге негізделген хабар алмасу технологиялары қалай жұмыс істейтіні туралы өтпелі таныс болуы мүмкін. Егер сіз осылай сезінсеңіз, уайымдамаңыз, сіз жақсы серіктессіз.

Адамдардың әдетте хабар алмасу инфрақұрылымымен байланысы өте шектеулі. Олар жиі бұрыннан жасалған жүйеге қосылады немесе Интернеттен таратуды жүктеп алып, оны PROM-ға орнатады және оған код жаза бастайды. PROM-да инфрақұрылымды іске қосқаннан кейін нәтижелер аралас болуы мүмкін: хабарлар сәтсіздіктерге байланысты жоғалады, жіберу сіз күткендей жұмыс істемейді немесе брокерлер сіздің өндірушілеріңізді «іліп қояды» немесе тұтынушыларыңызға хабарлама жібермейді.

Таныс дыбыс па?

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

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

  • Жүйе ешқашан хабарламаларды жоғалтпайды
  • Хабарламалар ретімен өңделеді
  • Тұтынушыларды қосу жүйені жылдамдатады
  • Хабарламалар тек бір рет жеткізіледі

Өкінішке орай, бұл мәлімдемелердің кейбірі белгілі бір жағдайларда ғана қолданылатын жорамалдарға негізделген, ал басқалары жай ғана қате.

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

Бастамас бұрын, негізгі мәліметтерді қарастырайық.

Хабарлама жүйесі дегеніміз не және ол не үшін қажет?

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

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

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

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

Нүктеден нүктеге

Александра Адамға пакет жіберу үшін пошта бөлімшесіне барады. Ол терезеге барып, пакетті қызметкерге береді. Қызметкер пакетті алып, Александраға түбіртек береді. Пакет жіберілген кезде Адамның үйде болуы қажет емес. Александра пакет Адамға болашақта жеткізілетініне және өз ісін жалғастыра алатынына сенімді. Біраз уақыттан кейін Адам пакетті алады.

Бұл хабар алмасу үлгісінің мысалы нүктеден нүктеге. Мұнда пошта бөлімшесі әр сәлемдеменің бір рет жеткізілуін қамтамасыз ететін сәлемдеме тарату механизмі ретінде әрекет етеді. Пошта бөлімшесін пайдалану пакетті жіберу актісін пакетті жеткізуден бөледі.
Классикалық хабар алмасу жүйелерінде нүктеден нүктеге модель арқылы жүзеге асырылады очереди. Кезек бір немесе бірнеше тұтынушы жазыла алатын FIFO (бірінші кірген, бірінші шыққан) буфері ретінде әрекет етеді. Әрбір хабарлама тек жеткізіледі жазылған тұтынушылардың біріне. Кезектер әдетте тұтынушылар арасында хабарларды әділ таратуға тырысады. Бұл хабарды тек бір тұтынушы алады.

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

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

Баспагер - жазылушы

Габриелла конференция нөмірін тереді. Ол конференцияға қосылған кезде, ол спикердің айтқанының барлығын, сонымен қатар басқа қоңырау қатысушыларымен бірге естиді. Ол күйге түскенде, ол айтылғанды ​​сағынады. Қайта қосылған кезде ол не айтылып жатқанын тыңдай береді.

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

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

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

гибридті модельдер

Дүкеннің веб-сайты тапсырыс хабарламаларын «хабарлама кезегіне» орналастырады. Бұл хабарламалардың негізгі тұтынушысы – атқарушы жүйе. Бұдан басқа, аудит жүйесінде кейінгі бақылау үшін осы тапсырыс хабарламаларының көшірмелері болуы керек. Жүйелердің өзі біраз уақыт қолжетімсіз болса да, екі жүйе де хабарлардың өтуіне рұқсат бере алмайды. Веб-сайт басқа жүйелер туралы хабардар болмауы керек.

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

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

Гибридті модельдер жаңа емес және көптеген хабар алмасу жүйелерінде, соның ішінде ActiveMQ (тақырыптар мен кезектерді біріктіретін виртуалды немесе құрама тағайындаулар арқылы) және Кафка (жасырын түрде, оның тағайындалған дизайнының негізгі қасиеті ретінде) пайдалануға болады.

Енді бізде кейбір негізгі терминология және хабар алмасу жүйесін не үшін пайдалануға болатынын түсінгендіктен, егжей-тегжейге көшейік.

Аударма жасалды: tele.gg/middle_java

Келесі аударылған бөлік: 3-тарау. Кафка

Жалғасы бар…

Ақпарат көзі: www.habr.com

пікір қалдыру