Изучение преимуществ использования API Gateway для Kafka

Yuan Bao

March 31, 2023

Technology

Краткое введение в Kafka

Kafka изначально была создана LinkedIn как распределенная система обмена сообщениями, которая полагалась на координацию Zookeeper и включала несколько разделов и реплик. Позже она была передана в Apache Software Foundation. Благодаря своей исключительной пропускной способности, устойчивости и возможностям горизонтального масштабирования, Kafka стала широко используемой платформой для обработки потоков данных в отрасли.

Kafka имеет три основных варианта использования:

  • Система обмена сообщениями: Это наиболее распространенный вариант использования, где она используется для обмена сообщениями между бэкенд-микросервисами. Kafka позволяет разделять системы, управлять трафиком и обеспечивать асинхронную связь.
  • Система хранения: Kafka хранит сообщения на диске и включает функцию многократного копирования, что делает ее подходящим вариантом для использования в качестве системы хранения данных. Это значительно снижает риск потери данных.
  • Платформа для обработки потоков данных: Kafka предоставляет обширную библиотеку для обработки потоков данных, включая операции, такие как оконная обработка, объединение и преобразования.

Техническая архитектура Kafka

Стандартный кластер Kafka состоит из нескольких продюсеров, потребителей, брокеров и кластера Zookeeper. Zookeeper является основным управляющим компонентом кластера Kafka, отвечающим за управление метаданными кластера и выборы контроллера. Продюсеры отправляют сообщения брокерам, которые хранят сообщения на диске, а потребители подписываются на сообщения и потребляют их от брокеров.

Основные концепции

Топики и разделы в Kafka

В Kafka сообщения классифицируются по топикам. Продюсеры обычно указывают топик при отправке сообщений, а потребители обычно подписываются на топик для получения сообщений.

Топик обычно состоит из нескольких разделов, каждый из которых содержит разные сообщения. Когда сообщение отправляется в Kafka, оно сохраняется в соответствующем разделе на основе правил разделения. Устанавливая соответствующие правила разделения, сообщения могут быть равномерно распределены по разным разделам.

Продюсеры и потребители

Продюсер — это сторона, которая отправляет сообщения, отвечает за создание сообщений и их отправку в брокеры Kafka.

Потребитель — это сторона, которая получает сообщения, отвечает за подключение к брокеру кластера Kafka, подписку на определенный топик и потребление сообщений.

Брокеры Kafka

Брокер можно рассматривать как независимый узел или экземпляр Kafka. Кластер Kafka состоит из одного или нескольких брокеров.

kafka cluster

Зачем Kafka нужен API-шлюз

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

Однако этот подход имеет ограничения в некоторых сценариях, например, когда клиенту необходимо напрямую подключаться к Kafka. В таких случаях добавление API-шлюза между вызывающей стороной и Kafka может помочь разделить сервисы. Таким образом, вызывающая сторона не должна беспокоиться о Kafka или конкретных протоколах связи, что снижает затраты на вызов. Кроме того, API-шлюз может обеспечить поддержку безопасности и управление трафиком для API, предоставляемых Kafka, обеспечивая стабильность сервисов Kafka.

Прямое подключение к Kafka

Прямое подключение к Kafka может привести к ряду ограничений и рисков при использовании ее в качестве промежуточного программного обеспечения для очередей сообщений:

  1. Разные потребители должны адаптироваться к протоколу связи Kafka.
  2. Kafka не предоставляет решений для защиты открытых API, управления трафиком и других проблем. Без политик ограничения скорости некоторые продюсеры или потребители могут потреблять чрезмерные вычислительные ресурсы и пропускную способность.
  3. Как потребители, так и продюсеры должны знать топологию кластера Kafka, которая может быть затронута изменениями в кластере Kafka.

API-шлюз улучшает удобство использования Kafka

Преобразование протоколов связи

Когда API-шлюз используется для проксирования Kafka, клиент общается с API-шлюзом по протоколу HTTP, а API-шлюз общается с Kafka по протоколу Kafka. API-шлюз преобразует сообщения клиента в протокол Kafka, устраняя необходимость адаптации клиента к различным протоколам сообщений Kafka. Это значительно снижает затраты на разработку и делает использование более удобным.

Ограничение скорости

Когда ресурсы ограничены, производительность узлов Kafka также ограничена. Превышение этого предела может привести к сбою сервиса и вызвать цепную реакцию. Ограничение скорости может предотвратить это. В традиционной архитектуре Kafka клиенты общаются с Kafka через SDK. Однако, если количество клиентов или запросов велико, это может повлиять на нагрузку на машины узлов Kafka и повлиять на стабильность функциональности Kafka. Добавление API-шлюза в архитектуру позволяет легко добавить поддержку функций ограничения скорости в различных измерениях для кластера Kafka, так как API-шлюзы отлично справляются с этим. Эти возможности включают:

  • Использование алгоритма фиксированного временного окна для ограничения общего количества запросов, которые один клиент может сделать к сервису в течение определенного периода времени.
  • Ограничение количества одновременных запросов, которые клиент может сделать к одному сервису.
  • Использование алгоритма "протекающего ведра" для ограничения скорости запросов одного клиента к сервису.

Реализация этих функций ограничения скорости позволяет эффективно защитить узлы Kafka, обеспечивая их стабильность.

Поддержка аутентификации

Аутентификация также является сильной стороной API-шлюза. В традиционной архитектуре Kafka большинство портов Kafka доступны внутри внутренней сети. Если требуется доступ из публичной сети, необходимы сложные конфигурации для обеспечения безопасности. Использование функции аутентификации API-шлюза при проксировании Kafka позволяет защитить порты, предоставляемые Kafka, а также избирательно разрешать или запрещать доступ клиентов.

Возможности мониторинга

В настоящее время существует множество продуктов для мониторинга Kafka, таких как Kafka Eagle, Kafka Monitor, Kafka Manager и другие. Каждый из них имеет свои преимущества и недостатки. Достичь универсальной возможности мониторинга сложно, а затраты на кастомизацию относительно высоки. Более того, интеграция с внутренними системами мониторинга может быть затруднена. Создание системы мониторинга Kafka с нуля также дорого, так как информация для мониторинга Kafka охватывает множество аспектов, а метрики мониторинга, предоставляемые самой Kafka, требуют сложной обработки через Java Management Extension (JMX).

Добавление API-шлюза в архитектуру позволяет клиенту и API-шлюзу общаться по протоколу HTTP. В результате экосистема программного обеспечения для мониторинга на основе протокола HTTP очень богата. Это позволяет обеспечить полную наблюдаемость для сервисов Kafka с очень низкими затратами.

Постепенное обновление Kafka

Сервисы Kafka предоставляются через адреса брокеров, которые продюсеры и потребители должны указывать в своей конфигурации для подключения к кластеру Kafka. Список адресов обычно форматируется как host1:port1, host2:port2 и может содержать один или несколько адресов, разделенных запятыми.

Однако этот метод конфигурации имеет ограничения: он требует, чтобы адреса брокеров Kafka оставались фиксированными, а сервисы оставались стабильными. Клиенты Kafka предполагают, что все адреса брокеров доступны и случайным образом выбирают один для использования. Это может вызвать проблемы во время постепенных обновлений, так как клиенты не знают, какой брокер использовать, а изменение адресов брокеров требует внесения изменений во всех клиентов-продюсеров и потребителей.

С использованием API-шлюза для Kafka адреса брокеров могут быть настроены на уровне шлюза, и клиентам больше не нужно фокусироваться на конкретных деталях брокеров Kafka. Даже если адрес брокера изменится, клиенты останутся незатронутыми. Это позволяет легко выполнять постепенные обновления Kafka, не беспокоясь о влиянии на клиентов.

Итог

Таким образом, добавление API-шлюза к Kafka позволяет легко обеспечить поддержку ограничения скорости, аутентификации, мониторинга и постепенных обновлений для сервисов Kafka благодаря богатым функциям API-шлюза.

Использование Apache APISIX для расширения Kafka

Apache APISIX — это высокопроизводительный, реального времени API-шлюз под эгидой Apache Software Foundation. Он предлагает ряд сложных функций управления трафиком, включая балансировку нагрузки, динамические апстримы, канареечные выпуски, прерывание цепи, аутентификацию и наблюдаемость. Как API-шлюз, APISIX помогает предприятиям быстро и безопасно обрабатывать трафик API и микросервисов и широко используется в Kubernetes Ingress и сервисной сетке. Добавление слоя APISIX перед сервисом Kafka позволяет предприятиям использовать богатую систему плагинов платформы для обеспечения проксирования сообщений, доставки логов, ограничения скорости, мониторинга и других возможностей. С APISIX как север-южный трафик от клиентов к серверам, так и восточно-западный трафик между микросервисами предприятия могут быть эффективно обработаны.

APISIX и Kafka

Проксирование сообщений Kafka

APISIX предлагает возможность проксирования сообщений Kafka. Клиенты могут напрямую общаться с APISIX, который обрабатывает преобразование протоколов сообщений между клиентами и Kafka.

Чтобы включить функцию проксирования Kafka в APISIX, нам просто нужно добавить маршрут, как показано ниже:

curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/Kafka' \
    -H 'X-API-KEY: <api-key>' \
    -H 'Content-Type: application/json' \
    -d '{
    "uri": "/Kafka",
    "plugins": {
        "Kafka-proxy": {
            "sasl": {
                "username": "user",
                "password": "pwd"
            }
        },
        "limit-count": {
            "count": 2,
            "time_window": 60,
            "rejected_code": 503,
            "key_type": "var",
            "key": "remote_addr"
        }
    },
    "upstream": {
        "nodes": {
            "Kafka-server1:9092": 1,
            "Kafka-server2:9092": 1,
            "Kafka-server3:9092": 1
        },
        "type": "none",
        "scheme": "Kafka"
    }
}'

Этот запрос создает маршрут с URI /Kafka в APISIX, который связан с тремя узлами брокеров Kafka как апстрим-сервисы. Плагин kafka-proxy используется для добавления аутентификации SASL/PLAIN к запросам Kafka. Конфигурация в APISIX поддерживает горячие обновления, поэтому брокеры Kafka могут быть изменены без необходимости перезапуска API-шлюза или нарушения работы клиента.

Кроме того, для этого маршрута включен плагин limit-count для поддержки ограничения скорости. Конфигурация плагина указывает, что только два запроса могут быть пропущены в течение интервала в 60 секунд, а любые дополнительные запросы будут отклонены APISIX с кодом состояния 503.

Отправка логов

Плагин kafka-logger APISIX позволяет отправлять логи в виде JSON-объектов в кластер Apache Kafka.

Пример конфигурации:

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
       "kafka-logger": {
            "brokers" : [
              {
                "host" :"127.0.0.1",
                "port" : 9092
              },
              {
                "host" :"127.0.0.1",
                "port" : 9093
              }
            ],
           "kafka_topic" : "test2",
           "key" : "key1"
       }
    },
    "upstream": {
       "nodes": {
           "127.0.0.1:1980": 1
       },
       "type": "roundrobin"
    },
    "uri": "/hello"
}'

APISIX предлагает не только возможность проксирования сообщений Kafka. Он также предоставляет возможности трассировки, метрик и логирования через различные плагины, охватывая все аспекты наблюдаемости. С помощью простой конфигурации плагинов на APISIX возможна интеграция с другими сервисами наблюдаемости, такими как Prometheus, Skywalking и другими, что улучшает возможности мониторинга кластеров Kafka.

Итог

Эта статья подчеркивает преимущества реализации API-шлюза для Kafka и использует Apache APISIX в качестве примера, чтобы продемонстрировать, как он предлагает функции Kafka, такие как ограничение скорости, аутентификация, мониторинг и постепенные обновления.

Tags:
APISIX Basics
Plugin