3.2.3 Service Mesh之中心化Broker模式
各应用之间的通信还有一个模式，即中心化Broker，具体是指通信双方同时连接到一个中心的Broker。当服务消费者需要调用一个服务时，只需要将服务请求发给中心的Broker，然后Broker会从已经连接到Broker的服务提供者列表中查找能够处理该服务的服务提供者，并将服务请求转发给该服务提供者。当服务提供者处理完服务请求后，再将结果原路返给服务消费者。中心化Broker模式整体流程如图3-6所示。
图3-6 中心化Broker模式整体流程
为什么要采用这种模式？下面就来讲解中心化Broker模式的优势。
1）无端口监听。传统的服务提供者首先需要启动本地的监听端口，然后接收来自其他应用的服务请求。而Broker模式则是由服务提供者主动创建到Broker的连接，然后复用该连接处理来自Broker的服务请求。这种模式下，服务提供者依然可以对外提供服务，但是没有本地端口号的监听。这就使得安全性得到了非常大的提升，端口扫描、端口攻击、未授权访问这些问题都不复存在。
2）无网络要求。传统的点对点通信模式要求通信双方网络互通，应用之间能够创建连接并进行通信。而Broker介入后，只要通信各方能够连接到Broker即可通信。例如，我们有一些应用部署在阿里云上，一些服务部署在自己的数据中心，这种情况下，应用之间如何互通访问？是通过VPN网关吗？现在我们只需要在阿里云上部署Broker，阿里云上的应用就可以通过云VPC连接到Broker，私有数据中心的应用通过公网（互联网）连接到Broker，这样应用之间就可以互相通信了。无论应用来自办公室还是工厂，所有应用都可以通过Broker连接在一起。这些连接的创建都会经过安全认证，通信通道也是经过TLS（Transport Layer Security，安全传输层协议）加密的，完全不用担心数据在通信过程中存在安全风险。
3）无底层设施依赖。对基础设施无任何要求，只要有服务器，同时网络能被其他应用触达即可。无论是经典VM基础设施、Kubernetes、Cloud Foundry还是公司自研的PaaS系统等，中心化Broker模式都支持这些基础设施之间的相互访问。
4）无服务注册依赖，无负载均衡要求。Broker本身承担了服务注册的功能，不需要额外的服务注册产品。另外，服务请求全部由Broker转发，消费者不需要关心服务在哪里、如何创建连接、如何负载均衡等问题，因为服务是透明的。
5）简化运维。与管理大量的终端Envoy代理不同，中心化Broker后，我们只需要管理中心化的几台高性能服务器就可以了。
当然，Broker的优点不只上述5点，还包括集中权限认证、集中化的安全证书、集中化的流量管控等。既然Broker有如此多的优点，为什么Broker并不是很流行呢？为什么架构设计中很少谈到它呢？因为Broker确实也存在如下两个致命问题，如果这些问题得不到很好的解决，那么Broker基本上就无法使用了。
1）异步化架构。众所周知，Nginx的异步架构设计非常优秀，能够支持庞大的访问流量。如果Broker还是基于Thread Pool设计，那么根本没法应对C10k问题。这就要求Broker必须采用完全异步的架构设计，如EventLoop和Actor模式。这些名词对大家来说都不陌生，如Node.js和Akka都在使用，但是用在中心化的Broker设计上并不多见，同时这个开发成本也比较高。
2）协议适配和单点故障。应用之间的通信协议是多种多样的，如HTTP、RPC、各种自定义的消息协议等。Broker需要承担这些协议的适配和转发等，如果对这些协议处理得不好，可能会出现Broker不稳定、性能下降乃至不可用等问题，从而引发致命的中心化系统单点故障。
处理好中心化性能、稳定性和负载均衡等问题非常具有挑战性，这也是F5公司的BIG-IP非常昂贵的原因。但是这并不代表中心化Broker是风险很高、不能做的架构设计。随着技术日新月异的发展，Broker成为可能。RSocket和Broker的相互配合让基于Broker的Service Mesh方案成为可能。让我们从RSocket通信协议的介绍开始。
RSocket（网站地址为https://rsocket.io/）是一个异步二进制消息通信协议，该协议采用连接复用技术，在连接复用的基础上支持4个通信模型，具体如下。
1）Request/Response：请求/响应模型，如HTTP1.1、RPC等。
2）Request/Stream：流式数据请求模型，典型的模型如消息订阅Pub/Sub模型。
3）Fire-and-Forget：数据发送后无须响应，所以性能更高，但存在一定的消息丢失风险。其主要用在一些高性能、非关键数据的网络传输场景，如日志传输、Metrics上报等。
4）Channel：一种双向发送数据模式，主要应用在IM聊天、双向消息推送等场景。Channel是基于连接的抽象概念，也就是在一个实际的连接中，我们可以虚拟出成千上万个虚拟的Channel。
除了上述4个通信模型之外，RSocket协议还支持metadataPush模型，其主要用于运维场景，如执行事件通知等。另外，RSocket协议并不是完全封闭的，基于RSocket扩展新的通信模型非常方便。RSocket协议的另一个特点是通信双方是对等的，也就是没有传统意义上的Client/Server模式。这就意味着Client也可以响应来自Server端的请求，成为Server，这一特性与Broker对接入方的要求完全匹配。
上文中提到过，中心化Broker的架构模式是完全异步的，而RSocket是基于消息的全异步通信协议，满足异步要求。另外，我们可以想象，如果Broker支持非常多的协议适配，势必非常难实现，而且其稳定性和高性能可能会大打折扣。而RSocket协议是二进制的，且支持丰富的通信模型，基本涵盖了应用之间通信的全部场景。当然，其他通信协议也可以通过Gateway方式适配到RSocket协议之上。
下面就来讲解一下RSocket Broker典型的通信场景，如图3-7所示。
图3-7 RSocket Broker典型的通信场景
如图3-7所示，所有微服务都作为RSocket Client连接到中心化的RSocket Broker集群上，当有一个应用想要调用其他服务时，调用请求通过RSocket协议将消息发送给Broker，然后Broker根据服务路由表，将对应的请求转发给服务提供者，在请求处理完毕后，再由Broker负责将响应转发给服务调用方。整个通信过程是完全异步的，不会出现由于阻塞而影响系统性能的情况，同时异步化极大地提升了CPU利用率，从而提升了系统的处理能力。
RSocket作为一个标准通信协议，支持使用多种主流编程语言。RSocket多语言技术栈如图3-8所示。
图3-8 RSocket多语言技术栈
在SpringOne 2020大会上，VMWare的工程师发表了题为“Weaving Through the Mesh:Making Sense of Istio and Overlapping Technologies”的演讲，讨论了Istio和类似的重叠技术，着重阐述了Istio、Spring Cloud和RSocket Broker在Service Mesh场景的对比。感兴趣的读者可以搜索相关视频自行了解。
截至2020年10月，RSocket Broker产品主要有两款，分别是Spring的RSocket Routing Broker（网址为https://github.com/rsocket-routing/rsocket-routing-broker）和Alibaba RSocket Broker（网址为https://github.com/alibaba/alibaba-rsocket-broker）。虽然这两种架构设计有较大差别，但是在RSocket协议上都是兼容的，可以相互访问。