日前，字节跳动技术社区 ByteTech 举办的第七期字节跳动技术沙龙圆满闭幕，本期沙龙以《字节高性能开源微服务框架：CloudWeGo》为主题。在沙龙中，字节跳动字节跳动基础架构服务框架资深研发工程师 高文举，跟大家分享了《大规模企业级 HTTP 框架的设计和实际》，本文依据分享整顿而成。
本文将从以下五个方面介绍 CloudWeGo 大规模企业级 HTTP 框架 Hertz：
1. 字节跳动外部 Go HTTP 框架的变迁；
2. 企业级 HTTP 框架的设计考量和落地思路；
3. Hertz 的外围特点；
4. 将来布局和挑战；
- 总结。
字节跳动外部 Go HTTP 框架的变迁
在正式开始介绍第一局部的内容之前，先给大家展现一组关键词。2020 年初 Hertz 立项，2020 年 10 月，Hertz 公布 第一个可用版本 。2022 年 6 月，Hertz 正式开源。截至目前，Hertz 在字节外部曾经撑持 超过 1.4 万个业务服务，日峰值 QPS 超过 5000 万。
Hertz 不仅反对业务服务，同时还会横向反对字节外部的各种根底组件，包含但不限于字节跳动服务网格管制面、公司级别压测平台以及 FaaS，还包含各种业务网关等等。Hertz 的高性能和极强的稳定性能够撑持业务复杂多变的场景。在公司外部 Hertz 接替了大量基于 Gin 框架开发的存量服务，大幅度降低了业务资源应用老本以及服务延时，助力公司层面的降本增效。
上面咱们能够从 Hertz 呈现的背景以及 Hertz 的设计指标和思路领会到，Hertz 的呈现绝不是偶尔。
基于 Gin 封装
家喻户晓，字节外部应用 Golang 比拟早，在大概 2014 年左右，公司就曾经开始尝试做一些 Golang 业务的转型。2016 年，咱们基于已开源的 Golang HTTP 框架 Gin 框架，封装了 Ginex，这是 Ginex 刚开始呈现的期间。
同时，2016 年还是一个垦荒的时代，这个期间框架随同着业务疾速横蛮地成长，咱们的口号是“鼎力出奇观”，把优先解决业务需要作为第一要务。Ginex 的迭代形式是业务侧和框架侧在同一个仓库外面独特保护和迭代。
问题浮现
2017 – 2019 年期间，也就是 Ginex 公布之后，问题逐步浮现。次要有以下几点：
- 迭代受开源我的项目限度
Ginex 是一个基于 Gin 的开源封装，所以它自身在迭代方面是受到一些限度的。一旦有针对公司级的需要开发，以及 Bugfix 等等，咱们都须要和开源框架 Gin 做联合开发和保护，这个周期不能齐全由咱们本人管制。
- 代码凌乱收缩、保护艰难
因为咱们和业务同学共同开发和保护 Ginex 框架，因而咱们对于管制整个框架的走向没有齐全的自主权，从而导致了整体代码凌乱收缩，到前期咱们发现越来越难保护。
- 无奈满足性能敏感业务需要
另外，咱们能用 Gin 做的性能优化非常少，因为 Gin 的底层是基于 Golang 的一个原生库，所以如果咱们要做优化，须要在原生库的根底上做很多革新，这个其实是十分艰难的。
- 无奈满足不同场景的性能需要
咱们外部逐步呈现了一些新的场景，因而会有对 HTTP Client 的需要，反对 Websocket、反对 HTTP/2 以及反对 HTTP/3 等等需要，而在原生的 Ginex 上还是很难扩大的这些性能需要。
魔改开源框架
逐步地，某些业务线开始做初步的尝试，他们会对另外的一些开源框架进行魔改。比拟典型的例子是有一些业务线尝试基于 Fasthttp 进行魔改，Fasthttp 是一款主打高性能的开源框架，基于它进行魔改能够短期内帮忙业务解决问题。这种魔改景象带来的问题是，框架魔改是一些业务线自发的行为，各个业务线可能会基于本身业务个性进行各自保护，从而导致保护成本上升十分重大。
到这里咱们好像陷入了 Ginex 的怪圈。如前段时间爆火的电视剧《开始》一样，咱们好像是从一辆开往学院南路的 45 路公交车上醒来，发现自己要返回公司进行下一代 Ginex 框架的保护工作。
大家也能够思考一下，如果是你来应答这样的场景，你会怎么做呢？
小结
第一章节的内容总结如下：
- 晚期基于开源框架封装
基于晚期开源的 Golang HTTP 框架，实现了 Ginex 的封装。
- 随着实际倒退，问题逐步呈现
框架凌乱收缩，框架的保护越来越艰难，业务的新需要无奈失去很好地满足。
- 为了解决问题呈现基于另外的开源框架魔改的萌芽
咱们须要思考如何跳出魔改的怪圈，把字节外部的企业级框架做得更好。
另外，还有一个遗留问题，就是应该如何跳出这个魔改的怪圈呢？这个问题第二章节会为大家进行解答。
企业级 HTTP 框架的设计考量和落地思路
跳出怪圈
为了跳出魔改的怪圈，咱们决定从以下三个方面开始着手。
- 自主研发
既然 Ginex 是因为基于开源框架 Gin，没法做一些灵便的管制，那咱们就改为齐全自主研发框架。自主研发框架的代码全链路自主可控，也能够防止引入任何三方不可控因素，这样咱们可能对本人的框架有一个比拟齐备的掌控力。
- 品质管制
下图列举了一些惯例的品质管制伎俩。我要着重强调的是含糊测试，含糊测试在字节外部是广泛应用于 Hertz 框架的稳定性测试中。它的外围点在于 通过一系列的模仿服务，尝试模仿出线上用户在应用咱们的框架时，理论遇到的一些场景和应用形式 。而后通过一些随机的算法，生成尽可能简单、笼罩各种 Case 的场景，这能够让咱们 检测出一些潜在的问题。这套测试也在 Hertz 晚期的品质建设中，帮忙咱们将一些问题防患于未然。
- 严格准入
既然 Ginex 的问题是大家都在向外面写入内容，那么咱们能够管制入口，建设一套齐备的需要开发以及 Review 的闭环，管制迭代的整体流程，从而控制代码准入。同时咱们装备对立的需要治理以及严格的发版准入标准，做一个规范的公司级别的框架。
举一个比拟形象的例子，如果咱们把下一代框架比作一个人——“框架人”，自主研发示意这个“框架人”首先会领有对本人身材的主导权，他不会受到来自于环境或者别人的影响；品质管制示意“框架人”可能定期体检，提前发现一些潜在的疾病，将其扼杀于摇篮；严格准入示意“框架人”有迷信的饮食摄入和自律的生活习惯。可想而知，如果咱们可能做到以上三点，咱们的“框架人”就可能领有一个衰弱的体格。
痛点梳理
明确了应该如何跳出怪圈之后，咱们还应该明确晓得这个框架要具备哪些性能和个性，也就是首先应该聚焦到框架的外围痛点上。“框架人”不能只有衰弱的体格，还应该领有乏味的思维和灵魂。一个成熟的框架不仅仅要 应答来自业务侧的需要 ，如性能需要、性能需求和易用稳固等，还要思考 框架本身的倒退，而这一点恰好是咱们在 Ginex 的迭代过程中疏忽的。
如下图右侧金字塔所示，最上层是 高效撑持 ，毋庸置疑框架的存在必定是为了撑持咱们的业务需要。中间层是一个 质量保证 的红线框架，框架须要保障它本身的品质，只有以高质量实现的框架能力有自信承当字节外部的 5000 万 QPS，以及各种各样的应用场景。金字塔的最底层是 长期、可持续性倒退，这也是作为将来想要放弃继续迭代的框架最重要的一点。
框架迷信发展观
基于上一部分，咱们能够进一步梳理出框架的需要痛点。痛点次要有两个方面：
- 多样的需要：撑持撑持各个业务线及基础设施（横向扩展性）。
- 灵便的构造：贯通 HTTP 生命周期的掌控力（纵向模块化）。
在此基础上进一步形象出框架的迷信发展观：
- 聚类需要：面向通用能力开展设计。
- 跳出部分：针对一些简单问题，在更大范畴内寻求最优解。
后续我会针对这个迷信发展观进一步论述 Hertz 到底是如何实现的。
小结
第二章节的内容总结如下：
- 跳出怪圈
引入“框架人”的概念，帮忙大家了解框架的自研、品质管制和严格准入。
- 痛点梳理
为“框架人”注入乏味的灵魂，框架须要应答来自业务侧的多样化需要，还要保障本人的可持续性倒退。
- 框架迷信发展观
需要聚类，跳出部分。
Hertz 的外围特点
Hertz 框架是如何实现第二章节中提到的框架痛点和迷信发展观的呢？本章节将具体进行介绍。
分层形象
首先介绍 Hertz 框架的架构设计。下图是一个申请从建设、连贯到实现的全过程。左侧是客户端，右侧是服务端，在咱们发动链接建设申请之后，链接建设实现；之后客户端发动申请到服务端，服务端进行路由解决，而后将路由导向业务逻辑解决；业务逻辑处理完毕后，服务端返回这个申请，实现一次 HTTP 申请的调用。
那么在这个过程中咱们的框架到底做了哪些事件呢？从图中不难发现，首先框架进行了 链接解决 ，其次是 协定解决 ，之后基于路由做了逻辑散发，即 路由解决 ，最初做了 业务逻辑解决。咱们把框架做成一个构造之后会发现，这个构造蕴含的就是这四局部。
基于这个逻辑，咱们能够看一下 Hertz 的整体架构图。如下图所示，从下往上看红线框圈住的局部，能够发现这就是上文提到的申请建设的全过程。各层的能力及作用如下：
- 传输层 Transport：形象网络接口；
- 协定层 Protocol：解析申请，渲染响应编码；
- 路由层 Route：基于 URL 进行逻辑散发；
- 应用层 Application：业务间接交互，呈现大量 API。
咱们能够看到图中除了两头局部蕴含的四层，左右两侧各有两列。右侧是通用层 Common，次要负责 提供通用能力、罕用的日志接口、链路追踪以及一些配置解决相干的能力 等。左侧是 Hertz 的代码生成工具 Hz，又称脚手架工具 ，它能够帮忙咱们在外部 基于 IDL 疾速地生成我的项目骨架，以减速业务迭代。
Hertz 的分层设计是可能和代码组织构造一一映射的。下图是 Hertz 仓库外面的代码组织构造，能够看到根目录下的 cmd 包外面寄存着 Hz 工具，在 pkg 包下寄存着上述次要四层以及通用层 Common。因而同学们看到架构设计图之后，能够间接在 Github 学习 Hertz 的代码。
Hertz: https://github.com/cloudwego/…
总体来说，Hertz 的架构设计理念就是“简洁有序，保障让所有开发者轻松了解，在开发的过程中继续贯彻”。
易用可扩大
那么基于 Hertz 的架构设计，应该如何开展易用性和可扩展性呢？下图是 Hertz 架构次要四个层级的形象。
- 应用层
应用层提供了一些通用能力，包含 绑定申请、响应渲染、服务发现 / 注册 / 负载平衡以及服务治理 等等。其中，洋葱模型中间件 的外围目标是让业务开发同学 基于这个中间件疾速地给业务逻辑进行扩大，扩大形式是能够在业务逻辑解决前和解决后别离插桩埋点做相应解决。一些比拟有代表性的利用，包含日志打点、前置的平安检测，都是通过洋葱模型中间件进行解决的。
- 路由层
路由层也是十分通用的，次要提供 动态路由、参数路由、为路由配置优先级以及路由修复 的能力，如果咱们的路由层没方法满足用户需要，它还能撑持用户做 自定义路由 的扩大。但理论利用中这些路由能力齐全可能满足绝大多数用户的需要。
- 协定层
Hertz 同时提供 HTTP/1.1 和 HTTP/2，HTTP/3 也是咱们在建设中的能力，咱们还会提供 Websocket 等 HTTP 相干的多协定反对，以及反对齐全由业务决定的自定义协定层扩大。
- 传输层
目前咱们曾经内置了两个高性能的传输层实现。一个是 基于 CloudWeGo 开源的高性能网络库 Netpoll 的传输层扩大，另一个是反对 基于规范库 的传输层扩大。此外，咱们也同样能反对在传输层上进行 自定义传输层协定扩大。
下图每一层中标红的能力都可能体现出，咱们可能在框架的任何一个分层上撑持用户做最大水平的自在定制，这样能够最大水平地满足企业级外部用户和潜在用户的业务需要。如果同学们想要深刻理解 Hertz，能够参考 CloudWeGo 官网的 Hertz 局部，上述所有内容均有具体形容。
官网：https://www.cloudwego.io/zh/d…
性能摸索
在性能方面，Hertz 又是如何在自主可控的范畴内做高性能摸索的呢？
场景形容
相熟 Hertz 代码的同学会发现，咱们的 HTTP/1.1 协定借鉴了一些 Fasthttp 的优化思路和伎俩。HTTP/1.1 协定中的 Header 为不定长数据段，往往须要解析到最初一行，才可能确定是否实现解析。同时，为了缩小零碎调用次数，晋升整体解析效率，波及 IO 操作时，咱们通常引入带 buffer 的 IO 数据结构。如下图所示，它的外围点是最上层的 buffer，buffer 是一个相似于一块残缺的内存空间，咱们能够将 IO 读到的数据放进这个空间做暂存。
bufio.Reader 的问题
这样做呈现的问题是，原生的 bufio.Reader 长度是固定的，申请的 Header 大小超出 buffer 长度后，.Peek() 办法间接报错 (ErrBufferFul)，无奈实现既定语义性能。
一些可能的解
对于上述问题，其实有一些可能的解决办法：
- 间接利用 bufio.Reader 的局限当做 Feature，通过 buffer 大小作为 Header 大小的限度。如果超出这个大小，Header 间接解析报错，这也是 Fasthttp 的做法。但实际上超出 buffer 长度后报错会导致咱们没方法解决这部分申请，从而导致框架 性能受限。
- header 解析带状态，暂存两头数据，通过在下层重叠额定复杂度的形式冲破 bufio 自身的限度。然而暂存两头态会波及到一些内存的拷贝，必然会导致 性能受限。
实在应用环境复杂多变
字节外部的应用场景十分多，咱们不仅要反对各种业务线的开发，还要反对一些横向的根底组件。不同的业务，不同的场景，数据规模各异。如何成为通用且高效的地解决 bufio.Reader 的问题成为 Hertz 面临的外部重要挑战。咱们既然曾经站在 Fasthttp 这个“伟人”的肩膀上了，是否往前再走一步呢？
答案是必定的。基于外部的应用场景，同时联合 Netpoll 的劣势，咱们设计出了 自适应 linked buffer，并且用它代替掉了原生的 bufio.Reader。从下图能够看到，咱们的 buffer 不再是一个固定长度的 buffer，而是一条链，这条链上的每一个 buffer 大小可能 依据线上实在申请进行动静扩缩容调整 ，同时搭配 Netpoll 中 基于 LT 触发的模型做数据预拷贝 。从施行成果上来看，这个自适应调整可能让咱们的业务方齐全无感地撑持任何他们的业务个性。也是因为咱们可能将 buffer 进行动静扩缩容调整，从而可能保障在 协定层最大水平做到零拷贝协定解析，这可能带来整体解析上的性能晋升，时延也会更低。
针对 HTTP/1.1 进行中的优化
因为目前在字节外部 HTTP/1.1 还是一个比拟支流的协定，所以咱们基于 HTTP/1.1 做了很多尝试。
首先是 协定层摸索 。咱们正在尝试基于 Header Passer 的重构，把解析 Header 的流程做得更高效。咱们还尝试了做一些 传输层预解析，将一些比拟固化的逻辑下沉到传输层做减速。
其次是 传输层摸索 。这包含应用 writev 整合发送 Header & Body 达到缩小零碎调用次数的目标，以及通过 新增接口整合 .Peek() + .Skip() 语义，在外部提供一个更高效的实现。
Hertz Benchmark
下图是 Benchmark 的开源数据。左侧第一张图是在等同的机器环境上，Hertz 和横向的框架 Gin、Fasthttp 极限 QPS 比拟状况，蓝线是 Hertz 处于较高极限 QPS 的状态。第二张图是 TP99 时延状态，第三张图是 TP999 时延状态，能够看到 Hertz 的整体时延是处于一个更低的程度上。
字节跳动服务网格管制面从 Gin 迁徙至 Hertz
CloudWeGo 公众号曾公布对于字节跳动服务网格管制面的文章，讲述字节跳动服务网格从 Gin 框架迁徙到 Hertz 的落地实际。下图是他们代码展现的实在收益，从 Gin 框架替换成为 Hertz 框架后，CPU 流量从大略快到 4K 降到大概只有 2.5K，Goroutine 数量从 6w 降到有余 100 个 ，Goroutine 稳定性失去极大地晋升。同时替换成 Hertz 后， 框架相干的开销曾经根本隐没，服务网格在线上稳固承载了超过 13M QPS 的流量。
字节跳动服务网格基于 Hertz 框架的实际：https://mp.weixin.qq.com/s/ko…
小结
第三章节的内容总结如下：
- 分层形象
解构 HTTP 框架，分层解耦。
- 易用可扩大
提供了更丰盛 API 和足够灵便的拓展能力，在每一层形象中都提供了一个足够灵便的扩大能力应答可能的需要。
- 自主可控的高性能摸索
自适应 buffer，零拷贝解析，将来将会进行更多的高性能摸索。
将来布局和挑战
我认为 Hertz 将来的倒退布局次要围绕以下几个方面：首先，打造泛 HTTP 框架 。咱们的最终目标是心愿 Hertz 可能解决在 HTTP 畛域内的所有问题；其次， 助力 CloudWeGo，心愿 Hertz 可能助力 CloudWeGo 打造一个企业级云原生微服务矩阵；最初心愿 Hertz 可能继续服务更多的用户。
总结
本次分享的次要内容总结如下：
- 字节跳动外部 Go HTTP 框架的变迁：从基于开源封装，到开启自研之路；
- 企业级 HTTP 框架的设计考量和落地思路：破圈、需要提炼、框架迷信发展观；
- Hertz 外围特点：分层形象、易用可扩大、自主可控的性能摸索；
- Hertz 将来的布局和挑战：框架继续打磨、助力 CloudWeGo、服务更多用户。
最初欢送对 Hertz 感兴趣的同学积极参与到 CloudWeGo 社区中，咱们一起欠缺 Hertz，独特建设 CloudWeGo！
以上内容整顿自第七期字节跳动技术沙龙《字节高性能开源微服务框架：CloudWeGo》，获取 讲师 PPT 和回放视频，请关注 CloudWeGo 公众号，并在后盾回复关键词“一周年”。
我的项目地址
GitHub：https://github.com/cloudwego
官网：www.cloudwego.io