Восемь новых пакетов и REST DSL вокруг прежних 56 глаголов маршрута; из ядра ушёл Newtonsoft.Json. Что ломает мажор и как мигрировать за десять минут.

Готовится четвёртая версия redb.Route, интеграционного движка для .NET в духе Apache Camel. В 3.x была закрыта ширина по паттернам: 56 глаголов DSL, тридцать с лишним коннекторов, свой язык выражений, скомпилированный в IL (в 4.0 он качественно переработан, об этом ниже). 4.0 закрывает то, что вокруг паттернов: как протестировать маршрут без брокеров, как собрать тело сообщения, как читать CSV и Avro, как выставить REST-фасад, как кэшировать ответ сервиса. Восемь новых пакетов, REST DSL внутри HTTP-коннектора, переработанный язык выражений и ядро, которое стало легче, а не тяжелее. За год это первый мажор такого масштаба: не смена номера под несколько ломающих правок, а качественное расширение функционала, и ломающих изменений в нём как раз немного.

Один и тот же артефакт разворачивается монолитом и кластером микросервисов. Те же модули, один дашборд на все воркеры, горячая замена без рестарта контейнера.

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

Обычно эту плоскость собирают заново: Prometheus, Grafana, самописный health-контроллер, скрипт деплоя, чат-бот для рестартов. Времени уходит столько же, сколько на сам распил.

redb.Tsak предлагает другой обмен: плоскость эксплуатации живёт в рантайме, и она одна и та же независимо от того, запущен у вас один воркер или девять. Кластер, дашборд, REST API, CLI, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

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

Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу продуктовым направлением «Интеграционная платформа» в «Диасофт». Той самой Digital Q.Integration, которую вы имеете полное право не покупать.

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

Раньше я отвечал в комментариях каждому, потом понял, что проще ответить сразу всем. И заодно признать неприятное: в изрядной части случаев этот комментарий справедлив. Хорошая новость в том, что за годы разговоров с коллегами из других компаний у меня накопилась приличная коллекция возражений против меня самого. Это архитекторы, аналитики, руководители разработки — люди, которые платформу не продают. Часть этих разговоров я тут перескажу, кое‑где даже дословно.

Дальше будет про то, где проходит граница между брокером и платформой, почему ее так трудно нащупать, почему настоящая причина «самописа» вообще не техническая и что во всей этой истории изменил ИИ. По последнему пункту спойлер: ничего хорошего.

Свой gRPC-wire в Route, отсечение props до агрегата в redb.Core, Tsak закрыт по умолчанию, второй фасад у Identity. И 3.7.0, отозванный через день.

За три дня у экосистемы сменилось три номера: 3.7.0, 3.7.1 и 3.7.2. Первый отозван, живой номер 3.7.2. Ниже разбор того, что в этой линии вышло, в порядке зависимостей: интеграционный движок redb.Route, хранилище redb.Core, рантайм redb.Tsak и OpenID-сервер redb.Identity. Все четыре продукта идут на одном номере, 66 пакетов.

Начну с того, почему номеров три.

SOAP никуда не делся. Продаёте авиабилеты, значит ходите в Amadeus, Sabre и Travelport по SOAP. Интегрируетесь с банком, госпорталом, страховым бэкендом, биллингом оператора или почти любым корпоративным продуктом, купленным до 2015-го: там контракт это WSDL, а на проводе <soap:Envelope>. Подписи WS-Security, вложения MTOM, SOAP 1.1 рядом с 1.2, soap:Fault при ошибке: этот мир жив, он приносит деньги и не переезжает на REST по вашей вежливой просьбе.

В .NET вызывать его стало неудобно. WCF как полноценный фреймворк ушёл. CoreWCF есть, но во всех опубликованных версиях висит незакрытая крипто-уязвимость, так что затащить его значит поменять одну проблему на другую. dotnet-svcutil генерит клиент из WSDL на этапе сборки, но это кодогенерация, приклеенная сбоку, а не шаг интеграции. А хостинг SOAP-эндпоинта, WS-Security руками или проводка MTOM обычно заканчиваются кучей конфигурации System.ServiceModel, которую никто не хочет держать.

redb.Route.Soap идёт другим путём. SOAP становится обычным шагом пайплайна в вашем же .NET-процессе. Вызвал сервис, получил типизированный ответ. Поднял эндпоинт, отдал тело маршруту, вернул ответ. Всё in-box: HttpClient, общий Kestrel-хост и System.Security.Cryptography.Xml для WS-Security. Ни WCF, ни рантайма System.ServiceModel, ни уязвимой зависимости, ни отдельного шлюза. Разберём, как это используется и почему нативный коннектор внутри ESB бьёт codegen-клиента или отдельную коробку.