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