confluent kafka网络体系解读
前言
因工作需要，看了一些confluent官方文档中关于网络的一些内容，做一些总结。本次解读重点分析confluent是如何在云上构建自己的网络体系来适配多云的差异，并且为用户提供稳定的消息服务的。
confluent网络解决方案概览
confluent cloud提供了几种不同的集群类型，不同的集群类型可选的网络解决方案也会不同。关于为什么不同cluster的网络存在如下差异，根据官方文档的描述，可以推测
- basic and standard cluster: 没有提供private的网络方案，主要是为了快速体验，降低部署运维复杂度。standard集群是product ready的，但是仍然不提供私网访问，可见引入私有网络会大大增加复杂度，因此confluent在整体网络解决方案做了细致的划分，避免过早引入私网复杂度，降低使用门槛和成本
- enterprise cluster: 可以理解是多租的云服务，并且confluent是构建在aws上，面相企业级的，默认就只提供基于aws的private link
- dedicated cluster: 独占集群，生产级别最高的类型，因为是独占的，可以多云部署
tips:
- 无论私有还是公有网络，全部基于TLS 1.2 和API keys做数据加密
- public/private 网络模式选定后无法再更改
私有网络的主要技术在云上主要如下，云上基本都提供了如下两种基本方式，aws做的更加完善一些，还有transit gateway这样的中心化私有网络云路由服务。
- vpc peering: 关注独立的vpc之间的通信
- private link: 主要关注私有vpc和云服务之间的通信
公有网络解决方案
云上的公有网络方案其实主要需要考虑的点是**保证访问endpoint的可靠性。**这种可靠性可以概括为以下两个维度：
- 地址稳定：云上的计算实例分配的public ip往往是不稳定的，如果引入EIP又会提升技术复杂度，需要处理eip的换绑。这块从confluent的文档我们可以看到他主要是采用了代理模式，在云上推测大概率是引入云的LB服务。对于endpoint通过域名访问。这个可以参考confluent aws network的文档
- 安全性： 暴露在公网需要有防dos、ddos等网络攻击的能力
Confluent Cloud clusters with internet endpoints are protected by a proxy layer that prevents types of DoS, DDoS, syn flooding, and other network-level attacks.
私有网络解决方案
这块主要是对云本身的能力的适配，不过概括起来其实任何云基本都会提供两种私网方案，名字上可能会有些不同，但是本质和应用场景是一样的：
- vpc perring：独立的vpc之间的通信
- private link/private service connect: 用户私有vpc和云上服务之间的私有通信
多可用区网络
除了私有、公有网络影响网络拓扑以外，在云上还需要考虑可用区分布。一般都是均衡分布，提供最佳的可用性级别。
Confluent for kubernetes(CFK)的网络
随着k8s的诞生，confluent的核心架构也逐建迁移到k8s上。2011年confluent推出了CFK，主要是解决私有化输出的问题。通过查看CFK网络相关的文档，由于其暴露了更多底层细节，我们可以知道其网络是如何构建的。简单来说让用户自己通过CR去定义自己的网络资源，网络资源会通过FQDN来唯一标识，透出的方式主要是靠云LB。
1 | ## 可以为集群上的组件例如broker、bootstrap server定义FQDN |
k8s上的CFK网络结构可以参考下图
host-based静态访问
这个是cfk暴露的一种网络能力，本质就是暴露底下的静态host-name给用户，让用户自己去关联网关，定义域名，有更好的灵活性
关于文中提到的SNI：SNI是TLS协议的扩展，主要是允许一个ip、port关联多个域名和证书。通过使用SNI，服务器可以根据客户端在TLS握手过程中提供的主机名来选择正确的证书