基于隧道的Kafka混合云传输链路

现在不少公司的业务都采用混合云架构，很多时候会存在跨多机房的数据交互需求。这里说的跨机房包括下面几种情况：

1. 自有机房-公有云机房
2. 公有云机房-公有云机房（相同服务商）
3. 公有云机房-公有云机房（不同服务商）

一般来讲前两者都可以通过专线链路解决，打通专线连接之后这些机房间的机器可以实现完全互通；但第三种情况则非常复杂，至少目前没有哪个公有云服务商提供了这种服务，给架构设计带来了一定挑战。

显然这个时候数据通信基本只能通过公网链路，安全隐患巨大且稳定性欠佳（带宽成本先放一边）。如采用VPN方式也可以部分解决问题，但是VPN自身稳定性和性能一般且增加了网络架构的复杂性。

经过实践考验，这里提出一种新的技术思路，即基于SSH隧道的公网传输链路，以互联网最常用的Kafka中间件为例。

关于SSH隧道本身的介绍和原理，若有不理解的请自行查阅文档，本文不再赘述。

这里主要使用的local port forwarding方式，这种方式会在当前机器上监听一个端口，并将所有数据转发至远端机器某个端口。

案例的整体部署架构如下：

• 数据Producer集群，2台普通虚机，部署在公有云A
• 目标Kafka集群，3台普通虚机，部署在公有云B，需开启公网SSH
• 每台Producer机器都打通到3台Kafka Broker的SSH免密登录（注意请提前开启防火墙策略）

为了实现隧道转发，Broker的监听器（listener）需要额外监听一个的本地端口，即127.0.0.1:PORT，因为Kafka本身就支持监听多个端口，所以只需要在原有配置中增加即可。

特别注意的是， 每台Broker的本地监听端口必须错开绝不能相同，例如依次配置为9093,9094,9095

在Producer端，每台机器针对每个Broker都启动一个SSH端口转发连接，转发目标地址即为127.0.0.1（也就是远端机器自身），端口请保持跟Local端口一致，否则与Broker的监听注册信息不一致，将无法投递成功。

Producer的Bootstrap设置为127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094。此时Producer可像正常一样投递消息。考虑到公网的稳定性，请自行增加出错重试次数，确保不丢数据。

SSH隧道有很多优点，如性能较高，对比原生本地通信几乎无性能衰减；稳定性好，对于公网抖动等情况不敏感；安全性好（这个仁者见仁了，毕竟很多公司对SSH这种东西非常敏感）。使用者应妥善管理SSH的私钥信息，做好安全管控如IP白名单、入侵检测等，避免产生安全隐患。

在生产实践中，上述方案得到了多次验证和实际应用，体现出很好的技术价值。

对于其它中间件，能否使用上述方案有待实践验证，理论上讲这是一种普适性的方案，与上层的通信协议无关。

---EOF---