Всім привіт!
Почав переклад невеликої книги:
««
автор: Jakub Korab, видавництво: O'Reilly Media, Inc., дата видання: June 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