Kafka如何进行内外网分流(超详细建议收藏)

本文涉及的产品
密钥管理服务KMS,1000个密钥,100个凭据,1个月
简介: Kafka如何进行内外网分流网络通信中常见的配置文件解析
🔥《Kafka运维管控平台LogiKM》🔥

✏️更强大的管控能力✏️


🎾更高效的问题定位能力🎾


🌅更便捷的集群运维能力🌅


🎼更专业的资源治理🎼


🌞更友好的运维生态🌞

参数详解

listeners

侦听器列表,这里配置的监听器底层调用的是


ServerSocketAdaptor.bind(SocketAddress local)

那么这个说明什么意思呢?说明你配置的监听器将被用于监听网络请求。
简单理解就是你建立监听一个通道,别人能够通过这个通道跟你沟通。
所以我们需要设置 IP:Port.

更好的阅读体验Kafka如何进行内外网分流(超详细建议收藏)

这个属性的格式为:

 listeners = listener_name://host_name:port,listener_name2://host_nam2e:port2
  1. 可以同时配置多个, 并且用逗号隔开
  2. 监听器的名称和端口必须是唯一的,端口相同,就冲突了
  3. host_name如果为空,例如(listeners = ://host_name:port),则会绑定到默认的接口(网卡),一般情况下是localhost,底层调用的是

    java.net.InetAddress.getCanonicalHostName()
  4. 将host_name设置为0.0.0.0 则会绑定所有的网卡, 也就是说不管从哪个网卡进入的请求都会被接受处理。但是请注意,假如你设置的是0.0.0.0,那么advertised.listeners 必须要设置,因为advertised.listeners默认请看下使用的是listeners的配置发布到zk中,发布到zk中是给其他Brokers/Clients 来跟你通信的,你设置0.0.0.0,谁知道要请求哪个IP呢, 所以它必须要指定并明确 IP:PORT。具体详情请看下面 示例3
  5. listener_name 是监听名,唯一值, 他并不是安全协议(大部分人都会搞错),因为默认的4个安全协议已经做好了映射, 例如 :PLAINTEXT ==> PLAINTEXT . 所以你经常看到的配置

    ## 这个PLAINTEXT是监听名称,刚好他对应的安全协议就是 PLAINTEXT
    ## 当然这个是可以自定义的, 详细情况 后面的配置listener.security.protocol.map
    listeners = PLAINTEXT://your.host.name:9092
     
  6. 可动态配置该属性

advertised.listeners

发布公开的监听器, 啥叫发布公开的监听器?
就是,让Brokers和Clients们都能够知道的监听器,你想想看,listeners是Broker用来监听网络请求的

那么,其他Broker或者客户端想要与它通信,则需要知道具体的IP:PORT吧?
所以,为了让别人知道自己的监听器,那么就需要公开出去,当然这个公开的形式,是通过zk来共享数据。

看看broker到zk节点/brokers/{brokerid}/ 下面的信息示例

{
    "features": {},
    "listener_security_protocol_map": {
        "PLAINTEXT": "PLAINTEXT"
    },
    "endpoints": ["PLAINTEXT://localhost:9092"],
    "jmx_port": -1,
    "port": 9092,
    "host": "localhost",
    "version": 5,
    "timestamp": "1647337490945"
}

其中endpoints就是我们发布出去的监听器。
这个属性的格式为:


advertised.listeners = listener_name://host_name:port,listener_name2://host_nam2e:port2
  1. 默认情况下,advertised.listeners不设置会自动使用listeners属性
  2. advertised.listeners不支持0.0.0.0这种形式, 所以如果listeners属性设置成0.0.0.0,则必须设置advertised.listeners属性。具体请看 示例3
    因为0.0.0.0是表示的是监听Broker上任意的网卡的, 你将这个发布出去,那么别的Broker和客户端怎么知道你具体的ip和端口呢?
  3. 可以同时配置多个, 并且用逗号隔开
  4. 可动态配置该属性

listener.security.protocol.map

监听器名称和安全协议之间的映射关系集合。

listeners=PLAINTEXT://localhost:9092

看看上面的配置, PLANINTEXT是监听器名称,那么它对应的安全协议是什么呢?
它对应的安全协议是 PLANINTEXT, 为什么呢? 那是因为默认情况下,已经有了他们的映射关系。

默认集合:

PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL

属性格式:

监听名称1:安全协议1,监听名称2:安全协议2

现有的安全协议,有4种, 分别如下, 下为默认监听器名称映射对应的安全协议情况。

  1. PLAINTEXT => PLAINTEXT 不需要授权,非加密通道
  2. SSL => SSL 使用SSL加密通道
  3. SASL_PLAINTEXT => SASL_PLAINTEXT 使用SASL认证非加密通道
  4. SASL_SSL => SASL_SSL 使用SASL认证并且SSL加密通道

当然你也可以自己重新映射监听器名称和安全协议, 比如: 示例4

inter.broker.listener.name

用于Broker之间通信的listener的名称。如果未设置,则listener名称由 security.inter.broker.protocol 定义(security.inter.broker.protocol默认值是PLAINTEXT)。

同时设置 这个和 security.inter.broker.protocol 属性是错误的。

默认值:空

不可动态配置。

特别注意:这个属性表示是Broker之间的网络通信使用的监听器, 比如 Broker2Broker
但是还有一种就是Controller2Broker、如果没有配置control.plane.listener.name ,那么走的也是inter.broker.listener.name 这个监听器。

根据本地配置的监听器名称, 去查找其他Broker的监听器的EndPoint。所以一般所有Broker的监听器名称都必须一致,否则的话就找不到具体的EndPoint,无法正确的发起请求。

security.inter.broker.protocol

用于在代理之间进行通信的安全协议。

有效值为:PLAINTEXTSSLSASL_PLAINTEXTSASL_SSL

同时设置 该属性和 inter.broker.listener.name 属性是错误的。

默认值:PLAINTEXT (纯文本)

注意这个跟inter.broker.listener.name是有区别的, 这个配置只有四个选项,是安全协议
inter.broker.listener.name是监听名称, 是需要通过这个监听名称去找到它映射的 安全协议 还有 IP:PORT

如果inter.broker.listener.name没有配置,则默认使用 security.inter.broker.protocol 的配置. 对inter.broker.listener.name而言,最终还是要去找到对应的 IP:PORT

一般自定义了监听器名称, inter.broker.listener.name就是必须要设置的, 不能使用security.inter.broker.protocol 来代替。

control.plane.listener.name

用于Controller和Broker之间通信的监听器名称, Broker将会使用control.plane.listener.name 来定位监听器列表中的EndPoint

如果未设置,则默认使用inter.broker.listener.name来通信,没有专门的链接。

示例说明

1 . 绑定一个IP, 客户端使用另外的IP访问

让broker 监听localhost:9092. 然后客户端访问broker的具体IP.

listeners=PLAINTEXT://localhost:9092

启动之后查看一下监听情况

Linux命令: netstat -anp |grep 9092
Mac环境命令:netstat -AaLlnW

在这里插入图片描述

当然,如果你这台机器刚好还是Controller的话,除了了LISTEN, 还能看到ESTABLISHED状态的连接,因为Controller也会给这台Broker建立连接发起请求的,比如通知Broker更新元信息之类的。

在这里插入图片描述

我们使用生产者客户端来生产几条消息

sh bin/kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092  --topic Topic4
## 或者
sh bin/kafka-console-producer.sh --bootstrap-server localhost:9092  --topic Topic4

在这里插入图片描述
在这里插入图片描述

可以发现正常发送消息。

那么接下来,使用使用具体IP发起请求


sh bin/kafka-console-producer.sh --bootstrap-server 10.xxx.xx.128:9092  --topic Topic4

在这里插入图片描述

[2022-03-16 12:59:07,024] WARN [Controller id=1000, targetBrokerId=1000] Connection to node 1000 

(/10.xxx.xxx.xx:9092) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)

可以看到,客户端提示说不能跟这个ip:port建立连接。

2. listeners 和 advertised.listeners 配置的IP不一样


listeners=PLAINTEXT://xx.xx.xxx.01:9092

advertised.listeners=PLAINTEXT:/xx.xx.xxx.02:9092

假设你本地监听和发布的监听不一样, 那么就会造成其他broker和客户端跟这台broker不能正确的建立链接。

如果你这台Broker刚好还是Controller,那么他也会对自己建立连接, 都是根据advertised.listeners的配置来建立的,同样会失败。其他broker也一样。


[2022-03-16 12:59:07,024] WARN [Controller id=1000, targetBrokerId=1000] Connection to node 1000 

(/10.xxx.xxx.xx:9092) could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)

3 . listeners监听任意可用IP, advertised.listeners发布指定IP

在示例2中,我们指定 listeners 监听器和advertised.listeners发布的监听器不一致会导致异常。
那么,我们只需要将监听器的和发布的监听器一致就行了

当然,我们还可直接设置监听器监听任意可用IP(该Broker上的可用IP)

listeners=PLAINTEXT://0.0.0.0:9092

当然,如果只是将host设置为 0.0.0.0. 那么会报错

java.lang.IllegalArgumentException: requirement failed: advertised.listeners cannot use the nonroutable meta-address 0.0.0.0. Use a routable IP address.
    at kafka.server.KafkaConfig.validateValues(KafkaConfig.scala:1789)

因为默认情况下,advertised.listeners不设置的话,则默认使用listeners的属性,然而advertised.listeners是不支持0.0.0.0的,所以需要指定暴露的监听器,如下

listeners=PLAINTEXT://0.0.0.0:9092
advertised.listeners=PLAINTEXT://xx.xx.xx.128:9092

这样子配置就不会报错了,其他Broker和客户端会通过advertised.listeners发布的监听器来跟该Broker建立链接。

注意: 这个时候你还可以在这台Broker的机器上使用 localhost 来进行访问。比如:


 sh bin/kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092  --topic Topic4
 

在这里插入图片描述

可以看到也是可以正常发送消息的。

4 . listeners配置多个监听器,内外网分流


listeners = INSIDE://内网IP:9091,OUTSIDE://外网IP:9092

#把OUTSIDE 的安全协议映射成PLAINTEXT INSIDE也映射成PLAINTEXT
listener.security.protocol.map=INSIDE:PLAINTEXT,OUTSIDE:PLAINTEXT

# Broker之间的连接用 INSIDE 监听器
inter.broker.listener.name=INSIDE

设置了2个监听器
①. INSIDE 监听内网IP
②. OUTSIDE 监听外网IP

因为这个是我们自己定义的监听名称,listener.security.protocol.map默认映射中并没有对应的映射关系
所以我们就需要主动设置这个映射关系
listener.security.protocol.map=INSIDE:PLAINTEXT,OUTSIDE:SSL

不然会抛异常

Caused by: java.lang.IllegalArgumentException: No security protocol defined for listener INSIDE

    at kafka.cluster.EndPoint$.$anonfun$createEndPoint$2(EndPoint.scala:48)

注意:自定义了监听器,则必须要配置inter.broker.listener.name

确定好内部的broker之间通信的监听器. 并确保能够正常访问。

这样Broker直接就会通过内网互相连接, 客户端除了可以通过内网连接(如果在内网环境的话),也可以通过外网连接。

几种场景的配置方式

1. 一台机器部署一套集群

这种场景一般是自己开发测试的时候, 比如自己搭建一个集群,学习学习,但是又没有那么多机器,那么就可以在一台电脑上部署多个Broker。

只配置listeners属性


listeners = 监听名称://your.host.name:port

关于监听名称,默认的映射关系有4种。

  1. PLAINTEXT => PLAINTEXT 不需要授权,非加密通道
  2. SSL => SSL 使用SSL加密通道
  3. SASL_PLAINTEXT => SASL_PLAINTEXT 使用SASL认证非加密通道
  4. SASL_SSL => SASL_SSL 使用SASL认证并且SSL加密通道

简单一点,用PLAINTEXT就够了, 这里我们可以把host给去掉, 或者使用localhost


listeners = PLAINTEXT://:port
或者
listeners = PLAINTEXT://localhost:port

如果没有配置host,会调用java.net.InetAddress.getCanonicalHostName()获取本机host. 默认情况下就是localhost.

这里之所以建议你不填写具体的host,是因为一般自己搭建玩玩的时候可能网络IP会经常变动(例如家里的和公司), 如果绑定了具体的IP的话,每次重启都要更换配置就很麻烦。

可以看看Broker启动后注册到zk中的配置如下

{
    "features": {},
    "listener_security_protocol_map": {
        "PLAINTEXT": "PLAINTEXT"
    },
    "endpoints": ["PLAINTEXT://localhost:9092"],
    "jmx_port": -1,
    "port": 9092,
    "host": "localhost",
    "version": 5,
    "timestamp": "1647337490945"
}

这个endpoints 就是broker注册到zk的访问地址, 如果其他Broker或者客户端要跟这台Broker发生网络请求话, 就是拿的这里面的值。

所以,你想想看,如果是不同机器上,你配置的host是 localhost, 是不是就访问不了?

当然,listeners属性的host,我们也可以自己去hosts文件里面配置别的域名。配置域名指向的具体IP, 这样的话那还能奏效。就是每个Broker和客户端都要配置host,这就比较麻烦,所以还不如直接配置IP呢。

2. 内网环境多机器部署集群

这种是绝大部分的场景, 一般公司部署集群都是在公司内网环境下, Broker之间和Broker与客户端之间都在同一个网络环境。并且安全协议都是直接PLAINTEXT(明文)或者其他


listeners=PLAINTEXT://ip:port

3. 内网和外网分流


listeners=INTERNAL://内网ip:port1,EXTERNAL://外网ip:port2

#把OUTSIDE 的安全协议映射成PLAINTEXT INSIDE也映射成PLAINTEXT
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT

# Broker之间的连接用 INSIDE 监听器
inter.broker.listener.name=INTERNAL

配置了两个监听器,每个Brokerinter.broker.listener.name=INTERNAL 使用内网交流。

其他的客户端例如Producer和Consumer 请求的时候直接访问外网IP.

3. 内网和外网和Controller分流


listeners=INTERNAL://内网ip:port1,EXTERNAL://外网ip:port2,CONTROLLER://内网ip:port3,

#把OUTSIDE 的安全协议映射成PLAINTEXT INSIDE也映射成PLAINTEXT
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT,CONTROLLER:PLAINTEXT

# Broker之间的连接用 INSIDE 监听器
inter.broker.listener.name=INTERNAL
control.plane.listener.name=CONTROLLER

这样配置

  1. Controller2Broker或者Broker2Controller
  2. Broker2Broker
  3. Clients2Broker

他们都会会有独立的网络通信线程

相关文章
|
6月前
|
消息中间件 运维 负载均衡
【Kafka】Kafka 实现负载均衡与故障转移
【4月更文挑战第5天】【Kafka】Kafka 实现负载均衡与故障转移
|
消息中间件 Kafka 网络安全
Conduktor连接阿里云Kafka集群
Conduktor是一款商业化的Apache Kafka Connector,可以使用该工具连接Kafka Cluster,方便对集群信息如Topic,Group,Partition,Offset能信息的在线管理的查看,本文主要在Windows10环境下演示该工具的下载以及如果连接阿里云上的Kafka集群。
1205 0
Conduktor连接阿里云Kafka集群
|
4月前
|
消息中间件 Java 测试技术
消息队列 MQ使用问题之数据流出规则是否支持平台的云RabbitMQ
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
24天前
|
消息中间件 存储 Prometheus
Kafka集群如何配置高可用性
Kafka集群如何配置高可用性
|
3月前
|
消息中间件 监控 Java
联通实时计算平台问题之监控Kafka集群的断传和积压情况要如何操作
联通实时计算平台问题之监控Kafka集群的断传和积压情况要如何操作
|
3月前
|
消息中间件 负载均衡 Kafka
Kafka 实现负载均衡与故障转移:深入分析 Kafka 的架构特点与实践
【8月更文挑战第24天】Apache Kafka是一款专为实时数据处理和流传输设计的高性能消息系统。其核心设计注重高吞吐量、低延迟与可扩展性,并具备出色的容错能力。Kafka采用分布式日志概念,通过数据分区及副本机制确保数据可靠性和持久性。系统包含Producer(消息生产者)、Consumer(消息消费者)和Broker(消息服务器)三大组件。Kafka利用独特的分区机制实现负载均衡,每个Topic可以被划分为多个分区,每个分区可以被复制到多个Broker上,确保数据的高可用性和可靠性。
77 2
|
5月前
|
消息中间件 网络安全 网络虚拟化
消息队列 MQ操作报错合集之如何实现公网访问内网RocketMQ集群
在使用消息队列MQ时,可能会遇到各种报错情况。以下是一些常见的错误场景、可能的原因以及解决建议的汇总:1.连接错误、2.消息发送失败、3.消息消费报错、4.消息重试与死信处理、5.资源与权限问题、6.配置错误、7.系统资源限制、8.版本兼容性问题。
|
6月前
|
消息中间件 Java API
MQ产品使用合集之RocketMQ dledger集群模式的dledgerpeers端口是集群之间通讯吗
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
6月前
|
消息中间件 负载均衡 Java
【Kafka】Kafka 中消费者与消费者组的关系与负载均衡实现
【4月更文挑战第11天】【Kafka】Kafka 中消费者与消费者组的关系与负载均衡实现
|
6月前
|
消息中间件 网络协议 前端开发
Kafka接入到Graylog5.1
Kafka接入到Graylog5.1
90 0
下一篇
无影云桌面