关于开源:微服务超-10-万跨语言场景字节服务网格依靠-CloudWeGo-扛住流量洪峰

随着企业用户逐步增多，面对不同场景下不同需要和技术问题，CloudWeGo 团队将会继续分享不同企业的落地实际，蕴含不同行业面临的技术问题、选型参考和最终落地性能和应用分享，帮忙更多用户开始应用 CloudWeGo。

字节服务网格承载着线上超大规模的微服务调用，作为集中式管制面，面临着高性能挑战。字节跳动服务网格通过应用 CloudWeGo 团队的高性能务 HTTP 框架 Hertz，实现了超简单调用网络下的流量治理体系的落地实际。

本文将从以下三个方面介绍字节跳动自研的高性能 HTTP 框架 Hertz 在服务网格的落地实际：

1. 服务网格在字节跳动的积淀与积攒；
2. 超简单调用网络下的流量治理体系；
3. Hertz 在字节跳动服务网格的落地实际。

以下内容来自字节跳动服务网格研发工程师 兰新宇 在 CloudWeGo 携手稀土掘金独特举办、以《CloudWeGo：从开源、凋谢到企业落地》为主题的 Meetup 流动中的分享。

本次分享分为三个局部。第一局部介绍服务网格在字节跳动倒退的心得、落地实际以及遇到的相干问题。第二局部介绍超简单调用网络下的流量治理体系，具体讲述对于这种超简单的调用网络字节跳动是怎么基于服务网格的个性给业务赋能、怎么做流量治理体系的。Hertz 目前曾经在 CloudWeGo 社区开源，为用户提供了一个高易用性、高性能和高扩展性的 HTTP 框架，Hertz 框架在字节跳动外部曾经广泛应用，服务网格在字节跳动外部也有着无足轻重的位置，所以第三局部具体讲述 Hertz 在字节跳动服务网格的落地实际。

服务网格在字节跳动的积淀与积攒

服务网格有得天独厚的架构劣势，使得它可能在各种状况下解决业务的痛点，包含架构的优雅性等等，很多互联网大厂陆续将本人的云原生架构从传统的单体或者分布式的利用迁徙到云原生服务网格上，字节跳动也不例外，往年开始大体量地应用服务网格。那么什么是服务网格呢？

什么是服务网格

首先简要介绍一下服务网格的概念。如下图所示，服务网格并不是一个特地陈腐的架构，咱们常说加一层代理就能够解决很多事件，服务网格从最简略的层面了解就是加一层代理，把流量通过代理来转发实现架构的剥离。这种解决形式会带来很多益处，上面重点介绍三个字节通过服务网格解决的痛点。

第一个是服务网格能够使业务过程和框架解耦。原来的过程是框架集成在一个过程外面，通过 SDK 的模式来提供，咱们通过提供隔离的 Proxy，以一个拆散的过程和业务过程独立存在，这是繁多职责在 RPC 通信畛域的体现，这样业务和 RPC 框架研发同学能够更专一于外围性能的实现。

第二个是灵便、牢靠的生命周期治理。咱们通过过程剥离的形式，使得咱们不再依赖业务降级本人的服务来达到框架版本的降级，服务网格的开发、运维者可能对生命周期做更好的把控，这个是对服务网格的开发者或者运维者十分无利的特色。

第三个是对立的跨语言流量治理体验。咱们把它通过中间层的形式实现独自代理，接管所有流量，咱们能够针对所有不同语言实现的业务过程对立治理体验，在字节跳动，多语言技术栈十分广泛，C/C++/Python/Java/Golang 等服务都有很强的流量治理诉求，所以服务网格也能够针对这种状况给他们提供治理体验的晋升。

典型架构

上面跟大家分享一个典型架构，以便前面引出字节外部的服务网格应用状况。社区内关注量比拟高的服务网格架构，如 Istio 和 Envoy 架构，它们会把服务网格分为两个层面，一个是数据面，一个是管制面。如图所示，数据面以一个独自的过程或者代理模式与业务过程在同一个 POD 外面运行，起到拆散的作用。数据面更关注是怎么做一个高性能的代理，除此之外，还关注流量治理能力的实现，如超时、垄断、降级等，把这些能力从 SDK 外面剥离进去，在数据面真正地实现跨语言治理体验的个性。

管制面是为所有网格的数据面提供残缺的流量管制性能。不只是在流量外面的控制能力，还包含对于 POD 或者服务之间通信上有平安层面的要求，安全控制也能够通过网格数据面和管制面的通信达成。此外，当服务的体量较大或者零碎较为简单时，咱们须要达到很高强度的可观测性，以度量零碎的稳定性以及零碎可能带来的其余收益，因而可观测性也是网格管制面一个十分重要的个性。

落地挑战

第一，字节外部有很多跨语言治理的诉求。除了最宽泛应用的 Go 语言，还有 Python，Node，C++ 和 Java 等等，包含最近比拟受欢迎的 Rust 语言。因而字节外部要落地服务网格实际上面临着比拟大的挑战。

第二，字节外部有很多服务量级以及这些服务对应的容器。据估计，在线微服务数量超过 10 万，容器实例部署的量级大略是 1000 万。面对如此大的体量，服务网格的管制面应该如何保障高可用性、稳定性和资源的开销？管制面和数据面之间的通信协议应该如何设计？怎么让更多新的服务和新的容器疾速地接入咱们的网格以享受便捷服务？

第三，咱们面临着非常复杂的业务状态。字节有很多用户端产品，比方抖音、今日头条和懂车帝，当然还有联盟和电商之类的产品。不同的业务状态对网格的诉求也是不一样的，比方抖音是一个强依赖“读”申请的产品，它须要疾速地获取大量数据，电商是强依赖“写”申请的产品，这类产品会收到很多订单申请，网格要保障这些的申请写入成功率。因而对于字节这种简单的业务状态，咱们的网格面临着很强的挑战。

落地实际

如图所示，为了应答这些挑战，咱们拓展了服务网格的通信性能，将其中的一个 POD 进行细化。能够看到图中最下面有一个业务的过程，其次有传统的服务网格数据面 Data Plane，也就是 Proxy，此外字节外部还会有一个专门的运维 Operation Agent。在此基础上，数据面会与管制面进行通信，同时咱们外部也会有专门的运维来做服务网格生命周期的治理。那么字节跳动服务网格的数据面、管制面和运维面都具备什么特点呢？接下来进行具体介绍。

1. 数据面

首先数据面会有动静配置能力，比方咱们可能须要配置缓存的过期工夫、缓存的规模、缓存是否淘汰等等来升高海量申请给管制片带来的压力。其次部署了大量服务后，每一个服务都有一个数据面代理，那么咱们就须要把性能做到足够高。对于这么多容器，哪怕代理层只节俭一点资源，整体的线上资源都能够节俭一大部分。所以咱们思考基于 Share Memory IPC 运行，这会使得网络通信量很大的容器尽可能应用本地内存通信，能够大大降低网络通信开销和反序列化开销。最初是在编译或者链接时做一些基于程序的优化，比方 LTO 等等。以上就是咱们从数据面的角度思考如何进行服务网格的优化。

2. 管制面

首先，咱们采纳纯自研的计划，没有应用 ACE，能够灵便反对服务动静接入网格。其次，咱们也通过多集群部署将服务以不同的业务状态或者业务线做辨别，而后无效地管制爆炸半径。同时在整个优化过程中，也能够以优先级的模式进行排位，从而逐渐地上线性能。最初是管制面具备多样的流量治理能力，可能继续为业务赋能。面对不同品种的业务诉求，咱们也在尝试一直地解决新呈现的问题和挑战。

3. 运维面

首先，咱们会做到全面掌控网格外部通信，也就是管制面和数据面的通信形式。其次，在服务网格数据面做降级或者变更时，咱们要保障网格的过程可能失常地运行，因而公布确认机制是须要有十分强的保障。最初，对于不同的服务或者业务线，对代理的非凡配置须要进行版本的锁定，在这方面咱们也有比拟丰盛的教训。

超简单调用网络下的流量治理体系

基于字节跳动如此大体量的服务网格，咱们给网格的用户带来了什么呢？这就要介绍一下在超简单的调用网络下的流量治理体系。

外围能力

咱们有十分多流量治理的性能，基于近几年的打磨，造成了一套绝对比拟残缺的治理体系。上面重点分享三个外围能力。

第一，微服务访问控制。字节外部秉持着“零信赖”的主旨，咱们认为不论是外网还是内网，微服务之间的拜访都是要有束缚的、是不可信赖的，所以咱们大规模落地了微服务之间的访问控制能力。访问控制包含以下几方面：

• 受权，拜访的权限；
• 鉴定，对本人身份的介绍是否是可信；
• 流量加密，避免嗅探或攻打流量，保证数据层面的平安。

第二，单元化。随着业务状态的复杂程度一直加深，会有各种各样的场景呈现，因而须要很强的隔离机制。咱们外部在单元化（流量管控 / 流量隔离）方面积攒了很多教训。咱们不仅仅反对传统的 HTTP、Thrift 和 RPC 等流量，还反对 Message Queue 这种类型的流量。

第三，动静治理。随着服务网格和机器量级逐步扩充，咱们面临的一个挑战是可能会有很动静的场景，不能通过非常简单或者变化无穷的配置来实现，它更多须要的是一种动静过载管制和动静负载平衡的能力，在这方面咱们也是有肯定积攒的。

落地规模

那么这些外围治理能力在字节外部的落地规模是怎么的呢？大略有超过 13,000 个服务都会应用受权能力，超过 2500 个服务开启了十分严格的身份认证能力。身份认证是基于字节外部一个绝对比拟成熟、稳固的身份颁发零碎来进行。单元化的局部咱们有超过 1000 条隔离链条做流量隔离。为了实时地爱护本人的服务所对应容器的容量状态，有超过 7500 个服务应用咱们动静过载管制的能力。有超过 2500 个服务接入了咱们动静负载平衡能力，使得流量可能尽可能地基于理论云环境的负载状况做动静流量调动。以下是具体应用状况介绍。

微服务访问控制

联合下图具体介绍一下在字节外部受权、鉴定和流量加密三种能力的应用场景。如图下面是一个比拟传统的服务网格架构图，咱们退出了 POD A 和 POD B，它就是通过咱们的网格做流量的传递和通信。上面的 POD B 是一个没有接入网格的服务，它只有本人的业务过程。地方的管制面分两个模块，这外面展现的是咱们在介绍时会用到的两个模块，一个是观测方面的，一个是平安方面的。平安方面次要做下发配置以及身份相干的校验。

• 受权

数据层是会做容许名单和不容许名单、回绝或放行的操作，以及数据的解析和匹配等等。同时受权也提供了比拟强的观测能力，因为对于如此大体量的服务，如果遇到没有失去受权的调用方来拜访，贸然开启受权是有很大危险的，所以咱们提供了绝对比拟成熟的观测能力。所有的服务都能够在相似 Dry Run 的场景下看有哪些调用方没有失去对应权限，而后进行相应的操作，这个就是由管制面的观测模块实现的。同时，业务同学可能有十分多的上游，因而保护受权列表也是很简单的，所以咱们也同时提供了巡检的零碎，一方面能够帮忙他们给本人存量的服务做配置，另一方面咱们也会去帮忙他们管制增量的危险。

• 鉴定

鉴定和受权比拟相似，也会提供观测能力。同时咱们思考到根底身份服务不可用的状况，也提供了动静灵便的降级能力，比方过期身份、有效身份或没有传递身份等等。

• 流量加密

为了保障线上的大部分服务（不管是否利用了服务网格）可能尽可能平滑地做流量加密，咱们在管制面做了极其场景的思考，这会主动地帮忙咱们曾经配置过的、开启服务网格的所有容器之间进行加密流量，也就是图中 POD A 到 POD B 的申请。如果上面的 POD 不具备流量加密或者解析的能力，咱们会主动地给它发送非加密的申请，使它达到比拟平安的接入状态。

单元化

在单元化方面服务网格面临的 应用场景 具体如下：

第一，因为传输进来的流量标识不同，用户可能想要依据不同流量标识对租户进行不同的解决，之后依据不同的集群或者服务做相应的策略。

第二，可能有一些服务具备常态化容灾演练的需要，比方有一些专门供给演练的集群。

第三，有很多敏感服务须要做流量的隔离，比方某些货色对某些人相对不可见。这些都是比拟典型的单元化场景。基于这些用户场景，咱们采取了绝对比拟灵便的单元化流量调度。

单元化的 特点 有以下四个方面：

第一，申请特色级别的智能路由能力。实际上这是咱们单元化的根底，基于申请特色决定流量的发送地位。

第二，申请特色级别的治理能力。在决定流量发送地位的根底上，还能够决定你是否有发送到对应地位的权限。

第三，动静更新，无业务入侵。那么超时或熔断降级等等这些参数应该怎么设置呢？这两种非常灵活的智能路由和治理能力应用条件也是非常简单的。首先，咱们能够动静更新，只有接入咱们的服务网格，就能够间接感知增加代码的参数或者应用哪种中间件。其次，能够采纳观测能力。

第四，反对观测、按比例灰度上量。想晓得流量是否能够正确地发到指定地位，咱们能够先不必真正发送，而是观测一下它对应的状况是否合乎预期。在确定没有问题之后，网格还具备按比例灰度上量的能力，直到你感觉齐全没有问题，能够全副切过去。这极大地升高了用户对于单元化能力的放心，能够缓缓地把本人的流量做单元化，实现本人的诉求。

动静治理

过载爱护

过载爱护，即这个服务保障本人不会过载、绝对比较稳定后对外提供服务的能力。实际上咱们基于 Mesh 也会做过载爱护。咱们参考了很多业界文章，比方微信、Google 等公司，借鉴了他们在过载爱护方面的一些积淀，以此来思考咱们是否有适合的参数或指标掂量一个服务或容器的过载状况。下图是对应的两个不同容器。首先 POD A 是一个 API 层的服务，它在通过 LB 层的流量进来后，会主动地依据一些申请特色注入申请优先级的数据。

什么是申请特色？这个优先级是什么样子的？具体来讲，如果申请是从某一个 HTTP  Server 的 URL 进来的，那么它会具备这样的特色。比方一类申请是抖音的 Feed，它的申请优先级是 A，另一类申请是抖音的评论，从另一个 URL 进来，它的申请优先级是 B，对应 A 和 B 申请优先级在业务状态上的重要性是不一样的。咱们在前面做扩大的时候会应用优先级作为一个很重要的评判指标。

在 A 和 B 外面都有一个流程，在收到申请之后，会有一个接管到申请的工夫点，在这个工夫点的根底上，咱们会把这个申请转化到业务过程。业务过程在应用这个申请或者在解析这个申请的时候，会有一段解决工夫，它也会把这个解决工夫做标记，放在申请回复外面。之后咱们在数据面代理会捕捉到“申请回复的工夫戳”，与咱们标记的“申请达到的工夫戳”做相应的计算，咱们把这个指标定义为排队工夫。

通过动静地更新排队工夫的状态机，咱们能够评判业务的状况以及它是否过载。相应地咱们也会将排队时间延迟胜利的申请量、谬误量等等，通过异步上报的模式传达到管制面的观测模块，基于 CPU 利用率、排队工夫、单位工夫内的申请量、客户端超时断点等等这些输出，咱们能够通过状态积载流转出。

那么这个服务是否处于过载状态？如果它处于过载状态，咱们会失去一个输入，即当你的申请优先级小于某一个值的时候，咱们会将这个申请抛弃掉。这也是绝对比拟动静地基于服务运行时的指标评判容器过载状况，它能够疾速地使服务从过载的状态复原，同时也能够迟缓地使服务的过载状态达到可利用状态，这会使得这个服务在压力比拟大的状况下，依然可能为一些高优先级的申请提供服务，保障客户层面看到的可用性。

负载平衡

字节外部的内网环境非常复杂，信息数量比拟大，咱们常常会碰到一些坏的机器，比方 CPU 主频比拟低等。在这种状况下部署的服务解决能力可能没有其余的机器强，所以偶然会反映出 CPU 程度不均，或者单实例的问题。

在面临这样的问题时，咱们解决方案是什么呢？首先咱们会从数据面和管制面着手。数据面更关注的事件是高精度指标的采集和上报，它的精度可能会高于绝大部分观测零碎的精度，这使得咱们的零碎可能更疾速地反映以后状态。而后这种指标被上报到管制面做聚合，进行解决剖析。同时，数据面只须要反对非常简单的基于权重的负载平衡算法即可，后续咱们会用这个权重做动静治理流量的调节。

管制面能够做基于指标的动静权重计算，比方咱们有 RPC 的胜利申请量、谬误量和一些其余的谬误改作工夫等等，那么咱们能够基于这些指标做聚合，即拿到所有从调研方视角来看被调用方的容器信息负载状况、提早状况做中心化的计算。计算输入会产出一个实例，即它的动静权重应该是多少，也就是它实际上应该承载申请的比例。而后把对应的服务发现后果下发给数据面，数据面须要采纳非常灵活的权重变动实现动静负载平衡，这就能够解决咱们后面所面临的问题。也就是说尽可能躲避那些呈现故障的机器，将尽可能少的流量发到解决能力较差的容器。

Hertz 在服务网格的落地实际

技术选型

在咱们的服务网格做技术选型的时候，咱们面临着很多挑战和艰难。咱们比拟关注的技术选型特点有三个方面。

• 性能

咱们存量的流量比拟大，服务的量级也比拟多，因而想要在框架方面尽可能节俭。过后调研了一些备选框架，当然那时 Hertz 还没有开源。咱们的面临问题是依据 13M 以上单位申请下的流量做框架的选型。

• 易用性

实际上咱们做服务网格的设计时，也会常常思考到网格对于用户的易用性。在咱们抉择框架时，咱们就变成了框架的用户，因而咱们也会思考框架的易用性。咱们比较关心框架对两个特点，第一，咱们是否能够很容易地通过框架写出高质量代码，而不必关怀过多的细节。第二，框架自身是否提供了比拟易用且丰盛的 API 供咱们间接应用，使得咱们尽可能少地造轮子。

• 长效反对

在抉择框架的时候，咱们会思考要用曾经开源的、还是用外部资源或者本人重写一个框架？如果用曾经开源的框架，遇到了问题怎么办？此外，咱们可能要二次开发加一些新的性能，面对这些 Features 社区是否有足够的人力进行反对？这些也是咱们抉择框架的时候面临的问题。

Hertz 介绍

最终咱们抉择了 Hertz 框架，也就是最新曾经开源的 CloudWeGo/Hertz。它实际上是字节跳动服务框架团队开发并且开源进去的一个基于 Golang 的高性能 HTTP 框架。咱们应用后体验到 Hertz 框架有以下三个方面的特点。

1. 高易用性。一个可能在字节外部积淀两年没有被淘汰，而且还有很多业务在应用的框架，它的易用性必定是十分高的。

2. 高性能。高性能实际上是咱们做框架抉择一个很重要的考察点。在开源计划外面为数不多的高性能框架，如  Fasthttp，它实际上也是咱们为数不多的抉择之一。如果一个框架兼备高易用性和高性能，是很难得的。

3. 高拓展性。从目前的应用状况来看，Hertz 的拓展性还是很强的。因为咱们服务网格须要框架具备高拓展性以满足咱们的一些特色，包含多协定的反对等等。大家能够从 Hertz 官网理解更多的相干细节。

Hertz 官网：https://github.com/cloudwego/…

Telemetry Mixer

Hertz 在服务网格外部是怎么应用的呢？首先就是刚刚提到的动静负载平衡的观测模块，这个模块的服务类型是一个 HTTP 服务，也就是咱们数据面代理的指标通过 HTTP 服务做直达，以便于咱们在整个管制面的架构外围外面做后续数据处理。如下图，Mixer 局部是应用 Hertz Server 实现的。咱们充分利用它高并发、高吞吐的特点，以及为了协定尽可能达到高易用性和可解释性，咱们应用了 JSON。当然也是因为思考到 Hertz 能够无缝集成基于 Sonic 的高性能 JSON 编解码计划。

咱们从 HTTP 层或 API 层接管到数据后，应用 CloudWeGo 社区的另一个开源框架 Kitex，从而使外部零碎通过 Thrift 高效编解码的形式做数据流转，以达到缩小开销的目标。同时因为咱们对数据有比拟高的自定义流量调度能力，所以也应用了 Kitex 拓展性比拟强的性能，即自定义负载平衡策略，将相应的指标从 API 层转到自研数据库做比较复杂的指标聚合，再全程计算。咱们也会做指标异步的存储 InfluxDB 等等用于前面的观测性看板。

此外，咱们也应用了 Kitex 在 Thrift 和 Frugal 方面的相干调研，以尽可能地升高协定、反序列化相干的 CPU 内存等等资源的开销。对于这个方面，咱们也还在与 Kitex 团队同学单干进行调研和测试。

Configuration Center

同时咱们也应用 Hertz 作为外围管制面配置核心 API 层的服务。这里的应用办法绝对简略，依然是应用 Hertz 为非接入 Mesh 的服务提供治理配置的拉取。

如下图所示，假如 POD A 接入了服务网格，应用数据面做数据存量的流量调度和解决，POD B 应用的是 Kitex 框架，与业务过程同时在一个容器外面提供服务。对于这样服务网格和非服务网格的服务之间的调用，数据面会向管制面的 Service Mesh Core 申请对应的配置和服务发现后果，框架会向管制面的 Configuration Center 申请对应的服务治理相干配置。实际上配置核心的申请量级与容器的数量是相干的，同时接入服务网格的局部服务框架，咱们会申请配置核心获取一些必不可少的配置信息。

收益剖析

应用了 Hertz 之后，给服务网格带来的收益大略是怎么的呢？这能够从三个方面进行剖析。

第一是从性能方面，最后抉择 Hertz 也是与很多开源框架从性能方面进行了比照，Hertz 是外部产品，过后还没有开源，然而它的性能做得十分好。咱们具体从性能方面思考了两个次要的点，一个是这个框架能够稳固地承载线上超过 13M QPS 的流量，另一个是在上线前后和咱们测试过程中发现 CPU 火焰图的占比是合乎预期的。这一点后续咱们会依据性能再具体地开展介绍。

第二是从应用性方面，这实际上也是咱们十分关注的点，即咱们如何基于这样的一款框架疾速地实现所须要的性能，从而尽可能关注咱们的业务逻辑，而不是框架自身。还有咱们如何基于这个框架实现一些高效代码，防止还要破费更多精力学习相干语言。

第三是从长效反对方面，目前 Hertz 已奉献给 CloudWeGo 开源社区，而且开源和外部为对立版本，这也为给咱们提供长效反对提供了保障。上面具体地从这三个方面进行具体介绍。

收益剖析之性能

因为字节外部业务容器数量过多，因而咱们服务的 Goroutine 数量比拟多，从而导致稳定性较差。

通过 CPU 火焰图，能够看到从 Gin 替换成 Hertz 之后，咱们获取的收益次要有四点。

第一，等同吞吐量下具备更高稳定性。Hertz 的设计和实际都是基于 Netpoll 网络库实现的，在同样的吞吐量下，它就会比其余框架具备更高的稳定性。

第二，Goroutine 数量从 6w 降到 80。之前 Goroutine 的数量是 6 万，应用 Hertz 从 6 万间接降到有余 100 个，Goroutine 稳定性失去极大地晋升。

第三，框架开销大幅升高。从火焰图能够看到，替换成 Hertz 后，之前 Gin 框架相干的开销曾经根本隐没不见。更多的还是像网络序列化、反序列化和业务逻辑相干的开销。

第四，稳固承载线上超 13M QPS 流量。替换成 Hertz 后，服务网格在线上稳固承载了超过 13M QPS 的流量。

最初再介绍一下替换前后 CPU 优化状况，替换成为 Hertz 框架后，CPU 流量从大略快到 4k 降到大概只有 2.5k。

收益剖析之易用性

咱们之前面临的痛点问题是很难基于已有的框架写出十分高性能的代码，可能须要对 Go 语言有更深刻的理解。同时咱们很难设计一个好的容错机制，比方要基于已有的框架去实现一个高性能的代码，咱们要关注连接池、对象池，而后去管制连贯超时、申请超时和读写超时等等。这两头如果有一个环节实现谬误，就会导致十分灾难性的结果，之后咱们要不停地回滚上线修复。

应用 Hertz 之后，代码实现变得非常简单。Hertz 自带比拟易用的对象回调机制，咱们不必再特地关注申请和响应的对象复用，以及怎么配置连贯超时和申请重试，这些都是 Hertz 框架间接提供的，用户只需依照它的阐明进行配置，它就能够达到用户预期。

收益剖析之长效反对

与性能和应用性相比，我感觉长效反对是更加重要的个性。咱们之前在抉择框架时也思考了一些其余开源我的项目，但它们的迭代速度往往达不到预期。比方 Fasthttp，它是一个十分优良的开源高性能 HTTP 框架，但如果用户有 HTTP/2.0 或者 WebSockets 相干的需要，会发现最近几年它都没有做相应的反对，在官网文档上也申明这方面的研发还在停顿之中。

所以在抉择框架或开源计划时，咱们可能会遇到一些这样的问题，如果咱们真的要应用它并且要达到预期，可能就要被迫保护开源我的项目的克隆。如果过一段时间开源我的项目迭代了，咱们还要花工夫做 Rebase 或与社区的同步等等，这个保护过程老本比拟高。

那应用 Hertz 的收益是什么呢？首先就是并不是所有的开源我的项目都有很弱小的社区继续经营。CloudWeGo/Hertz 是由字节外部十分弱小的社区组织经营的，同时 Hertz 也是字节跳动外部宽泛应用的框架。业务同学或其余公司用户应用 Hertz 时遇到的问题在字节外部应用过程中都曾经呈现过，而且曾经针对相干问题做了修复或者性能的增加，因而用户的要求大部分需要会间接失去满足。

同时 CloudWeGo/Hertz 字节外部的应用版本是基于 Hertz 的开源版本构建的。很多个性在外部上线之后，咱们也会同步地公布到内部的开源版本上，使得大家可能疾速地应用到这样的个性，享受到 Hertz 更高的性能。

CloudWeGo 社区曾经公布的 Kitex、Netpoll 和 Hertz 等我的项目，都在继续疾速进行迭代。最近 Hertz v0.2.0 也曾经正式公布，欢送大家到 CloudWeGo 官网查看相干信息。

Hertz v0.2.0：https://github.com/cloudwego/…

我的项目地址

GitHub：https://github.com/cloudwego

官网：www.cloudwego.io

【CSG 第二期】CloudWeGo 源码解读流动 ——“Hertz 框架篇”开始啦！流动链接：https://mp.weixin.qq.com/s/GU…