Інтеграція Ankr API: де ламається мультичейн-доступ
Мультичейн-доступ виглядає простим, поки застосунок працює з однією-двома мережами.
Щойно мереж десятки, єдиний шлюз — наприклад, Ankr — перестає бути зручною точкою входу і стає місцем, де сходяться всі відмови: у кожної мережі своя затримка підтвердження блоку, своя політика лімітів і своя поведінка під перевантаженням.
Таймаути вузлів влаштовані неоднаково: запит до швидкої мережі повертається миттєво, а повільна тримає з’єднання до обриву, і накопичена черга з’їдає пропускну здатність інших напрямів.
Ліміти запитів теж різняться за мережами — паралельне опитування десятка мереж швидко вичерпує квоту, частина запитів відбивається мовчки, і застосунок замість помилки отримує порожню відповідь.
Звідси наступний клас проблем — розсинхрон даних. Одна мережа вже підтвердила переказ, друга віддає попередній стан, і підсумковий баланс не сходиться з тим, що очікує бізнес-сценарій.
На піковому навантаженні це виглядає як мовчазна деградація: явних відмов у логах немає, а частка успішних відповідей падає в рази.
Розбираємо, як це закривається: маршрутизацією запитів за мережами, окремими політиками повторів і контролем свіжості даних — щоб шлюз витримував зростання навантаження без ручного розбору інцидентів.
Що змінюється після переходу на єдиний шлюз до мереж
Поки кожна мережа підключена власним вузлом, команда тримає стільки ж незалежних контурів: свою адресу, свої ліміти, свою логіку перепідключення і своє сповіщення про падіння.
Деградація одного вузла не видна на загальному графіку — вона проявляється як зростання частки неуспішних запитів у конкретного сценарію, і пошук причини починається з ручного перебору вузлів.
Єдиний шар доступу прибирає цю розгалуженість: звернення йдуть через один шлюз Ankr із загальним форматом запиту, і перемикання на резерв відбувається автоматично, а не за дзвінком чергового.
Час відновлення після відмови вузла вимірюється секундами — клієнтський код надсилає той самий запит, маршрутизацію змінює шлюз.
Друга вимірювана величина — частка успішних запитів. За прямих підключень вона просідає через розсинхрон вузла, обрив підписки на потік подій і вичерпання локального ліміту.
Це один клас відмов: шлюз сам виключає відсталий вузол із ротації і переводить потік на актуальний, тому сценарії на кшталт нарахування балансів і обліку переказів перестають залежати від стану конкретної ноди.
Супровід підключень стає плоским: нова мережа додається записом у конфігурацію, а не окремою обв’язкою, моніторинг дивиться в одну точку входу замість десятка різнорідних. Розбираємо, які мережі переводимо на спільний шлюз одразу, а які залишаємо на власному вузлі.
Способи підключення до Ankr: вузол, провайдер, гібрид
Варіанти доступу до мережі різняться не «якістю», а профілем навантаження: скільки унікальних методів викликається, чи потрібні підписки на події, наскільки критична затримка і чи допустимо віддавати адреси гаманців зовнішньому провайдеру.
Тому один варіант на весь проєкт обирають рідко — зазвичай це комбінація під різні сценарії та різні мережі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний вузол | Повний контроль над даними, приватні методи, рівномірне й високе навантаження на одну мережу | Синхронізацію та обслуговування беремо на себе; рідкісні мережі дорогі в підтримці |
| Публічний шлюз | Швидкий старт, читання балансів та історії транзакцій, піки трафіку | Спільні ліміти на частоту запитів, немає гарантій щодо приватності та часу відповіді під піком |
| Гібридна схема | Критичні мережі тримаємо самі, решту — через провайдера | Потрібна маршрутизація та єдина точка адресації запитів |
| Проміжний шар із кешуванням | Часто повторювані читання: блоки, списки токенів, метадані | Кеш інвалідується за номером блоку, інакше віддаємо застарілий стан |
Проміжний шар зазвичай і стає основною робочою схемою: він тримає кеш відповідей за номером блоку, повторює запит у разі відмови, перемикає маршрут між власним вузлом і шлюзом без правок у коді сервісу.
Розберімо, як це виглядає на рівні конфігурації і які перевірки ставимо перед виводом у робоче середовище.
Як відбувається впровадження: шість етапів інженерної роботи
Порядок етапів не випадковий: спочатку фіксуємо, як сервіс звертається до мереж зараз, потім будуємо маршрут, який переживе відмову окремого вузла, і лише потім переводимо на нього трафік. Нижче — як виглядає інтеграція з Ankr від розбору до передачі вашій команді.
- Розбір поточних підключень. Інвентаризуємо всі звернення до мереж: які мережі та методи задіяні, скільки запитів дає кожен сервіс, де підключення йде напряму до вузла, а де вже є проміжний шар.
- Схема відмовостійкості. Визначаємо, як запити розподіляються між незалежними точками доступу, за яких помилок і таймаутів спрацьовує перемикання і що бачить користувач, поки воно триває.
- Ключі та ліміти. Заводимо окремі ключі за середовищами та сервісами, задаємо квоти й пріоритети так, щоб фонові задачі не витісняли користувацькі запити, і плануємо ротацію.
- Перевірка на бойовому трафіку. Частина запитів іде паралельно за новим маршрутом: порівнюємо відповіді та затримки, дивимося частку успішних звернень і поведінку під час деградації.
- Документація та регламенти. Фіксуємо конфігурації, логіку перемикань і порядок дій у разі збою — з ознаками, за якими черговий одразу розуміє, що робити.
- Передача команді. Розбираємо з вашими інженерами керування ключами, метрики та типові відмови, домовляємося про межі підтримки.
Що залишається в проєкті після здачі робіт
Робота над інтеграцією закінчується не запуском в основну мережу, а передачею вашій команді повного набору артефактів щодо мультичейн-доступу через Ankr.
Нижче — те, що залишається у вашому репозиторії та внутрішній документації: кожен пункт можна відкрити, перевірити й застосувати без нашої участі.
- Конфігурації доступу — адреси ендпоінтів, ліміти та квоти за кожною мережею окремо, ключі в секрет-сховищі з ротацією, а не в коді.
- Схеми перемикань — який маршрут основний, який резервний, за якою ознакою спрацьовує перемикання і як система повертається назад після відновлення.
- Правила розмежування прав — матриця «роль → дозволені методи та мережі»: тестовий контур не може надіслати транзакцію в основну мережу.
- Регламент деградації — пороги за часткою помилок і часом відповіді, за яких сервіс переходить у режим читання, та умови виходу з нього.
- Інструкції для чергової зміни — покрокові сценарії на типові відмови: провайдер не відповідає, вичерпано квоту, розходяться дані між мережами.
- Панель моніторингу — метрики за кожною мережею та правила оповіщень: що черговий лагодить сам, а що ескалює.
- Порядок змін — як додати нову мережу або метод, не чіпаючи код, і де фіксується історія правок конфігурацій.
Розбір артефактів проводимо разом із вашими інженерами на передачі: черговий має діяти за інструкцією, а не шукати автора інтеграції.
Кейс: гаманець і аналітика на кількох мережах
Клієнт — некастодіальний гаманець з аналітикою портфеля: баланси, історія транзакцій, вартість активів у кількох мережах. До впровадження кожна мережа підключалася окремим вузлом, конфігурації жили в різних репозиторіях, а додавання нової мережі займало тижні.
Що було до
Шість мереж обслуговувалися вручну, у кожної свій формат відповіді та свій лічильник стану. За місяць фіксували три-чотири простої по 20-40 хвилин: падіння одного підключення зупиняло оновлення балансів по всій мережі, а перемикання на резервний вузол робили руками.
Частка успішних запитів трималася близько 92%, медіанний час відповіді — 1,8 секунди, і третину цього часу з’їдали повторні спроби при таймаутах.
Що змінили
Звели всі мережі в одну точку доступу на Ankr: перемикання між мережами йде за ідентифікатором мережі, формат відповіді однаковий, відмова одного вузла обробляється повтором на резервний без участі чергового.
Аналітика перейшла з шести окремих збирачів на один конвеєр — дані за всіма мережами надходять у загальному вигляді, різниться лише поле мережі.
Що стало
Покриття зросло з шести мереж до чотирнадцяти, додавання нової мережі займає дні, а не тижні. Простій за квартал — один епізод на 6 хвилин замість серії багатогодинних відмов, частка успішних запитів — 99,4%, медіанний час відповіді впав до 0,4 секунди.
Навантаження на аналітику знизилося: добовий звіт збирається хвилини замість годин, а підтримка більше не тримає таблицю з адресами вузлів за кожною мережею.
Чим відрізняються розширені методи від базових викликів?
Базовий виклик відповідає на одне питання: баланс адреси в конкретній мережі, номер блоку, читання одного контракту. Він передбачуваний за часом відповіді та витратою ресурсів — на таких запитах будуються сценарії з однією мережею та однією метрикою.
Розширений метод відповідає на складене питання: агрегує дані за кількома мережами, додає до балансу метадані токена та історію операцій, віддає портфель адреси однією відповіддю.
У Ankr такі виклики йдуть через той самий шлюз, що й базові, тому виграш рахується в кількості звернень: замість перебору мереж циклом клієнт отримує готову структуру.
Базового виклику достатньо, коли задача локальна: одна мережа, одна адреса, рідкісні опитування. Розширений метод поверне зайві поля, довше збиратиме відповідь і витратить ресурс шлюзу на дані, які ніхто не використовує. Тут вибір методу — про відповідність задачі, а не про його потужність.
Зворотний бік видно на потокових сценаріях.
Якщо через один шлюз іде постійне оновлення тисяч гаманців, агрегувальний запит на кожну подію створює навантаження на шлюз, до якого він не розрахований: зростає черга, з’являються відмови за частотою, а вартість запиту вимірюється витратою ресурсів і квоти, а не кількістю рядків у відповіді.
Тому вибір методу ми робимо за профілем навантаження: скільки мереж в одній відповіді, як часто повторюється запит, чи потрібна історія.
Далі — кеш проміжних результатів, групування однотипних читань і розділення потоків за окремими підключеннями, щоб розширені методи залишалися там, де дають виграш.
Технічні сумніви перед стартом робіт
Перед стартом інтеграції в інженерної команди випливають ті самі питання: що робити з уже розгорнутими нодами, як шлюз поводиться під навантаженням, що станеться при вичерпанні лімітів на ключ. Розбираємо їх до початку робіт, щоб рішення щодо стійкості не ухвалювалися в поспіху.
У нас уже розгорнуті власні ноди — чи не буде дублювання?
Шлюз Ankr вбудовується як додатковий маршрут, а не заміна. Власні ноди залишаються для критичних викликів і записів, шлюз закриває читання за мережами, які невигідно тримати на своєму залізі.
Маршрутизація йде за типом виклику: потрібен повний контроль — ідемо напряму, потрібна широта охоплення — через шлюз.
Як влаштовані ліміти на ключ і що при їх вичерпанні?
Ліміт прив’язаний до ключа і рахується за кількістю запитів в інтервал, тому ключі розносяться за сервісами — сплеск в одному не блокує інші. Біля порога вмикається черга з повторами та перехід на резервний ключ. Окремий лічильник і оповіщення показують запас заздалегідь, а не за фактом відмови.
Що буде, якщо шлюз стане недоступним?
Доступність перевіряється постійно, і при деградації трафік автоматично повертається на власні ноди або на другого постачальника. Зворотний перехід займає секунди і не потребує ручного втручання — резервний маршрут закладається одразу, а не після першого збою.
Як переконатися, що дані зі шлюзу коректні?
Звіряємо відповіді шлюзу з власними нодами на вибірці адрес і блоків, розходження фіксуємо, а не гасимо. Для критичних сценаріїв додаємо підтвердження за кількома джерелами. Якщо мережа віддає застарілі дані, запит повторюється з явним зазначенням глибини.
Обговоримо задачу і повернемося з планом та оцінкою
Опишіть задачу у вільній формі: які мережі потрібні, які виклики до вузлів робить застосунок і в якому режимі. Цього достатньо, щоб ми повернулися з оцінкою обсягу та схемою робіт — без загальних слів про «мультичейн» і «надійність».
Що корисно додати одразу:
- Перелік мереж і пріоритет: де запускаєтеся першими, де — у другій хвилі.
- Які методи потрібні: читання балансів і логів, надсилання транзакцій, підписки на події.
- Профіль навантаження: пікові запити за секунду, добовий обсяг, сезонні сплески.
- Вимоги до доступності та глибини історії блоків, чи потрібен архівний вузол.
- Що вже використовується: власні вузли, інші джерела доступу, кешування та черги.
- Хто приймає результат і до якої дати потрібен робочий контур.
У відповідь надішлемо схему робіт і план впровадження за етапами: отримання доступів і перевірка ключів, маршрутизація запитів між мережами, відмовостійкість із перемиканням при збої джерела, ліміти та моніторинг.
Схема покаже, де інтеграція Ankr API закриває задачу цілком, а де потрібен власний вузол або проміжний шар.
Окремим пунктом додамо перелік питань, які потрібно закрити до старту, — зазвичай саме вони визначають строк. Обговоримо задачу: назвіть зручний канал зв’язку, і ми повернемося з оцінкою та планом.
