Разбиране на брокерите на съобщения. Изучаване на механиката на съобщенията с 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 (чрез виртуални или съставни дестинации, които комбинират теми и опашки) и Kafka (имплицитно, като основно свойство на дизайна на дестинацията).

Сега, след като имаме основна терминология и разбиране за какво можем да използваме система за съобщения, нека да преминем към подробностите.

Извършен превод: tele.gg/middle_java

Следната преведена част: Глава 3. Кафка

За да се продължи ...

Източник: www.habr.com