Разумевање брокера порука. Учење меһанике размене порука помоћу АцтивеМК и Кафке. Поглавље 1

Поздрав свима!

Почео сам да преводим малу књигу:
«Разумевање брокера за поруке",
аутор: Јакуб Кораб, издавач: О'Реилли Медиа, Инц., датум издања: јун 2017, ИСБН: 9781492049296.

Из увода у књигу:
"... Ова књига ће вас научити како да размишљате о брокерским системима за размену порука, упоређујући и супротстављајући две популарне брокерске технологије: Апацхе АцтивеМК и Апацхе Кафка. У њему ће бити наведени случајеви коришћења и развојни подстицаји који су навели њихове програмере да заузму веома различите приступе истој области – размену порука између система са посредним брокером. Погледаћемо ове технологије од темеља и нагласити утицај различитих дизајнерских избора на путу. Стећи ћете дубоко разумевање оба производа, разумевање како би требало и како не би требало да се користе и разумевање шта треба тражити када разматрате друге технологије за размену порука у будућности … »

До сада преведени делови:
Поглавље 1 Увод
Поглавље 3. Кафка

Објављиваћу завршена поглавља како буду преведена.

ПОГЛАВЉЕ 1

Увод

Размена порука од система до система једна је од области ИТ-а које се најмање разумеју. Као програмер или архитекта, можда сте веома упознати са различитим оквирима и базама података. Међутим, вероватно је да сте само пролазно упознати са начином на који функционишу технологије размене порука засноване на брокерима. Ако се тако осећате, не брините, у добром сте друштву.

Људи обично имају веома ограничен контакт са инфраструктуром за размену порука. Често се повежу на систем који је давно креиран, или преузму дистрибуцију са интернета, инсталирају је у ПРОМ и почну да пишу код за њу. Након покретања инфраструктуре у ПРОМ-у, резултати се могу мешати: поруке се губе због кварова, слање не функционише како сте очекивали, или брокери „окаче“ ваше произвођаче или не шаљу поруке вашим потрошачима.

Звучи познато?

Уобичајени сценарио је када ваш код за размену порука за сада одлично функционише. Док не престане да ради. Овај период уљуљкава гард у лажни осећај сигурности, што доводи до више кода заснованог на лажним уверењима о фундаменталном понашању технологије. Када ствари почну да иду наопако, суочени сте са незгодном истином: да нисте заиста разумели основно понашање производа или компромисе које су одабрали аутори, као што су перформансе наспрам поузданости, или трансакција насупрот хоризонталној скалабилности .

Без дубоког разумевања како брокери раде, људи дају наизглед разумне изјаве о својим системима за размену порука, као што су:

  • Систем никада неће изгубити поруке
  • Поруке ће се обрађивати узастопно
  • Додавање потрошача ће учинити систем бржим
  • Поруке ће бити испоручене само једном

Нажалост, неке од ових изјава су засноване на претпоставкама које се примењују само под одређеним околностима, док су друге једноставно нетачне.

Ова књига ће вас научити како да размишљате о системима за размену порука заснованим на брокерима, упоређујући и супротстављајући две популарне брокерске технологије: Апацхе АцтивеМК и Апацхе Кафка. У њему ће бити наведени случајеви коришћења и развојни подстицаји који су навели њихове програмере да заузму веома различите приступе истој области – размену порука између система са посредним брокером. Погледаћемо ове технологије од темеља и нагласити утицај различитих дизајнерских избора на путу. Стећи ћете дубоко разумевање оба производа, разумевање како треба, а шта не треба да се користе, и разумевање на шта треба обратити пажњу када разматрате друге технологије за размену порука у будућности.

Пре него што почнемо, хајде да пређемо на основе.

Шта је систем за размену порука и зашто је потребан?

Да би две апликације могле да комуницирају једна са другом, прво морају да дефинишу интерфејс. Дефинисање овог интерфејса укључује избор транспорта или протокола, као што су ХТТП, МКТТ или СМТП, и преговарање о форматима порука који ће бити размењени између система. Ово може бити строг процес, као што је дефинисање КСМЛ шеме са захтевима за цену корисног оптерећења поруке, или може бити много мање формалан, као што је споразум између два програмера да ће неки део ХТТП захтева садржати идентификатор клијента.

Све док су формат порука и редослед којим се шаљу конзистентни између система, они могу да комуницирају једни са другима без бриге о имплементацији другог система. Унутрашњост ових система, као што је програмски језик или оквир који се користи, може се променити током времена. Све док се одржава сам уговор, интеракција се може наставити без промена са друге стране. Ова два система су ефективно одвојена (раздвојена) овим интерфејсом.

Системи за размену порука обично укључују посредника између два система који међусобно делују како би даље одвојили (одвојили) пошиљаоца од примаоца или примаоца. У овом случају, систем за размену порука омогућава пошиљаоцу да пошаље поруку без да зна где се прималац налази, да ли је активан или колико има инстанци.

Хајде да погледамо неколико аналогија за врсте проблема које систем за размену порука решава и уведемо неке основне појмове.

Од тачке до тачке

Александра одлази у пошту да пошаље Адаму пакет. Она прилази прозору и предаје раднику пакет. Запослени преузима пакет и даје Александри признаницу. Адам не мора да буде код куће када се пакет пошаље. Александра је уверена да ће пакет бити испоручен Адаму у неком тренутку у будућности и да може да настави да се бави својим послом. Касније у неком тренутку Адам прима пакет.

Ово је пример модела размене порука од тачке до тачке. Пошта овде делује као механизам дистрибуције пакета, обезбеђујући да се свака пошиљка уручи једном. Коришћење поште раздваја чин слања пакета од испоруке пакета.
У класичним системима за размену порука, модел од тачке до тачке се имплементира кроз редови. Ред се понаша као ФИФО (први ушао, први изашао) бафер на који се може претплатити један или више потрошача. Свака порука се испоручује само једном од претплаћених потрошача. Редови обично покушавају да поштено дистрибуирају поруке међу потрошачима. Само један потрошач ће примити ову поруку.

Термин „трајан“ се примењује на редове. Поузданост је својство услуге које осигурава да ће систем за размену порука задржати поруке у одсуству активних претплатника све док се потрошач не претплати на ред за испоруку порука.

Поузданост се често меша са упорност и иако се ова два термина користе наизменично, они служе различитим функцијама. Упорност одређује да ли систем за размену порука записује поруку у неку врсту складишта између њеног пријема и слања потрошачу. Поруке послате у ред чекања могу или не морају бити трајне.
Размена порука од тачке до тачке се користи када случај употребе захтева једнократну радњу на поруци. Примери укључују депоновање средстава на рачун или довршавање налога за испоруку. Касније ћемо разговарати о томе зашто сам систем за размену порука није у стању да обезбеди једнократну испоруку и зашто редови у најбољем случају могу да обезбеде гаранцију испоруке најмање једном.

Издавач-Претплатник

Габриелла бира конференцијски број. Док је повезана са конференцијом, она чује све што говорник каже, заједно са осталим учесницима позива. Када се искључи, пропушта оно што је речено. Када се поново повеже, наставља да чује шта се говори.

Ово је пример модела размене порука објави-претплати се. Конференцијски позив делује као механизам емитовања. Особа која говори не брине колико је људи тренутно на позиву - систем осигурава да ће свако ко је тренутно повезан чути шта се говори.
У класичним системима за размену порука, модел размене порука објави-претплати се имплементира кроз врхови. Топиц пружа исти метод емитовања као и механизам конференције. Када се порука пошаље на тему, она се дистрибуира за све претплаћене кориснике.

Теме су обично непоуздан (неиздржљив). Баш као и слушалац који не може да чује шта је речено током конференцијског позива када слушалац прекине везу, претплатници на тему пропуштају све поруке које су послате док су ван мреже. Из тог разлога можемо рећи да теме дају гаранцију испоруке не више од једном за сваког потрошача.

Размена порука објављивања и претплате се обично користи када су поруке информативне природе и губитак једне поруке није посебно значајан. На пример, тема може да преноси очитавања температуре са групе сензора једном у секунди. Систем који је заинтересован за тренутну температуру и који је претплаћен на неку тему неће бринути ако пропусти неку поруку - друга ће стићи у блиској будућности.

хибридни модели

Веб локација продавнице поставља поруке о поруџбини у „ред порука“. Главни потрошач ових порука је извршни систем. Поред тога, систем ревизије треба да има копије ових порука о наруџби за накнадно праћење. Оба система не могу дозволити да поруке пролазе, чак и ако су сами системи недоступни неко време. Веб локација не би требало да буде свесна других система.

Случајеви коришћења често захтевају комбинацију модела за објављивање-претплату и размену порука од тачке до тачке, на пример када више система захтева копију поруке, а поузданост и упорност су потребни да би се спречио губитак поруке.

Ови случајеви захтевају одредиште (општи термин за редове и теме) које дистрибуира поруке у основи као тему, тако да се свака порука шаље посебном систему заинтересованом за те поруке, али и у којем сваки систем може дефинисати неколико потрошача који примају долазне поруке. поруке, што више личи на ред. Тип читања у овом случају је једном за сваку заинтересовану страну. Ова хибридна одредишта често захтевају издржљивост, тако да ако потрошач оде ван мреже, поруке које се шаљу у то време се примају након што се потрошач поново повеже.

Хибридни модели нису нови и могу се користити у већини система за размену порука, укључујући и АцтивеМК (преко виртуелних или композитних дестинација које комбинују теме и редове) и Кафку (имплицитно, као основно својство његовог дизајна одредишта).

Сада када имамо неку основну терминологију и разумевање за шта бисмо могли да користимо систем за размену порука, пређимо на детаље.

Превод урађен: теле.гг/миддле_јава

Следећи преведени део: Поглавље 3. Кафка

Наставиће се ...

Извор: ввв.хабр.цом

Додај коментар