互联网发展早期，业务场景差异大，试错迭代速度很快。这导致其后台服务使用的语言技术栈、开发框架、通信协议、服务治理系统、运维平台等或多或少存在差异。

业务发展到一定阶段后，跨业务合作越来越多，组织架构调整也愈发频繁。技术体系差异，特别是开发框架的不统一，给业务互通带来巨大成本，也导致开发和运营的效率难以快速提高。

同时，随着云原生技术的发展，业务越来越多地使用开源技术和云组件。拥抱云原生已经是一种主流趋势。
上述问题在腾讯内部也同样存在，且因为规模大、业务类型多，更加难以解决，更必须解决。tRPC 就是在这种背景下诞生的。

既要与存量技术体系互联互通，又要适配云原生技术并且快速发展。这就要求开发框架必须具备开放性和可扩展性。为了达到这个目的，tRPC 在架构设计上采用插件化设计思想。

上图是 tRPC 整体的架构设计图，总体架构由“框架”和“插件”两部分组成， 其中虚线框内为 tRPC，中间的红色实线框为框架核心部分，蓝色实线框为插件部分。

框架核心部分分三层:

通信层: 负责数据的传输和协议的编解码，框架内置支持 tcp、udp 等通信协议，传输协议采用基于 Protocol Buffers 的 tRPC 协议来承载 RPC 调用，同时支持通过 Codec 插件来使用其它传输协议；

服务治理层: 负责将服务治理功能抽象成插件，通过调用插件和外部服务治理系统进行对接，实现服务发现、负载均衡、监控、调用链等功能；

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

插件部分则是框架核心和外部组件串联起来的桥梁。在插件设计上，框架采用了基于接口机制的插件工厂+基于 AOP 的拦截器 Filter。

其中，通过基于 AOP 的拦截器 Filter，框架把业务个性化的需求（比如：校验校验、请求回放、故障注入等）、以及服务治理的大部分功能（比如：监控指标上报，调用链跟踪，远程日志，鉴权等）以横切关注点的方式，插入到请求/响应处理的流程中，来增强框架的可扩展性。

通过基于接口机制的插件工厂，框架只需要定义一些插件模块的标准接口，并提供注册能力，而不做具体实现。而在与不同协议的服务互通，或者对接某个服务治理系统时，只需要开发对应的具体插件即可。

插件按功能大致分为下面几类:

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

Naming：提供了服务注册(Registry)、服务发现(Selector)、负载均衡(LoadBalance)、熔断(CircuitBreaker)等能力封装，用于对接各种名字服务系统；

Config：提供了配置读取相关的接口，支持读取本地配置文件、远程配置中心配置等，允许插件式扩展支持不同格式的配置文件、不同的配置中心，支持 Reload、Watch 配置更新；

Metrics：提供了监控上报的能力，支持常见的单维上报，如Counter、Gauge等，也支持多维上报，允许通过扩展对接不同的监控系统；

Logging：提供了通用的日志采集接口，允许通过插件的方式来扩展日志实现，输出到远程；

Tracing：提供了分布式跟踪能力，允许通过插件的方式上报到调用链系统；

Telemetry：提供了采集和上报遥测数据的能力，是一个集成了链路追踪（Tracing）、监控上报（Metrics）、日志采集（Logging）三大功能的插件。

此外框架还设计了 Admin 管理接口，方便用户或者运营平台可以通过调用 Admin 接口对服务进行管理。

总体来说，tRPC 将核心功能抽象封装成一个个独立的插件，然后由框架来负责这些独立插件的串联和拼装，从而实现框架所要支持的功能特性，通过这种设计使 tRPC 具备很强的开放性和可扩展性。业务可以灵活替换插件，实现与不同系统的对接，也可以进行业务个性化定制能力实现。

跨语言：基于 Protocol Buffers 来实现跨语言的服务通信。

多通信协议：支持多种通信协议，方便与不同框架进行互通（比如 gRPC）。

支持流式 RPC：更好地适用于大文件上传/下载、消息 Push、AI 类语音识别/视频理解等多种应用场景。

丰富插件生态：提供大量对接业界微服务组件的插件（比如 Consul/Promethues/Opentelemetry 等），方便用户构建适合自己的服务治理体系。

可扩展：基于框架插件化的设计，用户可以进行二次开发来扩展框架能力，比如：RPC 请求参数校验、鉴权、请求录制等。

流控和过载保护：提供多种应用场景下的流量控制和过载保护插件，防止服务因为访问突增造成过载而不可用。

tRPC 在性能这块更多的是适应腾讯不同的业务场景（比如：业务网关场景/推荐搜索场景/游戏场景/流式数据传输场景/AI 类场景/存储场景等）。以下是tRPC 框架简单的基准性能测试（数据仅作参考）：

测试机型：

腾讯云标准型 SA2 CVM虚拟机，CPU处理器型号 AMD EPYC™ Rome，8核，2.60GHz，内存16G。

测试场景和数据：

吞吐测试：调用方的 P99 延时在 10ms 左右时，测量服务的 QPS。

长尾请求测试：在纯服务端模式下，固定 QPS 为1w/s时，在有 1% 的请求处理存在 5ms 长尾延时情况下，考察普通请求的处理延时情况。

tRPC 在腾讯公司内部诞生，经过4年的不断打磨，已经广泛应用到了腾讯内部的多数业务当中。同时一些外部用户（阅文/腾讯音乐/腾讯云相关的合作公司等）也在使用当中。

● 开源更多编程语言：Java、Python、Node。

● 丰富生态，开源更多云原生相关的插件和组件。

对外开源的官方网站：

Github 主仓库：

Github 插件仓库：

-End-

本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿