# 关注并星标腾讯云开发者
# 每周3 | 谈谈我在腾讯的架构设计经验
# 第8期 | tRPC 团队:tRPC 项目开源
互联网发展早期,业务场景差异大,试错迭代速度很快。这导致其后台服务使用的语言技术栈、开发框架、通信协议、服务治理系统、运维平台等或多或少存在差异。
业务发展到一定阶段后,跨业务合作越来越多,组织架构调整也愈发频繁。技术体系差异,特别是开发框架的不统一,给业务互通带来巨大成本,也导致开发和运营的效率难以快速提高。
同时,随着云原生技术的发展,业务越来越多地使用开源技术和云组件。拥抱云原生已经是一种主流趋势。
上述问题在腾讯内部也同样存在,且因为规模大、业务类型多,更加难以解决,更必须解决。tRPC 就是在这种背景下诞生的。
既要与存量技术体系互联互通,又要适配云原生技术并且快速发展。这就要求开发框架必须具备开放性和可扩展性。为了达到这个目的,tRPC 在架构设计上采用插件化设计思想。
上图是 tRPC 整体的架构设计图,总体架构由“框架”和“插件”两部分组成, 其中虚线框内为 tRPC,中间的红色实线框为框架核心部分,蓝色实线框为插件部分。
框架核心部分分三层:
通信层: 负责数据的传输和协议的编解码,框架内置支持 tcp、udp 等通信协议,传输协议采用基于 Protocol Buffers 的 tRPC 协议来承载 RPC 调用,同时支持通过 Codec 插件来使用其它传输协议;
服务治理层: 负责将服务治理功能抽象成插件,通过调用插件和外部服务治理系统进行对接,实现服务发现、负载均衡、监控、调用链等功能;
调用层: 封装服务和服务代理实体,提供 RPC 调用接口,支持业务用同步、异步、单向以及流式调用等方式进行服务间调用。
插件部分则是框架核心和外部组件串联起来的桥梁。在插件设计上,框架采用了基于接口机制的插件工厂+基于 AOP 的拦截器 Filter。
其中,通过基于 AOP 的拦截器 Filter,框架把业务个性化的需求(比如:校验校验、请求回放、故障注入等)、以及服务治理的大部分功能(比如:监控指标上报,调用链跟踪,远程日志,鉴权等)以横切关注点的方式,插入到请求/响应处理的流程中,来增强框架的可扩展性。
通过基于接口机制的插件工厂,框架只需要定义一些插件模块的标准接口,并提供注册能力,而不做具体实现。而在与不同协议的服务互通,或者对接某个服务治理系统时,只需要开发对应的具体插件即可。
插件按功能大致分为下面几类:
此外框架还设计了 Admin 管理接口,方便用户或者运营平台可以通过调用 Admin 接口对服务进行管理。
总体来说,tRPC 将核心功能抽象封装成一个个独立的插件,然后由框架来负责这些独立插件的串联和拼装,从而实现框架所要支持的功能特性,通过这种设计使 tRPC 具备很强的开放性和可扩展性。业务可以灵活替换插件,实现与不同系统的对接,也可以进行业务个性化定制能力实现。
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。
● 丰富生态,开源更多云原生相关的插件和组件。
对外开源的官方网站:https://trpc.group/
Github 主仓库:https://github.com/trpc-group
Github 插件仓库:https://github.com/trpc-ecosystem
-End-
📢对 tRPC 项目开源你有什么想问的、想说的 ?欢迎留言。我们将挑选一则最有意义的评论,为其留言者送出腾讯定制-咖啡杯1个(见下图)。11月1日中午12点开奖。
📢📢欢迎加入腾讯云开发者社群,社群专享券、大咖交流圈、第一手活动通知、限量鹅厂周边等你来~
(长按图片立即扫码)
关注并星标腾讯云开发者
第一时间看鹅厂架构设计经验