Загрузка...Синхронизация данных в приложениях реального времени c Theron
Синхронизация данных в приложениях реального времени c Theron
Иногда я рисую себе граф того, как должна выглядеть архитектура современных систем и нахожу те моменты процесса разработки, которые могут быть улучшены и те практики, которые могут быть применены для улучшения этих процессов. После очередной такой итерации я еще раз убедился, что существуют потрясающие фреймворки и методологии для разработки и серверной и клиентской частей, но синхронизация данных между клиентом, сервером и базой данных работает не так, как того требуют современные реалии: быстрое реагирование на изменение состояния системы, распределенность и асинхронность обработки данных, повторное использование раннее обработанных данных.
В последние годы требования к современным приложениям и методы их разработки значительно изменились. Большинство таких приложений используют асинхронную модель, состоящую из множества слабо связанных компонентов (микросервисов). Пользователи же хотят, чтобы приложение работало безотказно и всегда было в актуальном состоянии (данные должны быть синхронизированы в любой момент времени), проще говоря, пользователи чувствуют себя более комфортно, когда им не нужно каждый раз нажимать кнопку «Обновить» или полностью перезагружать приложение, если что-то пошло не так. Под катом немного теории и практики и полноценное приложением c открытым исходным кодом со cтеком разработки React, Redux/Saga, Node, TypeScript и нашим проектом Theron.
Rick and Morty. Рик открывает множество порталов.
Я использовал различные сервисы для синхронизации и хранения данных в реальном времени, большинство из которых упомянуто в этой статье. Но каждый раз, как только приложение развивалось в более сложный продукт, становилось очевидным, что система слишком сильно зависит от одного провайдера услуг и в ней нет той необходимой гибкости, которую дает создание своей микроархитектуры с множеством диверсифицированных сервисов-сателитов, использование классических баз данных (SQL и NoSQL) и написание кода, взамен конструкторам и панелям управления BaaS. Такой подход, действительно, более сложен на начальной стадии разработки прототипа, но он окупает себя в будущем.
Результатом моих исследований стал Theron. Theron — сервис для создания современных приложений реального времени. Реактивное хранилище данных Theron беспрерывно транслирует изменения, произошедшие в базе данных, исходя из запроса к ней. Чуть больше чем за четыре месяца небольшой командой из двух разработчиков мы реализовали базовую архитектуру, основные критерии которой:
- Быстрое создание новых приложений и безболезненная миграция существующих на Theron.
- Использование современных практик при создании асинхронных, распределенных и отказоустойчивых систем и изоморфизм компонентов системы.
- Распределенная интеграция на низком уровне с базами данных, такими как Postgres и Mongo.
- Легкая интеграция с современными фреймворками, такими как React, Angular и их друзьями: ReactiveX, Redux т.д.
- Сфокусированность на решение задачи синхронизации данных, а не предоставление полного стека разработки и последующего «вендор локинга».
- Основная логика приложений (в том числе аутентификация и права доступа) должна реализовываться разработчиками на их стороне.
Реактивные каналы
Мне понравился функциональный подход еще тогда, когда я познакомился с одним из старейших функциональных языков программирования, ориентированным на символьные вычисления Рефал. Позже, сам того не осознавая, я начал использовать реактивную парадигму программирования, и, со временем, большая часть моей работы строилась на этих подходах.
Theron построен на основе ReactiveX. Фундаментальный концепт в Theron —реактивные каналы, предоставляющие гибкий способ трансляции данных различным сегментам пользователей. Theron использует классический Pub/Sub шаблон проектирования. Для создания нового канала (количество неограниченно) и стриминга данных достаточно лишь создать новую подписку.
После установки (англ.), импортируйте Theron и создайте нового клиента:
Создание нового клиента не устанавливает нового WebSocket подключения и не начинает синхронизацию данных. Подключение устанавливается только тогда, когда создается подписка, при условии того, что нет другого активного подключения. То есть в рамках реактивного программирования клиент Theron и каналы — это «cold observable» объекты.
Создайте новую подписку:
Когда канал больше не нужен — отпишитесь:
Отправка данных клиентам, подписанных на этот канал, со стороны сервера (Node.js) также проста:
Theron использует экспоненциальный бэкофф (включен по умолчанию) при потере соединения или при возникновении некритических ошибок (англ.): ошибки, когда возможна повторная подписка на канал.
Реализация многих алгоритмов в рамках реактивного программирования изящна и проста, например, экспоненциальный бэкофф в клиентской библиотеке Theron выглядит примерно так:
Интеграция с базой данных
Как было сказано выше, Theron — это реактивное хранилище данных: система уведомлений об изменениях, которая беспрерывно транслирует обновления по защищенным каналам для вашего приложения, исходя из обычного SQL запроса к базе данных. Theron анализирует запрос к базе данных и отправляет артефакты данных, с помощью которых можно воссоздать исходные данные.
Рассмотрим, как это работает на примере жизненного цикла простого списка, состоящего из первых трех элементов, упорядоченного в алфавитном порядке:
Перед тем как мы продолжим, подключите базу данных к Theron, введя данные для доступа к ней в панели управления:
Внутреннее устройство захвата (locking) базы данных — большая тема для отдельной статьи в будущем. Theron — распределенная система, поэтому пул подключений к базе данных ограничен 10-ю (с возможностью увеличения до 20-и) общими подключениями.
1. Создание новой подписки
Theron работает с SQL запросами, поэтому ваш сервер должен возвращать не результат выполнения запроса, а исходный SQL запрос. Например, в нашем случае JSON ответ сервера может выглядеть так:
На стороне клиента начнем трансляцию данных для нашего SQL запроса, создав новую подписку:
Theron отправит GET запрос ‘/todos’ вашему серверу, проверит валидность возвращенного SQL запроса и начнет трансляцию начальных инструкций с необходимыми данными, если данный запрос не был ранее скэширован на стороне клиента.
Инструкция TheronRowArtefact — это обычный JavaScript объект с самими данными `payload` и типом инструкции `type`. Основные типы инструкций:
- ROW_ADDED — добавлен новый элемент.
- ROW_REMOVED — элемент был удален.
- ROW_MOVED — элемент был изменен.
- ROW_CHANGED — элемент был изменен.
- BEGIN_TRANSACTION — новый блок синхронизации.
- COMMIT_TRANSACTION — синхронизация завершена успешно.
- ROLLBACK_TRANSACTION — при синхронизации возникла ошибка.
| Id | Name | Id | Name |
|---|---|---|---|
| 1 | A | ||
| 2 | B | ||
| 3 | C |
Инструкции Theron для данного состояния:
- < type: ROW_ADDED , payload: < row: < id: 1, name: 'A' >, prevRowId: null > >
- < type: ROW_ADDED , payload: < row: < id: 2, name: 'B' >, prevRowId: 1 >
- < type: ROW_ADDED , payload: < row: < id: 3, name: 'C' >, prevRowId: 2 > >
Каждый блок синхронизации начинается и заканчиваются инструкциями BEGIN_TRANSACTION и COMMIT_TRANSACTION. Для корректной сортировки элементов на стороне клиента Theron дополнительно отправляет данные о предыдущем элементе.
2. Пользователь переименовывает элемент A (1) в D (1)
Предположим, что пользователь переименовывает элемент A (1) в D (1). Так как SQL запрос упорядочивает элементы в алфавитном порядке, то произойдет сортировка элементов, и состояние клиента изменится следующим образом:
| Id | Name | Id | Name |
|---|---|---|---|
| 1 | A | 2 | B |
| 2 | B | 3 | C |
| 3 | C | 1 | D |
Инструкции Theron для данного состояния:
Предположим, что пользователь создает новый элемент A (4). Так как наш SQL запрос ограничивает данные первыми тремя элементами, то на стороне клиента произойдет удаление элемента D (1), и состояние клиента изменится следующим образом:
| Id | Name | Id | Name |
|---|---|---|---|
| 2 | B | 4 | A |
| 3 | C | 2 | B |
| 1 | D | 3 | C |
Инструкции Theron для данного состояния:
Предположим, что пользователь удаляет элемент D (1) из базы данных. Theron в этом случае не отправит новых инструкций, так как это изменение в базе данных не влияет на данные, возвращаемые нашим SQL запросом, и соответственно не влияет на состояние клиента:
| Id | Name | Id | Name |
|---|---|---|---|
| 4 | A | 4 | A |
| 2 | B | 2 | B |
| 3 | C | 3 | C |
Обработка инструкций на стороне клиента
Теперь, зная как Theron работает с данными, мы можем реализовать логику по воссозданию данных на стороне клиента. Алгоритм довольно простой: мы будем использовать тип инструкции и метаданные предыдущего элемента для корректного позиционирования элементов в массиве. В реальном приложении нужно использовать, например, библиотеку Immutable.js для работы с массивами и оператор scan — пример.
Время примеров
Изучать иногда лучше, основываясь на готовых примерах: поэтому вот обещанное приложение, опубликованное под лицензией MIT — https://github.com/therondb/figure. Figure — это сервис для работы с HTML формами в статичных сайтах; cтек разработки — React, Redux/Saga, Node, TypeScript и, конечно, Theron. Например, мы используем Figure для формирования листа подписчиков нашего блога и сайта документации (https://github.com/therondb/therondb.com):
Заключение
Помимо исправления гипотетической тонны ошибок и классического написания клиентских библиотек под популярные платформы, мы работаем над выделением в независимый компонент обратного прокси-сервера и балансировщика. Идея заключается в том, чтобы можно было создавать на стороне сервера API, к которому можно обращаться как через обычные запросы HTTP, так и через постоянное подключение WebSocket. В следующей статье про архитектуру Theron я напишу про это более подробно.
Команда у нас небольшая, но энергичная, и мы любим экспериментировать. Theron находится в активной разработке: есть множество идей и моментов, которые нужно реализовать и улучшить. С удовольствием выслушаем любую критику, примем советы и конструктивно это обсудим.
Синхронизация данных в реальном времени
Курс предназначен для базовой подготовки пользователей, осуществляющих интегрирование продуктов «1С-Битрикс» с торговыми конфигурациями компании «1С».
Пожалуйста, обратите внимание, что платформа 1С — это особая технологическая среда, совершенно отдельная от Битрикс: Управление сайтом. В нашем курсе мы не даем рекомендаций по выбору и приобретению (в том числе и для изучения курса) программ 1С, но рассказываем о способах интеграции с некоторыми из них.
В курсе рассматриваются как штатные способы взаимодействия, так и дополнительный функционал обмена при помощи специальных модулей, а также порядок действий при проблемах с интеграцией.
Вы научитесь:
- устанавливать модуль обмена в соответствии с версиями и редакциями 1С;
- настраивать параметры модуля обмена;
- управлять содержимым обмена;
- осуществлять обмен документами;
- диагностировать проблемы интеграции;
- работать с инструментами системы.
Начальные требования
Для прохождения курса необходимо:
- ориентироваться в терминах БУС и 1С;
- уметь работать с конфигуратором 1С;
- уметь настраивать инфоблоки БУС;
- ориентироваться в админском интерфейсе БУС;
- иметь представление об управленческом и товарном учете в 1С.
У нас часто спрашивают, сколько нужно заплатить
Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов — ничего из этого оплачивать не нужно.
Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.
Баллы опыта
В конце каждого урока есть кнопка . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:
уроке.
Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат — это если общее число набранных Вами баллов отличается от максимального на 1-2%.
Тесты и сертификат
После изучения курса вам будет предложено пройти тесты на сертификацию. При успешной сдаче линейки тестов на странице Моё обучение можно просмотреть результат обучения и загрузить сертификат в формате PDF.
Для преподавания оффлайн
Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 2 дня (16 академических часов).
Если нет интернета
Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла — от 08.09.2021.
Как проходить учебный курс?
Концепции в реальном времени
Если вы уже создали приложение реального времени, скорее всего, вы использовали шаблон, который называется «publish-subscribe» или «pub-sub» для краткости: подписчики прослушивают события на канале, а другие публикуют эти события. Это эффективный механизм связи «многие ко многим», который поддерживается широким спектром технологий и сервисов, таких как Socket.io или SocketCluster на стороне открытого исходного кода, или Pusher , PubNub или Ably в пространстве PaaS.
Но есть одна важная вещь, которую pub-sub не может предоставить: состояние. Практически у каждого приложения есть какое-то состояние — данные, которые нужно создавать, читать, обновлять и удалять, но pub-sub доставляет только одноразовые сообщения, которые немедленно исчезают. Обычный обходной путь — использование событий в качестве уведомлений об обновлениях, которые, в свою очередь, побуждают клиента получить последнее состояние с помощью традиционного запроса-ответа. Но это сложно, склонно к несоответствиям и, самое главное, медленно.
Это привело к растущему движению к синхронизации данных, подходу, который сочетает в себе состояние с обновлениями в реальном времени. Данные являются постоянными, а также синхронизированы между подключенными клиентами и внутренними процессами.
Технологии, которые поддерживают это, гораздо реже. На стороне открытого исходного кода раньше был прекращенный horizon.io ; в пространстве PaaS есть Firebase от Google .
Чтобы заполнить этот пробел, мы запустили deepstream.io . Наша цель состояла в том, чтобы создать сервер с открытым исходным кодом с той же производительностью и универсальностью, что и системы финансовой торговли или многопользовательских игр, но открытым и расширяемым способом, который облегчает использование для любого типа приложения.
Настройка
Для нашего приложения нам понадобятся следующие файлы:
index.html будет содержать HTML разметку
style.css предназначен для хранения основных стилей. В данном пример мы будем активно использовать Bootstrap.
app.js будет содержать код, написанный на AngularJS. Именно тут мы подключимся к Firebase и будем получать данные.
Давайте приступим к созданию разметки.
Для удобства мы прячем input , вместо него делаем кликабельным элемент label . Для корректной работы скрипта, убедимся что каждый элемент label должен содержать атрибут id с указанием идентификатора элемента input .
Теперь открываем style.css и приступаем к стилизации.
Браузерные префиксы: для упрощения, в данном листинге, мы не использовали браузерные префиксы -moz- или -webkit- .
Теперь у нас есть основа приложения. На данном этапе оно не очень динамично поскольку не взаимодействует с реальными данными. Давайте подключим Angular и Firebase для получения реальных данных.
JS (AngularJS)
Теперь мы начнём оживлять нашу страницу при помощи Angular шаг за шагом, а затем интегрируем наше приложение и Firebase.
Теперь можем взаимодействовать с Firebase.
Как настроить выгрузку товаров
- В соответствующем меню пометьте галочкой опцию “Выгружать информацию о товарах”;
- Отметьте товары для выгрузки и нажмите кнопку “Настроить отбор”. Здесь можно фильтровать позиции по номенклатуре, остатку и цене, выгружаемым свойствам.
Для завершения интеграции кликните на “Загружать информацию о товарах” и “Принять и закрыть”.
Важный момент: изображения и цены товаров из Б24 не загружаются.
Для чего нужна интеграция?
Этот вопрос вы, прежде всего должны задать себе. Не зная ответа на него, можно потерять много времени, нервов и даже денег. В целом, компании интегрируют Битрикс24 с 1С ради повышения эффективности бизнес-процессов, упрощения и убыстрения работы менеджеров, а также увеличения доли автоматизации. Для некоторых распространенных процессов уже готовы шаблоны и алгоритмы, другие, нестандартные ситуации, возможно решать кастомно, но есть и такое, чего нельзя сделать в принципе. Также эксперты преоеригат от распространенного желания многих заказчиков синхронизировать все: Битрикс24 и 1С это разные платформы и превращать их друг в друга не нужно. Выберете те процессы, кото которые необходимо синхронизировать и информацию, которой нужно обмениваться и переходите к следующему этапу — сверки возможностей.
Репозитории мы клонируем во временные папки. Если такие папки уже существуют, мы просто извлекаем последние коммиты и переключаемся на интересующие нас ветви. Ни удаления папок, ни повторного клонирования каждый раз не происходит, потому что pull производится быстрее, чем клонирование.
В целях синхронизации мы убираем и удаляем из индекса git все файлы/папки, присутствующие в toRepo , но не в fromRepo , следя за тем, чтобы исключить игнорируемые файлы/папки. Для этого мы применяем glob matching (глобальное сопоставление): определяем разницу между наборами путей к файлам и удаляем их:
