本文整理自51CTO開源基礎軟體學習季的直播公開課《位元組跳動的開源實踐與思考》
像很多公司一樣，位元組跳動接觸開源也有一個從 0 到 1、由淺入深的過程，大體經曆三個階段：
第一階段，使用開源。 為了推動業務更快發展，如果已經有比較好的、比較成熟的開源技術和工具，我們拿過來使用。
其實在位元組跳動業務發展的早期，在我們剛剛建構我們自身的技術中台和基礎架構的時候，我們就大量采用了公有雲，并且在公有雲之上廣泛采用相關的開源技術和開源中間件，來快速打造我們自身的技術中台。技術中台也推動了位元組跳動包括抖音、頭條等業務的發展。
第二階段，參與開源。随着我們開源用得越來越深，在自身業務場景下，我們還會做很多的創新，包括對原有的開源項目會做技術的優化。第二個階段我們也會把我們所産生成果反哺到社群裡，與社群同學一起進行經驗共享。
第三階段，主動開源。 當這樣的積累、經驗優化多了以後，甚至我們會形成自己的完整項目。這就到了第三個階段，我們會開源一些完整的、體系化的項目回饋到社群。
講到主動開源，我這裡也做了一個統計。大概從 2015 年我們開源 Rcproxy 項目開始，我們一直就在開源的層面不斷地去提出我們自己的開源項目。
這幾年大家從統計資料可以看到，我們總共開源了超過 100 個項目，當然這些項目我們也做了嚴格的分類。
比如正常項目，所謂正常項目就是端對端提供一個完整的場景化解決方案，或者是提供一個完整的功能閉環，這是我們的主體項目。
除了正常項目以外，我們也會輔助地去開源一些相關的 demo、CLI 或者 SDK 工具，這些是輔助的開源項目。
隻看正常項目的話，過去位元組跳動開源了超過 50 個主動開源項目，其中代表項目有前端的 Web 架構 Modern.js，雲原生領域的中間件集合 CloudWeGo，以及在機器學習領域開源的高性能分布式訓練架構 BytePS、聯邦學習平台 FedLearner。
如果從數量上看，正常項目裡排名第一的是基礎架構相關的開源項目，除此以外，是和 AI、算法與平台相關的開源項目，以及和前端、音視訊相關的開源項目。
1.開源委員會的責任和工作範疇
從 2015 年到現在，絕大多數開源項目由我們工程師的個人興趣驅動。
這雖然打造了一種很好的開源文化，但過程中其實也遇到了一些問題，比如規範性問題，比如前一段時間引發的所謂抄襲風波。
這使我們意識到，開源僅僅靠工程師的個人興趣驅動是不夠的，還需要引入公司級的政策、規範與流程機制，這也是位元組跳動開源委員會首先要做的工作。
此外，當公司越來越大，工程師投身開源的時候，需要合理配置設定精力和資源到更重要的戰略型項目上，這也是我們成立開源委員會的另外一個初衷。
當然，開源委員會還要推進各個公司、組織、社群在開源領域建立更好的合作關系。
從确定要成立開源委員會到開源委員會正式成立，期間我們用了半年左右時間來完成前期準備工作。
開源委員會成立以後，我們面臨的第一個問題是什麼樣的項目适合開源？
我們的标準是：
- 具備普适性
- 為開發者提供便利
- 助力社群/行業形成統一标準
- 具備技術領先優勢，不重造輪子，避免 KPI 工程
項目開源出去以後，我們也參考 CNCF、雲原生技術委員會對項目的分級機制，把項目分成了不同級别。
基于這樣的一些項目分級機制以後，下一個問題就是，什麼樣的項目能夠更加順暢地進入到成熟階段，獲得公司更多的資源以及以更高的優先級去進行開源？
我們的标準是：
- 技術領域中沒有形成事實标準，能夠填補局部空白
- 開源技術可覆寫的開發者基數大，具有普适性
- 位元組跳動在該技術領域有優勢，能推動領域技術發展
- 不與公司業務發生沖突
- 能夠推動自身業務發展、提升技術影響力
依據這些标準，當決定一個項目是否應該開源後，我們還要保證這個開源的項目能夠成功。
針對成功與否，我們就需要有一套所謂的價值觀或者價值體系來衡量。
這裡我列舉了幾個我們的思考：
- 首先，一個開源項目不應該去設立短期 KPI，這樣容易本末倒置，容易讓大家動作變形。是以我們更多的會定一些更加長期的北極星名額，這個北極星名額就會更多的圍繞我們前面說的幾個價值點來進行衡量。
- 第二，我們更追求去打造有價值的精品項目，這個優先級要高于做項目的廣泛覆寫。
- 第三，我們認為通過一個開源技術去創造使用者價值，它的優先級要高于實作短期商業變現。
- 第四，安全和合規是我們的底線。
講完這些以後，我會分享三個具體的開源項目，希望結合這些具體的項目，能夠把我們前面提到的一些理念具象化。
2. CloudWeGo：聚焦微服務通信與治理
今天第一個要分享的開源項目叫做 CloudWeGo，它是一個微服務中間件的集合。
CloudWeGo 其實是一套企業級雲原生架構的中間件集合，幫助企業快速地搭建自己的微服務系統。
CloudWeGo 也是由位元組跳動基礎架構團隊開源出來的項目，專注于微服務通信與治理，具有高性能、可擴充、高可靠、易用性等幾個顯著特點。
CloudWeGo 裡面的項目都是在位元組内部經過大規模落地實踐驗證的，開源後每個功能的疊代也都是第一時間在内部使用驗證過的，是一個真正的企業級落地項目，開源使用者和位元組跳動内部業務使用的是同一套服務架構。
其次，CloudWeGo 提供的功能，尤其是協定支援和服務治理，都是能解決真實業務痛點的，每一行代碼優化都能實實在在地提升使用者服務的性能。
最後，CloudWeGo 的研發也借鑒了一些知名開源項目的設計思路，同時也依賴一些開源項目的實作，項目開源出來既是為了回報開源社群，也是為了進一步豐富開源社群的生态。
CloudWeGo 在第一階段開源了四個項目，包括：
- Kitex
- Netpoll
- Thriftgo
- Netpoll-http2
發展到今天，CloudWeGo 在 GitHub 社群裡，Kitex 已經有超過 4.3K 的 star，Netpoll 今天也有超過 2.6K 的 star。
目前 CloudWeGo-Kitex 已經支援接入阿裡雲的雲服務引擎 MSE、應用實時監控服務 ARMS，還有騰訊雲的微服務引擎 TSE。此外，服務治理等高階的能力也在對接中。
前面我們也提到，位元組跳動也提供了火山引擎這麼一個企業服務的産品集合，CloudWeGo 項目目前也在和火山引擎的相關産品做內建，完成後相關産品和能力也将陸續地對大家開放，友善開源使用者快速上雲。
CloudWeGo 非常注重社群文化和社群建設，具有完善的成員晉升機制，同時也積極培養社群開發者作為社群的核心力量。
截止到目前，CloudWeGo 已經先後培養了五位 Committer，他們給社群的發展也做出了重要的貢獻，在此感謝這些開源貢獻者。
同時，我們也非常歡迎有更多志同道合的朋友可以參與到社群的建設中來，為社群的發展建言獻策、貢獻自己的力量。
3. Elkeid：更适合雲原生時代
下面我再分享另外一個也是非常重要的領域——安全領域的開源項目實踐，這個開源項目叫做 Elkeid，意思是瑤光/破軍，也是北鬥七星之一，它解決的問題就是主機安全。
Elkeid 是由位元組跳動内部安全與風控團隊自研的一個新的主機安全解決方案，它具備幾個鮮明的特點。
一個就是規模大，能夠支撐位元組跳動内部百萬級的伺服器數量。當然講到這塊，也稍微劇透一下位元組跳動内部的伺服器規模。
另外一個特點，就是 Elkeid 采用了我們核心态的技術進行大多數名額和資訊的收集。
這樣一方面可以極大地提升性能，另一方面也可以去采集更多更豐富的資料，進而大大增強我們的檢測能力。
上圖是整個 Elkeid 的技術架構，這樣一個架構提供了若幹個好處：
- 首先，我們實作了端上去做采集，但是在後端去做分析，進而降低在端上原地的計算壓力。
- 其次，後端所有的元件都可以支援高可用，進而可以支援我們剛才說的百萬級别規模的接入。
- 除此以外，整體的依賴少，維護成本低。
- 最後，二次開發友好，每一個主機上的 Agent 都支援不同的插件，進而實作一些定制化的能力。
我們為什麼要去開源這麼一個項目呢？其實最早我們也是基于一些已有的主流主機安全方案來提升我們自身的業務系統的安全性。
但是随着我們業務體量、規模和需求不斷地增多，我們也逐漸看到傳統的方案在應對我們的場景之下越來越暴露出了瓶頸。
随後，基于我們前面所提到的核心态的這麼一個開源主機方案，我們自研了 Elkeid，并且為行業裡面去證明了該方案的可行性和價值。
進一步随着混合雲和雲原生發展的越來越快，傳統的主機方案也很難适應新的容器化和雲原生化的這樣一種新的應用形态。
當我們看到這樣一個趨勢以後，我們也希望能夠把自研的 Elkeid 開源出來，和領域去進行共建，能夠借助更多的力量，我們去涵蓋更多的場景，去開發更多的政策，進而提升整個我們項目的有效性。
4. ByteHouse：賦能下一代技術架構
今天最後一個案例，是一個非常重要的領域，資料倉庫、資料分析。在這個領域會跟大家介紹我們從開源演化出來的一個技術，叫做 ByteHouse。
從 2019 年之後，位元組跳動開始廣泛使用 ClickHouse。目前，ClickHouse 在位元組跳動内部的總節點數已經超過了 1.5 萬個，管理的資料總量也達到了 600PB 之多，每日查詢的請求也有超過上億次，它的應用場景也非常多。
ClickHouse 本身有很多的優勢，如果總結下來就是多快好省。當然，ClickHouse 本身也有不适合的場景。
比如說對于 KV 的支援，對于 Blog 或者文檔存儲的支援，或者在查詢中如果使用大量的 Drive，也不能夠支援得特别好。
當然除了這些局限以外，随着位元組跳動深度使用，在第二階段我們也開始遇到了一些問題，很多問題的根源其實都是來自于 ClickHouse 的架構。
随着我們業務的發展和擴張，ClickHouse 叢集的算力會逐漸成為瓶頸，這時候我們就要對叢集進行擴容。
但是一旦我們進行擴容，資料其實也要相應的去進行移動，去做所謂的重新平衡。
但是在重新平衡的過程中，我們又有很多其他的開銷，有很多運維的準備工作。
包括我們要去應對資料丢失的風險，要保證原資料的一緻性和正确性。是以這樣也會導緻我們錯失了很多去進行叢集擴充的最佳時間。
基于 ClickHouse 這些問題，在第三個階段，我們就開始進行對應的技術優化。
最主要的一個技術優化點，就是我們使用了計算和存儲分離的架構，我們也管它叫做分解式的基礎架構。
大家如果看下邊架構圖就可以看得比較清楚：
原來在一台的節點之上，我們既做存儲又做計算，但是在我們的分解式的基礎架構或者存算分離的架構裡，我們會提供一個通用存儲層。
計算層可以自由地去進行靈活的彈性伸縮，這個時候當我們需要更多算力的時候，我們隻需要添加更多的計算節點，如果我們需要更多的存儲空間，我們就可以擴充存儲層所需要的容量。
當然，彈性的伸縮還帶來了無盡的擴充性，因為資料是在存儲層中共享的，是以理論上我們可以橫向地擴充，以盡可能的利用更多的計算資源。這樣最終帶來一個好處，就是對于叢集管理者來講也更加友好。
當然這個新架構也會帶來一些挑戰，我們也設計了對應的解決方案。比如我們能想到的就是性能，共享存儲的架構是否會引發一些性能的妥協。
當進行 ByteHouse 研發的時候，我們會通過增加資料的緩存層來彌補遠端讀寫的性能損耗。
第二個挑戰就是 ByteHouse 引擎在讀寫分離的架構下，資料存儲的系統我們希望可以适配使用不同的場景和不同的實作方案。
比如說如果是做本地存儲，我們就會适配 HDFS，原始資料檔案就不需要做大量的遷移。當我們部署在不同的公有雲的時候，我們也希望能夠快速地适配不同的雲存儲。
是以，在整個的實體存儲系統之下，我們就需要建構一個抽象層，這一層我們内部管它叫 VFS，Virtual Filesystem，就是虛拟檔案系統，來提供面向不同存儲系統的通路接口。這是第三個階段，我們做了一系列的技術優化。
到了第四階段，當我們實作了一些自身的業務優化或者是功能創新的時候，我們也希望能夠反哺社群。
ByteHouse 作為基于容器化和雲時代的一個計算引擎，一個很大的亮點就是架構上實作了計算和存儲的分離，允許兩者去做獨立的擴充和彈性的伸縮。
同時，我們可以友善使用者根據不同的業務工作負載特點，來實作實時的計算和存儲的資源配比，來達到最高的 TCO。
基于這樣的一些架構的設計和技術創新，我們開始不斷地把 ByteHouse 再進行産品化，并且把它定位成一站式輕量的雲數倉。
除了 ByteHouse 以外，周邊我們也補充了大量的工具和能力，來友善開發者更好的使用這項技術，包括獲得多種資料源的導入，包括提高查詢的這種可觀測的能力和診斷能力，以及在多租戶下去進行資料權限的多級管控等等。