共计 8434 个字符，预计需要花费 22 分钟才能阅读完成。
本文整顿自 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 文档建设
首先，在文档建设方面，CloudWeGo 官网上线了近 3 万字较为欠缺的文档体系。内容笼罩从 1 分钟疾速上手，到各个相干模块的根本个性介绍，再到一些拓展能力的建设。
其次，咱们为了达到真正的开箱即用，节俭用户对接各个扩大我的项目的应用老本，上线了 Kitex 和 Hertz 相干的 Example，帮忙建设了相干从注册发现，到各个中间件应用的一些开箱即用的 Demo。\
另外，为了晋升更多开发者的应用体验，官网也上线了动态文档的搜寻能力。
- CloudWeGo 生态建设
想在外部构建一套残缺的云原生微服务架构体系，仅仅应用 CloudWeGo 的一个框架我的项目，是远远不够的。因而，CloudWeGo 在易用性方面鼎力拓展相干的生态建设。
- CloudWeGo 在 2021 年退出 CNCF Landscape，心愿给用户一个更加明确的产品定位。同时，反对对接各大云厂商，为 CloudWeGo 我的项目的用户提供更多私有云的应用抉择。
- 为帮忙大家缩小相干的应用老本，咱们十分踊跃地和上下游的开源我的项目进行深度单干，建设了一整套微服务开源供应链的单干体系，搭建了 CloudWeGo 框架对接各个我的项目的相干 Demo 和开箱即用的 Example。
- 从思考将来倒退的角度而言，当企业落地了一整套微服务架构之后，可能会存在易用性或性能方面的问题。当呈现更好的技术解决和性能晋升计划，基于原有架构的耦合和复杂度，很难推动新的架构进行整体的迭代。因而，咱们也十分踊跃地在推动建设云原生微服务治理的整体规范。心愿更多的我的项目，可能造成对立的接入和对接的规范，从而在将来的一些新的、更高性能的技术解决方案的迁徙和过渡上，可能让迁徙和应用老本降到最低。
- CloudWeGo 的开发者流动
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/c…
华兴证券的张天老师团队向社区奉献了来自证券行业应用 Kitex 实现混合云部署下跨机房应用场景的案例。
咱们在跟张天老师团队单干的时候发现，他们遇到的最大的问题是有的业务部署在金融云机房上，有的业务部署在公有机房上，所以存在跨机房调用的问题。因为他们应用 K8s 集群，还会呈现同集群调用和跨集群调用的问题。整个调用的链路十分长，这两头就会呈现很多不可观测的问题，当呈现问题的时候，排查难度就极其大。
于是张天老师团队在和 CloudWeGo 单干之后，整体搭建了一个 Kitex + K8s 的可观测性零碎，也将相干的搭建实际奉献到了开源社区。感兴趣的同学能够通过 CloudWeGo 公众号查看相干的企业案例和最终的实际场景。
森马
案例链接：https://www.cloudwego.io/zh/c…
CloudWeGo 和森马独特梳理了与电商行业相干的一个整体应用场景。非常感谢森马团队，奉献了电商行业应用 Kitex 接入 Istio，以进步对高并发订单解决能力的应用场景。
森马团队还奉献了基于微服务架构的两种模式，为有相干高性能业务需要的用户提供了 服务网格 + Kitex 治理模式相干的选型根据，并且给出了相干的压测报告，也给社区有雷同需要的小伙伴提供重要参考。
飞书
案例链接：https://www.cloudwego.io/zh/c…
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 提供两种可行计划：
1. 认准 CloudWeGo 官网，咱们会在官网上线十分残缺的文档体系。所有的更新我的项目，包含技术文档都会在官网上同步更新。
CloudWeGo 官网：https://www.cloudwego.io/
2. 关注 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