redb для бизнеса: программируем только бизнес, инфраструктура уже написана

redbredb.Routeredb.Tsakredb.Identity

12 сентября вышла redb 4.0.0. Четыре продукта экосистемы (хранилище, интеграционный движок, рантайм и сервер идентификации) получили общий мажорный номер: 76 пакетов, внутренний аудит безопасности и сборку на .NET 10, который Microsoft поддерживает до ноября 2028 года. Для инженеров изменения разобраны в отдельной статье. Этот текст для тех, кто решает, на чём строить бэкенд: что экосистема заменяет, во что обходится, какие риски снимает и что важно знать до старта.

Коротко, из чего она состоит:

  • redb.Core хранит типизированные объекты в PostgreSQL, MS SQL Server или SQLite. Структура данных описывается классом C#, схема базы синхронизируется из кода, миграций нет.
  • redb.Route это интеграционный движок по канону Enterprise Integration Patterns, того же рода, что Apache Camel: 29 транспортов, от Kafka, RabbitMQ и IBM MQ до SOAP, gRPC, AS2 и SFTP.
  • redb.Tsak это рантайм: модули разворачиваются и заменяются на лету, узлы собираются в кластер, всё видно и управляется из одного дашборда.
  • redb.Identity это сервер OpenID Connect и OAuth 2.1 с фасадами HTTP, gRPC и SOAP, который работает модулем того же рантайма.

Команда программирует только бизнес

В обычном проекте до первой строки бизнес-логики команда строит инфраструктуру: подключения к брокерам и внешним системам, повторы и защиту от дублей, миграции базы, деплой без простоя, мониторинг, авторизацию. Это месяцы работы, за которые бизнес не получает ни одной новой функции, а потом годы сопровождения всего написанного.

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

В цифрах, посчитанных на реальных системах:

  • 2,2–4 человеко-года инфраструктуры до первой строки бизнес-логики в TMS на WSO2 MI и EF Core и 2,8–4,4 человеко-года в модели платёжной платформы, плюс 0,8–1,1 постоянной ставки в год на сопровождение. С redb этот слой писать и сопровождать не нужно.
  • Двадцать минут вместо половины дня или дня на проверку продуктовой идеи, которой нужно новое поле или сущность: нет миграции, стенда и обратного скрипта. Разница на порядок, и команда успевает сравнить три-пять вариантов вместо того, чтобы взять первый работающий.
  • Вчетверо короче описание интеграций: при переезде с шины 861 строка XML на WSO2 превратилась в 212 строк маршрута.

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

Что это заменяет

Задача Как обычно решают В redb
Данные ORM, миграции и отдельный процесс их выката класс C# и есть схема
Интеграции Apache Camel или WSO2 MI на Java, самописные коннекторы маршруты redb.Route
Рантайм и эксплуатация своя обвязка: деплой без простоя, очереди недоставленных, дашборды redb.Tsak
Идентификация Keycloak или WSO2 Identity Server на Java, с собственными базами redb.Identity

Цена такого набора видна не в лицензиях, а в объёме чужой инфраструктуры. В разборе реальной TMS на WSO2 MI и EF Core один только сервер идентификации принёс 227 служебных таблиц в четырёх базах, при 53 таблицах бизнес-модели самой системы. Каждую из них нужно развернуть, бэкапить и обновлять вместе с продуктом. redb.Identity хранит клиентов, токены и ключи в том же хранилище redb, что и остальные данные.

Во что обходится

Лицензии. Открытая часть распространяется под Apache 2.0. Pro-возможности (оптимизированные запросы, частичная запись изменений, параллельная материализация, кластер) бесплатны на всей линии 4.x, включая коммерческую эксплуатацию. Ключ не нужен, регистрация тоже, оплаты за процессоры или узлы нет. Курс на то, чтобы Pro оставался бесплатным и дальше. Pro-пакеты закрытые, но исходники отдаются по запросу компаниям, которые выбрали экосистему: под аудит безопасности, депонирование или собственную сборку.

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

Люди: один язык на весь бэкенд

Хранилище, интеграции, рантайм и сервер идентификации пишутся и сопровождаются одной командой на C#. Не нужны отдельные специалисты по Java под Camel, Keycloak или WSO2, и нанимать можно из общего рынка .NET-разработчиков.

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

Словарь интеграции при этом общий с индустрией. Названия шаблонов взяты из книги Enterprise Integration Patterns, на которой построены Apache Camel и WSO2, так что опыт интеграторов переносится без переучивания. С 4.0 интеграции можно описывать и без C#: декларативными маршрутами в XML, в духе конфигураций WSO2 MI. В разметке доступны бины, SQL и остальные коннекторы, чтение, запросы, запись и удаление объектов хранилища redb, транзакции. Такой маршрут разворачивается в Tsak пакетом из одного XML-файла. Собственный код, если он понадобится, пишется на .NET, так же как расширения WSO2 MI пишутся на Java.

Скорость изменений

  • Новое поле данных это новое свойство класса. Схема синхронизируется при старте, миграций и релизных окон под них нет.
  • Модуль заменяется на лету, без перезапуска узла и без окна обслуживания, об этом отдельный раздел ниже.
  • Интеграцию можно поменять без перекомпиляции: с 4.0 модуль может состоять из одного XML-маршрута.
  • Интеграции тестируются без брокеров. Тест-кит подменяет обращения к Kafka, очередям и базам моками, не трогая сам маршрут, и регрессия перестаёт требовать стенд.

Скорость не отменяет контроля. С 4.0 изменение схемы боевой базы можно полностью отдать DBA: приложение останавливается с понятным сообщением и отдаёт скрипт обновления, а не выполняет DDL само при старте.

Релиз без окна обслуживания

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

  • Новая версия модуля проверяется до того, как тронуть работающую. Рантайм загружает её отдельно и убеждается, что пакет открывается и модуль в нём находится; если нет, работающая версия остаётся как была. Затем старая версия плавно останавливается, перестаёт принимать новые сообщения и дорабатывает начатые, после чего стартует новая. Короткая пауза касается только контекста этого модуля: процесс не перезапускается, а модули других контекстов узла выкладку не замечают.
  • Остановка по умолчанию плавная. Маршрут сначала перестаёт принимать новые сообщения, затем дорабатывает начатые в пределах заданного таймаута и только потом закрывает транспорты и соединения с базой. Так устроены и выкладка, и удаление модуля, и остановка всего узла: узел сначала отдаёт лидерство в кластере, потом останавливает контексты, и медленный контекст не обрывает остановку остальных.
  • Узел обслуживается без простоя. Переведённый в cordon узел не берёт новую работу и передаёт свои кластерные маршруты соседям, после чего его можно обновить или перезагрузить. Проверка готовности сообщает Kubernetes, когда узел не может работать.
  • В деньгах: в модели платёжной платформы подготовка и проведение релизных окон стоят около 450 часов в год. Здесь окно не нужно, и выкладка перестаёт быть ночным событием с дежурными.

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

Эксплуатация

  • Новая база не нужна. redb разворачивается прямо в существующей, уже эксплуатируемой базе PostgreSQL или MS SQL Server: его таблицы и функции ставятся рядом с вашими и чужих объектов не трогают. Бэкапы, репликация и мониторинг базы остаются прежними, а установку, если так принято, выполняет DBA готовым скриптом.
  • Кластер без двойной обработки. С 4.0 уникальность в кластере держит сама база: один модуль не назначается на два узла, а два узла, стартующие на пустой базе, не создают два кластера.
  • Несколько кластеров заложены в структуру. Топология устроена деревом «кластер, группа, узел», и в одной базе живут несколько кластеров со своими группами и узлами. Межкластерное взаимодействие, в том числе между регионами, в дорожной карте. До него кластеры разных регионов связываются маршрутами redb.Route через брокер или HTTP.
  • Один дашборд на все узлы: маршруты, ошибки, очередь недоставленных сообщений с повторной отправкой, журнал аудита, логи. Метрики забирает Prometheus, трассировки уходят в OpenTelemetry, узлы разворачиваются в Kubernetes.
  • Пик нагрузки не валит соседей. С 4.0 каждой точке входа можно задать свой лимит: лишние запросы получают отказ до начала обработки, а соседние маршруты на том же порту работают дальше. На дашборде видно, какие маршруты упёрлись в лимит, то есть где не хватает мощности, ещё до появления ошибок.
  • Высокочастотные потоки в той же базе. Координаты транспорта, показания датчиков и другие потоки принимают коннекторы redb.Route: Kafka, MQTT, RabbitMQ и остальные. Сырые точки пишутся не в объекты redb, а в обычные трендовые (например, партиционированные) таблицы рядом, в той же базе, массовой вставкой пачками, которые собирает агрегатор маршрута. Отдельная СУБД под поток не нужна, а внешний ключ на объект redb (машину, рейс, датчик) ставится как в любой таблице. В объектах живут сущности и итоги, в трендовых таблицах сырой поток, как в архитектуре TMS.
  • Одна сборка, две топологии. Те же модули разворачиваются монолитом или кластером микросервисов, подробно об этом в статье про Tsak.

Безопасность и аудит

  • Код модуля подписывается. Рантайм можно настроить так, что неподписанный модуль не загрузится, а подпись ставится вашим ключом в вашем конвейере сборки. Релизные архивы экосистемы подписаны cosign.
  • Чужой модуль запускается отдельно. Модуль работает с правами процесса воркера, и подпись подтверждает, кто его собрал, но не ограничивает, что он делает. Поэтому модуль от поставщика, чей код вы не проверяли, разворачивается в отдельном воркере-контейнере: изоляцию обеспечивают ОС и контейнер, а управляется он из того же дашборда, что и остальные.
  • Сервер идентификации сверен с официальным набором тестов OpenID Foundation. Профили Config OP и Basic OP (35 модулей) проходят без единого провала. Набор тестов открытый и поднимается в Docker, а результаты и порядок прогона опубликованы в репозитории, так что повторить проверку может любой; как проходил прогон. Протокольная подготовка к формальной сертификации сделана, а сам знак OpenID Certified фонд выдаёт по отдельной платной заявке. В поставке второй фактор, федерация с внешними провайдерами и LDAP, SCIM, DPoP.
  • Перед 4.0 фасады Identity и дашборд Tsak прошли внутренний аудит безопасности, найденное закрыто в этом релизе. С 4.0 access-токены несут audience по RFC 9068, и токен, выданный для внешнего API, не открывает API управления сервером идентификации.
  • Журнал изменений для аудиторов. С 4.0 перехватчики записи дают приложению «кто, что и когда изменил» без правок бизнес-кода, а в режиме частичной записи изменений (Pro) ещё и разницу значений по каждому полю. Действия администраторов рантайма пишутся в отдельный журнал.

Независимость от поставщика

  • Всё работает в вашем контуре. Нет SaaS и лицензионного сервера, и ничего не уходит поставщику: ни проверка лицензии, ни сведения об использовании. Собственная телеметрия маршрутов сама никуда не отправляется: метрики забирает с узла ваш Prometheus, а экспорт трассировок OpenTelemetry по умолчанию выключен и включается с адресом вашего коллектора или Jaeger. Пакеты и образы зеркалируются во внутренние фид и реестр, после чего доступ к внешним площадкам не нужен.
  • Данные остаются вашими. Они лежат в вашей PostgreSQL, MS SQL Server или SQLite, структура хранения открыта и документирована, база читается обычным SQL. Есть штатная выгрузка и загрузка всей базы, в том числе между разными СУБД.
  • Для российских компаний санкционного вопроса здесь нет: работа системы не зависит от зарубежного лицензиара или внешнего сервиса, всё нужное разворачивается внутри контура.

Кто за этим стоит

redb это экосистема из четырёх продуктов на одной линии релизов. У проекта уже есть внешний контрибьютор, и мы открыты к новым: вклад принимается через GitHub, правила описаны в CONTRIBUTING.md. Направление развития задаёт обратная связь: обсуждения на GitHub, внешние отчёты по безопасности, комментарии к статьям.

Для бизнеса важнее не размер команды, а то, что остаётся у вас на руках при любом развитии событий: открытый код под Apache 2.0, исходники Pro по запросу, данные в вашей собственной базе, релизы с подписанными артефактами и публичными списками изменений по каждому продукту. Исправления закрепляются интеграционными тестами на трёх СУБД. Библиотеки собраны под .NET 8, 9 и 10, а .NET 10 поддерживается Microsoft до ноября 2028 года.

Развёртывание, в том числе в облаке, поддержка, помощь с внедрением и SLA обсуждаются по договорённости. Так же обсуждается провайдер под другую СУБД, например Oracle или MySQL: из коробки поддерживаются PostgreSQL, MS SQL Server и SQLite. Связаться можно через redb.ru/about.

Что важно знать до старта

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

Как начать

Переходить на экосистему целиком сразу не обязательно, и поэтапное внедрение ничего не ломает: redb встаёт рядом с тем, что уже работает, в ту же базу и рядом с существующими системами. Удобно начать с пилота одним модулем: выбрать интеграцию или сервис с понятной границей, перенести его и сравнить сопровождение на живой нагрузке. Так сделано в истории переезда с ESB, где перенос одного модуля посчитан построчно. Дальше модули переезжают один за другим, в том темпе, который удобен бизнесу.

Для первого знакомства хватит образа redb-tsak-stack, где рантайм и дашборд живут в одном контейнере. Пакеты лежат на NuGet, исходники на GitHub. Если нужен разговор о пилоте, внедрении или поддержке, пишите через redb.ru/about.

Если было полезно, ⭐ на GitHub поможет другим это найти.

Другие мои статьи — redb.ru/articles, ещё — на Хабре.