> 日前，位元組跳動技術社群 ByteTech 舉辦的第七期位元組跳動技術沙龍圓滿落幕，本期沙龍以《位元組高效能開源微服務框架：CloudWeGo》為主題。在沙龍中，位元組跳動 CloudWeGo 開源（社群）運營負責人鄧逸雲，跟大家分享了《開源社群的長期主義與新變化 — CloudWeGo 開源社群實踐》，本文根據分享整理而成。
>
> 本文將從以下三個方面介紹 CloudWeGo 開源一年以來社群的變化和我們一直堅持的長期主義：
>
> 1. CloudWeGo 開源一週年的變化；
>
>
> 2. 新一代雲原生微服務使用者畫像；
> 2. 持續演進的 CloudWeGo 開源社群。
# **1. 概述**
CloudWeGo 開源一週年以來收穫了超過 1w 的 star 數，這一年 CloudWeGo 從專案的數量、效能的提升、社群的活躍、生態的拓展等各個方面都有一些整體的變化。同時，通過一週年的開源，我們收穫了非常多的開源社群使用者，這些使用者在社群裡也提供了很多專案的使用反饋。基於這些反饋，我們發現隨著技術發展和使用者業務的不停迭代，使用者需求也在發生著變化。因此我們梳理了新一代關於雲原生微服務使用者的畫像，作為指導我們社群持續演進的重要參考。
# **2. CloudWeGo 開源一週年的變化**
## **2.1 全景圖**
CloudWeGo 是一套由位元組跳動開源的雲原生微服務架構中介軟體集合。在 2021 年 9 月正式推出的時候，只開源了 Kitex 高效能 RPC 框架、高效能網路庫 Netpoll，還有相關的輔助工具和基礎庫。
經過一年的建設，CloudWeGo 社群目前有 11 個重點專案齊頭並進。我們不僅有 Kitex 框架，還有基於 HTTP 相關的高效能框架 Hertz，同時開源了高效能的 Rust RPC 框架 Volo，這也是國內首個開源 Rust RPC 框架。
從 CloudWeGo 開源的專案也能感受到我們對效能的極致追求，我們不僅開源了框架相關的專案，同時也把深度優化的一些編解碼庫、網路庫都進行了開源。在 CloudWeGo 整體的專案中，始終都保持著三高的特性，即高效能、高可靠性和高擴充套件性。
與此同時，這一年我們也在致力於開源社群的建設：
- **易用性**
CloudWeGo 非常重視整個專案的易用性建設。我們有非常完整的官方文件體系，包括整體的擴充套件和 Example 的建設，以及各大雲廠商生態的對接等。
- **落地支援**
為了幫助更多對高效能微服務架構有需求的使用者，能夠讓他們真實地把高效能的技術解決方案落地，我們提供了 Benchmark 的效能測試和選型參考，同時提供免費的企業支援，幫助使用者解決自己業務特異性上的一些問題。
- **活動 & 佈道**
為了讓更多有需求的使用者能夠在社群找到高效能技術解決方案，我們開設了相關的活動和佈道體系的建設。在 CloudWeGo 開源一週年之際，專案整體收穫了很多使用者支援，也收穫了很多企業使用者的使用反饋。
## **2.2 CloudWeGo 開源社群的長期主義**
### **2.2.1 高效能技術解決方案的持續探索**
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 社群運營的第一個長期主義關鍵詞：高效能技術解決方案的持續探索。
### **2.2.2 活躍 & 高可靠性的長期承諾**
CloudWeGo 開源一年來，收穫了超過 1w 的 star 數，整個社群的活躍度也有了飛速提升。
社群保持著 2-3 個月釋出一次中版本的發版頻率，PR 和 Issue 數量在開源一年的時間內實現穩步提升，從每月 47 條 PR 合入增加到每月超過 160 條 PR 合入。
其實高活躍的社群並不少見，但是我們社群還有一個關鍵詞：堅持活躍 & 高可靠性的長期承諾。CloudWeGo 社群對可靠性的堅持，要求我們不僅要維持活躍，還要保持活躍且可靠。
CloudWeGo 開源社群一直保持著我們所有的開源專案內外一致的承諾，同時我們開源到外部的所有能力和專案都是在內部經過可靠性驗證的。這也正是 CloudWeGo 開源社群堅持的另一個長期主義。
### **2.2.3 高易用性設計**
我們非常希望 CloudWeGo 開源出來的高效能技術解決方案，能夠更好地幫助更多使用者搭建自己的微服務架構體系。因此，CloudWeGo 在社群建設上圍繞著易用性建設做了非常多的拓展：
- **CloudWeGo 文件建設**
首先，在文件建設方面，CloudWeGo 官網上線了近 3 萬字較為完善的文件體系。內容覆蓋從 1 分鐘快速上手，到各個相關模組的基本特性介紹，再到一些拓展能力的建設。
其次，我們為了達到真正的開箱即用，節省使用者對接各個擴充套件專案的使用成本，上線了 Kitex 和 Hertz 相關的 Example，幫忙建設了相關從註冊發現，到各個中介軟體使用的一些開箱即用的 Demo。
另外，為了提升更多開發者的使用體驗，官網也上線了靜態文件的搜尋能力。
- **CloudWeGo 生態建設**
想在內部構建一套完整的雲原生微服務架構體系，僅僅使用 CloudWeGo 的一個框架專案，是遠遠不夠的。因此，CloudWeGo 在易用性方面大力拓展相關的生態建設。
1.CloudWeGo 在 2021 年加入 CNCF Landscape，希望給使用者一個更加明確的產品定位。同時，支援對接各大雲廠商，為 CloudWeGo 專案的使用者提供更多公有云的使用選擇。
2.為幫助大家減少相關的使用成本，我們非常積極地和上下游的開源專案進行深度合作，建設了一整套微服務開源供應鏈的合作體系，搭建了 CloudWeGo 框架對接各個專案的相關 Demo 和開箱即用的 Example。
3.從考慮未來發展的角度而言，當企業落地了一整套微服務架構之後，可能會存在易用性或效能方面的問題。當出現更好的技術解決和效能提升方案，基於原有架構的耦合和複雜度，很難推進新的架構進行整體的迭代。因此，我們也非常積極地在推進建設雲原生微服務治理的整體標準。希望更多的專案，能夠形成統一的接入和對接的標準，從而在未來的一些新的、更高效能的技術解決方案的遷移和過渡上，能夠讓遷移和使用成本降到最低。
- **CloudWeGo 的開發者活動**
CloudWeGo 專案包括整個社群都對高效能有非常熱烈的追求。因此，我們也在不停地迭代。
CloudWeGo 一直在不斷追求高效能框架以及高效能技術解決最新方案。每次上線新的技術解決方案和一些相關能力之後，我們都期望讓更多的使用者知道這些方案是怎樣的，讓使用者能夠更便捷地學習到一些相關的技術指南。
因此，我們針對性地設計了 CloudWeGo Study Group 學習計劃，這是為了將一些全新的效能解決方案進行體系化的學習分享，即通過一些類似於從框架入門到核心能力的解讀、再到一些學習路徑的分享以及擴充套件知識的相關介紹對外開放給社群。
我們會提供一份完整的學習資料，降低使用者學習新的技術解決方案的成本，也能夠讓使用者瞭解到自己的學習是否適合其業務場景。在整個學習和使用的過程中，降低最終學習的時長，通過體系化的學習更快地理解技術方案的效能亮點和需要學習的相關點。
### **2.2.4 小結**
CloudWeGo 開源社群堅持的長期主義：
## **2.3 CloudWeGo 的使用者**
基於開源社群長期主義的堅持，CloudWeGo 自 2021 年 9 月開源，至今開源 1 年，獲得超過 1w star，支援完成了證券、電商、中臺、社交、遊戲、AI 等行業企業客戶的落地使用。
## **2.4 CloudWeGo 的貢獻者**
在活躍的社群氛圍下，我們收穫了從最初剛開源只有 20 個內部貢獻者，到現在已經有了超過 200 個程式碼貢獻者。這些貢獻者在深度使用了 CloudWeGo 開源專案之後，也為 CloudWeGo 開源專案貢獻了大量生態方面相關對接能力。
**2.4.1 貢獻者體系更新**
基於越來越多的貢獻者在我們的開源社群裡做了大量深度貢獻，CloudWeGo 開源社群在一週年的週年慶之際，推出**全新的貢獻者激勵體系**。
我們新增開放了三個角色體系，希望通過這種完善的角色機制，賦予社群開發者更多的社群治理許可權。同時我們也鼓勵更多的貢獻者能夠成為專案的維護者，希望長期的維護者能夠真正帶領我們的專案持續進行高效能的優化和相關的演進。
**2.4.2 貢獻者多樣化**
在開源專案的運營和維護中，包括開源社群的建設，不僅僅是依賴程式碼貢獻者的參與，還有很多其他方面的貢獻，其中包括企業支援場景的貢獻、佈道活動的貢獻、整體活動組織的貢獻等多元參與。這些貢獻者在 CloudWeGo 社群也是被大力支援的，因此我們專門針對多元貢獻上線了 CloudWeGo 年度激勵計劃。
社群在 8 月份剛剛完成了 2021 - 2022 年度 CloudWeGo Awesome Contributor 的評選，我們非常榮幸地收穫了 84 位年度優秀貢獻者。在完成了社群的提名與公示後，這些同學已經順利成為了 CloudWeGo 年度優秀貢獻者，之後我們會為這些優秀貢獻者送上 CloudWeGo 一週年的榮譽紀念徽章。
## **2.5 CloudWeGo 社群遇到的問題**
正是因為社群較高的活躍度以及眾多貢獻者的參與，大量使用者加入了 CloudWeGo 社群。我們逐漸發現使用者的使用場景開始慢慢發生了拓展。從最初可能只是想了解一下微服務的框架、單獨的一個專案如何去落地和使用，到後來慢慢變成探索一整套微服務架構的設計，以及多個專案之間的實踐配合和相關生態能力的建設。
這些其實是非常體系化、大規模的需求，因此我們聯合一些企業使用者進行了相關場景的實踐貢獻。CloudWeGo 之前支援了包括證券、電商、AI 和各個行業使用者場景落地，我們也和這些企業使用者進行了相關場景的梳理。
## **2.6 CloudWeGo 的企業使用者貢獻**
### **2.6.1 華興證券**
案例連結：http://www.cloudwego.io/zh/cooperation/huaxingsec/
華興證券的張天老師團隊向社群貢獻了來自證券行業使用 Kitex 完成混合雲部署下跨機房使用場景的案例。
我們在跟張天老師團隊合作的時候發現，他們遇到的最大的問題是有的業務部署在金融雲機房上，有的業務部署在私有機房上，所以存在跨機房呼叫的問題。因為他們使用 K8s 叢集，還會出現同叢集呼叫和跨叢集呼叫的問題。整個呼叫的鏈路非常長，這中間就會出現很多不可觀測的問題，當出現問題的時候，排查難度就極其大。
於是張天老師團隊在和 CloudWeGo 合作之後，整體搭建了一個 **Kitex** **+** **K8s** 的可觀測性系統，也將相關的搭建實踐貢獻到了開源社群。感興趣的同學可以通過 CloudWeGo 公眾號檢視相關的企業案例和最終的實踐場景。
### **2.6.2 森馬**
案例連結：http://www.cloudwego.io/zh/cooperation/semir/
CloudWeGo 和森馬共同梳理了與電商行業相關的一個整體使用場景。非常感謝森馬團隊，貢獻了電商行業使用 Kitex 接入 Istio，以提高對高併發訂單處理能力的使用場景。
森馬團隊還貢獻了基於微服務架構的兩種模式，為有相關高效能業務需求的使用者提供了**服務網格** **+** **Kitex** 治理模式相關的選型依據，並且給出了相關的壓測報告，也給社群有相同需求的小夥伴提供重要參考。
### **2.6.3 飛書**
案例連結：http://www.cloudwego.io/zh/cooperation/feishu/
Hertz 開源後，很多使用者會問到內部閘道器平臺架構的設計思路，包括內部閘道器平臺如何配合 Hertz 整體使用？
飛書之前是一個 all-in-one 的套件開發模式，各個業務團隊會將業務程式碼提交到飛書閘道器平臺的程式碼倉裡面，由飛書閘道器相關的同學來做 web 邏輯的開發。這就導致他們所有的服務都是融在一起的，沒有辦法做到釋出隔離，極大地阻礙了閘道器平臺架構的演進和迭代速度。
因此，飛書團隊將前端 Node 單體服務做了微前端架構拆分，配合 Kitex 泛化呼叫各個業務的微服務，實現了各個業務釋出完全隔離，這使得他們不再依賴閘道器平臺的業務開發，進而加快了整個閘道器業務迭代的速度。
## **2.7 來自社群的使用者具體問題**
我們非常感謝企業使用者貢獻的相關問題，CloudWeGo 配合企業使用者的場景案例也獲得了社群使用者的眾多好評。與此同時，有更多的使用者也提出了新的問題，這些問題非常具體。
通過總結髮現，這些問題具有顯著的業務特異性。我們也很好奇這些使用者在內部到底是如何搭建其微服務體系的？
因此我們開始梳理 CloudWeGo 開源社群的雲原生微服務使用者畫像。
# **3. 新一代 雲原生 微服務 使用者畫像**
我們將社群的使用者大概分成了三種類型：
- 位元組跳動
位元組跳動是我們目前最大的使用者。位元組跳動的線上微服務數量已經超過了 10 萬，服務端峰值 QPS 已經達到了數億的級別，業務複雜性非常大，存在跨語言、跨平臺、跨終端、跨叢集、跨機房等多種複雜的問題。
同時位元組跳動內部有非常完善的微服務架構體系，整體的微服務治理已經全面邁入了 2.0 的時代，用微服務框架配合服務網格攜手並進。
在這個場景之下，位元組跳動最大的需求就是高效能和可擴充套件性，這也是 CloudWeGo 作為位元組跳動內部孵化的一個優秀的高效能技術解決方案最初開源時所具有的特性。
- 處於轉型期的使用者
社群裡數量最大的群體，這些使用者可能是電商的、證券的、後臺的以及一些創業公司，他們的節點數量不是特別多，可能在 5-1000 以內，線上微服務數量處於 5000 以內的水平，但這些使用者可能本身就是雲原生架構，或者已經在往這方面做一些相關的遷移。
這類使用者在 CloudWeGo 開源社群的訴求，主要是針對業務的特異性方面存在高效能相關的需求。
- 非雲原生架構企業使用者
這一類使用者屬於非雲原生架構的企業，他們的服務可能還沒有完全雲化，具有一定的歷史遷移負擔。這類使用者著重會優先考慮如何將自己的服務遷移上雲。
因此可以看到，第二類使用者是目前社群數量最大，且最需求最迫切的一類使用者。
我們認為理想狀態下使用者整個雲原生架構體系的搭建過程：
> - 第一個階段：服務上雲
>
> 類似第三類使用者，當前面臨的問題就是怎麼把自己的業務遷移上雲。
>
> - 第二個階段：雲原生部署
>
> 類似第二類社群大量的使用者，其實已經是雲原生部署的企業，用到了相關容器化和編排排程的技術。
>
> - 第三個階段：微服務架構
>
> 繼續往前演進，開始搭建相關的微服務架構，以及會做服務的拆分和通訊的治理。
>
> - 第四個階段：微服務治理
>
> 當用戶在線上有了一定數量的微服務之後，會開始出現依賴管理和一致性保障的問題。
但是我們在跟使用者溝通過程中發現，這其實不是一種絕對意義上的區分。
因為很多公司其實並不是完全屬於其中一種狀態，而是一種長久的中間態，公司的業務會處於不同的狀態。同時，我們在和相關使用者進行深度的溝通時，發現這些業務場景其實並不是完全不可複製的，而是具有一定的行業聚合性和相似性。
於是，我們開始探索如何通過社群更好地幫助這些開發者解決痛點問題，這也正是 CloudWeGo 開源社群接下來整體的演進方向。
# **4. 持續演進的 CloudWeGo 開源社群**
CloudWeGo 1.0 社群搭建的主要方向，是將位元組跳動內部孵化的高效能框架解決方案觸達給更多的使用者，讓更多對高效能解決方案有需求的使用者能夠真正地在內部落地和使用這些方案。
當我們發現使用者出現特異性的行業需求後，ClouWeGo 2.0 希望社群建設以開發者服務為主，能真正地幫助到社群的開發者，解決其在微服務治理過程中遇到的一些真實存在的問題。
- 行業解決方案
通過使用者問題、場景和解決方案的行業共建，形成社群的 Go 雲原生微服務最佳實踐，希望能夠針對有特異性需求的使用者給到一定的參考。
- 易用性建設
我們會持續和開源鏈條的上下游深入合作，建設雲原生微服務相關的標準治理。致力於後續易用性的建設，希望能夠給到成本更低的遷移，以及建立後期維護的治理標準。
- 持續投資高效能方案
繼續維持 CloudWeGo 開源社群的長期主義。我們會深入投入對高效能解決方案的持續探索，也會在 Rust 領域持續開展相關生態和開源的建設，共建 Rust 中國的開源生態。
基於此，引出 CloudWeGo 開源社群 2.0：
CloudWeGo 2.0 的階段，我們希望社群能夠跨越專案邊界，真正能夠幫助社群使用者搭建一套高效能的微服務治理架構和整體的微服務治理體系：
- 通過 Go 領域相關微服務治理的標準和最佳實踐的建設，為一些通用性技術和行業最佳實踐提供參考；
- 對接開源專案上下游進行深度合作，極大地提升整個專案的易用性；
- 推進高效能 Rust 解決方案的落地，持續探索 Rust 高效能技術解決方案，構建 Rust 相關生態。
如果大家對 CloudWeGo 開源社群，以及剛才提到的一些技術解決方案、企業的落地支援有任何的疑問，可以關注 CloudWeGo 公眾號，我們會在公眾號上釋出一些新聞動態以及各個相關場景的案例報道，同時我們也會在公眾號上提供相關的技術支援。感謝大家的關注！
# **5. Q & A**
**Q1：第一次瞭解到** **CloudWeGo** **，想請問一下 CloudWeGo 有技術社群嗎？怎麼樣能快速地加入到技術社群？如何快速地獲取到這個專案的官方文件？**
A：對於初步瞭解 CloudWeGo 提供兩種可行方案：
1. 認準 CloudWeGo 官網（http://www.cloudwego.io/），我們會在官網上線非常完整的文件體系。所有的更新專案，包括技術文件都會在官網上同步更新。
2. 關注 CloudWeGo 公眾號，我們會在公眾號上持續釋出最新的 CloudWeGo 技術分享以及相關活動，幫助引導使用者獲取最新動態並加入技術社群。
**Q2：作為一個新手，怎麼樣能夠比較快速地參與到** **CloudWeGo** **開源社群，有沒有比較好的一些方式推薦？**
A：總結的一些通用路徑如下：
1. 明確自身目的。清楚自己參與開源社群的核心目標是什麼，為了學習專案還是為了快速地根據自己的業務去搭建和落地使用。
2. 跟隨社群提供的學習指南和路徑，藉助社群給到的一些資源。比如 CloudWeGo 開源社群，我們會有相關的 CSG 活動，就是 study group 的活動形式，在這裡可以體系化地瞭解一整套的技術解決方案，從小的模組再到大的全場景的落地。
3. 瞭解專案，從區域性走向全域性。社群提供的新手 issue 和任務，比如一些 First Good Issue，通過這些 issue 的開發及解決，能夠快速地加入到開源社群。
4. 在開源社群裡通過自己的深度使用，進行相關的貢獻。
以上，是參與開源社群的一個比較通用的路徑。CloudWeGo 公眾號中也有我們社群的 Contributor 詳細地分享過關於參與開源社群的往期文章，全面介紹如何從一個新手到深度參與開源社群的相關內容。
**Q3：請問不同專案是如何去匹配不同的社群發展模型的呢？**
A：首先明確兩個思考問題：
1. 社群運營對整個專案的價值是什麼？
最初大部分的開源專案，只關注相關的技術佈道，使用者看到適合的專案就進行技術的學習並在企業內部落地，這一階段的社群運營會基於整個社群的生長階段設定相關的發展模型。但是這種方式，存在社群和專案之間脫節的問題。比如，原有專案技術方案的更新推廣到社群不具備連續性，對使用者缺乏體系化的內容輸出，使用者在社群所獲取的內容和專案的演進階段是有一定差異的。
2. 開源社群對整個專案的價值是什麼？
這裡存在一個視角：要把整個開源專案當做是一個產品來運營。比如 CloudWeGo 開源專案，我們有各個框架的技術負責人，核心負責各部分相關的技術問題，但是專案中有非常多的使用者存在場景的特異性問題以及整個專案的使用體驗問題等，這些問題由誰來去解決？
綜上，可以明確整個開源社群最終的目標，其實就是維護專案並幫助解決使用者所產生的相關問題。一旦明確目標，就會根據專案不同的發展階段以及專案當前演進中使用者產生的相關疑問，去匹配專案的未來發展規劃。
比如，CloudWeGo 專案一直都是在高效能方面做了相關的演進，我們的使用者其實也都是基於一些高效能的業務特異性需求來到了 CloudWeGo 社群。當我們和社群的使用者進行了相對深度的溝通之後，我們也發現基於行業特性、體系的特異性、或者和位元組跳動內部技術方案的差異性，直接提供的技術方案是沒有辦法適配落地的。因此，我們就通過社群的一些支援，幫助使用者在其內部真正落地高效能的技術解決方案。
因此，優先明確社群對專案的核心價值，瞭解使用者的核心需求，在把握整個專案的演進節奏之後，根據專案的階段以及發展目標，再去匹配相應的運營手段和運營的發展模型得以推動社群的發展。
# **6. 位元組跳動 CloudWeGo 團隊**
CloudWeGo 是一套由位元組跳動開源的、可快速構建企業級雲原生微服務架構的中介軟體集合。它包含許多元件：Golang RPC 框架 Kitex，HTTP 框架 Hertz，Rust RPC 框架 Volo，網路庫 Netpoll，Go 語言 Thrift 編譯器 Thriftgo 等等。通過結合社群優秀的開源產品和生態，可以快速搭建一套完善的雲原生微服務體系。專案共同的特點是高效能、高擴充套件性、高可靠，專注於微服務通訊與治理。CloudWeGo 專案自 2021 年 9 月開源，至今開源 1 年，獲得 1w+ star，程式碼貢獻者人數已有 140+，年度 Awesome Contributor 提名 84 位。更多生態能力對接，請參考 kitex-contrib 和 hertz-contrib。
以上內容整理自第七期位元組跳動技術沙龍《位元組高效能開源微服務框架：CloudWeGo》，獲取講師 PPT 和回放視訊，請在公眾號“位元組跳動技術團隊”後臺回覆關鍵詞“0827”。