Nginx代理Kafka集群
背景
项目是需要从生产单位上传数据到集团，由于公司生产环境网络端口个数限制，因此考虑用Nginx代理出Kafka集群。便 于理解，附上系统部署架构图如下：
动手搞起来
hosts 配置
kafka的监听配置中，用主机名进行配置与IP配置相比好处有以下：
. 1. 弹性扩展
- 动态节点管理
当集群需要横向扩展（新增 Broker）时，只需为新节点分配一个主机名并更新 DNS 记录，无需修改 Kafka 配置文件中的 IP 列表。这对云原生环境（如 Kubernetes、AWS EC2）尤其友好。 - 负载均衡集成：
主机名可以与负载均衡器（如 Nginx、云厂商的负载均衡服务）结合，自动将流量分发到多个 Broker 节点，提高吞吐量和可用性（主机名可以指向多个IP，实现请求的分发）
2 可读性好
主机名比IP地址更具可读性和可维护性。管理员可以通过修改主机名来轻松管理集群中的节点，而无需记住复杂的IP地址。
3 增强稳定性
主机名相对于IP地址来说更加稳定。 - 主机名相对于IP地址来说更加稳定。即使某个节点的IP地址发生变化（如重启后分配了新的IP），只要主机名不变，集群中的其他节点仍然可以正常通信
配置hosts，通过命令vi /etc/hosts进行配置;
192.168.1.50 kafka1
192.168.1.51 kafka2
192.168.1.52 kafka3
PS： VI 常用小命令
在ESC的情况下:
- 回到内容起始: gg
- 全选 :ggVG
- 复制： ggyG
- 显示行号：: set number
- 保存 wq
- 退出q!
kafka配置
配置如下所示：
listeners=INTERNAL://192.168.1.50:9092,EXTERNAL://kafka1:9090
inter.broker.listener.name=INTERNAL
advertised.listeners=INTERNAL://192.168.1.50:9092,EXTERNAL://kafka1:9090
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT
-
listeners
先看第一个配置项：listeners。这里有两个监听器，INTERNAL和EXTERNAL，分别指向内网的IP和主机名加端口。这说明这个Broker同时监听两个端口，一个给内部网络，另一个给外部。内网使用具体的IP，而外部可能通过主机名解析到不同的IP，比如可能有负载均衡或者不同子网的情况。 -
inter.broker.listener.name
inter.broker.listener.name=INTERNAL。这应该是指定了Broker之间通信使用的监听器名称。因为Kafka的Broker需要与其他Broker通信来同步元数据和消息，所以这里设置成INTERNAL，意味着它们会使用内网的监听器地址进行通信。通常内网监听器的地址应该是可靠的，不会变化，适合服务间通信。 -
advertised.listeners
这里同样配置了INTERNAL和EXTERNAL。广告监听器是告诉客户端这个Broker的地址，客户端会根据自己所在的监听器类型来连接。比如，内部客户端可能会连接到INTERNAL的地址，而外部客户端则连接到EXTERNAL的。注意这里的EXTERNAL用的是主机名kafka1，可能需要DNS解析或者负载均衡来指向正确的IP -
listener.security.protocol.map
INTERNAL和EXTERNAL监听器都映射到PLAINTEXT协议。这意味着这两个监听器都不加密通信，适用于测试环境，但在生产环境中应该使用SSL或SASL等安全协议 。
总结一下：
用户可能的疑问包括：为什么需要两个监听器？如何区分内部和外部客户端？安全协议的选择有什么影响？另外，用户可能在配置过程中遇到了连接问题，比如客户端无法正确连接到EXTERNAL监听器，或者Broker之间的通信失败。需要确保DNS配置正确，防火墙开放相应端口，并且安全协议配置与客户端匹配。
还需要提醒用户，如果EXTERNAL使用主机名，要确保该主机名在客户端能够正确解析到对应的IP地址。此外，在配置多个监听器时，要注意端口不要冲突，并检查Kafka的日志是否有相关错误信息。对于生产环境，建议启用安全协议，避免数据泄漏。
还需要提醒一下，如果EXTERNAL使用主机名，要确保该主机名在客户端能够正确解析到对应的IP地址。此外，在配置多个监听器时，要注意端口不要冲突，并检查Kafka的日志是否有相关错误信息。对于生产环境，建议启用安全协议，避免数据泄露或中间人攻击。
配置效果总结
| 场景 | 客户端连接地址 | 实际通信端口 | 安全协议 |
|---|---|---|---|
| 内部 Broker 通信 | INTERNAL://192.168.1.50:9092 | 9092 (内网 IP) | PLAINTEXT |
| 外部客户端访问 | EXTERNAL://kafka1:9090 | 解析后的 IP:9090 | PLAINTEXT |
注意事项
-
DNS 解析：
• 外网客户端需能通过kafka1主机名解析到正确的 IP 地址。
• 建议在生产环境中使用负载均衡器（如 Nginx）或云服务（如 AWS ELB）绑定kafka1名称。 -
防火墙规则：
• 开放内网端口9092和外网端口9090（根据实际安全需求调整）。 -
安全性：
•PLAINTEXT协议不加密数据，建议仅在测试环境中使用。
• 生产环境中必须启用安全协议（如 SSL/TLS 或 SASL）。 -
配置一致性：
•listeners、inter.broker.listener.name、advertised.listeners需保持一致，否则会导致连接失败。
典型应用场景
• 混合网络架构：内网 Broker 通过固定 IP 互联，外网客户端通过域名访问。
• 隔离测试环境：内网开发/测试使用 IP，外网生产环境通过域名暴露服务。
• 负载均衡集成：外网监听器绑定到负载均衡器，隐藏 Broker 实际节点信息。
如果有具体问题（如连接报错），可以结合日志和网络工具（如 dig、telnet）进一步排查。
Nginx配置
假设nginx布在了60服务器上，首先也是需要配置hosts文件，解析kafka主机名的
192.168.1.50 kafka1
192.168.1.51 kafka2
192.168.1.52 kafka3
#以下配置kafka 映射
stream{
upstream kafka{
server kafka1:9090;
server kafka2:9090;
server kafka3:9090;
}
server{
listen 9090;
proxy_pass kafka;
}
#以下是模拟了两层Nginx代理，即再用一台Nginx将9090的Nginx代理出来。比较简单，就不赘述了
server{
listen 8090;
proxy_pass 192.168.1.60:9090;
}
配置好Nginx要重启，reload不生效~~~，要重启~~重启
测试
通过kafka命令进行生产、消费测试即可
生产者写数据
kafka-console-producer.sh --bootstrap-server 192.168.1.60:9090 --topic tesstByZl
消费者读数据
kafka-console-consumer.sh --bootstrap-server 192.168.1.60:9090 --topic tesstByZl
自己测试下吧，下班