我曾经在不同的场景下给Kafka配置域名，难度各有不同，这篇文章按照从易到难的顺序介绍三种难度下给Kafka配置域名的方法。
内容提要：
- 背景说明
- 初级难度 - 无认证Kafka
- 中级难度 - SASL/PLAIN认证Kafka
- 有人捣乱的难度 - Ambari中SASL/PLAIN认证Kafka（重点）
1. 背景说明
- 在默认的Kafka配置下，客户端与Kafka集群通信都是通过broker的主机名进行的，因此客户端都需要在
/etc/hosts中配置各个broker的IP和主机名； - 采用主机名通信的方式带来的问题是，客户端要配置所有broker的主机名，一是麻烦，用户不爽；二是如果扩容必须通知到所有的上下游，否则访问会出错（因为客户端解析不出新的主机名）；
- 给Kafka配置域名可以很好地解决上面的问题，但相应地，付出的代价是，Kafka的管理人员需要进行额外的配置；
- 本文介绍三种难度下给Kafka配置域名访问的方法，分别是：
- 无认证Kafka，支持内外网同时访问，内网配置域名；
- SASL/PLAIN认证Kafka，支持内外网同时访问，内网配置域名；
- Ambari发行版的SASL/PLAIN认证Kafka，支持内外网同时访问，内网配置域名；
- 三种方法有一个共同的前提：配置好DNS，将域名解析到所有Kafka broker的IP地址，并且在扩容（如果有）的同时，更新DNS解析配置；
- 本文所出现的配置域名的方法在1.0（包括）之后的多个版本都应用过，如有例外，欢迎反馈；
为了方便表述，假设一台broker的内、外网地址分别为 192.168.1.1 和 8.8.8.8，内网使用 9092 端口，外网使用9093 端口，因为各个broker的配置方式是相同的，所以我将以这个broker的配置为例讲解，其它broker的配置请自行类推。
注意，不配置域名的情况下，kafka的 listeners 一般长下面这个样子：
listeners=PLAINTEXT://:9092
# 或者 listeners=PLAINTEXT://localhost:9092
2. 初级难度 - 无认证
因为要支持内外网同时访问，初级难度也不初级，先看配置：
listeners=PLAINTEXT://192.168.1.1:9092,EXTERNAL://8.8.8.8:9093
listener.security.protocol.map=PLAINTEXT:PLAINTEXT,EXTERNAL:PLAINTEXT
security.inter.broker.protocol=PLAINTEXT
解释一下：listeners 的格式是多个逗号分隔的 安全协议://主机名或IP或域名:端口，但是安全协议不可以重复，如果相同的话，就需要使用 listener.security.protocol.map 配置项来进行映射，这里就采用了这种方法，security.inter.broker.protocol 这个配置也需要从 listeners 中的安全协议（或listener名称）进行选择。这种配置方法，以及接下来的两种配置方法的理论根据都可以参考 KIP-103。
可以看到，配置域名访问最重要的地方是，用IP来替换原来的默认配置或者主机名配置，这样客户端获取的broker元信息就是IP而不是主机名，所以也就不需要配置 /etc/hosts 了。
3. 中级难度 - SASL/PLAIN认证
配置其实和无认证情况的类似，但需要多两个配置：
listeners=SASL_PLAINTEXT://192.168.1.1:9092,EXTERNAL://8.8.8.8:9093
listener.security.protocol.map=SASL_PLAINTEXT:SASL_PLAINTEXT,EXTERNAL:SASL_PLAINTEXT
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.enabled.mechanisms=PLAIN
sasl.mechanism.inter.broker.protocol=PLAIN
没什么好说的，不过内外网的安全协议并非都要是 SASL_PLAINTEXT，一个为 SASL_PLAINTEXT，一个为 PLAINTEXT 也是OK的。
4. 有人捣乱的难度 - Ambari中SASL/PLAIN认证
其实无论使用什么发行版的Kafka，上面两种配置方法都应当是一样的，但是你挡不出Ambari给你造个bug。我按照上面的方法在Ambari中进行配置，也确实有效，认证和域名访问都正常，就有一个问题，Ambari会报警，报警如下：
图中遮住的部分是真实的内网地址，这个报警就让人很摸不着头脑了，9093端口绑在外网，从内网可不是不通吗？尴尬的是，如果不解决这个问题，报警就没有作用了，但监控broker的存活还是很有必要的，我尝试了以下三种解决方法：
- 调换
listeners中内外网的顺序，把外网listener放前面，结果又报警说连不上外网的9092端口，无语； - 读Ambari代码，想从里面找到它是怎么切分这个IP和端口的，无果；
- 在Cloudera Community提问，感兴趣可以去看这个问答，有人热心的帮我复现了这个错误，但是没有解决；
上面的方法都失败之后，我想起之前看过的一篇博客，详细的讲解了 listeners 和 advertised.listeners 的区别和用法，重新看了一遍之后，终于用下面的配置让Ambari不再瞎报警：
listeners=SASL_PLAINTEXT://0.0.0.0:9092,EXTERNAL://0.0.0.0:9093
advertised.listeners=SASL_PLAINTEXT://192.168.1.1:9092,EXTERNAL://8.8.8.8:9093
listener.security.protocol.map=SASL_PLAINTEXT:SASL_PLAINTEXT,EXTERNAL:SASL_PLAINTEXT
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.enabled.mechanisms=PLAIN
sasl.mechanism.inter.broker.protocol=PLAIN
注意到我修改了 listeners 的配置，并新增了 advertised.listeners 的配置，为什么这样就可以解决呢？
listeners中配置的IP和端口的作用是接收客户端初始请求，而客户端实际生产和消费数据使用的是advertised.listeners中的IP和端口，当没有advertised.listeners配置的时候，advertised.listeners就直接复用了listeners的配置。当我们把listeners中的IP绑定在0.0.0.0的时候，这两个端口内外网都可以访问到，但advertised.listeners给内网客户端返回的是内网地址和端口，给外网返回的是外网地址和端口，因此内外网访问也得以分开，最重要的是，Ambari在通过端口来检测broker是否存活时不会再有问题，因为无论两个端口通过内外网都可以访问到。
解决Ambari的瞎报警问题之后，我在Cloudera Community上回复了帮助我复现问题的人并把方法也贴了上去。
这是我最近在工作中爬过的坑，希望你可以在这个坑里少呆一会。
欢迎交流讨论，吐槽建议。
勤学似春起之苗，不见其增，日有所长
辍学如磨刀之石，不见其损，日有所亏
关注【大数据学徒】，用技术干货助你日有所长
