База. Язык.
Серверная платформа.

Что делает A7

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

Моя область работы — серверная часть. Она принимает сообщения разных протоколов, приводит данные к общей объектной модели, выполняет скрипты, хранит состояние и передаёт изменения подписчикам.

Оборудование и клиентские экраны помогают увидеть границы системы. За любым показанием в интерфейсе стоят объекты, правила доступа, протокольные плагины и доставка изменений.

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

Объекты в памяти.
Состояние на диске.

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

Рабочие объекты живут в арене с неподвижным базовым адресом; внутренняя адресация использует смещения. Слой сохранения отвечает за журнал изменений, снимки и восстановление при запуске.

building
 └─ room_12
     └─ sensor_07
         temperature: 22.4
         humidity: 48

Старая ссылка остаётся старой

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

Поле появляется без переписи всей базы

Если у старого объекта ещё нет нового поля, чтение возвращает значение по умолчанию. Место для поля появляется при первой записи. Развитие схемы не требует немедленно переписать каждый объект.

Свой скриптовый движок

Для нового ядра заново реализован JS-подобный язык с классами, наследованием и декораторами жизненного цикла. Скрипты описывают логику рядом с серверными данными.

1. Разбор
2. Связывание имён
3. Компиляция
4. Виртуальная машина

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

Исполнение под контролем сервера

У виртуальной машины есть бюджет и кооперативная отмена. Фиберы и автоматическая уступка исполнения позволяют длинным скриптам отдавать управление. Обработка исключений помогает локализовать ошибку, сохраняя дальнейший обход объектов.

Совместимость проверяется на разных уровнях: разбор исходников, компиляция и поведенческое сравнение со старым интерпретатором. В сравнительном прогоне зафиксировано 33 совпавших сценария из 33; это результат конкретного набора проверок.

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

Снимок пишется.
Сервер продолжает работу.

Снимок должен зафиксировать согласованное состояние, пока система продолжает принимать данные. В режиме ForkCow запись выполняет дочерний процесс. Основной процесс обслуживает устройства; изменяемые страницы памяти разделяются по мере записи.

Поэтому у сохранения есть два разных времени: пауза сервера и длительность записи. В одном нагрузочном прогоне они составили 12 мс и 3943 мс соответственно. Проигрывание на схеме показывает эту разницу на общей шкале.

Без второй полной копии базы

Потоковый писатель направляет данные в небольшой буфер, затем на диск. Контрольная сумма обновляется по ходу записи. Это устраняет необходимость собирать весь образ базы во втором большом буфере; память для текущих изменений и Copy-on-Write всё равно нужна.

Отказ диска и отказ памяти — разные ситуации

При отказе записи свежие изменения ещё находятся в памяти. Сервер может продолжать обслуживание оборудования, пока запись восстанавливается. Если процесс остановится до успешного сохранения, накопленные изменения будут потеряны.

Исчерпание рабочей памяти требует другого поведения: сервер запрашивает штатную остановку. Политика отказов определяется тем, где находится единственная свежая копия состояния.

Развитие схемы и переход со старого ядра

Паспорт вместо пересборки истории

Идентификаторы типов, координаты полей и версии релизов записаны в паспорт схемы. Он обновляется вместе с конфигурацией. Сервер не должен заново выводить все координаты из всей истории релизов при каждом запуске.

На копии базы примерно с 580 тысячами объектов это сократило готовность сервера с 2973 до 2173 мс. Полная выгрузка объектов и сохраняемых полей — 3,39 миллиона строк — совпала побайтно между двумя способами запуска.

Миграция с независимой проверкой

Мигратор читает старый формат и создаёт новую базу в отдельном каталоге. Проверка выделена в самостоятельный компонент: она восстанавливает ожидаемые объекты и связи по исходной базе независимо от записи нового формата.

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

Правки конфигурации без рестарта

В режиме разработки изменения накладываются поверх релиза и записываются журналом. Применение и восстановление при следующем запуске должны одинаково понимать добавления, изменения, удаления и откаты.

Редактор и админка работают с этими серверными контрактами: отправляют изменения, показывают объектную модель, диагностику и журналы.