Service Mesh

Service Mesh的典型架构是Sidecar的方案，关于Sidecar的架构已经有很多文章，这里介绍一下基于RSocket的Service Mesh方案。 下图是两者的架构对比：

从上图中我们可以看出，两者最大的区别在于SideCar Proxy和中心化Broker。RSocket的方案中，介入了Broker(中间人)，通讯的两端都会和Broker建立连接，然后服务间的通讯由Broker来负责转发。 RSocket能到这点主要是它采用了对等通讯模型，而不是传统的client-server模式，相当于Broker牵手了通讯的两端。

接下来让我们看一下这两个方案的对比，这里列举一下典型的特征对比：

• 基础设施层：两者都是，但是部署结构不太一样，一个是sidecar proxy + control plane，一个中心化broker并集成了control plane功能
• 服务到服务间的通讯： 两者都是在协调服务间通讯，不同的是sidecar proxy要适配各种通讯协议，而RSocket则通过自身丰富的通讯模型，来实现其他协议提供的功能。
• 应用或者设备接入： 并不是所有的设备都可以安装Proxy的，主要有几种原因：设备和系统本身就不支持，如IoT设备；另外一个是不经济，浪费钱： 如你用Node.js写一个function，只需要128M内存+1核CPU，如果要应用侧安装Envoy，那么1G内存可能就没有啦，卧榻之侧，岂容他人鼾睡； 特殊的网络环境，如在Edge端，要从云端control plane来反向控制Edge端的Proxy，那么可能要进行各种网络打通，设备，VPN，安全等等，相对非常复杂。
• 运维成本增加： 管理中心化的20台服务器RSocket Broker集群，和管理10K个Proxy实例是不一样的。 就好比我们在实现微服务架构时，如果你还没有容器化，那最好不要微服务，众多的应用数量会让你非常头痛，无容器不微服务。
• FAST: RSocket是异步化的， 异步化虽然没有解决请求响应的时长问题，但是异步化能提升系统的处理能力，大家不需要等待，理论上也是更快啦。 在SideCar的模式下，如果没有介入异步化处理，必然导致响应时间更长，系统就更慢啦。 即便你完成了Sidecar Service Mesh架构，你还是需要做异步化，不然TCP多跳和Proxy层协议解析，只会让系统更慢。 上述的架构图中，Sidecar是TCP 6跳，虽然其中4跳是本机内部进行的，额外2次协议解析，而RSocket是TCP 4跳，额外1次或者0次协议解析。
• 安全：这方面只能说在同样的安全要求下，RSocket的安全实现更简单。Broker目前主要是TLS + JWT，而非mTLS，不需要证书管理。 同时借助于JWT的安全模型，可以轻松实现更细粒度的权限控制。同时RSocket服务是无端口监听的，不配置端口监听对应的TLS证书，同时也避免了一定的网络攻击。
• RELIABLE：消息通讯可靠性这个大家都是能明白的，重新、序列化、转发投递等都非常容易，大家参考一下Reactive宣言，就明白Reactive架构设计的出发点。
• 无网络要求： sidecar还是采用传统的端口监听模式对外提供服务，而RSocket对外提供服务完全是无端口监听的，只要能能连接上Broker，任何服务就可以通讯，没有任何网络要求，iptables配置等。
• 网络交互模型： 如果要你采集应用的metrics怎么做？如果该应用在Edge端该怎么办？ Sidecar Service Mesh模型对网络还是非常强的依赖，你要做网络打通和安全保障等，这样应用间才能相互访问。 而Broker的介入，你完全不用考虑网络的问题，你完全不用知道应用在哪里，要采集metrics等，直接发给broker，broker帮你和应用进行通讯，然后拿回你需要的数据。RSocket的网络模型中，通常不允许其他系统直接访问应用，存在很大的安全风险，同时需要网络配合。