-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Внимание: Информация в этом разделе обновляется не всегда своевременно.
Kafka REST Proxy - это приложение с открытым исходным кодом, разработанное на платформе ASP.NET Core. Лицензия Apache 2.0.
Приложение представляет собой HTTP-сервер, который принимает REST-запросы от информационных баз 1С, и перенаправляет эти запросы брокерам Apache Kafka. Платформа 1С не имеет возможности взаимодействия с брокерами Kafka напрямую, чем и обусловлена необходимость наличия данного приложения. Приложение устанавливается на серверы 1С как служба Windows (сделан MSI-установщик).
- Отправка сообщений.
- Получение сообщений.
- Административные функции: получение метаданных кластера (список брокеров и топиков), чтение параметров брокеров и топиков, создание новых топиков.
Работа с приложением осуществляется путем вызова соответствующих HTTP-методов. Со стороны информационных баз 1С праимодействие с приложением осуществляется с помощью подсистемы "Кафка". API приложения полностью реализован в обработке "КафкаАдаптер", входящей в состав подсистемы.
- Внутри приложения создается экземпляр клиента Kafka одного из трех типов: "Producer", "Consumer", "AdminClient". Одновременно может существовать произвольное количество экзампляров клиентов разного типа. Экземпляры изолированы друг от друга.
- Ведется работа с экземпляром клиента, например, отправка или получение сообщений.
- По окончанию сеанса работы экземпляр клиента удаляется, и освобождаются занятые экземпляром ресурсы.
При создании экземпляра клиента ему передаются все не обходимые настройки, главными из которых является адрес кластера Kafka и данные аутентификации.
Полный список возможных параметров:
- Общие параметры для всех типов клиентов: ClientConfig
- Параметры "Producer": ProducerConfig
- Параметры "Consumer": ConsumerConfig
- Параметры "AdminClient": AdminClientConfig
Экземпляр "Producer" является потокобезопасным. Это означает, что один экземпляр может параллельно использоваться несколькими сеансами 1С. Это бывает полезно в сценариях многопоточной отправки сообщений: управляющий сеанс 1С создает экземпляр "Producer", передает параметры доступа к экземпляру произвольному количеству дочерних сеансов, и все они используют этот единственный экземпляр.
После создания экземпляра "Consumer" ему назначается конкретный перечень топиков (тем) и партиций (разделов), из которых необходимо получать сообщения. Для каждой комбинации топик-партиция также передается начальная позиция чтения (номер сообщения, с которого нужно начать читать). После этого циклически вызывается функция "Consume", которая возвращает по одному новому сообщению. Если конечная позиция чтения еще не достигнута, функция сразу вернет новое сообщение. Если же новых сообщений нет, функция будет "ожидать" в течение периода, переданного в параметрах вызова функции. Таким образом реализуется "подписка" на новые сообщения для получениия их в реальном времени.
Предполагается, что информационная база 1С должна хранить свои позиции чтения внутри себя. Сценарий, при котором кластер Kafka осведомлен и хранит у себя позиции чтения каждого получателя, в данный момент не поддерживается (хотя Apache Kafka имеет данный функционал).
Экземпляр "Consumer" НЕ является потокобезопасным. Это значит, что каждый сеанс 1С должен работать со своим собственным экземпляром клиента. Многопоточное чтение топика реализуется путем назначения каждому из потоков отдельных разделов для чтения. Это означает, что количество параллельных потоков чтения топика ограничено количеством разделов в топике.
Статические параметры конфигурации приложения указываются в файле "appsettings.json", который находится в каталоге приложения.
Главным статическим параметром является адрес/порт для прослушивания приложением.
По-умолчанию экземпляры "Producer" и "Consumer" отправляют/получают данные в виде строк (UTF-8).
Однако, имеется возможность использования бинарной сериализации передаваемых данных в формат Apache Avro. В случае использования бинарной серизации, данные отправляются в виде XML-строки специального формата ("AvroAsXml"), и вместе с данными передается схема Avro (в формате JSON), в соответствиии с которой происходит сериализация. Схему достаточно передать один раз с первым отправляемым сообщением, далее она кэшируется в приложении, а также отправляется в реестр схем. Идентификатор схемы добавляется к сериализованным данным.
При получании бинарно сериализованных данных экземпляр получателя запрашивает из реестра необходимую схему по идентификатору, выполняет десериализацию данных обратно в формат "AvroAsXml", и возвращает XML-строку вызывающей стороне.
Адрес реестра схем задавется в файле "appsettings.json" и является статическим параметром, т.е. одно приложение может работать только с одним реестром схем.