Клиент
Наш заказчик предоставляет облачную платформу, с помощью которой ведущие разработчики ПО собирают статистику использования своих приложений. В частности, платформа показывает, какие функции используются часто, а какие редко; на что обращают внимание пользователи и какие у них возникают трудности. Это позволяет лучше понять потребности конечных пользователей, учесть их при разработке новых версий и таким образом повысить ценность продукта.
Задачи
Существующее решение в основном работало с десктопными приложениями. Клиент поставил цель — создать новую систему на базе современных технологий, которая могла бы работать и с десктопными, и с веб-приложениями. Предполагается, что покупатели решения будут интегрировать его в разрабатываемые продукты, чтобы собирать информацию о действиях пользователей. Система должна быть простой в установке, поддержке и обновлении. Кроме того, она должна быть гибко настраиваемой, чтобы разработчики приложений могли выбрать, какие им нужны показатели и отчёты.
Решение
С самого начала стало понятно, что систему следует разделить на три группы компонентов: серверные, клиентские и SDK. При этом для SDK нужно было сделать две версии — на C и на JavaScript, — одинаково работающих с одними и теми же конечными точками API. Серверный API должен поддерживать клиентские SDK, получать входящие данные и создавать автоматические и пользовательские отчёты. Клиентский компонент (интерфейс) должен выводить данные в виде диаграмм со множеством настроек.
Клиентские SDK
Веб-компонент SDK собран на чистом JavaScript и ECMAScript-5, что обеспечило совместимость практически со всеми возможными браузерами. Для поддержки десктопных приложений мы разработали динамическую библиотеку ссылок на C. Оба компонента совершенно нетерпимы к ошибкам; любая ошибка должна быть выявлена до того, как она сможет привести к некорректной работе основного приложения. Соответственно, компоненты обрабатывают все ошибки внутри себя и отправляют уведомление о том, завершилась ли операция успешно.
Хранилище данных
Хранилище разделено на реляционную и нереляционную базы данных. В реляционной базе хранятся, как обычно, учётные данные пользователей, предпочитаемые настройки, структуры отчётов и фильтры. Для всего этого нам было достаточно PostgreSQL.
Выбор нереляционной СУБД оказался не таким простым. Изучив разные варианты, мы решили использовать для хранения данных о входящих событиях InfluxDB — БД для хранения временных рядов. Нам очень импонировал безсхемный подход, поскольку приложение заказчика могло отправлять неопределяемые данные, а хранить нужно всё. Мы создали прототип, и на небольших объёмах данных он показал себя неплохо, однако после тестирования производительности стало ясно, что с рабочей нагрузкой InfluxDB не справится.
Мы изучили другие варианты, и наш выбор пал на ClickHouse. Это тоже столбцовая база данных, однако, в отличие от InfluxDB, она использует строгую схему, поэтому нам нужно было создать множество столбцов, которые пользователи далее привязывали бы к собираемым показателям. ClickHouse хорошо справлялась с высокой нагрузкой.
Серверные компоненты
Со стороны сервера мы создали два отдельных компонента: первый принимает, проверяет и нормализует входящие данные, а затем отправляет их в ClickHouse через промежуточный буфер, а второй отвечает за авторизацию пользователей, обработку входящих запросов на отчёты, собственно создание отчётов и отправку их в компонент пользовательского интерфейса. Оба серверных компонента имеют требуемый уровень доступа к базам ClickHouse и PostgreSQL.
Компонент пользовательского интерфейса (клиентский компонент)
Пользовательский интерфейс, с помощью которого можно просматривать и обрабатывать полученные данные, реализован как одностраничное приложение (SPA) на базе библиотеки React. Через интерфейс пользователь получает доступ к отчётам, может копировать их, переименовывать, а также применять фильтры. Для отображения данных о перемещениях пользователей внутри приложения строятся разнообразные диаграммы — столбчатые, составные, линейные, круговые, диаграммы Сэнкей и др. — с помощью библиотеки D3.js.
Общая схема архитектуры приложения выглядит следующим образом:
Результат
Мы создали гетерогенную (интегрирующую сервера различных СУБД) информационную систему, предназначенную для локальной установки. Она включает несколько клиентских и серверных компонентов для обработки потока данных. Система поддерживает версионирование и поставляется через Docker. Уровень масштабируемости проверен методом тестирования производительности и стресс-тестов, однако в будущем его можно улучшить за счёт использования кластеров ClickHouse.