作者 | 火山引擎云原生平臺負(fù)責(zé)人 沈健
2022 年，火山引擎聯(lián)合咨詢機構(gòu) IDC 對超過 4500 個云消耗大于 100 萬的企業(yè)進(jìn)行調(diào)研，發(fā)現(xiàn)使用多云架構(gòu)的企業(yè)占比達(dá)到 88%，達(dá)到歷史新高。另據(jù)麥肯錫的報告，到 2025 年，依然會有 42% 的企業(yè)保留有私有云。在負(fù)載分布層面，邊緣云占比在逐步上升，根據(jù) IDC 報告，25 年超過 30% 的數(shù)據(jù)需要邊緣實時處理。
造成這些現(xiàn)象背后的原因是復(fù)雜的，既有業(yè)務(wù)形態(tài)和成本管控的原因，也有數(shù)據(jù)安全和監(jiān)管要求的考慮。對于企業(yè)來說，隨著云上遷移的業(yè)務(wù)變多、復(fù)雜度變高，分布式云也成為各類組織必須迎接的挑戰(zhàn)。如何做好多云策略，如何平衡好負(fù)載，如何保障安全，只有構(gòu)建好適合自身的分布式云架構(gòu)，才能真正做到“用好云”。
在 7 月舉辦的 ArchSummit 全球架構(gòu)師峰會上，火山引擎云原生平臺負(fù)責(zé)人沈健圍繞“字節(jié)跳動的多云實踐之路”為主題進(jìn)行了分享，介紹了字節(jié)跳動實行多云云原生戰(zhàn)略的原因、過程和最終成果。
業(yè)務(wù)需求驅(qū)動多云架構(gòu)建設(shè)
云服務(wù)經(jīng)過十幾年的演進(jìn)，如今在企業(yè)的應(yīng)用已經(jīng)發(fā)展出了多云、混合云、分布式云、邊緣云、行業(yè)云等多種形態(tài)。面對業(yè)界層出不窮的新概念，很多人會困擾：它們的區(qū)別是什么？
在云服務(wù)商眼中，按照中國信通院發(fā)布的定義，所謂分布式云，是一種將云服務(wù)按需部署到不同地理位置，提供統(tǒng)一管理能力的云計算模式。它摒棄了公有云、私有云、混合云、多云等分類，首次將地理位置作為考量因素，為用戶提供不同位置的云資源統(tǒng)一管理平面，能夠增強混合多云一致性管理、拓展邊緣計算服務(wù)能力、實現(xiàn)云服務(wù)統(tǒng)一托管治理。
但對于真正意義上需要用云的企業(yè)，不同云形態(tài)的含義則更加場景化：業(yè)務(wù)本身需要什么樣的云，開發(fā)團隊有能力用好什么形態(tài)的云，企業(yè)運維團隊的云管理能力成熟度發(fā)展到了什么階段……雖然大家都在談云，但關(guān)注點是全然不同的。
字節(jié)跳動在發(fā)展過程中，也慢慢發(fā)展成了多云的狀態(tài)：無論是中心云、私有云、邊緣云，它們都是多云的一種形態(tài)，分布式云則是多云之上更高層次的一個形態(tài)。這種變化是和業(yè)務(wù)發(fā)展密切相關(guān)的：
2017-2018 年，抖音經(jīng)歷快速發(fā)展，DAU 增長破億。在這種場景下，由于單朵公有云、私有云的資源供給都存在時間周期，技術(shù)團隊很難預(yù)估全年具體需要多少資源量，靈活從其他云廠商補充云資源成了一個必要的解決方案。
視頻直播業(yè)務(wù)盛行期間，為了更好地保障直播效果，技術(shù)團隊需要采購對直播網(wǎng)絡(luò)較友好的云資源——它們往往是地域性的、邊緣性的，在業(yè)務(wù)驅(qū)動下，區(qū)域云、邊緣云也進(jìn)入了字節(jié)跳動的云計算資源池。
早期業(yè)務(wù)出海期間，建設(shè)自主數(shù)據(jù)中心會給新業(yè)務(wù)帶來巨大的成本壓力，再加上各國不同的數(shù)據(jù)安全合規(guī)要求，在拓展海外業(yè)務(wù)的時候，我們也基本上都使用了海外的云資源。
隨著業(yè)務(wù)持續(xù)增長，出于成本、安全、信創(chuàng)的考慮，避免廠商綁定的重要性也日益凸顯。長期使用單一供應(yīng)商會存在云產(chǎn)品漲價、服務(wù)質(zhì)量下降、技術(shù)架構(gòu)不夠靈活等風(fēng)險，考慮到?jīng)]有一朵云是 100% 無故障的，技術(shù)團隊也更愿意選用更多的云供應(yīng)商提供服務(wù)。
由于上述問題的存在，字節(jié)跳動的技術(shù)團隊堅定地選擇了多云作為基礎(chǔ)架構(gòu)發(fā)展的主要路徑。當(dāng)然，這也帶來了一些實踐層面的挑戰(zhàn)：
部署 / 運維復(fù)雜度：應(yīng)用 / 服務(wù)多云部署方式，容器、主機、云上服務(wù)等不同類型的部署方式都額外增加了部署和運維的難度
打通 / 互操作性：網(wǎng)絡(luò)打通、身份 / 權(quán)限打通、運維打通、數(shù)據(jù)訪問打通、流量管理
數(shù)據(jù)管理 / 合規(guī)難度：數(shù)據(jù)離散分布之后數(shù)據(jù)資產(chǎn)的管理難度加大，數(shù)據(jù)合規(guī)挑戰(zhàn)加大、數(shù)據(jù)泄漏風(fēng)險和追蹤難度加大
成本控制復(fù)雜度：業(yè)務(wù)、成本、資產(chǎn)的管理難度
字節(jié)跳動的多云實踐
在業(yè)務(wù)發(fā)展驅(qū)動下，字節(jié)跳動的多云實踐在不同時期有不同的側(cè)重點，驅(qū)動著云原生架構(gòu)的逐步發(fā)展：
2016 年，今日頭條等業(yè)務(wù)快速發(fā)展，字節(jié)跳動基礎(chǔ)架構(gòu)團隊啟動 TCE（Toutiao Cloud Engine）平臺建設(shè)，用一個統(tǒng)一的云平臺管理之前業(yè)務(wù)中臺各自維護(hù)的資源池，解決了應(yīng)用的快速部署問題和管理問題。
2017 年，隨著外部競爭態(tài)勢的復(fù)雜化，快速迭代、快速推出新功能變得迫切，我們開始引入微服務(wù)架構(gòu)，通過微服務(wù)的靈活性和服務(wù)網(wǎng)格的統(tǒng)一治理能力，提供多樣性適配，讓每個技術(shù)人員都能快速投入到業(yè)務(wù)發(fā)展中去。
2019 年，抖音、今日頭條等業(yè)務(wù)達(dá)到較大規(guī)模，頻繁的營銷活動要求底層有海量云資源供應(yīng)，在這一階段，基礎(chǔ)架構(gòu)大力推進(jìn)了“推廣搜”的云原生化，把物理機服務(wù)與在線服務(wù)進(jìn)行全面融合，實現(xiàn)統(tǒng)一容器化調(diào)度。
2020 年，為進(jìn)一步控制資源使用成本，技術(shù)團隊實現(xiàn)了常態(tài)化在離線混部，在面對高峰流量時能夠快速進(jìn)行資源出讓，保障業(yè)務(wù)穩(wěn)定性。同時，數(shù)據(jù)庫、緩存等存儲系統(tǒng)也開始進(jìn)行云原生化改造，加速了更大范圍資源池的統(tǒng)管和融合。
從上述演進(jìn)不難看出，云原生架構(gòu)這些年要解決的難題之一就是巨大的資源缺口。大量資源短缺會不可避免地導(dǎo)致“集群建設(shè) — 應(yīng)用搬遷 — 騰挪資源”，進(jìn)而帶來不小的運維成本和穩(wěn)定性問題。
為了解決這一問題，早在 2019 年，我們就開始進(jìn)行集群聯(lián)邦建設(shè)，通過解耦應(yīng)用和集群的綁定關(guān)系，將各個業(yè)務(wù)線的資源并池，以應(yīng)對分布式云帶來的挑戰(zhàn)。到 2021 年，字節(jié)跳動正式實現(xiàn)了全場景應(yīng)用編排和資源管理的標(biāo)準(zhǔn)化和統(tǒng)一化，目前聯(lián)邦集群已管理近 50 萬節(jié)點，即便面對超過 10 萬的微服務(wù)數(shù)、每天 3 萬多次的變更數(shù)，也能為業(yè)務(wù)提供持續(xù)、穩(wěn)定的保障。
多云下的海量算力實踐
如今再看字節(jié)跳動的底層算力平臺，它可以被分為分布式云原生平臺和計算平臺體系兩部分。
其中分布式云原生平臺匯集所有公有云集群、IDC 集群和匯聚集群（區(qū)域性 / 邊緣集群），由 開源編排引擎 KubeAdmiral 統(tǒng)一管理。通過分布式的集群編排，在不采取任何其他措施的情況下，字節(jié)跳動的常態(tài)運維水位可以從 85%-90% 提高到 95%，資源利用率提升非常顯著。
為了緩解運維復(fù)雜度問題，技術(shù)團隊也開發(fā)了一個基于分布式編排引擎的統(tǒng)一調(diào)度器 Godel。這是一個融合調(diào)度器，能管理在離線資源，調(diào)度在離線任務(wù)，同時它也針對大規(guī)模場景進(jìn)行了很多性能上的優(yōu)化。
資源管控系統(tǒng) Katalyst 采用 Kube.NETes Native 的方式進(jìn)行重構(gòu)，能提供更強的資源管理能力、調(diào)度能力、抽象能力和數(shù)據(jù)能力。通過這些能力，技術(shù)團隊可以更好地按級劃分應(yīng)用使用的資源，實施精細(xì)化的資源出讓策略、多維度的資源隔離能力、多層級的負(fù)載驅(qū)逐策略，讓整體混部變得更健壯。
在這些核心中間件之上，是持續(xù)交付、服務(wù)網(wǎng)格、應(yīng)用引擎等服務(wù)，這些服務(wù)可以識別資源在哪個部門、哪條業(yè)務(wù)線使用，再通過流量分發(fā)引擎調(diào)度，實現(xiàn)全局性的資源和流量管理。
計算平臺體系則是針對字節(jié)跳動內(nèi)部存在的海量離線業(yè)務(wù)，這類業(yè)務(wù)存在資源離散的問題：各個云上的存儲、各個機房的 HDFS、各個機器學(xué)習(xí)任務(wù)使用的 NAS……為了進(jìn)行統(tǒng)一管理和使用，技術(shù)團隊推出了大數(shù)據(jù)文件存儲 CloudFS，提供對接多云對象存儲能力，無論用戶在哪里、用戶想訪問的數(shù)據(jù)在哪里，它都能提供本地緩存加速。
離線業(yè)務(wù)存在的第二個問題是大數(shù)據(jù)作業(yè)無法享受云原生的好處：傳統(tǒng)大數(shù)據(jù)引擎不是針對云原生設(shè)計，難以直接云原生部署，各計算引擎和任務(wù)需要進(jìn)行深度改造才能支持原先在 YARN 上的各種特性，改造成本巨大?；诖吮尘?，字節(jié)跳動推出了基于云原生的 YARN 解決方案 —— Serverless YARN，它 100% 兼容 Hadoop YARN 協(xié)議， Hadoop 生態(tài)下的大數(shù)據(jù)作業(yè)無需修改即可透明遷移到云原生系統(tǒng)上，在線資源和離線資源間可以高效靈活轉(zhuǎn)換、分時復(fù)用，集群整體資源利用率得到顯著提升。
在這些系統(tǒng)之上，我們又建設(shè)了一個關(guān)鍵模塊——多數(shù)據(jù)中心離線統(tǒng)一資源湖 ResLake。它作為一個融合了計算 + 存儲 + 網(wǎng)絡(luò)的巨大離線算力湖，方便批計算、流計算、AI 訓(xùn)練等任務(wù)接入，讓技術(shù)團隊可以進(jìn)一步加強跨機房資源管控、加強熱點數(shù)據(jù)治理、提升多集群多隊列用戶體驗、提升多機房資源利用率。按照最新數(shù)據(jù)，在 ResLake 的作用下，技術(shù)團隊實現(xiàn)了超過 1.4 的作業(yè)加速比，隊列跨機房流量優(yōu)化也超過 30%。
降低運維部署復(fù)雜度
對于在線業(yè)務(wù)，分布式云原生平臺就變得至關(guān)重要了。舉個例子，直播業(yè)務(wù)之前在各種云上都開了 Kubernetes 資源，在分布式云原生平臺上線后，新平臺如果需要對這些一開始就游離在外的資源進(jìn)行納管，就必須具備對存量應(yīng)用的無縫接管特性：不僅需要無改造、無運行影響地轉(zhuǎn)移應(yīng)用，也要能連接多基礎(chǔ)設(shè)施 Kubernetes 集群，方便集群接入。
除了資源統(tǒng)一，在應(yīng)用管理方面，分布式云原生平臺也提供靈活的跨云分發(fā)策略，包含集群名稱、標(biāo)簽、污點容忍調(diào)度，以及依賴資源的跟隨分發(fā)。技術(shù)團隊也著重錘煉和打磨了平臺的開源兼容性，使其能完全兼容 Kubernetes 生態(tài)，支持原生 Kubernetes 及 CRD 資源、Helm 等應(yīng)用定義。
在日常運維管理方面，字節(jié)跳動內(nèi)部有一套統(tǒng)一的可觀測體系，提供在離線應(yīng)用的監(jiān)控能力。如前文所述，我們的在離線業(yè)務(wù)是通過各種各樣的中間件被混合在一起的，在這種情況下，我們可以輕松做到統(tǒng)一可觀測，幫助業(yè)務(wù)團隊快速定位問題、解決問題。
除此之外，字節(jié)跳動的分布式云原生平臺也提供統(tǒng)一的應(yīng)用治理。業(yè)務(wù)應(yīng)用的實例可以多云多活的部署在不同云上的 Kubernetes 容器服務(wù)中，通過多集群的應(yīng)用、流量、存儲等的統(tǒng)一治理，實現(xiàn)高可用容災(zāi)，提升整個業(yè)務(wù)系統(tǒng)的故障彈性和可靠性標(biāo)準(zhǔn)。
降低成本之資源利用率
在統(tǒng)一資源底座后，技術(shù)團隊接下來要面對的就是如何長期地提高資源利用率。我們把業(yè)務(wù)負(fù)載按時延容忍度和可重入性進(jìn)行劃分，在下圖的兩個象限中進(jìn)行合理分布：
依據(jù)這樣的分級分類，我們就能判斷各個應(yīng)用對哪些資源相對更敏感，在遇到一些特殊情況時，能夠根據(jù)不同業(yè)務(wù)的優(yōu)先級進(jìn)行有梯度的分級去除，確保高優(yōu)先級、高時延敏感任務(wù)的穩(wěn)定運行。
此外，隔離能力也是非常重要的一個因素。因為計算機系統(tǒng)本身是一個分布式系統(tǒng)，它包含 CPU、硬盤、存儲和網(wǎng)絡(luò)，字節(jié)跳動內(nèi)部也針對這些不同的算力資源采用了一些隔離機制，比如 CPU 會有一些 cache 隔離、系統(tǒng)級的喚醒能力，硬盤方面則實現(xiàn)了 cgroup 級別的內(nèi)存回收，以及通過用戶態(tài)的 advisor 機制實現(xiàn)兜底強殺。
技術(shù)團隊也有嘗試借助一些機器學(xué)習(xí)的能力，使得不同算力能按照不同要求，更精準(zhǔn)有效地去匹配這些隔離機制，從而減輕各業(yè)務(wù)間的干擾影響。
目前，通過這些機制，字節(jié)跳動的混部方案已覆蓋數(shù)十萬機器，天極平均利用率高達(dá) 63%，部分核心業(yè)務(wù)集群也實現(xiàn)了整機天級利用率從 23% 到 60% 的提升。
分布式云的下一階段
回到落地多云給企業(yè)帶來的實踐層面挑戰(zhàn)，除了部署 / 運維復(fù)雜度、打通 / 互操作性和成本控制復(fù)雜度，最后一點就是數(shù)據(jù)管理 / 合規(guī)難度。隨著國際格局愈發(fā)復(fù)雜，多云 / 分布式云也出現(xiàn)了一些亟待解決的下一階段發(fā)展問題。
一方面，近年來 AI 興起，以 GPU、FPGA、ASIC 為代表的 AI 芯片被廣泛應(yīng)用，并與 CPU 組合來滿足高吞吐量、高并發(fā)和并發(fā)互聯(lián)的需求。各式各樣專有芯片的產(chǎn)生，對算力造成了巨大挑戰(zhàn)：如何更好地匹配算力、如何更好地感知不同的算力、如何結(jié)合效率 / 成本 / 用戶體驗做出更加智能精準(zhǔn)的判斷、如何實現(xiàn)對應(yīng)的調(diào)度……這是分布式云下一階段在算力調(diào)度側(cè)要解決的重要問題之一。
另一方面，近年來各個企業(yè)也開始越來越重視數(shù)據(jù)合規(guī)，如何對聯(lián)通的數(shù)據(jù)進(jìn)行隱私保護(hù)也成了一個重要課題。當(dāng)前比較流行的方案是隱私增強計算（Privacy-enhancing Computation），包含三個主要流派：
聯(lián)邦學(xué)習(xí)：一種分布式機器學(xué)習(xí)算法，在不交換原始數(shù)據(jù)的前提下，完成共享模型訓(xùn)練。聯(lián)邦學(xué)習(xí)可以幫助多個參與方共享數(shù)據(jù)價值，實現(xiàn)數(shù)據(jù)可用但不可見；
可信執(zhí)行環(huán)境：基于硬件的安全機制，將參與計算的代碼和數(shù)據(jù)加載至一個受 CPU 保護(hù)的可信環(huán)境中，在機密性和完整性上提供保護(hù)；
多方安全計算：在運行時，多個參與方各自擁有私有數(shù)據(jù)，他們通過非明文的數(shù)據(jù)交互，來實現(xiàn)約定的對整體數(shù)據(jù)全集的某種計算（如聯(lián)合查詢、聯(lián)合建模等）。
上述變化都對企業(yè)級云平臺的管理能力提出了更高的要求：一是要 有能力解決應(yīng)用的研發(fā)和管理問題，為用戶提供一致的云原生體驗，包括開發(fā)框架的跨云能力、整體效率問題和底層成本問題；二是 需要具備一定的開放接入能力，這是一個面向應(yīng)用、面向開發(fā)者、面向企業(yè)的真正意義上友好的多元化增強平臺所需要解決的問題。
這些問題都會伴隨底層問題的破解被一一解決，并走向持續(xù)發(fā)展。
