0. 前言

我们在开发过程中，需要对大模型做推理验证。而在开发环境下，由于本地物理机性能限制（GTX1660的显卡，GPU显存只有6G），在大模型推理的过程中，会报显存不足的错误，导致功能验证block。

为了满足这个业务需求，我们考虑是否可以将公有云上的硬件资源（Tesla T4显卡，显存有16G）接入到我们的开发环境里呢？

理论上是可行的，但是由于推理引擎是通过kafka队列获取任务，而我们的kafka是部署在内网环境下的，所以外网的推理引擎如何获取来自内网kafka的数据，是解决这个需求的关键。

于是，我们的需求就转换成了具体的问题：如何在外网服务器上访问内网的kafka集群？

1. 思路

思路1：将kafka迁移到公网，和推理引擎在一个网络环境
思路2：kafka还是放在内网，通过内网穿透，将kafka暴露给特定公网IP
思路3：内网kafka保持不变，在公网搭建另一套kafka，然后在内网新增一个中转服务，用于将内网kafka上的数据中转到公网的kafka

2. 方案

2.1 对比

思路1

优点
- 可以保证推理引擎可以顺利的从kafka中消费数据
- 无需内外网复杂环境下的kafka配置
- 内网业务服务可以消费kafka中的数据
缺点
- 部署kafka额外的工作量
- 所有内网业务服务都要修改kafka地址
- 业务服务间的基于kafka通信也要走外网，效率安全成本都有问题

思路2

优点
- 对内网现有业务服务没有影响，无需改动配置
- 对推理引擎来说，只需要修改下kafka链接地址
缺点
- 需要配置内外网穿透，有一定的学习门槛

思路3

优点
- 结合1和2
缺点
- 搭建外网kafka需要时间成本
- 需要额外开发一个转发队列消息服务
- 同样需要内外网穿透技术

从技术可行性和技术难度以及时间成本考虑，显然思路2是最佳选择。

2.2 落地

2.2.1 网络映射配置

假设：

内网kafka所在机器的ip：192.168.1.5
推理引擎公网ip：109.109.109.109
推理引擎内网ip：172.1.1.171

分别配置内外网的/etc/hosts：

内网 192.168.1.5 kafka
外网 ‌172.1.1.171 kafka

2.2.2 内网穿透配置

内网穿透用frp，将frp服务端（frps）部署在公网，客户端（frpc）部署在内网kafka机器上。

服务端（公网）配置：

‌[common]
bind_port = 7000
bind_udp_port = 7001

客户端（内网）配置：

‌[common]
server_addr = 109.109.109.109
server_port = 7000

[kafka]
type = tcp
local_ip = 192.168.1.5
local_port = 9092
remote_port = 909

[zookeeper]
type = tcp
local_ip = 192.168.1.5
local_port = 2181
remote_port = 2181

2.2.3 kafka配置

kafka主要配置server.properties文件中的两项：

listeners = PLAINTEXT://192.168.1.5:9092
advertised.listeners = PLAINTEXT://kafka:9092

2.2.4 原理和架构图

内网和公网的网络通信：是通过frp做穿透的，分别暴露9092/2181端口（如果公网没有暴露这些端口，可用80/443代替，前提是这俩端口没有被使用）。那么，在公网上，telnet 109.109.109.109 9092 就相当于在内网 telnet 192.168.1.5 9092。

kafka的配置里有一项是advertised.listeners，这个参数，顾名思义，advertised就是将kafka监听的ip+port 广而告之，这个参数会被注册到zookeeper上。这样，kafka客户端（即业务服务和推理引擎）在连接kafka服务端的时候，就会获得kafka的连接信息（即advertised.listeners的配置参数），即kafka:9092。

对于内网来说，kafka:9092 = 192.168.1.5:9092；对于公网来说，kafka:9092 = 172.1.1.171:9092。那么只要在相应的机器上配置/etc/hosts，加上域名和对应的ip映射即可。

基于FRP实现外部访问内网kafka集群