个大家也能理解,如果进程 A 直接发给另外一个进程 B,必然要了解对应的内存地址,微内核中的服务是可以被随时替换的,如果服
务不可用或者被替换,这个时候要通知和其通讯的其他进程,是不是太复杂?刚才已经提到,只有 send 和 receive 接口,没有其他
通知下线、服务不可用的接口。在微内核的设计中,一定是通过总线结构,进程向 Kernel 发送消息,然后 kernel 再发送给对应的进
程,这样的一个总线设计。实际上很多应用内部在做 Plug-in 组件解耦时,都会使用 EventBus 的结构,其实就是总线的设计机制。
为何婆婆妈妈说这些?因为非常关键。分布式的进程通讯是微服务的核心,我们理解的服务到服务的通讯,就是服务 A 启动监
听端口,服务 B 会和服务 A 建立连接,然后两者通讯即可。这个方式和微内核设计中内核负责消息接收和转发的总线架构设计是不一
样的。如采用 HTTP,HSF 等通讯协议时,相当于 kernel 告知通讯的双方各自的地址,然后它们之间就可以通讯了。然后就没有 Kernel
什么事情了,也不会用到什么总线的结构设计,这个就是传统的服务发现机制。
Plug-in 组件,也就是微服务架构中的服务,是不能直接通讯的,而是需要 Core System 进行转发。这样做的好处和微内核架
构一样,插件相互之间无直接联系,彼此之间非常透明,例如服务 A 下线后,完全不需要通知其他服务;服务 A 被替换,也不需要通
知其他服务;服务 A 从数据中心 1 到数据中心 2,也不用通知其他服务;即便服务 N 和服务 A 之间网络不互通,两者之间也能通讯。
这里有个问题:性能问题。我们都知道,两点之间,直线段最短。为何要多绕一下到 Core System 呢?这就是微内核和宏内核
之间的争论之处,使用函数调用非常快,而进程间的消息通讯则是非常慢的,但是这种通过中介进行通讯机制的好处也是非常明显的。
那么如何提升这种基于总线的通讯性能呢?当然有,比如选择高性能的二进制协议,HTTP 1.1 这种文本协议就不需要了;采用 Zero
Copy 机制,可以快速进行网络包转发;好的网络硬件,如 RDMA;好的协议,如基于 UDP 的 QUIC 等。总结下来,和微内核一样,这种
微服务通讯的性能是可以提升的。当然如果实在受不了这种性能,在关键场景,你可以采用 Hybrid 模式,混入一些服务之间直接通
讯的设计,但只能在性能极致的场景中使用。
此外,插件化架构中的插件组件是各种各样的,通讯的机制也各不一样,一些是 RPC 的,一些是 Pub/Sub 的,一些是无需 ACK
的(如 Beacon 接口),还有一些是双向通讯的等等。当然你可以选择不同的通讯协议,但是这里有一个问题,就是 Core System 需要
理解这个协议,然后才能进行消息路由。这个时候 Core System 需要编写大量的 Adapter 来解析这些协议,例如 Envoy 包含各种 filter
来支持不同的协议,如 HTTP、MySQL、ZooKeeper 等,但是因此 Core System 就会变得非常复杂且不稳定。
另外可以选一种通用的协议,Core System 只支持这一种协议,各个插件之间都基于该协议通讯,至于服务和其他外部系统如
何通讯,如数据库、github 集成等,这些 Core System 并不关心,那只是 Service 内部的事情。目前比较通用的协议是 gRPC,如 K8s
内部都会采用该协议,另外 Dapr 也采用 gRPC 协议做服务集成,因为 gRPC 提供的通讯模型基本可以满足大多数的通讯场景。当然另
外一个就是 RSocket,提供更丰富的通讯模型,也适用于 Core System 这种服务间通讯场景。对比 gRPC,RSocket 可以运行在各种传
输层上,如 TCP、UDP、WebSocket、RDMA 等,相反的,gRPC 目前只能运行在 HTTP 2 之上。
3.服务通讯的延伸
前面说到,最好由插件化架构设计的 Core System 作为服务之间消息通讯的路由,如果是这样的话,就会产生一种 Broker
模式,当然也有可能是 Agent。这里大家一定会想到 Service Mesh,没错。当然你可以选择 Agent Sidecar 模式,也可以选择中心化
的 Broker 模式,这两者的功能都是一样的,只是处理的方式不一样而已。Agent 基于服务注册和发现机制,然后找到对方服务的 Agent,
再进行两个 Agent 之间的通讯,只是省掉服务之间的调用的开销。但是 Broker 是集中式的,大家都向 Broker 发送和接收消息,不涉
及服务注册发现机制,不涉及服务元信息推送,就是总线结构。
我现在做的就是基于这种 Broker 的总线的架构设计,在 RSocket Broker 中,也是采用微内核架构设计,当然未必做得最好 。
RSocket Broker 核心就是管理注册的服务、路由管理、数据采集等,而不会添加过多的功能,和 Core System 的设计理念一样,只添
加必须的功能。如果你要扩展整个系统更多的功能,如发短信、发邮件、对接云存储服务等,需要编写一个 Service ,然后和 Broker