查看原文
其他

腾讯开源 tRPC:多语言、高性能 RPC 开发框架

The following article is from 腾讯云开发者 Author tRPC 团队



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


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


同时,随着云原生技术的发展,业务越来越多地使用开源技术和云组件。拥抱云原生已经是一种主流趋势。

上述问题在腾讯内部也同样存在,且因为规模大、业务类型多,更加难以解决,更必须解决。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。

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


对外开源的官方网站:https://trpc.group/

Github 主仓库:https://github.com/trpc-group

Github 插件仓库:https://github.com/trpc-ecosystem


-End-


参考阅读:



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


继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存