我个人不会通过tcp直接向客户机公开kafka服务器，原因如下：
如果一个坏客户端打开了太多的连接，这可能会影响kafka平台的稳定性，也可能会影响其他客户端
kafka服务器上打开的文件太多，需要进行硬件/软件设置和操作系统调整，以限制不受控制的客户端
如果您需要添加kafka服务器来提高可伸缩性，那么您可能需要在客户端和服务器端进行大量的低级别配置（防火墙、ips可见性、证书等）。其他产品使用网关或代理解决这些问题：coherence使用扩展代理客户端，tibco ems使用路由目的地，其他sw（许多jms服务器）使用存储转发机制，等等。
如果客户机连接到kafka服务器，则kafka节点的维护还必须考虑客户机的需求和与客户机定义的sla（服务级别聚合）（例如247365）
如果您还将kafka用作后端服务，则应考虑多层体系结构：fe网关和be服务等。
其他注意事项需要了解您认为系统中的外部（通过互联网）消费者/生产者是什么。它是您系统中需要访问kafka服务器的组件吗？他们是你组织内部的还是外部的，等等。。。
当然，所有这些问题也可以通过使用到kafka服务器的tcp直接连接来正确解决，但我个人会使用不同的解决方案。
http代理
或者至少我会使用一个专用的fe kafka服务器（或者ha的两个服务器），为每个客户机专用，将消息转发到主kafka服务器组

除了配置客户机tls之外，代理还必须具有我们试图避免的公共ip。通常对于其他服务，我们将所有内容隐藏在负载平衡器后面。Kafka能做到这一点吗？
当您需要java producer客户机的高性能批处理时，我不确定托管在公共服务器上的合流rest代理是一个真正的选择。

有可能通过互联网公开Kafka（事实上，这就是管理Kafka的提供商，如aiven和instaclustr赚钱的方式），但你必须确保它有足够的安全性。至少：
zookeeper节点应该位于专用子网中，并且不能从外部路由。zk的安全性是不够的，无论如何，它不再需要用zk地址引导kafka客户机。
在网络级别限制对代理的访问。如果您的所有客户端都是从受信任的网络连接的，那么请设置适当的防火墙规则。如果在aws中，如果您正在连接云到云或云到地，请使用vpc对等或直接连接。如果您的大多数客户机都在受信任的网络上，但相对少数客户机不在，请强制后者通过vpn隧道。最后，如果您想允许从任意位置进行连接，您只需 allow * 在端口9092上（或配置代理侦听的任何端口）；确保其他端口都关闭。
为客户端代理连接启用tls（ssl）。这很容易用自签名ca进行配置。根据您公开侦听器的方式，您可能需要在客户端上禁用ssl主机名验证(如果播发的主机名与证书的公用名不匹配，则证书信任链将断开。）客户端将需要安装ca证书(与签署经纪人证书的ca相同。）
可选地，您可以启用相互tls认证；然而，这在逻辑上更为繁重，因为它要求每个客户机都有自己的私钥，该私钥由代理信任的ca签名。
使用sasl向代理验证客户机，并为每个应用程序和预期访问集群的每个人创建单独的用户。
遵循最小权限（polp）原则，在acl中为每个用户发出最少足够的集群级和主题级访问权限。
要记住的另一件事：并非所有工具都支持sasl/ssl连接，有些工具实际上需要连接到zookeeper节点（在上述设置中无法访问）。确保您所依赖的任何工具都直接使用“新”样式的连接到kafka代理，并且不需要zookeeper连接。

Kafka的有线协议是基于tcp的，在公共互联网上运行良好。在最新版本的kafka中，您可以为内部和外部流量配置多个接口。生产中的kafka在internet上的例子包括heroku、ibmmessagehub和confluentcloud提供的几个kafka-as-a-service产品。
如果kafka客户机使用新的使用者api，则不需要公开zookeeper。
您也可以选择公开一个rest代理，比如开源合流rest代理，作为一个更为客户端防火墙友好的接口，因为它运行在http上，并且不会被大多数公司或个人防火墙阻止。