本文整理自 CloudWeGo 开源一周年技术沙龙活动中字节跳动 CloudWeGo 开源（社区）运营负责人邓逸云的演讲分享，技术沙龙主题为《字节高性能开源微服务框架：CloudWeGo》。
本文将从以下三个方面介绍 CloudWeGo 开源一年以来社区的变化和我们一直坚持的长期主义：
CloudWeGo 开源一周年的变化；
新一代云原生微服务用户画像；
持续演进的 CloudWeGo 开源社区。
![]()
概述
CloudWeGo 开源一周年以来收获了超过 1w 的 star 数，这一年 CloudWeGo 从项目的数量、性能的提升、社区的活跃、生态的拓展等各个方面都有一些整体的变化。同时，通过一周年的开源，我们收获了非常多的开源社区用户，这些用户在社区里也提供了很多项目的使用反馈。基于这些反馈，我们发现随着技术发展和用户业务的不停迭代，用户需求也在发生着变化。因此我们梳理了新一代关于云原生微服务用户的画像，作为指导我们社区持续演进的重要参考。
CloudWeGo 开源一周年的变化
全景图
CloudWeGo 是一套由字节跳动开源的云原生微服务架构中间件集合。在 2021 年 9 月正式推出的时候，只开源了 Kitex 高性能 RPC 框架、高性能网络库 Netpoll，还有相关的辅助工具和基础库。
经过一年的建设，CloudWeGo 社区目前有 11 个重点项目齐头并进。我们不仅有 Kitex 框架，还有基于 HTTP 相关的高性能框架 Hertz，同时开源了高性能的 Rust RPC 框架 Volo，这也是国内首个开源 Rust RPC 框架。
从 CloudWeGo 开源的项目也能感受到我们对性能的极致追求，我们不仅开源了框架相关的项目，同时也把深度优化的一些编解码库、网络库都进行了开源。在 CloudWeGo 整体的项目中，始终都保持着三高的特性，即高性能、高可靠性和高扩展性。
![]()
与此同时，这一年我们也在致力于开源社区的建设：
CloudWeGo 非常重视整个项目的易用性建设。我们有非常完整的官方文档体系，包括整体的扩展和 Example 的建设，以及各大云厂商生态的对接等。
为了帮助更多对高性能微服务架构有需求的用户，能够让他们真实地把高性能的技术解决方案落地，我们提供了 Benchmark 的性能测试和选型参考，同时提供免费的企业支持，帮助用户解决自己业务特异性上的一些问题。
为了让更多有需求的用户能够在社区找到高性能技术解决方案，我们开设了相关的活动和布道体系的建设。在 CloudWeGo 开源一周年之际，项目整体收获了很多用户支持，也收获了很多企业用户的使用反馈。
CloudWeGo 开源社区的长期主义
高性能技术解决方案的持续探索
CloudWeGo 开源一周年的历程，其实就是对高性能技术解决方案持续探索的历程。
![]()
- CloudWeGo 从 2021 年 9 月 8 日正式开源。推出高性能的 RPC 框架 Kitex、配合 Kitex 使用的高性能网络库 Netpoll、基于 Thrift 代码生成工具 Thriftgo 和基础库 Sonic。
- 2022 年 5 月，开源了基于 JIT 的编解码工具 Frugal。Kitex 配合 Frugal 的使用，能够带来 5 倍的性能提升。
- 2022 年 6 月，开源高性能 HTTP 框架 Hertz。Hertz 不仅仅是一个 高性能的HTTP 的开源框架，同时也是一个超大规模的企业落地实践。在我们内部的网关场景下，替换 Hertz 框架之后的 CPU 使用节省了超过 40%。
- 2022 年 7 月，我们响应社区呼声最高的关于 Protobuf 的性能优化，带来了高性能的 Protobuf 序列化反序列化库 FastPB，再次对相关的性能进行提升。
- 开源一周年之际，我们又进行了更深度的高性能框架能力探索，开源了国内首个 Rust RPC 框架 Volo。
CloudWeGo 开源一周年的时间线，隐藏着 CloudWeGo 社区运营的第一个长期主义关键词：高性能技术解决方案的持续探索。
活跃 & 高可靠性的长期承诺
CloudWeGo 开源一年来，收获了超过 1w 的 star 数，整个社区的活跃度也有了飞速提升。
社区保持着 2-3 个月发布一次中版本的发版频率，PR 和 Issue 数量在开源一年的时间内实现稳步提升，从每月 47 条 PR 合入增加到每月超过 160 条 PR 合入。
![]()
其实高活跃的社区并不少见，但是我们社区还有一个关键词：坚持活跃 & 高可靠性的长期承诺。CloudWeGo 社区对可靠性的坚持，要求我们不仅要维持活跃，还要保持活跃且可靠。
CloudWeGo 开源社区一直保持着我们所有的开源项目内外一致的承诺，同时我们开源到外部的所有能力和项目都是在内部经过可靠性验证的。这也正是 CloudWeGo 开源社区坚持的另一个长期主义。
高易用性设计
我们非常希望 CloudWeGo 开源出来的高性能技术解决方案，能够更好地帮助更多用户搭建自己的微服务架构体系。因此，CloudWeGo 在社区建设上围绕着易用性建设做了非常多的拓展：
首先，在文档建设方面，CloudWeGo 官网上线了近 3 万字较为完善的文档体系。内容覆盖从 1 分钟快速上手，到各个相关模块的基本特性介绍，再到一些拓展能力的建设。
其次，我们为了达到真正的开箱即用，节省用户对接各个扩展项目的使用成本，上线了 Kitex 和 Hertz 相关的 Example，帮忙建设了相关从注册发现，到各个中间件使用的一些开箱即用的 Demo。
另外，为了提升更多开发者的使用体验，官网也上线了静态文档的搜索能力。
![]()
想在内部构建一套完整的云原生微服务架构体系，仅仅使用 CloudWeGo 的一个框架项目，是远远不够的。因此，CloudWeGo 在易用性方面大力拓展相关的生态建设。
CloudWeGo 在 2021 年加入 CNCF Landscape，希望给用户一个更加明确的产品定位。同时，支持对接各大云厂商，为 CloudWeGo 项目的用户提供更多公有云的使用选择。
为帮助大家减少相关的使用成本，我们非常积极地和上下游的开源项目进行深度合作，建设了一整套微服务开源供应链的合作体系，搭建了 CloudWeGo 框架对接各个项目的相关 Demo 和开箱即用的 Example。
从考虑未来发展的角度而言，当企业落地了一整套微服务架构之后，可能会存在易用性或性能方面的问题。当出现更好的技术解决和性能提升方案，基于原有架构的耦合和复杂度，很难推进新的架构进行整体的迭代。因此，我们也非常积极地在推进建设云原生微服务治理的整体标准。希望更多的项目，能够形成统一的接入和对接的标准，从而在未来的一些新的、更高性能的技术解决方案的迁移和过渡上，能够让迁移和使用成本降到最低。
![]()
CloudWeGo 项目包括整个社区都对高性能有非常热烈的追求。因此，我们也在不停地迭代。
CloudWeGo 一直在不断追求高性能框架以及高性能技术解决最新方案。每次上线新的技术解决方案和一些相关能力之后，我们都期望让更多的用户知道这些方案是怎样的，让用户能够更便捷地学习到一些相关的技术指南。
因此，我们针对性地设计了 CloudWeGo Study Group 学习计划，这是为了将一些全新的性能解决方案进行体系化的学习分享，即通过一些类似于从框架入门到核心能力的解读、再到一些学习路径的分享以及扩展知识的相关介绍对外开放给社区。
![]()
我们会提供一份完整的学习资料，降低用户学习新的技术解决方案的成本，也能够让用户了解到自己的学习是否适合其业务场景。在整个学习和使用的过程中，降低最终学习的时长，通过体系化的学习更快地理解技术方案的性能亮点和需要学习的相关点。
![]()
小结
CloudWeGo 开源社区坚持的长期主义：
![]()
CloudWeGo 的用户
基于开源社区长期主义的坚持，CloudWeGo 自 2021 年 9 月开源，至今开源 1 年，获得超过 1w star，支持完成了证券、电商、中台、社交、游戏、AI 等行业企业客户的落地使用。
![]()
CloudWeGo 的贡献者
在活跃的社区氛围下，我们收获了从最初刚开源只有 20 个内部贡献者，到现在已经有了超过 200 个代码贡献者。这些贡献者在深度使用了 CloudWeGo 开源项目之后，也为 CloudWeGo 开源项目贡献了大量生态方面相关对接能力。
贡献者体系更新
基于越来越多的贡献者在我们的开源社区里做了大量深度贡献，CloudWeGo 开源社区在一周年的周年庆之际，推出全新的贡献者激励体系。
我们新增开放了三个角色体系，希望通过这种完善的角色机制，赋予社区开发者更多的社区治理权限。同时我们也鼓励更多的贡献者能够成为项目的维护者，希望长期的维护者能够真正带领我们的项目持续进行高性能的优化和相关的演进。
![]()
贡献者多样化
在开源项目的运营和维护中，包括开源社区的建设，不仅仅是依赖代码贡献者的参与，还有很多其他方面的贡献，其中包括企业支持场景的贡献、布道活动的贡献、整体活动组织的贡献等多元参与。这些贡献者在 CloudWeGo 社区也是被大力支持的，因此我们专门针对多元贡献上线了 CloudWeGo 年度激励计划。
![]()
社区在 8 月份刚刚完成了 2021 - 2022 年度 CloudWeGo Awesome Contributor 的评选，我们非常荣幸地收获了 84 位年度优秀贡献者。在完成了社区的提名与公示后，这些同学已经顺利成为了 CloudWeGo 年度优秀贡献者，之后我们会为这些优秀贡献者送上 CloudWeGo 一周年的荣誉纪念徽章。
CloudWeGo 社区遇到的问题
正是因为社区较高的活跃度以及众多贡献者的参与，大量用户加入了 CloudWeGo 社区。我们逐渐发现用户的使用场景开始慢慢发生了拓展。从最初可能只是想了解一下微服务的框架、单独一个项目如何去落地和使用， 到后来慢慢变成探索一整套微服务架构的设计，以及多个项目之间的实践配合和相关生态能力的建设。
![]()
这些其实是非常体系化、大规模的需求，因此我们联合一些企业用户进行了相关场景的实践贡献。CloudWeGo 之前支持了包括证券、电商、AI 和各个行业用户场景落地，我们也和这些企业用户进行了相关场景的梳理。
CloudWeGo 的企业用户贡献
华兴证券
案例链接：https://www.cloudwego.io/zh/cooperation/huaxingsec/
华兴证券的张天老师团队向社区贡献了来自证券行业使用 Kitex 完成混合云部署下跨机房使用场景的案例。
我们在跟张天老师团队合作的时候发现，他们遇到的最大的问题是有的业务部署在金融云机房上，有的业务部署在私有机房上，所以存在跨机房调用的问题。因为他们使用 K8s 集群，还会出现同集群调用和跨集群调用的问题。整个调用的链路非常长，这中间就会出现很多不可观测的问题，当出现问题的时候，排查难度就极其大。
![]()
于是张天老师团队在和 CloudWeGo 合作之后，整体搭建了一个 Kitex + K8s 的可观测性系统，也将相关的搭建实践贡献到了开源社区。感兴趣的同学可以通过 CloudWeGo 公众号查看相关的企业案例和最终的实践场景。
森马
案例链接：https://www.cloudwego.io/zh/cooperation/semir/
CloudWeGo 和森马共同梳理了与电商行业相关的一个整体使用场景。非常感谢森马团队，贡献了电商行业使用 Kitex 接入 Istio，以提高对高并发订单处理能力的使用场景。
森马团队还贡献了基于微服务架构的两种模式，为有相关高性能业务需求的用户提供了服务网格 + Kitex 治理模式相关的选型依据，并且给出了相关的压测报告，也给社区有相同需求的小伙伴提供重要参考。
![]()
飞书
案例链接：https://www.cloudwego.io/zh/cooperation/feishu/
Hertz 开源后，很多用户会问到内部网关平台架构的设计思路，包括内部网关平台如何配合 Hertz 整体使用？
飞书之前是一个 all-in-one 的套件开发模式，各个业务团队会将业务代码提交到飞书网关平台的代码仓里面，由飞书网关相关的同学来做 web 逻辑的开发。这就导致他们所有的服务都是融在一起的，没有办法做到发布隔离，极大地阻碍了网关平台架构的演进和迭代速度。
因此，飞书团队将前端 Node 单体服务做了微前端架构拆分，配合 Kitex 泛化调用各个业务的微服务，实现了各个业务发布完全隔离，这使得他们不再依赖网关平台的业务开发，进而加快了整个网关业务迭代的速度。
![]()
来自社区的用户具体问题
我们非常感谢企业用户贡献的相关问题，CloudWeGo 配合企业用户的场景案例也获得了社区用户的众多好评。与此同时，有更多的用户也提出了新的问题，这些问题非常具体。
![]()
通过总结发现，这些问题具有显著的业务特异性。我们也很好奇这些用户在内部到底是如何搭建其微服务体系的？ 因此我们开始梳理 CloudWeGo 开源社区的云原生微服务用户画像。
新一代云原生微服务用户画像
我们将社区的用户大概分成了三种类型：
![]()
字节跳动是我们目前最大的用户。字节跳动的线上微服务数量已经超过了 10 万，服务端峰值 QPS 已经达到了数亿的级别，业务复杂性非常大，存在跨语言、跨平台、跨终端、跨集群、跨机房等多种复杂的问题。
同时字节跳动内部有非常完善的微服务架构体系，整体的微服务治理已经全面迈入了 2.0 的时代，用微服务框架配合服务网格携手并进。
在这个场景之下，字节跳动最大的需求就是高性能和可扩展性，这也是 CloudWeGo 作为字节跳动内部孵化的一个优秀的高性能技术解决方案最初开源时所具有的特性。
社区里数量最大的群体，这些用户可能是电商的、证券的、后台的以及一些创业公司，他们的节点数量不是特别多，可能在 5-1000 以内，线上微服务数量处于 5000 以内的水平，但这些用户可能本身就是云原生架构，或者已经在往这方面做一些相关的迁移。
这类用户在 CloudWeGo 开源社区的诉求，主要是针对业务的特异性方面存在高性能相关的需求。
这一类用户属于非云原生架构的企业，他们的服务可能还没有完全云化，具有一定的历史迁移负担。这类用户着重会优先考虑如何将自己的服务迁移上云。
因此可以看到，第二类用户是目前社区数量最大，且最需求最迫切的一类用户。
![]()
我们认为理想状态下用户整个云原生架构体系的搭建过程：
类似第三类用户，当前面临的问题就是怎么把自己的业务迁移上云。
类似第二类社区大量的用户，其实已经是云原生部署的企业，用到了相关容器化和编排调度的技术。
继续往前演进，开始搭建相关的微服务架构，以及会做服务的拆分和通信的治理。
当用户在线上有了一定数量的微服务之后，会开始出现依赖管理和一致性保障的问题。
但是我们在跟用户沟通过程中发现，这其实不是一种绝对意义上的区分。
因为很多公司其实并不是完全属于其中一种状态，而是一种长久的中间态，公司的业务会处于不同的状态。同时，我们在和相关用户进行深度的沟通时，发现这些业务场景其实并不是完全不可复制的，而是具有一定的行业聚合性和相似性。
于是，我们开始探索如何通过社区更好地帮助这些开发者解决痛点问题，这也正是 CloudWeGo 开源社区接下来整体的演进方向。
持续演进的 CloudWeGo 开源社区
CloudWeGo 1.0 社区搭建的主要方向，是将字节跳动内部孵化的高性能框架解决方案触达给更多的用户，让更多对高性能解决方案有需求的用户能够真正地在内部落地和使用这些方案。
当我们发现用户出现特异性的行业需求后，ClouWeGo 2.0 希望社区建设以开发者服务为主，能真正地帮助到社区的开发者，解决其在微服务治理过程中遇到的一些真实存在的问题。
![]()
通过用户问题、场景和解决方案的行业共建，形成社区的 Go 云原生微服务最佳实践，希望能够针对有特异性需求的用户给到一定的参考。
我们会持续和开源链条的上下游深入合作，建设云原生微服务相关的标准治理。致力于后续易用性的建设，希望能够给到成本更低的迁移，以及建立后期维护的治理标准。
继续维持 CloudWeGo 开源社区的长期主义。我们会深入投入对高性能解决方案的持续探索，也会在 Rust 领域持续开展相关生态和开源的建设，共建 Rust 中国的开源生态。
基于此，引出 CloudWeGo 开源社区 2.0：
![]()
CloudWeGo 2.0 的阶段，我们希望社区能够跨越项目边界，真正能够帮助社区用户搭建一套高性能的微服务治理架构和整体的微服务治理体系：
- 通过 Go 领域相关微服务治理的标准和最佳实践的建设，为一些通用性技术和行业最佳实践提供参考；
- 对接开源项目上下游进行深度合作，极大地提升整个项目的易用性；
- 推进高性能 Rust 解决方案的落地，持续探索 Rust 高性能技术解决方案，构建 Rust 相关生态。
如果大家对 CloudWeGo 开源社区，以及刚才提到的一些技术解决方案、企业的落地支持有任何的疑问，可以关注 CloudWeGo 公众号，我们会在公众号上发布一些新闻动态以及各个相关场景的案例报道，同时我们也会在公众号上提供相关的技术支持。感谢大家的关注！
Q & A
Q1：第一次了解到 CloudWeGo，想请问一下 CloudWeGo 有技术社区吗？怎么样能快速地加入到技术社区？如何快速地获取到这个项目的官方文档？
A：对于初步了解 CloudWeGo 提供两种可行方案：
- 认准 CloudWeGo 官网，我们会在官网上线非常完整的文档体系。所有的更新项目，包括技术文档都会在官网上同步更新。
CloudWeGo 官网：https://www.cloudwego.io/
- 关注 CloudWeGo 公众号，我们会在公众号上持续发布最新的 CloudWeGo 技术分享以及相关活动，帮助引导用户获取最新动态并加入技术社区。
Q2：作为一个新手，怎么样能够比较快速地参与到 CloudWeGo 开源社区，有没有比较好的一些方式推荐？
A：总结的一些通用路径如下：
明确自身目的。清楚自己参与开源社区的核心目标是什么，为了学习项目还是为了快速地根据自己的业务去搭建和落地使用。
跟随社区提供的学习指南和路径，借助社区给到的一些资源。比如 CloudWeGo 开源社区，我们会有相关的 CSG 活动，就是 study group 的活动形式，在这里可以体系化地了解一整套的技术解决方案，从小的模块再到大的全场景的落地。
了解项目，从局部走向全局。社区提供的新手 issue 和任务，比如一些 First Good Issue，通过这些 issue 的开发及解决，能够快速地加入到开源社区。
在开源社区里通过自己的深度使用，进行相关的贡献。
以上，是参与开源社区的一个比较通用的路径。CloudWeGo 公众号中也有我们社区的 Contributor 详细地分享过关于参与开源社区的往期文章，全面介绍如何从一个新手到深度参与开源社区的相关内容。
Q3：请问不同项目是如何去匹配不同的社区发展模型的呢？
A：首先明确两个思考问题：
最初大部分的开源项目，只关注相关的技术布道，用户看到适合的项目就进行技术的学习并在企业内部落地，这一阶段的社区运营会基于整个社区的生长阶段设置相关的发展模型。但是这种方式，存在社区和项目之间脱节的问题。比如，原有项目技术方案的更新推广到社区不具备连续性，对用户缺乏体系化的内容输出，用户在社区所获取的内容和项目的演进阶段是有一定差异的。
这里存在一个视角：要把整个开源项目当做是一个产品来运营。比如 CloudWeGo 开源项目，我们有各个框架的技术负责人，核心负责各部分相关的技术问题，但是项目中有非常多的用户存在场景的特异性问题以及整个项目的使用体验问题等，这些问题由谁来去解决？
综上，可以明确整个开源社区最终的目标，其实就是维护项目并帮助解决用户所产生的相关问题。一旦明确目标，就会根据项目不同的发展阶段以及项目当前演进中用户产生的相关疑问，去匹配项目的未来发展规划。
比如，CloudWeGo 项目一直都是在高性能方面做了相关的演进，我们的用户其实也都是基于一些高性能的业务特异性需求来到了 CloudWeGo 社区。当我们和社区的用户进行了相对深度的沟通之后，我们也发现基于行业特性、体系的特异性、或者和字节跳动内部技术方案的差异性，直接提供的技术方案是没有办法适配落地的。因此，我们就通过社区的一些支持，帮助用户在其内部真正落地高性能的技术解决方案。
因此，优先明确社区对项目的核心价值，了解用户的核心需求，在把握整个项目的演进节奏之后，根据项目的阶段以及发展目标，再去匹配相应的运营手段和运营的发展模型得以推动社区的发展。
项目地址
GitHub：https://github.com/cloudwego
官网：www.cloudwego.io
