Використання Apache Kafka для взаємодії АБС Б2 з новим клієнт-банком – одна зі значущих подій у низці проектів компанії CS. Чому ця новина варта уваги, у чому її важливість? Навіщо взагалі це потрібно банкам, яка поточна реалізація і перспективи?
Для початку – кілька слів про Kafka. Ні, не про всесвітньо відомого письменника.
Apache Kafka – розподілена потокова (стрімінгова) платформа, такий собі (визначення з Вікіпедії) програмний брокер повідомлень. «Брокер», тобто «посередник» – ключове слово для розуміння процесу. Грубо кажучи, Kafka дозволяє впорядкувати безліч (мільйон плюс) повідомлень (транзакцій), вибудовуючи їх у правильні черги та оперативно обробляючи. Основна функція Kafka – це управління паралельними потоками даних у реальному режимі часу із забезпеченням надійного безперервного передавання інформації між системами та/або застосунками.
Тобто якщо великі розгалужені системи генерують величезну кількість подій (транзакції, логи, дані моніторингу та доступу до ресурсів тощо), то Kafka збирає відповідні дані у видавців (producer), поміщає їх в своє розподілене сховище згідно з категоріями, або темами (topic), і роздає їх підписантам (consumer) згідно з так званими оформленими підписками. Чим це відрізняється від інших рішень, які передбачають оброблення черги повідомлень від видавця до підписанта? У чому тут новаторство і прорив?
Переваги
Переваги черги повідомлень Kafka:
- Кластеризація (горизонтальна масштабованість). Kafka працює як кластер на одному або декількох серверах, які можуть охоплювати різні центри оброблення даних. Навіть один Kafka-брокер – це кластер, і для того щоб додати другий, не потрібно ніяких особливих налаштувань. Додавання нової машини дозволяє уникнути простоїв, притому кількість машин, що додаються до кластера, не обмежується.
- Продуктивність і доступність. Пропускна здатність Kafka – до мільйона повідомлень за секунду. Водночас обслуговування однієї теми декількома брокерами, дроблення черг на частини і розподіл їх по кластеру дозволяє істотно збільшити пропускну здатність.
- Зберігання повідомлень. Kafka зберігає повідомлення стільки, скільки потрібно (за замовчуванням – тиждень). Таким чином, підписуючись на тему в Kafka, можна отримати і вчорашні, і позавчорашні повідомлення і… Тимчасом як інші брокери повідомлень видаляють їх після успішної доставки. Крім того, Kafka автоматично зберігає повідомлення на диску – для цього не потрібно окремих налаштувань.
- Журнал транзакцій. Для кожної теми (топіка) кластер Kafka веде журнал, який розбивається на розділи (partition). Кожен журнал являє собою незмінну послідовність записів з ідентифікаційним номером (до цієї структури можна тільки додавати записи, видаляти або змінювати їх неможливо). Сувора впорядкована структура – серцевина Kafka. Розділи журналу дозволяють йому масштабуватися за межі розміру, здатного вмістити один сервер.
Кластеризація забезпечує надійність та безпеку.
Кластер Kafka з декількох вузлів залишається працездатним, навіть якщо пара вузлів вийде з ладу.
Загальну схему передавання інформації за допомогою Apache Kafka наведено на рисунку.
А що в нас? Поставлена задача й поточна реалізація
Отже, яке завдання ми вирішуємо? Взаємодія АБС Б2 з новим клієнт-банком для передавання онлайн-повідомлень про кредити й депозити фізичних осіб (з АБС Б2 клієнт-банку передається інформація, наприклад, про транзакції, стан рахунку та про інші динамічно змінювані параметри кредитних і депозитних угод). Навіщо нам для цього Kafka – вже зрозуміло. Тепер про те, як саме ми використовуємо можливості Kafka в роботі банківської інфраструктури.
Загальний алгоритм передавання повідомлень через потокову платформу Kafka:
- Генерування та відправлення вихідних повідомлень. Для генерування вихідних повідомлень реалізовано новий механізм, який за певних подій в АБС (створення/змінення об’єкта моніторингу – контрагента, угоди, рахунку тощо) генерує відповідні події та відправляє їх до Oracle Advanced Queue. На ці події можуть підписуватися всі, кому вони цікаві. Одним з таких підписантів є підсистема взаємодії через Kafka з клієнт-банком, яка читає події з Oracle Advanced Queue і формує повідомлення. Для передавання повідомлень використовується застосунок Java, який отримує сформоване повідомлення із зазначеної підсистеми та записує його до відповідного топіку Kafka. Клієнт-банк не відповідає на вихідні повідомлення.
- Оброблення та приймання вхідних повідомлень. На боці клієнт-банку формуються повідомлення, які відправляються до АБС, – вхідні повідомлення. Притому вони не проходять через Oracle Advanced Queue (див. попередній пункт). Для передавання вхідних повідомлень використовується Java-застосунок, який читає повідомлення з топіків Kafka та передає до АБС для оброблення. АБС обробляє вхідне повідомлення та відправляє результат оброблення у вигляді вихідного повідомлення (за допомогою описаного вище механізму відправлення вихідних повідомлень).
Кафка явно щось знав…
«Істинний шлях йде по канату, який натягнутий не високо, а над самою землею».
Франц Кафка
Як ми бачимо, використання платформи Kafka для інтеграції між різними банківськими системами дозволяє впорядкувати та істотно прискорити передавання інформації, а також убезпечити банківську інфраструктуру від технічних форс-мажорів.
