日前,字节跳动技术社区 ByteTech 举办的第七期字节跳动技术沙龙圆满落幕,本期沙龙以《字节高性能开源微服务框架:CloudWeGo》为主题。在沙龙中,字节跳动字节跳动基础架构服务框架资深研发工程师杨芮,跟大家分享了《高性能 RPC 框架 Kitex 内外统一的开源实践》,本文根据分享整理而成。
本文将从以下四个方面介绍 CloudWeGo 高性能 RPC 框架 Kitex 的实践及开源:
1. 由内至外 - 开源过渡;
2. 开源一年变更回顾;
3. 社区共建完善生态及企业落地;
4. 总结和展望。
由内至外 - 开源过渡
很多同学可能刚刚了解 CloudWeGo,先介绍一下 CloudWeGo 和 Kitex 的关系。
CloudWeGo 和 Kitex
Kitex 是 CloudWeGo 开源的第一个微服务框架,它是一个支持多协议的 Golang RPC 框架,从网络库、序列化库到框架的实现基本完全自研的。特别地,Kitex 对 gRPC 协议的支持使用了 gRPC 官方的源码,但是我们对 gRPC 的实现做了深度且定制的优化,所以 Kitex 支持的 gRPC 协议性能优于 gRPC 官方框架。同时这也是 Kitex 与目前已经开源的、支持 gRPC 协议的其他 Golang 框架的主要差异。如果用户想使用 gRPC 又对性能有很高的要求,那么 Kitex 框架将会是一个很不错的选择。
继 Kitex 开源后,今年 CloudWeGo 又陆续开源了 Golang HTTP 框架 Hertz,Rust RPC 框架 Volo,同时围绕这些微服务框架和微服务的一些通用能力,我们还开源了一些高性能的基础库。关于更多 CloudWeGo 开源的子项目,可以进入 CloudWeGo 官网详细了解。
CloudWeGo 官网:https://www.cloudwego.io/
根据社区同学反馈,在一些开源群里大家会讨论 Kitex 会不会是一个字节跳动的开源 KPI 项目呢?它的稳定性、持续性能够得到保障吗?我可以负责任地讲,Kitex 不是一个 KPI 项目,它是来自字节跳动内部大规模实践的真实项目。在 Kitex 开源后始终保持内外统一,基于内外代码的统一我们保证了 Kitex 的持续迭代。为了进一步消除大家的顾虑,下面具体介绍一下 Kitex 的诞生和开源历程。
Kitex 发展历史
2014 年,字节跳动开始引入 Golang。2015 年,字节跳动内部的服务化开启。在 RPC 调用的场景选择了 Thrift 协议,在内部开始支持 RPC 框架。2016 年,第一个 Golang RPC 框架 Kite 正式发布。通常在一个公司高速发展的初期,基础能力都是为了快速支持需求落地,面对的需求场景也较单一,设计上不会有较多考量,其实这也是合理的,因为探索阶段并不完全清楚还需要支持哪些场景,过多的考虑反而会出现过度设计的问题。
但是,随着业务场景复杂化,需求也会多样化,而且接入服务及调用量逐年增长,Kite 已经不足以支持后续的迭代,在线上服役三年多后,2019 年我们开启了新的项目 Kitex,2020 年初发布了正式版本,在 2020 年底字节内部已经有 1w+ 服务接入 Kitex。
从 2014 年到 2020 年,Golang 已经是字节跳动内部主要的业务开发语言,应该是业界 Golang 应用最多的公司。我们的服务框架支持着数万个 Golang 微服务的可靠通信,经过数量众多的微服务和海量流量的验证,我们已经有了较为成熟的微服务最佳实践,于是考虑将内部的实践开源出去丰富云原生社区的 Golang 产品体系。在 2021年,我们以 CloudWeGo 品牌正式开源了第一个服务框架 Kitex。截至今年 8 月,Kitex 已经为字节跳动内部 6w+ 的服务提供支持,峰值 QPS 达到上亿级别。
大家或许还有疑问,完整的微服务体系离不开基础的云生态,无论在公有云、私有云,都需要搭建额外的服务以很好地支持微服务的治理,比如治理平台、注册中心、配置中心、监控、链路跟踪、服务网格等,而且还存在一些定制的规范。字节跳动自然也有完善的内部服务支持微服务体系,但这些服务短期还无法开源,那 CloudWeGo 如何内外维护一套代码,统一迭代呢?
关于这个问题,我们看一下 Kitex 的模块划分。Kitex 的模块分为三个部分:中间是 Kitex 主干部分 Kitex Core,它定义了框架的层次结构、接口核心逻辑的实现以及接口的默认实现;左边的 Kitex Tool<