我们在不同设计模式中都谈到了RSocket Broker发挥的核心作用,这里我们想阐述一下为何有Broker这个概念。 Broker是介于服务调用方和服务提供方之间,协调两者之间的服务通讯。 加入一个中间Broker后,最大的好处就是调用方和服务提供方之间的解耦。
- 调用方: 不用感知服务提供者的信息: IP,端口号,当前健康度状态,服务方服务器数量等等问题,请求方只要将请求发给Broker就可以。
- 服务提供者: 服务启动后向Broker发送一个事件就完成啦服务注册,不需要额外的服务注册中心。另外服务消费者和服务提供者只和Broker打交道,调用透明,其他安全、流控等等全不用担心,这些Broker帮我搞定啦
- Broker中间人: Broker作为调用方和服务方的中间人,担当着服务注册、请求路由、安全、流量管控等角色,所有的信息都经过中间人,那么Observability和服务治理等都非常简单啦。
RSocket Broker典型的架构如下:
RSocket Broker是一个中心化的结构,这个和网关类产品的结构设计差不多,称之为软路由设计。不少同学可能会担心Broker成为网路瓶颈,这里解释一下Broker的设计:
- 全异步架构设计: 非传统的ThreadPool的结构设计,None-Blocking,不会出现阻塞导致的雪崩场景。Broker在解析RSocket协议时,采用零拷贝(Zero-Copy)的设计,只需读取协议头部分字节就完成请求转发
- 服务注册: 由于所有的应用都会连接到Broker进行注册,但是每一个应用只会和broker建立一个长连接,应用的元信息都保存在内存中。关于长连接的数量,不同语言实现的Broker性能不太一样,如基于Java开发的Broker,单机连接总数在30-50万之间,而C++ Broker可以做到单机100万左右。如果有更多连接,目前RSocket Broker通过集群方案进行解决。
- 开放式Ops API: Broker不参与到具体的计算中,如限流策略、安全防护等,这些都是Broker将数据给其他计算应用,然后将计算的结果返回给Broker,所有Broker会提供非常多的Ops API,这个和路由设备管理都是类似的。
基于以上的架构设计,大家基本不用担心RSocket Broker集群会成为系统单点或者瓶颈。当然不同厂商的RSocket Broker实现还有各自的特点,可以参考具体的产品。 这里也将当前的RSocket Broker产品列一下,方便大家参考:
- Alibaba RSocket Broker: Alibaba开源产品 https://github.com/alibaba/alibaba-rsocket-broker
- Spring Cloud RSocket: Spring Cloud团队推出的RSocket Broker,目前孵化中 https://github.com/rsocket-broker