Здравейте на всички!
Започнах превода на малка книга:
««,
автор: Jakub Korab, издателство: O’Reilly Media, Inc., дата на издаване: юни 2017, ISBN: 9781492049296.
От въведението към книгата:
«… Тази книга ще ви научи да разсъждавате за системите за обмен на съобщения чрез брокери, като сравнявате и противопоставяте две популярни технологии на брокери: Apache ActiveMQ и Apache Kafka. Тук ще бъдат изложени примери за използване и стимулите за разработка, които накараха техните разработчици да използват напълно различни подходи в една и съща област — обмена на съобщения между системите чрез междинен брокер. Ще разгледаме тези технологии от основите и ще подчертаем влиянието на различните дизайнерски варианти по този път. Ще получите дълбочинно разбиране за двата продукта, разбиране за това как да ги използвате и как не, и разбиране за какво да внимавате, когато разглеждате други технологии за обмен на съобщения в бъдеще. …»
Преведените до момента части:
Ще публикувам завършените глави, докато превеждам.
ГЛАВА 1
Въведение
Обменът на съобщения между системи е една от най-слабо разбраните области в ИТ. Като разработчик или архитект, вероятно сте добре запознати с различни фреймворкове и бази данни. Въпреки това, напълно е възможно да имате само повърхностно познание за начина, по който работят технологии за обмен на съобщения, базирани на брокери. Ако се чувствате така, не се притеснявайте, вие не сте сами.
Хората обикновено взаимодействат с инфраструктурата за обмен на съобщения много ограничено. Често се свързват с система, създадена преди много време, или изтеглят дистрибуция от интернет, инсталират я в ПРОМ и започват да пишат код за нея. След стартиране на инфраструктурата в ПРОМ, резултатите могат да бъдат неясни: загуба на съобщения при сривове, изпращането не работи така, както очаквате, или брокерите „задържат“ вашите продуценти или не изпращат съобщения на вашите потребители.
Звучи ли ви познато?
Разпространен сценарий е, когато вашият код за обмен на съобщения работи отлично, докато не спре да работи. Този период успокоява бдителността и дава фалшиво чувство за безопасност, което води до още повече код, основан на погрешни разбирания за основното поведение на технологията. Когато нещо започне да не върви, се изправяте пред неудобната истина: всъщност не сте разбрали основното поведение на продукта или компромисите, избрани от разработчиците, като производителност спрямо надеждност или транзакционност спрямо хоризонтална мащабируемост.
Без задълбочено разбиране за начина, по който работят брокерите, хората правят изглеждащи разумни твърдения за техните системи за обмен на съобщения, като:
- Системата никога няма да загуби съобщения.
- Съобщенията ще се обработват последователно.
- Добавянето на консумиращи устройства ще ускори системата.
- Съобщенията ще бъдат доставяни само веднъж.
За съжаление, част от тези твърдения се основават на предположения, които са валидни само при определени обстоятелства, докато други просто не са верни.
Тази книга ще ви научи как да разсъждавате за системи за обмен на съобщения, базирани на брокери, като сравнявате и противопоставяте две популярни технологии за брокери: Apache ActiveMQ и Apache Kafka. Ще изложим примери за приложения и стимулите за разработка, които доведоха техните разработчици да използват напълно различни подходи към една и съща област — обмен на съобщения между системи с междинен брокер. Ще разгледаме тези технологии от нулата и ще подчертаем влиянието на различните дизайнерски опции по този път. Ще получите дълбочинно разбиране на двата продукта, осъзнавайки как да ги използвате и как не, както и за какво да внимавате при разглеждане на други технологии за обмен на съобщения в бъдеще.
Преди да започнем, нека да разгледаме основите.
Какво е система за обмен на съобщения и защо е необходима?
За да могат две приложения да комуникират помежду си, те първо трябва да определят интерфейса. Определянето на този интерфейс включва избор на транспорт или протокол, като HTTP, MQTT или SMTP, и съгласуване на форматите на съобщенията, с които ще обменят системите. Това може да бъде строг процес, като определяне на XML схема с изисквания за разходите на полезния товар (payload) на съобщението, или може да бъде много по-малко формално, например споразумение между двама разработчици, че определена част от HTTP заявката ще съдържа идентификатор на клиента.
Докато форматът на съобщенията и редът на тяхното изпращане между системите са съгласувани, те ще могат да взаимодействат помежду си, без да се притесняват за имплементацията на другата система. Вътрешностите на тези системи, като програмния език или използвания фреймворк, могат да се променят с времето. Досега, докато контрактът се поддържа, взаимодействието може да продължи без промени от другата страна. Тези две системи са ефективно разделени от този интерфейс.
Системите за обмен на съобщения обикновено предвиждат участие на посредник между две системи, които взаимодействат, за да осигурят допълнително разединение между изпращача и получателя или получателите. При това системата за обмен на съобщения позволява на изпращача да изпрати съобщение, без да знае къде се намира получателят, активен ли е той или колко са неговите екземпляри.
Нека разгледаме няколко аналогии на разновидности проблеми, които решава системата за обмен на съобщения, и да въведем някои основни термини.
Point-to-Point
Александра отива на пощата, за да изпрати на Адам пратка. Тя се приближава до гишето и предава пратката на служителя. Служителят взима пратката и издава на Александра разписка. Адам не трябва да бъде у дома в момента на изпращането на пратката. Александра е сигурна, че пратката ще бъде доставена на Адам в някакъв момент в бъдеще и може да продължи да се занимава с делата си. По-късно Адам получава пратката.
Това е пример за модел на обмен на съобщения точка-точка. Пощенската служба тук действа като механизъм за разделение на пратките, гарантиращ, че всяка пратка ще бъде доставена веднъж. Използването на пощата разделя акта на изпращане на пратката от доставката на пратката.
В класическите системи за обмен на съобщения моделът „точка-точка“ се реализира чрез на опашката. Опашката действа като FIFO буфер (първи влязъл, първи излязъл), на който може да се абонира един или повече потребители. Всяко съобщение се доставя само на един от абонатите. Опашките обикновено се стремят да разпределят съобщенията между потребителите справедливо. Само един потребител ще получи дадено съобщение.
На опашките се прилага терминът „надеждни“ („durable“). Надеждност — това е свойството на услугата, което гарантира, че системата за обмен на съобщения ще запази съобщенията при отсъствие на активни абонати, докато потребителят не се абонира за опашката за доставка на съобщения.
Надеждността често се бърка с персистентността и, макар че тези два термина са взаимозаменяеми, те изпълняват различни функции. Персистентността определя дали системата за обмен на съобщения записва съобщението в някакъв вид хранилище между получаването и изпращането му на потребителя. Съобщенията, изпратени в опашката, могат да бъдат или да не бъдат персистентни.
Обменът на съобщения от тип „точка-точка“ се използва, когато вариантът на употреба изисква единично действие със съобщението. Например, можем да дадем пример с депозиране на средства по сметка или осъществяване на поръчка за доставка. След малко ще обсъдим защо самата система за обмен на съобщения не е в състояние да осигури единична доставка и защо опашките могат в най-добрия случай да предоставят гаранция за доставка поне веднъж.
Публикуване-Абониране
Габриела набира номера на конференцията. Докато е свързана с конференцията, тя чува всичко, което казва говорителят, заедно с останалите участници в разговора. Когато се отключи, тя пропуска това, което е казано. При повторно свързване тя продължава да чува какво говорят.
Това е пример за модел на обмен на съобщения публикация-абониране. Конферентната връзка действа като механизъм за широкоразпространение. Говорещият не се интересува колко хора в момента са се присъединили към разговора — системата гарантира, че всеки присъединил се в този момент ще чуе какво се казва.
В класическите системи за обмен на съобщения моделът на обмен на съобщения „публикация-абониране“ се реализира чрез топициТопик предоставя същия начин на широковещание, както и механизма за конференционна връзка. Когато съобщение бъде изпратено в топика, то се разпространява на всички абонирани потребители..
Топиците обикновено ненадеждни (nondurable). Както слушателят, който не чува какво се говори по време на конференция, когато слушателят се изключи, абонатите на топика пропускат всякакви съобщения, които се изпращат по време, когато са офлайн. Поради тази причина можем да кажем, че топиците предоставят гаранция за доставка не повече от един път за всеки потребител.
Обменът на съобщения от тип «публикация-абонамент» обикновено се използва, когато съобщенията са информационни и загубата на едно съобщение не е от особено значение. Например, топик може да предава показания на температура от група сензори веднъж в секунда. Системата, която се интересува от текущата температура и се абонира за топика, няма да се притеснява, ако пропусне съобщение — друго ще постъпи съвсем скоро.
Хибридни модели
Уебсайтът на магазина поставя съобщения за поръчки в «опашка за съобщения». Основният потребител на тези съобщения е изпълнителната система. Освен това, системата за одит трябва да има копия на тези съобщения за поръчки за последващо проследяване. И двете системи не могат да пропускат съобщения, дори ако самите системи не са налични за някакъв период от време. Уебсайтът не трябва да знае за другите системи.
Сценарии за употреба често изискват комбиниране на моделите на обмен на съобщения «публикация-абонамент» и «точка-точка», например, когато на няколко системи е необходима копия на съобщение, и за предотвратяване на загубата на съобщение са необходими както надеждност, така и персистентност.
В тези случаи е необходим адресат (destination) (общ термин за опашки и топици), който разпределя съобщенията основно като топик, така че всяко съобщение да бъде изпратено в отделна система, заинтересована от тези съобщения, но също така всяка система може да определи няколко потребители, които получават входящите съобщения, което по-скоро напомня на опашка. Типът четене в този случай е един път за всяка заинтересована страна.Тези хибридни адресати често изискват надеждност (durability), така че, ако потребителят се отключи, съобщенията, които се изпращат по това време, се получават след повторно свързване на потребителя.
Хибридните модели не са нови и могат да се прилагат в повечето системи за обмен на съобщения, включително както ActiveMQ (чрез виртуални или съставни адресати, които обединяват теми и опашки), така и Kafka (неявно, като основно свойство на дизайна на нейния адресат).
Сега, когато имаме известна основна терминология и разбираме за какво може да ни послужи система за обмен на съобщения, нека преминем към детайлите.
Преводът е завършен:
Следващата преведена част:
Продължение следва…
Източник: habr.com
