【原创】为什么我的 Kafka 总是连接失败呢？

提出问题

近日助友 Docker 部署 Kafka 服务，服务日志启动正常，但客户端却无法连接

往日曾踩过此坑，然方法均源于博客，其语焉不详，不知为何不行，亦不知为何行，印象不甚深刻，耗费大量时间

为避此坑，特地学习官方文档相关章节，让我寻到珠丝马迹，请听我娓娓道来~

如嫌篇幅较长，可跳过验证，直奔结论

本文主要记录为何会出现无法连接到 Broker 的原因，想必看完本文你会知道该怎么做的

谨以此文献给那些因为无知而浪费的时光！

大胆猜测

Kafka的服务端称为 Broker，每个 Broker 启动时会将自己的 Broker 配置信息上报给 Zookeeper ，如，监听地址与端口号等，Kafka的客户端（生产者与消费者统称）要连接 Broker 需要经过一层认证，不通过认证就无法连接！

小心求证

测试环境：

GNU/Linux Debian 10 4.19.0内核
Docker：19.03.6
Docker-compose：1.17.1
镜像：zookeeper:3.5.5
镜像：wurstmeister/kafka:2.12-2.2.1

设计实验：

使用 docker 镜像部署一套单节点的 Zookeeper + Kafka

要求Broker监听自定义域名（主机名）与端口，服务启动后展示 Zookeeper 中 Broker 的注册信息

使用客户端连接 Broker ，使用不同的 --bootstrap-server 组合方式，进行验证

开始实验

为了提高部署效率，这里提供一个简单可启动的 docker-compose-test.yml

version: "3.3"

services:

    zookeeper:

        image: zookeeper:3.5.5

        restart: always

        container_name: zookeeper

        ports:

            - "2181:2181"

        expose:

            - "2181"

        environment:

            - ZOO_MY_ID=1

    kafka:

        image: wurstmeister/kafka:2.12-2.2.1

        restart: always

        container_name: kafka

        environment:

            - KAFKA_BROKER_ID=1

            - KAFKA_LISTENERS=PLAINTEXT://kafka:9090

            - KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181

            - KAFKA_MESSAGE_MAX_BYTES=2000000

        ports:

            - "9090:9090"

        depends_on:

            - zookeeper

将 docker-compose-test.yml 放入你的目录，运行部署脚本

查看两者的日志，检查是否正常启动

docker logs -f zookeeper

docker logs -f kafka

可以看到 Kafka 已经注册成功

让我们查看一下，Zookeeper 中注册的 Broker 信息

docker exec -it zookeeper bash bin/zkCli.sh

输入 quit 退出

想到我们已经将Kafka监听的端口号已经映射到宿主机了，使用宿主机 IP 访问不就得了？

先创建个Topic

docker run -it --rm --network host wurstmeister/kafka:2.12-2.2.1 \

             bash /opt/kafka/bin/kafka-topics.sh \

             --bootstrap-server 192.168.1.19:9090 \

             --create --topic logsTopic --partitions 1 --replication-factor 1

噢！又是这该死的错误！

想到刚才在 zookeeper 中看到的信息，要不我把 IP 换成 kafka 不就结了？

docker run -it --rm --network host wurstmeister/kafka:2.12-2.2.1 \

             bash /opt/kafka/bin/kafka-topics.sh \

             --bootstrap-server kafka:9090 \

             --create --topic logsTopic --partitions 1 --replication-factor 1

不对，宿主机本身没有对 kafka 作映射，问题一定出在这里！

再次执行刚才的命令，没有输出，说明创建 Topic 成功！

生产一条消息测试下

docker run -it --rm --network host wurstmeister/kafka:2.12-2.2.1 \

        bash /opt/kafka/bin/kafka-console-producer.sh \

        --broker-list kafka:9090 --topic logsTopic

输入回车，发送消息； ctrl + c 断开连接

创建消费者，消费消息测试

docker run -it --rm --network host wurstmeister/kafka:2.12-2.2.1 \

        bash /opt/kafka/bin/kafka-console-consumer.sh \

        --bootstrap-server kafka:9090  --topic logsTopic  --from-beginning

嗯，消费也成功了

归纳总结

这个实验说明了什么呢？

说明 Kafka 客户端在连接 Broker 的时候，Broker 将客户端发来的请求带的信息与 Broker 启动时上报给 Zookeeper 的信息进行了比对，比对相同则认证通过，反之建立连接失败！

官方文档

通过耐心地查看 Kafka 的官方文档，终于在角落里看到她的影子！（好久不见妹子，看文档都眉清目秀的~）

比如下面这段：

From Kafka version 2.0.0 onwards, host name verification of servers is enabled by default for client connections as well as inter-broker connections to prevent man-in-the-middle attacks.

大意是讲通过这种认证hostname的机制，来避免中间人攻击

还有这段：

advertised.host.name: DEPRECATED: only used when advertised.listeners or listeners are not set. Use advertised.listeners instead. Hostname to publish to ZooKeeper for clients to use. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, it will use the value for host.name if configured. Otherwise it will use the value returned from java.net.InetAddress.getCanonicalHostName().

虽然这个参数已经标记为废弃了，但是她提供了个信息：如果设置主机名可能会被上报

最后看看这段

advertised.listeners: Listeners to publish to ZooKeeper for clients to use, if different than the listeners config property. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, the value for listeners will be used. Unlike listeners it is not valid to advertise the 0.0.0.0 meta-address.

也就是说，默认设置 advertised.listeners与 listeners 的值相同，上报Zookeeper供客户端使用；无需绑定不同接口时，只需要设置 listeners 即可。

结论

Kafka 客户端在连接 Broker 的时候，Broker 将客户端发来的请求附加信息与 Broker 启动时上报给 Zookeeper 的 listeners参数信息、host（来自listeners的中间域名或主机名部分）、port (来自listeners的端口部分) 进行了验证，认证通过建立连接执行请求，反之建立连接失败

如果看完本文还不知如何去做，请参考https://www.cnblogs.com/hellxz/p/how_to_add_hosts_on_docker.html

写这篇文章费了好大的功夫，猜是一回事，弄明白又是一回事，如果本文对你有所帮助，欢迎点推荐与关注

引用：
https://kafka.apache.org/documentation.html

本文采用 CC BY 4.0 协议进行授权，转载请标注作者署名及来源。
https://www.cnblogs.com/hellxz/p/why_cnnect_to_kafka_always_failure.html