У 2017 році ми виграли конкурс на розробку транзакційного ядра інвестиційного бізнесу Альфа-Банку та розпочали роботу (на HighLoad++ 2018 з доповіддю про ядро інвестиційного бізнесу Володимир Дринкін, керівник напряму транзакційного ядра інвестиційного бізнесу (Альфа-банку). Ця система повинна була агрегувати дані про угоди з різних джерел у різних форматах, приводити дані до уніфікованого вигляду, зберігати їх та надавати доступ до них.
У процесі розробки система еволюціонувала і обростала функціоналом, і в якийсь момент ми зрозуміли, що у нас кристалізується щось набагато більше, ніж просто прикладне ПЗ, створене для вирішення певного кола завдань: у нас вийшло система для побудови розподілених додатків із персистентним сховищем. Отриманий нами досвід ліг в основу нового продукту. (TDG).
Я хочу розповісти про архітектуру TDG і про ті рішення, яких ми прийшли в процесі розробки, познайомити вас з основним функціоналом і показати, як наш продукт може стати базою для побудови закінчених рішень.
Архітектурно ми розділили систему на окремі ролі, кожна з яких є відповідальною за вирішення певного кола завдань. Один запущений екземпляр програми реалізує один або кілька типів ролей. У кластері може бути кілька ролей одного типу:
з'єднувач
Connector відповідає за зв'язок із зовнішнім світом; його завдання - прийняти запит, розпарсувати його, і якщо це вдалося, то надіслати дані на обробку до input processor. Ми підтримуємо формати HTTP, SOAP, Kafka, FIX. Архітектура дозволяє легко додавати підтримку нових форматів, незабаром з'явиться підтримка IBM MQ. Якщо аналіз запиту завершився помилкою, то connector поверне помилку; в іншому випадку він відповість, що запит був опрацьований успішно, навіть якщо і виникла помилка при його подальшій обробці. Це зроблено спеціально, щоб працювати із системами, які вміють повторювати запити — чи навпаки, роблять це надто наполегливо. Для того, щоб не втрачати дані, використовується ремонтна черга: об'єкт спочатку потрапляє до неї і тільки після успішної обробки видаляється з неї. Адміністратор може отримувати сповіщення про об'єкти, що залишилися в черзі, а після усунення програмної помилки або апаратного збою виконати повторну спробу.
Input processor
Input processor класифікує отримані дані за характерними ознаками та викликає відповідні обробники. Обробники - це код на мові Lua, що запускається в пісочниці, вплинути на функціонування системи вони не можуть. На цьому етапі дані можна привести до необхідного вигляду, а також за необхідності запустити довільну кількість завдань, які можуть реалізовувати необхідну логіку. Наприклад, у продукті MDM (Master Data Management), побудованому на Tarantool Data Grid, при додаванні нового користувача ми, щоб не уповільнювати обробку запиту, створення золотого запису запускаємо окремим завданням. Пісочниця підтримує запити на читання, зміну та додавання даних, дозволяє виконувати певну функцію на всіх ролях типу storage та агрегацію результату (map/reduce).
Обробники можуть бути описані у файлах:
sum.lua
local x, y = unpack(...)
return x + yІ потім, оголошені у конфігурації:
functions:
sum: { __file: sum.lua }
Чому Lua? Lua дуже проста мова. Виходячи з нашого досвіду, через пару годин після знайомства з ним, люди починають писати код, який вирішує їхнє завдання. І це не лише професійні розробники, а, наприклад, аналітики. Крім того, завдяки jit-компілятору Lua працює дуже швидко.
зберігання
Storage зберігає персистентні дані. Перед збереженням дані проходять валідацію на відповідність до схеми даних. Для опису схеми ми використовуємо розширений формат . приклад:
{
"name": "User",
"type": "record",
"logicalType": "Aggregate",
"fields": [
{ "name": "id", "type": "string"},
{"name": "first_name", "type": "string"},
{"name": "last_name", "type": "string"}
],
"indexes": ["id"]
}За цим описом автоматично генерується DDL (Data Definition Language) для СУБД Тарантул та схема доступу до даних.
Підтримується асинхронна реплікація даних (додати синхронну).
Output processor
Іноді про надходження нових даних потрібно сповістити зовнішніх споживачів, при цьому існує роль Output processor. Після збереження даних, вони можуть бути передані у відповідний ним обробник (наприклад, щоб привести їх до виду, який потребує споживач) - і після цього передано до connector на відправку. Тут також використовується ремонтна черга: якщо об'єкт ніхто не прийняв, адміністратор може спробувати пізніше.
масштабування
Ролі connector, input processor і output processor немає стану, що дозволяє нам масштабувати систему горизонтально, просто додаючи нові екземпляри програми з включеної роллю потрібного типу. Для горизонтального масштабування storage використовується для організації кластера з використанням віртуальних бакетів. Після додавання нового сервера, частина бакетів зі старих серверів у фоновому режимі переїжджає на новий сервер; це відбувається прозоро для користувачів і не позначається на роботі системи.
Властивості даних
Об'єкти можуть бути дуже великими та містити інші об'єкти. Ми забезпечуємо атомарність додавання та оновлення даних, зберігаючи об'єкт із усіма залежностями на один віртуальний бакет. Таким чином виключається «розмазування» об'єкта кількома фізичними серверами.
Підтримується версійність: кожне оновлення об'єкта створює нову версію, і ми завжди можемо зробити тимчасовий зріз і подивитися, як тоді виглядав світ. Для даних, яким не потрібна довга історія, ми можемо обмежити кількість версій або навіть зберігати лише одну — останню, тобто фактично відключити версію для певного типу. Також можна обмежити історію за часом: наприклад, видаляти всі об'єкти деякого типу старше 1 року. Підтримується і архівація: ми можемо вивантажувати об'єкти старші за вказаний час, звільняючи місце в кластері.
Завдання
З цікавих функцій варто відзначити можливість запуску завдань за розкладом, на запит користувача або програмно з пісочниці:
Тут ми бачимо ще одну роль – runner. Ця роль не має стану, і при необхідності до кластера можна додати додаткові екземпляри програми з цією роллю. Відповідальність runner – виконання завдань. Як говорилося, з пісочниці можливе породження нових завдань; вони зберігаються у черзі на storage і потім виконуються на runner. Цей тип завдань називається Job. Також у нас є тип завдань, званий Task - це завдання, що визначаються користувачем і запускаються за розкладом (використовується синтаксис cron) або на вимогу. Для запуску та відстеження таких завдань ми маємо зручний диспетчер завдань. Для того, щоб даний функціонал був доступний, необхідно включити роль scheduler; ця роль має стан, тому не масштабується, що, втім, і не потрібно; при цьому вона, як і всі інші ролі, може мати репліку, яка починає працювати, якщо майстер раптом відмовив.
Лісоруб
Ще одна роль називається logger. Вона збирає логи з усіх членів кластера і надає інтерфейс для їх розвантаження та перегляду через веб-інтерфейс.
Сервіси
Варто згадати, що система дозволяє легко створювати послуги. У конфігураційному файлі можна вказати, які запити надсилати на написаний користувачем обробник, що виконується у пісочниці. У цьому обробнику можна, наприклад, виконати аналітичний запит і повернути результат.
Сервіс описується у конфігураційному файлі:
services:
sum:
doc: "adds two numbers"
function: sum
return_type: int
args:
x: int
y: int
GraphQL API генерується автоматично і сервіс стає доступним для виклику:
query {
sum(x: 1, y: 2)
}
Це призведе до виклику оброблювача sum, який поверне результат:
3
Профілювання запитів та метрики
Для розуміння роботи системи та профілювання запитів ми реалізували підтримку протоколу OpenTracing. Система може на вимогу надсилати інформацію інструментам, які підтримують цей протокол, наприклад, Zipkin, що дозволить розібратися з тим, як виконувався запит:
Звичайно, система надає внутрішні метрики, які можна збирати за допомогою Prometheus та візуалізувати за допомогою Grafana.
Деплой
Tarantool Data Grid може бути задеплоєний з RPM-пакетів або архіву, за допомогою утиліти з поставки або Ansible, також є підтримка Kubernetes ().
Додаток, що реалізує бізнес логіку (конфігурація, обробники), завантажуються в задеплоєний кластер Tarantool Data Grid у вигляді архіву через UI або за допомогою скрипту, через наданий нами API.
Букварі філософії
Які програми можна створити за допомогою Tarantool Data Grid? Насправді більшість бізнес-завдань так чи інакше пов'язані з обробкою потоку даних, зберіганням та доступом до них. Тому, якщо у вас є великі потоки даних, які необхідно надійно зберігати і мати доступ до них, то наш продукт може заощадити вам багато часу на розробці і зосередиться на своїй бізнес-логіці.
Наприклад, ми хочемо збирати інформацію про ринок нерухомості, щоб у подальшому, наприклад, мати інформацію про найвигідніші пропозиції. У цьому випадку ми виділимо такі завдання:
- Роботи, які збирають інформацію з відкритих джерел, — це будуть наші джерела даних. Це завдання можна вирішити, використовуючи готові рішення або написавши код будь-якою мовою.
- Далі Tarantool Data Grid прийме та збереже дані. Якщо формат даних із різних джерел відрізняється, то ви можете написати код мовою Lua, яка виконає приведення до єдиного формату. На етапі попередньої обробки ви також зможете, наприклад, фільтрувати пропозиції, що повторюються, або додатково оновлювати в базі даних інформацію про агентів, що працюють на ринку.
- Зараз у вас вже є рішення в кластері, яке можна наповнювати даними і робити вибірки даних. Далі ви можете реалізовувати новий функціонал, наприклад, написати сервіс, який зробить запит до даних і видасть найвигіднішу пропозицію за добу — це вимагатиме кількох рядків у конфігураційному файлі та трохи коду на Lua.
Що далі?
У нас у пріоритеті — підвищення зручності розробки за допомогою . Наприклад, це IDE з підтримкою профілювання та налагодження обробників, які працюють у пісочниці.
Також ми приділяємо велику увагу питанням безпеки. Прямо зараз ми проходимо сертифікацію ФСТЕК Росії, щоб підтвердити високий рівень безпеки і відповідати вимогам сертифікації програмних продуктів, що використовуються в інформаційних системах персональних даних і державних інформаційних системах.
Джерело: habr.com