Шлюз¶
Kafka HTTP Gateway — отдельный сервис, который выполняет все операции с брокерами и общается с 1С по HTTP. Без него подсистема работать не может: 1С не обращается к Kafka напрямую.
Релизы: GitHub · GitFlic. Исходники: github.com/SergeSavel/kafka-gateway, зеркало — gitflic.ru/project/sergesavel/kafka-gateway.
Версия шлюза должна соответствовать версии подсистемы: они общаются по двоичному протоколу с номером версии.
Где разворачивать¶
Шлюз рекомендуется устанавливать на том же сервере, где работает служба «1С:Предприятие». Если кластер 1С состоит из нескольких рабочих серверов — на каждом сервере кластера.
Так обращения из 1С не выходят за пределы машины: это быстрее, не нагружает сеть и не требует защищать канал до шлюза. В настройках кластера при этом достаточно оставить адрес localhost — сеанс обмена обратится к шлюзу своего сервера, а поток отправки, запущенный кластером 1С на другом сервере, — к шлюзу сервера родительского сеанса (подробнее).
Причина, по которой недостаточно одного шлюза на кластер: потоки обмена выполняются фоновыми заданиями, а их кластер 1С запускает на любом свободном рабочем сервере. Заранее неизвестно, где окажется поток, поэтому шлюз должен быть доступен локально на каждом из них.
Соединение 1С со шлюзом не шифруется
Подсистема обращается к шлюзу по обычному HTTP. Развёртывание на одном сервере со службой 1С снимает этот вопрос: трафик не покидает машину. Выносить шлюз на отдельный узел допустимо только внутри доверенной сети и никогда — через публичные каналы.
Если шлюз всё же один
Когда развернуть шлюз на каждом сервере невозможно, укажите в настройках кластера его сетевое имя вместо localhost, откройте доступ к порту со всех рабочих серверов 1С и включите аутентификацию.
Требования¶
- Java 21 на сервере, где работает шлюз;
- сетевой доступ от шлюза к брокерам Kafka;
- свободный порт — по умолчанию 8086.
Установка¶
Из готового архива. Скачайте архив дистрибутива со страницы релизов — GitHub или GitFlic. Распакуйте его, например в /opt/kafka-gateway или C:\kafka-gateway, — внутри лежат каталоги bin и lib, файл службы systemd и скрипт установки службы Windows.
Из исходников. Потребуется JDK 21:
./gradlew installDist
Готовый дистрибутив появится в build/install/kafka-gateway.
Первый запуск¶
./bin/kafka-gateway
Шлюз слушает 0.0.0.0:8086. Проверить, что он отвечает:
curl http://localhost:8086/version
Ответ с версией означает, что шлюз работает и можно переходить к настройке кластера. Из 1С та же проверка выполняется открытием рабочего места администратора — версия шлюза выводится в шапке.
Параметры запуска¶
Параметры передаются как опции JVM через переменную окружения KAFKA_GATEWAY_OPTS:
KAFKA_GATEWAY_OPTS="-Dhost=127.0.0.1 -Dport=9090" ./bin/kafka-gateway
| Параметр | По умолчанию | Назначение |
|---|---|---|
-Dhost |
0.0.0.0 |
адрес привязки; для локального шлюза разумно ограничить 127.0.0.1 |
-Dport |
8086 |
порт прослушивания |
-Dlog.dir |
не задан | каталог журналов; если не задан, вывод идёт в консоль |
-Dnetty.readTimeoutSeconds |
300 |
таймаут чтения HTTP-соединения |
-Dnetty.writeTimeoutSeconds |
300 |
таймаут записи HTTP-соединения |
-Dnetty.maxRequestBytes |
33554432 |
максимальный размер тела запроса |
-Dshutdown.timeoutSeconds |
60 |
время корректного завершения |
Остальные параметры — размеры буферов, число рабочих потоков, использование epoll — описаны в документации шлюза; менять их без необходимости не нужно.
Согласуйте таймауты
Таймаут ожидания новых сообщений на шине не должен превышать таймаут чтения у шлюза, иначе соединение оборвётся раньше, чем шлюз вернёт ответ. Реквизит «Шлюз: Таймаут» в настройках кластера, в свою очередь, ограничивает ожидание уже со стороны 1С.
Запуск службой¶
Linux, systemd¶
Файл службы поставляется вместе со шлюзом. Типовая последовательность:
sudo useradd -r -s /usr/sbin/nologin kafka-gateway
sudo mkdir -p /var/log/kafka-gateway && sudo chown kafka-gateway:kafka-gateway /var/log/kafka-gateway
sudo systemctl link /opt/kafka-gateway/kafka-gateway.service
sudo systemctl enable --now kafka-gateway
По умолчанию служба запускается с параметрами -Dhost=127.0.0.1 -Dport=8086 -Dlog.dir=/var/log/kafka-gateway; журналы ротируются ежедневно. Изменить параметры можно в файле службы.
В многосерверном кластере 1С петлевого интерфейса мало
Привязка -Dhost=127.0.0.1 закрывает шлюз для соседних рабочих серверов, а они к нему обращаются: поток отправки, запущенный на другом сервере, работает со шлюзом сервера родительского сеанса — см. Отправка данных. В такой конфигурации привяжите шлюз к адресу, доступному внутри кластера, и ограничьте доступ сетевыми средствами и аутентификацией.
Windows, Apache Procrun¶
Потребуется prunsrv.exe из состава Apache Commons Daemon. Установка выполняется скриптом из дистрибутива:
powershell -ExecutionPolicy Bypass -File .\install-windows-service.ps1 -InstallDir C:\kafka-gateway
Скрипт принимает рабочий каталог, каталог журналов, имя службы, опции JVM и опции шлюза — по умолчанию служба называется kafka-gateway и запускается на 127.0.0.1:8086. Управление службой:
prunsrv //ES//kafka-gateway
Остановка — //SS//, удаление службы — //DS//.
Аутентификация¶
Шлюз поддерживает HTTP Basic-аутентификацию. Учётные записи перечисляются в файле users.json в рабочем каталоге службы:
[
{
"username": "admin",
"password": "secret"
}
]
Эти же имя и пароль указываются в реквизитах «Шлюз: Пользователь» и «Шлюз: Пароль» в настройках кластера.
Если файла нет, аутентификация отключена и шлюз пишет об этом предупреждение. Оставлять шлюз без аутентификации допустимо только тогда, когда он слушает 127.0.0.1 и доступен исключительно локально: через него можно читать и писать любые данные в Kafka.
Шифрование¶
TLS в самом шлюзе не реализован. Если соединение всё же должно идти через сеть, поставьте перед шлюзом обратный прокси — например nginx — и терминируйте TLS на нём. Учтите, что подсистема обращается к адресу из настроек кластера по HTTP, поэтому такой прокси имеет смысл для доступа со стороны других систем, а не для обмена из 1С.
Обновление¶
Подсистема и шлюз обмениваются данными по двоичному протоколу с номером версии. Если версии разошлись, обмен завершается ошибкой «Неизвестная версия бинарной сериализации» — обновляйте шлюз и подсистему согласованно, а после обновления проверяйте версию шлюза в шапке рабочего места администратора.