Англійська мова для архітекторів: словник, який вам потрібен

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

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

---

Використовує словниковий запас

** Подія Storming ** — це метод спільної роботи для відображення складних бізнес- областей за допомогою кольорових листівок на стіні (або віртуальній дошці). Якщо вас запросили на такий, вам потрібно знати словник - швидко.

Основні будівельні блоки:

• Доменна подія (помаранчева) — щось, що сталося в минулому, назване в минулому часі: OrderPlaced, PaymentFailed, ShipmentDispatched. Події домену є основою сеансу.

• Command (синій) — дія, яка викликає подію: PlaceOrder, ProcessPayment. Команди є навмисними; події є фактами.

• Policy (фіолетовий, також називається «reaction») — правило, яке автоматично реагує на подію і видає команду: « Кожного разу, коли OrderPlaced → відправити команду ConfirmEmail. » Під час обговорення ви почуєте: « Тут є правило — щоразу, коли платіж зазнає невдачі, ми автоматично запускаємо команду повторення »

• ** Агрегат** (жовтий) — кластер об’ єктів домену, що розглядається як єдина одиниця. Команди надсилаються до агрегату; агрегат вирішує, прийняти чи відхилити, а потім видає подію.

• ** Горяча точка ** (червоний) — конфлікт, ризик або нерозв’ язане питання, яке було викликано під час сеансу. У справжніх майстернях: “У нас тут є гаряча точка — ніхто не впевнений, хто володіє цією подією.”

У розмові під час семінару:

• “Давайте продовжимо називати події домену в минулому часі — ShipmentDispatched, а не Dispatch Shipment. Це команда.”*

• “Хто є агрегатом, який приймає цю команду? Чи це Order або Inventory?»*

“Існує прогалина в політиці: що викликає команду ReserveInventory, коли замовлення внесено?”

---

Доменні події

Коли ви залишаєте майстерню і переходите до реалізації, словник змінюється, але точність залишається.

** Подія домену ** є незмінним записом того, що щось сталося. Ви почуєте дебати про два суперечливі стилі:

• ** Fat event ** (також називається * event- carried state transfer *) — корисна нагрузка події містить всі або більшість даних, необхідних споживачеві. Не потрібно додаткових викликів API. “Ми використовували жирні події — споживачам не потрібно дзвонити назад до служби замовлення.”

• ** Thin event ** (також називається * notification event *) — подія містить лише ідентифікатор і тип; користувачі повинні звернутися до служби джерела для отримання подальшої інформації. * « Ми навмисно не додавали подій — це зменшує обсяг даних і уникає приєднання користувачів до нашої схеми. » *

** Конвенції щодо назв ** мають значення в англомовних базах кодів. Стандарт: PascalCase минулого часу з використанням всюдисущої мови домену — спільного словника, узгодженого між інженерами і бізнес-партнерами. Приклади: OrderShipped, UserDeactivated, InvoiceOverdue.

У переглядах коду ви побачите такі коментарі:

• “Ця подія повинна бути в минулому часі — ProductPriceUpdated, а не UpdateProductPrice. Останнє звучить як команда.»*

*“Чи ми тут використовуємо всюдисущу мову? Команда бізнесу називає це «відправкою», а не «пересилкою». *

** Еволюція схем ** є постійним питанням, коли системи ростуть. Ви почуєте:

• “Ми потребуємо зміни, сумісної з попередніми версіями — додайте поле, не вилучайте його. Наші споживачі не можуть всі одночасно розгортати.»*

• “Ми використовуємо реєстр схем з Avro. Будь-яка зміна вимагає нової версії схеми і плану міграції.”*

Термін consumer contract (або consumer-driven contract) відноситься до угоди — іноді кодованої як тест — що визначає, що споживач очікує від схеми подій. “Перед тим, як змінити цю подію, запустіть тести споживчого договору.”

---

Засновник і керівник КПРС

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

Ключові слова у дискусіях щодо дизайну:

• Склад подій — база даних, де події зберігаються лише за допомогою додавання. “Ми використовуємо EventStoreDB як наш склад подій — без UPDATE або DELETE, тільки додавання.”

• ** Проекція ** (також відома як * модель читання *) — похідний перегляд, створений за допомогою обробки подій, оптимізований для запитів. Проекції * врешті- решт * збігаються зі сховищем подій. * “Сторінка резюме замовлення читає з проекції, а не зі сховища подій безпосередньо.” *

• ** Повторне відтворення подій ** — повторне відтворення збережених подій для відновлення проекції або відновлення після помилки. * “В логіці проекції була помилка. Ми виправили помилку і відтворили поток подій з нуля, щоб відновити модель читання.”*

** CQRS ** (Command Query Responsibility Segregation) часто супроводжує Event Sourcing. Шаблон розділяє * writes * (команди) від * reads * (запити) на різні моделі — іноді різні служби або бази даних.

У обговореннях архітектури:

• “На стороні запису команди переходять до агрегату і створюють події. На стороні читання, ми маємо проекції, оптимізовані для інтерфейсу користувача.”*

• “CQRS додає складності до операцій — ви керуєте двома моделями. Ми ввели його тільки там, де навантаження на читання і запис були справді асиметричними.”*

GDPR створює виклик для систем, що базуються на подіях: якщо ви не можете вилучити дані з незмінного журналу, як ви можете виконати запит на право на вилучення? Рішення - крипто-роздроблення: шифрування полів особистих даних за допомогою ключа для кожного користувача, а потім вилучення ключа. Подія залишається в магазині, але особисті дані стають недоступними. * “Ми обробляємо GDPR крипто-роздробленістю - шифрування PII з ключем користувача, видалення ключа на запит стерти.” *

---

Пам’ятний знак

** Saga pattern ** розв’ язує фундаментальну проблему розподілених систем: як підтримувати послідовність даних у багатьох службах без розподіленої транзакції (що вимагає блокування у службах і є непрактичним у масштабі)?

** Saga ** це послідовність локальних транзакцій. На кожному кроці буде опубліковано подію або повідомлення, яке викликає наступний крок. Якщо крок зазнає невдачі, saga видає ** компенсуючі транзакції ** — зворотні операції, розроблені для скасування ефекту попередніх кроків.

Критична фраза: компенсуючі транзакції надають ** семантичний відкат **, а не справжній відкат бази даних. Ви не можете скасувати відсилання електронної пошти, але ви * можете * надіслати електронну пошту про скасування. Ви не можете скасувати карту, але ви можете випустити повернення. Інженери використовують цю мову точно:

“Це компенсаційна операція — вона не скасує запис бази даних, а скасує бізнес- ефект.”

“Яка компенсуюча операція для ReserveInventory? Це має бути ReleaseReservation. ”

Постійно обговорюються два стилі координації:

• ** Хореографія ** — кожна служба реагує на події з інших служб; немає центрального координатора. * « Ми використовували хореографію — тут всі служби повністю відокремлені, кожна з них просто слухає події, які її цікавлять. » *

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

** Шаблон вихідних повідомлень ** розв’ язує проблему подвійного запису: як ви можете атомарно записувати до вашої бази даних * і* опублікувати повідомлення до вашого брокера? Рішення — записати обидва повідомлення до бази даних (запис бізнесу і вихідне повідомлення у таблицю « вихідні »), а потім окремий процес прочитає вихідні повідомлення і опублікує їх у брокера:

• “Ми використовуємо шаблон транзакційної скриньки вихідних повідомлень, щоб забезпечити доставку повідомлень до брокера тільки один раз. Читач outbox є idempotent.”*

• « Без теки Вихідні ви ризикуєте успішним записом бази даних, але подія так і не буде опублікована — або навпаки. » *

Временне з’єднання є ризиком того, що кроки цієї гілки непрямо залежать від часу або порядку навіть у нібито від’єднаній архітектурі. “Існує приховане часове з’єднання — крок C припускає, що крок B вже завершений, навіть якщо немає явної залежності.”

---

Словник-довідник слов’янських мов

Незалежно від того, використовуєте ви Kafka, RabbitMQ, AWS SQS/SNS або Google Pub/Sub, основний словник перетинається.

** Терміни, характерні для Кафки **, які з’ являються майже в кожній розмові:

• ** Тема ** — журнал з назвою, розділений на розділи, де публікуються події. * « Всі події порядку переносяться до теми order-events. » *

• ** Розділ ** — тема поділена на розділи для паралельності і масштабованості. Події в межах розділу впорядковані. * “Ми розділяємо на customerId, щоб гарантувати порядок для подій одного клієнта.” *

• ** Група користувачів ** — група користувачів, які разом читають всі розділи теми, кожен з яких буде призначено лише одному члену групи. Використовується для конкурентних споживачів (балансування навантаження). Не плутати з ** fan- out **, де декілька незалежних груп користувачів отримують повну копію кожного повідомлення.

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

“Для горизонтального масштабування в межах самої служби сповіщень, декілька екземплярів мають одну групу споживачів — це конкуруючі споживачі.”

** Черга мертвих листів (DLQ) ** — черга або тема, куди повідомлення, які неможливо обробити (після вичерпання можливостей повторних спроб), переносяться для перевірки. * « Перевірте чергу мертвих листів — у ній застрягло 47 повідомлень з минулої ночі ». *

** Семантика доставки ** — скільки разів буде доставлено повідомлення:

• ** Майже раз ** — повідомлення можуть бути втрачені, але їх ніколи не буде дублювати. Прийнятний для метрик або журналів, де втрати допустимі.
• ** Принаймні- один- раз** — повідомлення ніколи не втрачаються, але їх можна доставити декілька разів. Найбільш поширене типове значення; споживачі повинні бути імпотентними.
• ** Точно- один раз** — кожне повідомлення обробляється точно один раз. Kafka підтримує це з транзакціями; це несе витрати на продуктивність. * “Ми використовуємо семантику точно-один раз на конвеєрі платежу. Всюди іншому, принаймні раз з іменемпотентними споживачами.»*

** Модель зберігання журналів проти моделі черги ** — ключова відмінність архітектури. Черга (SQS, RabbitMQ) вилучає повідомлення після їх використання. Kafka зберігає журнал протягом налаштованого періоду часу (типово: 7 днів), що надає користувачам змогу повторити відтворення з будь- якого відхилення. Цей параметр є центральним у архітектурі пошуку подій + Kafka:

• “Модель збереження журналу Кафки означає, що нові споживачі можуть переграти історичні події. З SQS, це неможливо — спожиті повідомлення зникли.»*

---

Архітектурна дискусійна мова

Крім індивідуальних термінів, здатність * аргументувати * за або проти архітектури англійською мовою є кар’єрною диференційованою вмінням.

Пропозиція EDA:

“Я б запропонував розглянути тут події, що керуються підходом. Сервіси публікують події домену; споживачі реагують асинхронно. Перевагою є вільне з’єднання - служба замовлення не повинна знати, які служби нижче існують. ”

• “Це хороший кандидат для EDA, оскільки зв’ язок між цими двома службами спричиняє розгортання тертя. Відокремлення через події дозволить кожній команді випускати незалежно.»*

** Обґрунтування можливої послідовності: **

• “Ми погоджуємося з можливою послідовністю — користувачеві не потрібно бачити оновлений баланс у реальному часі. Ми можемо показати стан «обробки» і оновити інтерфейс користувача, коли настане подія. ”*

• “Компроміс полягає в тому, що читання можуть бути застарілими. Ми зробили це рішення продукції явно — бізнес прийняв його, тому що поліпшення затримки було того варте.»*

** Обговорення переваг відокремлення: **

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

• “Однією з переваг переходу на керування за подією є можливість незалежного розгортання. Служба доставки і служба розрахунків можуть відправляти по різних розкладах. ”*

Пропозиція стратегії міграції:

“Я рекомендую шаблон “душитель-фіг”. Ми не переписуємо моноліт — ми маршрутизуємо нові функції через шар, керований подією, і поступово мігруємо існуючі потоки. ”

• “Ми можемо розпочати з користувача тільки для читання — підписуватися на події і заповнювати нове сховище даних без втрати існуючої системи. Як тільки ми перевіримо це, ми перевернуємо перемикач.”*

** Обговорення режимів аварій: **

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

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

---

Впровадження в практику

Словник, описаний вище, буде марним, якщо ви не зможете використовувати його під тиском — під час перегляду проекту, під час співбесіди на роботу, або коли щось не виходить о 2 годині ранку, і ви розмовляєте з чотирма старшими інженерами.

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

Щоб вдосконалити цей словниковий запас з негайним зворотнім зв’ язком, скористайтеся Мова Є — у ньому наведено терміни щодо штурму подій, пошуку подій, шаблонів легенд, словника брокера повідомлень і фраз для обговорення архітектури.