字節跳動如何從0到1打造一個開源項目？
像很多公司一樣，字節跳動接觸開源也有一個從 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 以外，周邊我們也補充了大量的工具和能力，來方便開發者更好的使用這項技術，包括獲得多種數據源的導入，包括提高查詢的這種可觀測的能力和診斷能力，以及在多租戶下去進行數據權限的多級管控等等。?
