Tokenplace: Криптовалютный стартап снаружи и изнутри

Желая извлечь выгоду из торговли криптовалютой, нет смысла ограничиваться только одной биржей — даже простой уровень спроса, не говоря уже о курсе, существенно варьируется от биржи к бирже. Это заставляет следить за курсами и их изменениями сразу на нескольких ресурсах, что занимает ощутимо больше времени и создает хаос. В данной статье мы расскажем, как нам удалось оптимизировать этот процесс.

Задача: централизовать статистику и действия с множества бирж в одном месте.

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

Проблема заключается в том, что сбор котировок со всех бирж займет у пользователя время, а обилие вкладок браузера (на каждую биржу — как минимум по одной) усложнит работу. Учитывая, что эта задача регулярная и повторяющаяся, количество затрачиваемого времени переходит все разумные границы. Нужно оптимизировать!

Решение: единый портал, интегрированный с крупнейшими биржами криптовалют.

Как это работает? Зарегистрировавшись на портале, пользователь может привязать свои учетные записи с крупнейших бирж, используя API ключи, и получить всю необходимую информацию в одном месте — своё полное портфолио с учётом всех валют на всех биржах, глобальную историю продаж, курс интересующей пары на каждой бирже и его изменение, уровень спроса и предложения, и, что самое важное, ещё и в один клик провести нужную операцию, не уходя с портала.

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

Как это устроено изнутри?

В общих чертах разработка делится на следующие шаги:

— Итак, нам нужно собрать необходимую информацию. Как?

Было выбрано несколько наиболее популярных и стабильных бирж криптовалют (Binance, Bitfinex, Bitstamp, Bittrex, Coinbase, Hitbtc, Huobi, Kucoin, Okex, Poloniex). Поскольку пользователи решали одни и те же задачи на каждой из них, интеграцию в Tokenplace выполнял один модуль с универсальным интерфейсом и различной реализацией в зависимости от той или иной биржи. Например, каждая биржа имеет свой формат обмена данными и API, или например, пара биткоин — доллар США может иметь вид: btcusd, BTCUSD, BTC-USD и BTC_USD. Поэтому для каждой биржи реализованы свойственные только ей методы защиты, списки поддерживаемых действий, а управление и обмен данными с главным приложением унифицированы. Такой подход позволил быстро подключать новые биржи в приложение, минимизировать затраты на обеспечение качества продукта, так как при отладке интеграции с каждой новой биржей невозможно испортить работу уже существующих.

Большое внимание уделено информационной безопасности. Применены как стандартные подходы к криптозащите (обмен данными по защищенному протоколу HTTPS, шифрование данных с помощью уникальных одноразовых токенов (nonce), “соль” для защиты от атак через “радужные таблицы” и т.д.), так и ряд специальных мер.

Имея многолетний опыт интеграций с различными финтех-сервисами мы учитывали следующие особенности:

• Часто API даже самых известных продуктов не имеют актуальной документации, это влияет на таймлайн интеграционного проекта. Гарантировать результат в срок может только подрядчик с опытом подобных интеграций.

• Любые API не статичны, они развиваются вместе со своими продуктами. Увы, не всегда обеспечивается обратная совместимость и своевременное информирование владельцев интегрированных сервисов об изменениях. Поэтому в разработке подобных систем наряду с умной обработкой исключительных ситуаций непосредственно в коде, мы рекомендуем внедрение в продукт средств мониторинга и анализа данных, например, Kibana, которые своевременно помогут администраторам сервиса среагировать на аварию.

• Узкое место многих API — это обработка исключительных ситуаций: если отправить запрос содержащий неверные данные, как, например, покупка биржевого инструмента на средства, превышающие установленные лимиты, то в ёмком ответе «Forbidden” никак не узнать причину отказа. Такие особенности требуют реализации дополнительных проверок на бирже и понимания последовательности их вызовов.

— Биржи подключили; теперь работаем над скоростью?

Действительно, сбор нужной информации для одного клиента мог занимать огромное количество времени: стучимся в биржу А и запрашиваем баланс. В ответ получаем только список валют и их количество. Но ведь этого мало: мы хотим знать, как эти валюты чувствуют себя сейчас на этой бирже, что новенького произошло в их жизни за последнее время, и сколько вечнозелёных президентов за них дают.

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

Так как мы не хотели заставлять посетителей ждать по 30 секунд, пока их данные загрузятся, нужно было действовать.

Целевая аудитория сервиса — это среднесрочные и долгосрочные криптоинвесторы, для которых не требуется актуальность котировок в реальном времени. Поэтому мы внедрили механизм умной загрузки котировок — единожды загруженные пары валют запоминались для всех пользователей системы в течении периода актуальности, а данные которые требовались каждому конкретному пользователю (такие как динамика портфеля, заявки и т.д.) запоминались и актуализировались на сервере нашего приложения, что существенно снизило потребность регулярного обращения к биржам через их API. Например, запрос баланса при отображении разных страниц приложения происходил не при открытии каждой, а один раз, и обновлялся на основе изменений курсов, которые актуализировались для всех пользователей одновременно.

— Но ведь можно ещё быстрее?

Для этого клиентская часть выполнена в виде легкого и функционального SPA (Single Page Application) с использованием vue.js и хранилища vuex. Хранилище сыграло огромную роль в «облегчении»: с одной стороны, точно зная, что требует обновления, мы могли гораздо меньше обращаться к серверу, пользуясь хранилищем, а с другой — пока пользователь просматривал курсы в одной бирже, мы могли незаметно для него обновить данные по другой в бекграунде.

Описанная архитектура и накопление исторических данных дает возможность без ущерба для скорости доступа к данным отображать динамику баланса пользователя на графиках по всем биржам в зависимости от его торговли и изменения курса валют.

Для отображения свечных диаграмм, индикаторов и инструментов теханализа применены компоненты от TradingView — на наш взгляд они одни из самых удобных.

— А будет ли так же быстро, когда на сервис придет много пользователей?

Для этого мы провели нагрузочное тестирование, чтобы понять, как система себя поведет при возрастающем количестве запросов, при каком количестве одновременно работающих пользователей она перестанет работать, какая серверная инфраструктура обеспечивает масштабирование приложения с ростом числа пользователей.

Реальные биржи:

• Не позволяют с одного ip адреса отправлять к себе большое количество запросов одновременно
• Не все биржи предоставляют возможность создания тестовой учетной записи без валидации пользователей или возможности торговли на демо-счетах.

Чтобы обойти данные ограничения мы приняли решение мокировать (симулировать) действия биржи через наш внутренний сервис и проверять поведение именно приложения. Мы знали, как сервис “общается” с биржами, какие запросы отправляет и какие ответы ожидает получить. Были созданы скрипты, которые максимально точно имитировали действия разных пользователей во время клиентской сессии. А что обычно делает клиент в этом приложении? Покупает, продает монеты и отслеживает динамику портфеля. Зная времена ответа на запросы реальных бирж, мы настроили работу приложения таким образом, что с увеличением числа пользователей нагрузка росла линейно, что позволяло развернуть приложение на любых популярных облачных серверах.

На первом графике видно увеличение количества запросов в секунду (requests per second) с течением времени теста. При этом время ответа сервера на 3 самых популярных пользовательских запроса (второй график) не превысило 0,911 секунды.

— Из интересного:

Мы заметили, что биржи в своих API почти не предлагает т.н. отложенные заявки или shadow order (невидимый заказ, который разместится только тогда, когда заранее заданные условия будут выполнены). А ведь у нас уже были все детали пазла в руках: мы и так регулярно получали свежайшие котировки разных бирж и состояние балансов, а, значит, вполне могли заодно проверить, не сработал ли триггер для размещения подобного заказа. Пожалуй, получившаяся платформа была просто создана для такой возможности.

— Happy End

Главное в работе — это положительный результат, признанный нашими клиентами. Мы были рады помочь владельцам Tokenplace в развитии отличного финтех-продукта.