Інтеграція з CCXT: універсальний API бірж під ключ

CCXT інтеграція: де ламається обмін із біржами

Одна біржа — це набір дрібних компромісів, які не видно до другого підключення.

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

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

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

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

Далі розходяться баланси: кошти заблоковані під відкриті заявки, комісії списані не там, де очікувалося, депозити за різними мережами враховані одним числом.

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

У сумі виходить система, де помилку видно лише в логах, відмова приходить без винятку, а відновлення робиться руками. Розбираємо, як це закривається.

Що дає єдиний шар доступу до бірж

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

CCXT прибирає цю різнорідність: замість набору самописних обгорток — єдиний інтерфейс до бірж із загальним набором операцій.

Єдиний формат даних — основне джерело економії. Ордербуки, свічки, баланси та статуси угод надходять в одній структурі незалежно від джерела, тому логіка стратегії, обліку ризиків і звітності не містить розгалужень під кожен майданчик. Клас помилок «на цій біржі поле називається інакше» перестає існувати.

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

На практиці це години замість тижнів, і такий самий порядок — під час додавання нового типу інструментів.

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

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

Режими підключення до бірж: що вибрати

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

Торгові не переживають: без ідемпотентного ключа повтор ордера перетворюється на дублювальну позицію.

Нижче — чотири моделі доступу, між якими реально вибирають на старті проєкту.

Ключі в будь-якому варіанті зберігаються поза кодом — у захищеному сховищі з роздільними правами на читання, торгівлю та виведення.

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

Етапи впровадження: від аудиту до передачі

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

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

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

2. Проєктування потоків даних. Визначаємо, які сутності ходять між біржами та обліковою системою: заявки, угоди, баланси, історія. Для кожної вибираємо режим отримання — потокові підписки там, де потрібна реакція за секунди, періодичні зрізи там, де достатньо звірки. Окремо описуємо, що робити під час розходження даних між джерелами.

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

4. Обробка помилок і лімітів. Опрацьовуємо те, що ламається в реальній торгівлі: обриви з'єднання, відмови біржі, часткове виконання, повторне надсилання однієї й тієї самої заявки. Обмежувач частоти запитів і повтори з наростаючою паузою не дають інтеграції піти в блокування.

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

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

Артефакти впровадження: конфігурації, схеми, регламенти

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

• Конфігурації підключень. Окремий набір параметрів для кожного майданчика: перелік ринків, ліміти запитів, таймаути, правила повторів, розділення ключів на читання даних і на торгівлю.
• Схема потоків даних. Діаграма руху ордерів, угод і балансів від інтерфейсу біржі до сховища: де формат нормалізується й де сходяться розходження між біржами.
• Політики доступу та ролі. Матриця «роль — дія»: хто бачить ключі, хто змінює ліміти, хто запускає ручні операції, плюс правила ротації ключів і порядок зберігання секретів.
• Регламент обробки помилок. Таблиця типових відмов — біржа недоступна, перевищено ліміт запитів, ордер відхилено — із зазначенням, що система виправляє сама і коли викликає чергового.
• Передача документації. Опис модулів, інструкції з локального запуску й розбору інцидентів, журнал змін і підсумковий розбір упровадження з вашою командою.
• Спостережуваність. Метрики й порогові значення оповіщень за кожним майданчиком, щоб збій на біржі фіксувався раніше, ніж стане збитком.

Кейс: зняли ручні звірки між біржами

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

Дані сходилися лише в таблицях в аналітика, і будь-яка затримка вивантаження означала, що рішення ухвалюється за застарілими залишками.

Що було до змін

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

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

Підключення нової біржі займало 3–4 тижні: писали конектор, окремо налагоджували формати відповідей, окремо — обробку часткових виконань.

Що змінили

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

Звірка залишків тепер іде за розкладом, розходження потрапляють у чергу з повідомленням і не потребують ручного пошуку.

Що стало

Ручних операцій залишилося дві на тиждень — лише за спірними позиціями. Розходження фіксується в межах одного циклу звірки, а не через кілька днів. Нова біржа виводиться в роботу за 4–6 днів: залишається заповнити карту символів і перевірити поведінку лімітів запитів.

Відключення майданчика — керований крок: конектор знімається, історія угод і залишки зберігаються у внутрішньому обліку.

Чим відрізняється CCXT інтеграція від прямих підключень

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

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

Плата за універсальність — втрата окремих випадків.

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

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

Часті технічні питання щодо підключення бірж

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

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

Що станеться під час збою на боці біржі?

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

Як додається нова біржа?

Пишемо адаптер до спільної моделі даних: інструменти, типи ордерів, формати відповідей. Спершу перевіряємо на тестовому контурі майданчика, потім вмикаємо до робочого списку — решта логіки правок не потребує.

Чи можна працювати з кількома біржами одночасно?

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

Чи є обмеження за інструментами?

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

Розкажіть про задачу — повернемося з оцінкою та планом

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

• Біржі та спосіб доступу: спотові й ф'ючерсні майданчики, ключі з обмеженими правами, тестові контури бірж.
• Сценарії: виконання заявок, виведення коштів, збір ринкових даних, звірка балансів, звітність для бухгалтерії.
• Поточна схема: свої скрипти, готові бібліотеки або ручні операції; що перевикористовуємо, що переписуємо.
• Обмеження: ліміти запитів майданчиків, вимоги до доступів і журналів, правила зберігання ключів, поведінка під час обриву зв'язку.
• Терміни та пріоритети: які біржі потрібні першими, що можна відкласти на другий етап.
• Пілотний контур: на одному-двох майданчиках перевіряємо зв'язку на реальних, але обмежених обсягах і дивимося логи.

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

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