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