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