作者 | 火山引擎云原生平臺負責人 沈健
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 采用 Kube.NETes 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 保護的可信環境中，在機密性和完整性上提供保護；
多方安全計算：在運行時，多個參與方各自擁有私有數據，他們通過非明文的數據交互，來實現約定的對整體數據全集的某種計算（如聯合查詢、聯合建模等）。
上述變化都對企業級云平臺的管理能力提出了更高的要求：一是要 有能力解決應用的研發和管理問題，為用戶提供一致的云原生體驗，包括開發框架的跨云能力、整體效率問題和底層成本問題；二是 需要具備一定的開放接入能力，這是一個面向應用、面向開發者、面向企業的真正意義上友好的多元化增強平臺所需要解決的問題。
這些問題都會伴隨底層問題的破解被一一解決，并走向持續發展。
