Найкраща практика поводження з асинхронним взаємодією?

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

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

Ще складніше було те, що при відмові надсилання повідомлення шлюз намагається надсилати сповіщення кожні 15 хвилин протягом декількох годин.

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

Розумно важко!

Але це, мабуть, вирішувалося вже газильйон разів, тож яка найкраща практика?

Я бачу, що моє майбутнє буде писати обробку між усіма цими системами та керувати тимчасовими затримками та можливими відмовами мережі, тому я хочу дотримуватися кращих практик.

Рекомендації з книги / статті були б чудовими.

Спасибі заздалегідь!

При побудові розподілених систем різниця між "синхронною" системою та "асинхронною" системою така: Синхронна система має відомі верхні межі щодо часу обчислень та доставки повідомлень. Отже: у вас є асинхронна система, де певні події не мають цих відомих верхніх меж. Як ви впораєтесь?

1. Якщо ці асинхронні процеси мають вірогідні верхні межі, то ви можете використовувати тайм-аути, щоб змусити вашу систему діяти як частково синхронна система. Якщо 98-й відсоток часу відповіді шлюзу платежів становить 5 секунд, то 5-секундний тайм-аут зробить 98% ваших запитів успішними, а інші 2% просто не вдасться. Це означає, що тепер у вас є відома верхня межа того, скільки часу цей процес займе, щоб досягти успіху чи невдачі. Це імовірнісне виявлення несправностей є критичним інструментом для перетворення асинхронних систем у синхронні системи.

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

3. Кожна складна транзакція, по суті, є сукупністю перетворень стану, заснованих на надсиланні та отриманні повідомлень (подій) всередині системи. Це здається, що ви неофіційно моделюєте це, використовуючи "запис відкладених транзакцій", але я б запропонував вам піти далі: Для кожної транзакції вам потрібно керувати, створити офіційну державну машину, яка описує її та зберігати міцний запис про її поточний стан . Ви побачите, що ці державні машини легко зрозуміти, їх легко перевірити і надати дуже потрібну видимість цим процесам як для вас, так і для користувачів.

Чим більше асинхронна ваша система, тим формальнішими і явнішими ви повинні бути під час управління цими складними перетвореннями з рівним станом. Часи очікування, тривала реєстрація подій та стан машини - найкраща практика тут. Саме тому, Erlang OTP базує багато своєї поведінки на застосуванні, наприклад, на моделі державної машини.

Для довідки я не знайшов нічого кращого, ніж Вступ до надійного та безпечного розподіленого програмування . Це дасть вам міцну алгоритмічну основу для розуміння як синхронних, так і асинхронних систем з перших принципів.