Проксирование jsonrpc вызовов через тарантул

Очень часто наша команда сталкивается с проблемой рассинхронизации наших собственных сид-нод, о которых нам поведал @muhazokotuha и, как следствие, плохой скоростью отдачи ресурса golos.io. Давайте разберемся с тем, что происходит в клиентской части голоса.

Первым клиентом для блокчейна “ГОЛОС” стало изоморфное javascript-приложение на ресурсе golos.io.

Рассмотрим, что происходит в момент отгрузки страницы "Популярное":

1. Браузер выполняет запрос файла в html-формате к нашему ресурсу по адресу http://golos.io/trending.
2. Серверная NodeJS часть опрашивает блокчейн, формирует ответ в виде html-страницы и отправляет ее браузеру.
3. Транспортировка файла от сервера к клиенту почти незаметна. Когда html-файл загружен, браузер выделяет из html-файла дополнительные файлы для загрузки стилей (css), скриптов приложения (javascript), картинок и других не менее важных файлов.
4. Браузер запрашивает все эти недостающие файлы.

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

Правильно было бы подгружать только само приложение скажите Вы, а только потом уже отдавать данные из блокчейна. И я бы согласился с такой формулировкой, если бы не одно но! На данный момент кроме нашего с Вами сообщества, контент из блокчейна потребляют поисковые роботы Яндекса, Гугла и других систем. Для того чтобы боты считывали контент корректно, сервер отдает html-страницы с контентом внутри, иначе golos.io просто не будут индексировать поисковые системы. Если golos.io выпадет из поисковой индексации, это плохо скажется на популяризации ресурса в интернете. Почему сайт выпадет из индексации? Все дело в том что golos.io - сайт не со статическими страницами, это javascript динамическое приложение. Репозиторий которого расположен здесь.

Что у нас получается, когда сиднода рассинхронизировалась, и мы не можем вытащить из нее данные? Правильно, сайт выдает “ошибку 500” или вообще не грузится. Узким местом в нашем приложении остается получение данных из блокчейна. По этой причине и происходит длительная загрузка страниц сайта. Кроме того, некоторые запросы в блочкейн ГОЛОСа очень ресурсоемкие. Например JSONRPC запрос getState(/trending) или getState(/created) являются одними из самых сложных запросов с точки зрения сбора данных из всей цепочки блоков блокчейна.

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

Вопрос: Почему?
Ответ: С таким решением мы возвращаемся в прошлый век централизованного управления, где взлом БД влечет за собой все те же проблемы целостности данных.

Решение с поднятием еще 100500 дополнительных сиднод не работает. Причины рассинхронизации описаны здесь.

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

Логика работы данного подхода следующая:

1. 1000 пользователей открыли браузер и запросили страницу golos.io.
2. Сервер считал самый первый запрос, сбегал в блокчейн, сохранил ответ в кэше тарантула и отдал данные уже из кэша. Получается, что все получили одинаковый результат, не запрашивая данные из блокчейна 1000 раз. В блокчейн последовал всего 1 запрос.

Конечно это идеальная картина, на самом деле в момент загрузки страницы golos.io данных из блокчейна берется много. Если вам интересно насколько много, можете повнимательнее рассмотреть логику изоморфной генерации страницы тут. Смотрим вызовы api & proxify.

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

Есть немного статистики из Гугла. Ниже представлены 4 скриншота. Каждый представляет из себя выборку из двух выходных дне из двух выходных дней текущего месяца. Кеширование было запущено в тестовом режиме в пятницу 27-го октября 2017 г.  Сегодня понедельник, и мы смело можем взять прошедшие два выходных дня как период для сравнения.

Выборка с 7 по 8

Выборка с 14 по 15

Выборка с 21 по 22

Выборка с 28 по 29

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

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

@pav
Команда Golos.io