Зробивши трохи більше досліджень, я натрапив на цю статтю, з якої витягнув кілька цитат, які, на мою думку, є корисними для того, що я хочу досягти (і для будь-яких майбутніх читачів). Це пропонує спосіб прийняти реактивну модель програмування над імперативною моделлю програмування.
Події-джерела
Ідея тут полягає в тому, щоб представляти перехід стану кожної програми у формі незмінної події. Потім події зберігаються у журналі або формі журналу у міру їх виникнення (також їх називають "сховищем подій"). Їх також можна запитувати і зберігати нескінченно, маючи на меті представити, як стан програми в цілому розвивався з часом.
Що допомагає досягти цього, це те, що якщо мікросервіс знижується, а інші події, пов'язані з ним, публікуються, а події споживаються, скажімо, іншими екземплярами цієї мікросервісу, коли ця мікросервіс повертається назад, вона може звернутися до цього, event storeщоб отримати все події, які він пропустив протягом періоду, коли він знизився.
Apache Kafka як брокер подій
Розглянемо використання Apache Kafka, який може зберігати та відправляти тисячі подій в секунду та має вбудовані механізми реплікації та відмовостійкості. У ньому зберігається постійний запас подій, які можна зберігати на диску нескінченно і споживати в будь-який час (але не видаляти) з теми (нарядною чергою Кафки).
Потім події призначаються компенсаціями, які однозначно ідентифікують їх у межах теми - Kafka може сама керувати компенсаціями, легко надаючи семантику доставки "щонайбільше" або "принаймні один раз", але вони також можуть бути узгоджені, коли споживач події приєднується до теми , що дозволяє мікросервісам почати споживати події з будь-якого довільного місця в часі - зазвичай з того місця, де споживач зупинився. Якщо зсув останнього споживаного події транзакційно зберігається в локальному сховищі служб, коли «успішно завершено», використання цього зрушення можна легко використовувати для досягнення семантики доставки подій «точно один раз».
Насправді, коли споживачі ідентифікують себе Kafka, Kafka записуватиме, які повідомлення були доставлені до якого споживача, щоб він більше не обслуговував його.
Саги
Для більш складних випадків використання, де комунікація між різними службами дійсно необхідна, відповідальність за завершення використання шафи повинна бути добре розпізнана - використання шафи децентралізовано і закінчується лише тоді, коли всі залучені служби визнають своє завдання успішно виконаним, інакше вся скринька використання повинна вийти з ладу і повинні бути вжиті коригувальні заходи для відкату будь-якого недійсного місцевого стану.
Це коли сага вступає в гру. Сага - це послідовність локальних транзакцій. Кожна локальна транзакція оновлює базу даних та публікує повідомлення або подію, щоб викликати наступну локальну транзакцію в сазі. Якщо локальна транзакція провалюється через те, що вона порушує ділове правило, то сага виконує ряд компенсаційних транзакцій, які скасовують зміни, що були здійснені попередніми локальними транзакціями. Прочитайте це для отримання додаткової інформації.