Словник для систем, керованих подіями: виробники, споживачі, саги і багато іншого

Архітектура з керуванням подією (EDA) має свій власний щільний словник, і багато з нього легко зловживати, якщо англійська не є вашою першою мовою. Слова * опублікувати *, * випустити *, * споживати * і * відтворити * мають тут певне значення. Цей посібник містить основні терміни, показує, як інженери використовують їх у реченнях, і позначає помилки, які позначають вас як носіїв мови, для яких мова не є рідною.

---

Основная ментальная модель

У системі, керованій подією, компоненти не викликають один одного безпосередньо. Замість цього, щось відбувається — ** подія ** — і інші компоненти реагують на це. Подія є фактом про щось, що вже сталося, написаним у минулому часі: OrderPlaced, PaymentFailed, UserRegistered.

“Коли клієнт виходить, служба замовлення ** видає ** подію OrderPlaced. Доставщики реагируют на это. Дві служби ніколи не розмовляють прямо»

Зауважте час: назви подій є фактами минулого часу, ніколи командами. CreateOrder є командою (інструкцією); OrderCreated є подією (фактом). Зрозуміти це розрізнення в розмові - це сигнал справжньої плавності.

---

Виробники, споживачі, брокер

• ** Продюсер ** (або ** видавець **) — компонент, який створює і ** видає ** / ** публікує ** події.
• ** Consumer ** (або ** subscriber **) — компонент, який читає і ** обробляє ** події.
• ** Broker ** — середнє програмне забезпечення, яке зберігає і маршрутизує події (Kafka, RabbitMQ, NATS).
• ** Topic ** (Kafka) або ** queue ** (RabbitMQ) — потоки подій каналу з назвою.

Звичайні колокації дієслів — використовуйте ці парування:

• виробники ** опублікувати ** / ** надсилати ** / ** створити ** події
• споживачі підписуються на теми і споживають події
• брокер ** маршрутизує **, ** буферизує ** і ** доставляє ** події

«Три сервіси підписуються на тему payments. Кожен ** споживає ** події у своєму темпі. ”

** Помилка, якої слід уникати: ** Нерідні носії часто кажуть « виробник * надсилає * подію * до * споживача ». У EDA виробник не знає, хто є споживачем — скажіть « виробник ** публікує ** подію » і « споживач ** підписується ** на тему »

---

Гарантія доставки

Тут дійсно важливо знати англійську мову, оскільки ці терміни звучать схоже, але мають дуже різне значення:

• ** Майже раз ** — події можуть бути втрачені, але ніколи не дублюватимуться.
• ** Принаймні- раз** — події ніколи не втрачаються, але їх можна ** дублювати **.
• ** Точно- один раз** — кожна подія обробляється один раз (важко досягти; часто « ефективно точно- один раз »).

Оскільки at-at-least-once є типовим, користувачі повинні обробляти дублікати. Це приводить до одного найважливішого слова в EDA:

• ** Ідемпотентність / ідемпотентність ** — обробка однієї події двічі дає той самий результат, що і обробка її один раз.

“Наша доставка принаймні-один раз, тому кожен споживач має бути імпотентним. Ми дедуплікуємо за допомогою ID події.”

Произноси это о-к-о-м-о-н-т. Неправильно вимовляти це слово надзвичайно поширене — практикуйтеся.

---

Упорядкування, розділи і відхилення

• ** Розділ ** — тема розділена на розділи для паралельності; порядок гарантовано * всередині * розділу, а не між ними.
• ** Ключ розділу ** — поле, яке визначає, на який розділ буде перенесено подію.
• Offset — позиція користувача в потоці; користувачі записують зсуви для запису прогресу.
• Lag — наскільки відстає споживач. “Consumer lag is spiking — we’re falling behind.”
• ** Повторити ** — повторне читання старих подій з журналу, наприклад, для відновлення стану.

“Ми вводимо customerId, щоб всі події одного клієнта приземлялися в тому ж розділі і залишалися в порядку. Якщо споживач аварійний, він відновлюється з останнього затвердженого offset. “

---

Когда что-то пойдет не так

• ** Черга мертвих літер (DLQ) ** — місце, куди переносяться події після повторних спроб обробки.
• ** Отруйне повідомлення / отруйна таблетка ** — подія, яка завжди завершується невдачею і блокує чергу.
• ** Повторити з відстрочкою ** — повторення після збільшення затримки.
• ** Перезапуск ** — пересування подій з DLQ назад для переобробки.

“Отруєне повідомлення затримало споживача. Ми маршрутизували його до ** dead-letter queue ** і ** redrive ** його після виправлення помилки. “

---

Саги і розподілені транзакції

Ви не можете виконати одну транзакцію бази даних у багатьох службах, отже, вам слід координувати її з ** саґою **: послідовністю локальних транзакцій, кожна з яких видає подію, яка запускає наступний крок. Якщо крок зазнає невдачі, ви виконуєте ** компенсуючі транзакції **, щоб скасувати попередні.

• ** Оркестрація ** — центральний координатор наказує кожній службі, що робити.
• ** Хореографія ** — немає центрального мозку; сервіси реагують на події один одного.
• Компенсація транзакції — дія, яка семантично скасує попередню (наприклад, refund компенсує charge).

“Ми використовуємо хореографовану сагу. Якщо доставка не вдається, платіжна служба ловить подію ShipmentFailed і запускає компенсаційний повернення

Примітка про вимову: saga звучить як /ˈsɑːɡə/. Choreography звучить як /ˌkɒriˈɒɡrəfi/ — ch звучить як k.

---

Вихідні дані vs. потокове відтворення подій

Ці два параметри часто плутають:

• ** Потік подій ** — перенесення подій між системами у реальному часі.
• ** Походження подій ** — зберігання стану * як послідовності подій *; поточний стан отримується шляхом ** відтворення ** подій.
• CQRS (Command Query Responsibility Segregation) — відокремлення моделі запису від моделі читання, часто в парі з пошуком подій.
• ** Проекція ** — перегляд з оптимізацією для читання, створений за допомогою повторення подій.

“З ** джерелом подій **, журнал подій є джерелом правди. Ми створюємо проекцію для панелі приладів, відтворюючи потік в модель читання.”

---

До / після: вільно говорить

** До: ** “Отправитель посылает сообщение, получатель получает его, и если это не удается, он пытается еще раз.”

** Після: ** ”** Виробник опублікував ** подію у темі. ** Потребувачі ** обробляють її ** неефективно **, і при повторних невдачах подія потрапляє до ** черги мертвих літер ** для пізнішої ** перезапуску **.”

Друга версія коротша і більш точна — саме це ви отримуєте, якщо освоїли словниковий запас.

---

Швидкий довідковий словник

Term	One-line meaning
Event	A past-tense fact about something that happened
Producer / consumer	Emits events / processes events
Broker	Stores and routes events
Idempotent	Safe to process twice
Offset / lag	Consumer position / how far behind
DLQ	Where failed events go
Saga	Coordinated multi-service transaction
Compensating transaction	Undoes a previous step
Event sourcing	State stored as a log of events
CQRS	Separate read and write models

---

Ключевые вещи

• Події є ** фактами минулого часу **; команди є інструкціями. Не переплітайте їх.
• Продюсери опублікують; споживачі підпишуться і споживають — вони не звертаються один до одного безпосередньо.
• ** Ідемпотенційно** — це основа правильності, що базується на подіях — вивчайте слово і його вимову.
• Sagas використовують ** компенсуючі транзакції **, а не відновлення, щоб скасувати розподілену роботу.
• Освоєння цих колокації, і ви будете описувати складні системи в реченні, де інші потребують абзац.

На практиці: Навігація нюансів в командному спілкуванні

Будьмо чесними - навіть досвідчені розробники іноді натякають на точні формулювання, коли обговорюють складні системи, такі як архітектури, що керуються подіями. Це не просто про те, щоб знати визначення «продюсера» або «саги»; це про те, щоб чітко і впевнено пояснити ці поняття в команді, особливо при співпраці з колегами, які можуть мати різні рівні володіння англійською мовою. Поширеною пасткою є використання надмірно технічного жаргону без урахування того, як інші його інтерпретують. Наприклад, під час перегляду коду нового обробника повідомлень ви можете побачити коментар на зразок: « Цей споживач не обробляє події- дублікати — потрібна ідемпотенція! » Хоча ця фраза технічно правильна, вона може здатися різкою і залякуючою для когось, хто не знайомий з основними поняттями.

Розглянемо цю розмову у Slack між двома розробниками, Алексом і Беном, які обговорюють запит на витягування нової системи обробки замовлень, створеної навколо Kafka:

Алекс: “Бен, я реалізував продюсера подій OrderCreated. Він надійно публікує події до теми «заказів»

«Я хочу, щоб ти був крутим». Просто перевірка — чи використовуємо ми чергу мертвих листів для невдалих замовлень? Схоже, це хороша практика, щоб уникнути втрати даних, якщо щось не так з інтеграцією. ”

Ключовим тут є те, що питання Бена — про чергу мертвих листів — сформулюється як пропозиція або спостереження, а не пряма критика. Це більш доступно і запрошує до обговорення. Аналогічно, при написанні опису запитів на витягування, уникнення надмірно формальної мови може значно поліпшити розуміння. Замість того, щоб сказати « Цей компонент забезпечує ідемпотентність, щоб запобігти дублюючій обробці », ви можете написати: « Цей обробник розроблений для обробки кожної події замовлення тільки один раз, навіть якщо він отримує ту ж подію кілька разів — забезпечуючи послідовність даних. »

Зрозуміти ці тонкі відмінності у фразування дозволяє вам побудувати міцніше спілкування у вашій команді і уникнути непорозумінь, які можуть призвести до дорогих переробок. Це про передачу наміру, а не просто про висловлювання фактів. Пам’ятайте, чітке спілкування - це кращий спосіб успішного інженерного співробітництва.

Ось приклад використання kafka-console для зневадження:

kafka-console --bootstrap-server localhost:9092 --topic orders --describe-group my-order-group

За допомогою цієї команди ви зможете спостерігати за темою і групою Kafka, підтверджуючи, що події створюються і використовуються правильно. Хоча це простий приклад, він демонструє, як технічний словник може бути використаний в практичному контексті - демонструючи функціональність або вирішуючи проблеми. Це набагато ефективніше, ніж просто сказати “Кластер Кафки функціонує”