trpc框架

与存量系统互通, 保持框架的开放性和可扩展性是tRPC的核心诉求. 为了实现此目标, tRPC的框架设计遵循了插件化架构设计理念. 

插件化架构

插件化架构在后面的描述中会被频繁提到,是tRPC架构设计的核心概念之一, 所以在介绍tRPC的总体架构之前, 我们先谈谈什么是插件化架构. 要理解插件化架构, 我们可以把它分为 "基于接口机制的插件工厂"和"基于AOP思想的拦截器"两部分来介绍.

 

插件工厂

 

tRPC核心框架是采用基于接口编程的思想, 通过把框架功能抽象成一系列的插件组件, 注册到插件工厂, 并由插件工厂实例化插件. tRPC框架负责串联这些插件组件, 拼装出完整的框架功能. 我们可以把插件模型分为以下三层:

1. 框架设计层: 框架只定义标准接口，没有任何插件实现，与平台完全解耦；

2. 插件实现层: 将插件按框架标准接口封装起来即可实现框架插件；

3. 用户使用层: 业务开发只需要引入自己需要的插件即可，按需索取，拿来即用

tRPC的总体架构由"框架核心"和"插件"两部分组成. 如图所示, 虚线框内为tRPC, 其中中间的红色实线框为框架核心, 蓝色框为插件部分.

 

 

框架核心

RPC框架核心由以下三部分组成:

• 通信层: 负责数据的传输和协议的编解码. 框架内置支持tcp/udp/quic等通信协议, 传输协议采用基于PB的tRPC协议来承载RPC调用, 支持通过codec插件来使用其它传输协议

• 服务治理层: 负责将服务治理功能抽象成插件组件, 采用插件化架构, 通过调用插件和外部服务治理系统完成对接, 实现服务发现，负载均衡，监控，调用链等服务治理功能

• 调用层: 封装服务和服务代理实体, 提供RPC调用接口, 支持业务用同步,异步,单向以及流式调用等方式进行服务间调用

插件

插件是框架核心和外部服务治理组件串联起来的桥梁. 插件一边需要按框架标准接口实现插件, 注册到框架核心, 并完成插件实例化；另一边插件需要调用外部服务治理服务的SDK/API, 实现如服务发现，负载均衡，监控，调用链等服务治理功能.下图是一个典型的名字系统实现方式:

 

 

tRPC框架对插件按功能大致分为下面几个组件:

• Selector: 提供服务发现（selector）、负载均衡（loadbalance）、熔断（circuitbreaker）标准接口. 插件通过实现这些接口来实现基于服务名的寻址功能

• Conf: 提供获取配置的标准接口. 通过抽象出"数据源"概念, 来实现从本地配置文件、配置中心等不同数据源读取配置. 通过插件来扩展对各种数据格式(json,yaml, toml等)的支持. Conf组件也提供了watch机制,来实现配置的动态更新

• Log: 提供了统一的日志打印和日志上报接口. 日志插件通过实现日志上报接口来完成和远程日志系统的对接

• Metrics: 提供监控指标的上报接口, 支持常见的单维上报，如counter、gauge等，也支持多维上报. 插件通过实现上报接口来完成和监控平台的对接

• Tracing: 调用链跟踪插件采用filter(拦截器)的机制来实现和调用链跟踪平台对接.

• Codec: 提供协议编解码相关的接口，允许通过插件的方式来扩展业务协议、序列化方式、数据压缩方式等协议处理