在世界杯等大規模流量突發的情況下，作為承載抖音集團業務核心流量的基礎設施，在運維效率、質量方面都可觀測、調度、容災、成本可觀測與優化方面都遇到了很多的挑戰。LiveVideoStackCon 2023上海站邀請了火山引擎邊緣云融合CDN團隊負責人孫益星介紹火山引擎在多云應用架構下的CDN運維管理解決方案。

大家好，我是來自火山引擎邊緣云融合CDN團隊的孫益星，主要負責多云平臺的建設。

今天主要想跟大家分享的內容包括三個部分：

第一部分是介紹下我們團隊在過去幾年面向字節內部業務，持續建設一個多云CDN平臺的演進過程；

第二部分主要是介紹在這個過程中我們所面臨的一些主要難點和挑戰，以及是怎么解決的；

最后是介紹我們接下來的主要投入方向：如何把我們的能力開放出來，以產品的形式提供給火山引擎的用戶和開發者。

-01-

字節多云CDN平臺的演進

首先為大家介紹一下我們面向內部業務的多云CDN平臺，包括這個平臺有什么用以及要解決的到底是什么問題。

字節跳動有很多流量型的業務，包括抖音、頭條、西瓜視頻等。為了承載這樣的流量，團隊使用了各種各樣流量加速的產品，包括靜態加速、動態加速、域名解析、證書管理以及與各種配套的解決方案，比如源站緩存、回源調度、邊緣函數等。

從業務角度出發，如果有一個平臺能夠直接管理所有加速域名的配置，這將會帶來很大便利。只需要把源站儲存的信息發送給平臺，剩下的配置解析、流量分配、質量管理等都是由平臺完成。

于是字節多云CDN平臺——我們叫做融合CDN平臺——應運而生，它向上承接所有業務方的CDN加速場景需求，底層對接不同的公有云服務，包含靜態加速、動態加速等，這些服務本身由不同的廠商來提供，業務方在上層不需要關心它所對接的是哪些廠商，也不關心具體功能需求在不同的廠商上應該分別怎么去實現，它要做的事情就是把需求提給平臺，然后由平臺協調不同廠商的資源，最終再交付給業務。對于業務方來說，這就是一個普通的CDN服務平臺，像是一家廠商提供的打包的服務一樣，所以業內有個比較通俗的稱謂是融合CDN平臺。

業務對于這個平臺的訴求有以下幾點：

第一個訴求是質量：業務對平臺的加速服務能力是有預期的，平臺有責任保障上層的每一個域名的可用性和加速效果；

第二個訴求是成本：成本越便宜越好；

第三個訴求是功能：不同業務有比較大的差異的，比如訪問鑒權、回源rewrite，緩存時間等。每個業務都會有自己的設計和需求，作為融合平臺需要理解這些設計的差異，然后將它轉換成廠商可滿足的服務需求，最后實現、驗證、最后交付給業務方；

第四個訴求是服務：這個是比較寬泛的概念，就是當我們完成了一系列的資源的配置工作后，業務在日常使用中需要看監控，看報表，刷新預熱、排查問題，提一些on call，這些都需要對應的服務能力來支持。

總結下來，上層業務對于平臺有四個方面的需求：質量、成本、功能以及服務，這個是上層業務對于平臺的需求。

從平臺的角度考慮，廠商越少，復雜度的可能性就會越低。但由于這是一個融合平臺，所以需要從所有字節的業務體系的角度考慮問題。

首先就是資源的保障，資源方面要能承載日常一兩百T的業務帶寬，這已經超出了絕大部分廠商的資源儲備。

另一方面是在例如春晚、618、世界杯或者演出賽事這種大型的活動籌備時，我們很難在單個廠商上找到充足的冗余，這個冗余可能是超出常規業務量的一倍或者更多的需求，總資源池子需要多個供應商一起協調資源。

其次是質量，用戶分布在全國各地甚至全世界，而用戶體驗跟節點的訪問質量密切相關，不同廠商在不同地區、不同運營商的節點分布是有比較大的差異的。這會導致在實際的業務表現中，這個地區廠商質量的排序是ABC，另一個地區就變成了CAB，這種情況在海外會更明顯。對于那些時刻要求最優服務資源的業務來說，很難通過單個廠商來滿足要求。

質量的另一個體現形式是可用性，地區性的節點不可用是經常發生的，這會造成業務的質量波動。另外，大規模的廠商故障也時常會發生，如果只綁定一家廠商，那么它故障時流量切換也會帶來明顯的質量影響。所以對我們來說，保證流量較為分散的分配在多個供應商是一個必要的措施。

價格方面也有多廠商的考慮，價格并不是越便宜越好。不同的業務對于質量的要求是不同的，有些對于用戶體驗不敏感的業務會更關注成本，對質量的要求就沒有那么高；另一部分業務為了更好的質量，就對價格容忍度更高一些。平臺需要價格和質量層面為不同的業務找到不同的廠商，選出一個最合適的方案。

最后是功能和服務的支持，有多個廠商就可以在我們有新的功能需求的時候，縮短從聯調到測試到上線的周期，在排查具體問題的時候也能給我們更多的信息反饋。

作為一個融合平臺，我們的目標并不是要對接盡可能多的廠商，或者對接盡可能少的廠商。而是如果需要讓整個業務達到這樣一個理想的狀態，多廠商基本是一個唯一的方案。在這個方案里，資源是動態變化的，不存在一種資源在各種場景下都是最好的。而是不同場景下總有一個最合適的，而平臺在這里的職責就是向業務方高效的交付那些最合適的資源，并保證這些資源的可靠性，這是這個平臺的核心能力。

平臺的建設經過了兩個階段：

第一階段是最原始的方式：我們會有固定的幾個SRE，每個人固定的對接幾個業務。大一些的業務可能會有多個專職，小一些的可能會由一個SRE對接多個業務。每個人都比較熟悉自己所對接的業務的需求和背景，按照自己的經驗去廠商控制臺上去配置，具體的要求也直接跟廠商的技術人員去溝通。在這個初始階段中，主要靠人的能力來支撐；

第二階段開始有些通用的功能需求被提出放在平臺里：比如說看域名的配置，數據，調流量。于是平臺的功能被分成不同的功能方向分別被建設。并且不同類型的資源有不同的團隊分別去實現。在這個階段中由于業務不斷有需求進來，整個平臺的設計是在被需求拖著走的。這中間暴露出了一些問題，比如權限設計、接口規范不統一、數據一致性有問題等。

經過這兩個階段之后，我們清晰的認識到：需要有一個統一的設計，把這些需要用到的能力都集中起來。

經過幾年的迭代，平臺完成了多個模塊的整合，形成了一個統一的管理平臺。大致分為權限管理、資源管理、質量管理、統計監控、廠商管理、運營分析幾個模塊。

-02-

多云管理的挑戰

接下來我跟大家分享下這個平臺建設中遇到的一些挑戰。

使用多個CDN廠商的情況在行業內是一種普遍的現象。我們一開始對于對接多廠商的認識是打通API，向上統一封裝。但是在真正實踐時，我們發現事情的復雜度比預期要高很多。

首先，行業里面基本沒有公認的規范。作為一個融合平臺，需要理解不同廠商的不同規范，逐個對接，避免業務踩坑。要在不同的廠商匯總的數據中，及時準確的發現地區性的質量波動并定位原因等。

其次，當資源選擇變多了之后，如何保證我們的選擇是最優的變成了一個被大家關注的問題。

最后還有一個重要的問題：就是我去解決這些問題的時候，應該投入多少，怎么來評估產出，團隊的價值如何量化。

我們從配置和數據兩個基礎的問題開始討論，再展開到上層的方案，介紹我們質量和成本的運營，最后討論平臺團隊價值的問題。

2.1|配置

行業內配置的差異非常大。廠商之間沒有規范，對接成本高。廠商的開放接口并不能覆蓋全部的能力，接口操作風險高，一次變更全網下發。有些功能還必須去和廠商的后臺溝通才能加入。

解決這個問題分為三個方面：

1. 制定配置規范

所有廠商所有的功能集合盡可能開放到一個規范里面，一次性實現完整的規范。即便人力開銷會增大，但會變成一個相對來說較為固定的投入，不會像以前那樣一直在反復的調整。

2. 規范變更流程

首先要求所有的配置變更必須有一個統一的入口。任何操作必須在內部的平臺實現，不能在廠商操作。入口收斂之后，所有的配置只有有權限的人才能夠發起變更，需要有熟悉業務的人來審批，審批之后由SRE來觸發實際下發的流程。配置在下發完成之后，在接口層面會檢查對應的配置是不是符合預期結果，進行一次重新的配置讀取，廠商也會給到相應的反饋。配置下發完成之后，也會做一些調度層面的準備，例如新建域名或者刪除域名。

最后在交付之前，會進行一次完整的回歸測試。這些測試需要是配置項級別的，比如修改源站，我們要確認回源相關的響應里面有沒有新源站的信息，如果是修改訪問控制規則，我們要確認對應條件的訪問是不是真的被攔截了或是被放行了。這些回歸做完之后，意味著我們這次變更從用戶側的訪問效果應該是真的達成預期了，最后才會通知業務方這個變更完成

3. 完善測試框架

最后還有一個接口的測試框架，與前面提到的回歸測試區別在于：上述的測試是面向配置結果，而這個測試框架是面向整個配置接口。因為接口轉換的實現很重要，并且很容易出問題，導致這些問題的原因可能是我們代碼的bug，或者廠商API層面的一些變更導致不兼容的問題、環境的變化產生的影響等，這些問題如果沒有一個很好的測試框架，就只能等它出現問題的時候才能發現。在過去的一兩年，經過測試框架的積累，火山引擎邊緣云完成了大約2000多個case的建設，每次API上線都會跑一個完整的測試，每天有定時的巡查保證廠商測試的功能是符合預期的。這樣大量的測試積累，也幫助我們發現了很多問題。

2.2|數據

下面我們再說一個比較基礎的能力：數據。

我們知道數據產生的源頭分別來自于服務端和客戶端。服務端從access log開始由廠商轉換成兩種數據出口，離線日志和實時統計的接口，前者延遲一般是小時計甚至天級別的，后者可能可以做到分鐘級。我們平時看到的帶寬請求數狀態碼都是從服務端的數據源產生的。客戶端則是我們自己的業務上報客戶端的訪問質量數據，同時加上自身的撥測任務巡檢，采集一些更詳細的鏈路質量信息。

為了做統一的聚合分析，這些數據被統一存儲到數據中臺的統一數倉里。整體來看很容易可以理解要做什么，但是跟傳統的大數據系統相比，多云平臺的工程實現有出現一些額外的問題。

首先就是數據的延遲，接口級別的延遲雖然是分鐘級的，但是不同廠商的差異也比較大，有的1分鐘、有的5分鐘、有的10分鐘。但是我們自己的調度系統在做切換的時候希望拿到的數據是越實時越好；

其次是接口的局限，雖然接口的延遲相對日志會低一些，但是它能提供的信息量是有限的；

再次是采集能力，采集時會出現接口不可用，被限頻等問題，這就要求我們的采集系統能夠識別哪些錯誤需要重試，針對廠商主動地控制自己的采集頻率；

最后是采集的數據質量如何保障，廠商對于接口的實時性是沒有辦法100%保證的，接口報錯很頻繁。采集數據還沒出來時，有問題的數據如何修正，修正之前如何判斷這個數據是不是可信的。

整個建設分為三個階段：

第一階段是多源數據采集。解決包括客戶端的、服務端的、實時的、離線的不同數據源的適配；

第二階段是數據可靠性建設。廠商的數據、日志、API、賬單等數據會有對比過程，如果發現某個數據出現問題，會發起主動的修復。同時會對整個數據大盤進行實時性監控。上層系統會根據數據做置信度判斷。結合服務端的QPS和業務側上報的數據，判斷當前數據是否真實可信。如果不可信，需要使用其他的數據擬合進行針對性的修復。

第三階段是統一數倉。數據采集之后，會使用統一的規范儲存到數據倉庫里，向上會提供統一的API查詢和信息查詢能力。在實際操作過程中，可能會遇到API層面無法實時采集地區運營商級別數據的情況。業務方在查詢的時候，需要把這部分查詢實時轉化成接口的請求轉發給廠商，以達到相同的效果。

右側是整體的模式圖。底層是統一的數據中臺，負責數據的采集、計算、存儲、對外提供查詢的接口，上層包括監控、運營、策略等不同模塊，面向不同的用戶提供不同的功能。

2.3|質量管理

介紹完配置和數據這兩個基礎的能力，下面向上講一些業務方更關心的橫向的能力，首先是質量保障。

作為一個融合平臺，業務方如果有感覺到質量出現問題，一般是出現了故障。平臺要做的事情就是把質量的標準提高，盡可能避免對業務產生影響。很多問題對上層沒有影響，但是在內部已經走了一個完整的故障處理流程，包括問題的檢測發現、通知告警、診斷定位、預案恢復。對于一些比較明顯的問題，不管有沒有對業務造成影響，我們也會做內部的復盤和改進。

在這個流程中，我們要面對各種各樣的問題，比如如何保證檢測到的告警的有效性、縮短定位的時長、提升我們無人工干預自動恢復的比例，以及后面的復盤定級需要怎么做。這里我簡單介紹下這個過程：

最基礎的能力是監控的數據源，相較于剛才的多源數據采集，還定制了廠商側的告警上報、實時錯誤日志推送等能力，也會結合業務側的SDK打點、撥測數據、以及自有節點的一些質量數據。這些統一到數倉里，構建了一個比較實時的質量庫。

往右就是數據的檢測告警，數據會根據不同的維度聚合，比如域名的、業務的、AB測試的都可能有不同的告警規則。這些規則可以是例如狀態碼異常比例、播放錯誤率比例這類靜態的規則，也可以是根據時序數據的特征和歷史趨勢動態判斷告警閾值應該是多少。我們對于周期性的和非周期的時序數據都可以支持動態閾值的告警。

當告警觸發后，會進入根因分析流程，判斷這個告警產生的真實原因是什么。比如當業務方客戶端錯誤率上升時，需要判斷對應的是哪個域名，這個域名是放在哪個廠商上，對應的各個維度的監控是否正常。這些判斷會涉及到時序數據異常檢測、不同數據的相關性分析等等。基本上我們常見的異常都會有完整的根因分析邏輯，直到排查出最終的問題，比如到底是廠商側的問題還是我們源站的問題還是地區性的網絡問題。

這樣最終在告警發送時，已經帶著完整的診斷結果通知我們的SRE。比如，當前的現象是客戶端錯誤率上升，原因是源站問題，對應中間的檢查結果是怎樣的。這時候我們可以直接通知業務方處理自己的源站問題了。

如果是廠商的問題，例如地區性的節點不可用，除了會通知廠商之外，我們還會自動去執行一些預案。最常見的就是切流，把對應地區的調度權重從問題廠商上調走，同時保持對廠商對應地區的主動探測，當廠商的流量正常時再切回來。最后這個質量問題的影響時長、故障定級等等會在質量系統中有明確的體現，廠商側也可以根據我們反饋的信息進行檢查和改進。

這樣最終整套的系統就實現了閉環，質量數據的檢測會觸發告警和根因，自動的根因分析和預案執行能夠自動的改善質量數據。

過去幾年我們一直在改善閉環里的執行效率和準確性，讓更多的問題能夠被自動預案來覆蓋。目前的告警準確性，就是那些波動異常經過智能閾值判斷，以及降噪處理后，被確認真的是異常的占了98%以上，80%以上的告警會帶著準確的根因分析信息一同提供給SRE和技術支持的同事。

2.4|成本運營

成本運營在過去幾年一直是一個令人非常頭疼的問題。由于數據的敏感性，我們最初做了很多的限制，導致相關的技術只能局限在一個很小的范圍內討論。但是這個團隊要解決的工程問題還是非常復雜的，需要充分的投入。比如每個月一到月初就要花大量的時間去校驗廠商的賬單數據是不是準確，還有像成本分攤、波動歸因等方面都存在很大的挑戰。解決辦法一種是讓業務方熟悉我們的成本邏輯，自己去分析，另一種方式是從平臺層面提供統一的能力來幫助業務。

首先需要明確的是數據因為和錢相關，確實是很敏感的，因為涉及到商務的保密問題等，但是錢可以拆分成兩部分：一部分是單價，一部分是用量。單價只有有權限的人才能可見，所以我們額外做了一套系統，把價格隔離起來管理。用量信息則沒有那么敏感，大部分業務方都會接觸用量信息。將單價隔離開以后，平臺的負責人就可以深度的參與到用量的優化之中。這些用量，比如邊緣帶寬、存儲、專線會分別對應到不同的分攤算法中去，讓每一種資源的用量都有一個固定的邏輯分攤到最小的成本單元上，一般就是域名。域名在總的用量上面占多大比例是可以明確的，成本單元有自己的組織歸屬，包括葉子結點和跟結點的歸屬都可以映射過去。

對于業務方來說，可以直觀的看到每月的帶寬上漲到底是哪些業務甚至是域名導致的問題，這個就是我們近期面向業務方開放的成本分析能力。

在排查問題的時候，每一層的數據都是可校驗的。所有域名的總用量加和，一定等于我們分攤前的總用量加和。每個資源的總用量，乘以對應的單價，一定等于對應的資源花掉的錢。做數據校驗的時候，只需要一層層的校驗就好了。

2.5|平臺價值

剛才說了我們作為一個多云管理的平臺，資源是來自于底層的廠商，流量來自于上層的業務，平臺做的事情只是把這個資源更好的交付給業務，協助我們的業務使用好這些資源。

在這個過程中我們投入了接口開發、QA、數據工程、運營分析、調度系統、質量監控、權限管理還有前臺、文檔等等，但是向上還是要落實到業務層面可以感知到的收益上，就是我的質量是不是有保障，還有我的成本是不是在持續的優化。

所以一直以來衡量我們的團隊產出的指標一直都是一些相對固定的維度，質量、成本、效率、穩定性。

最近一年來整套的系統設計才逐漸完整，把線上問題收斂穩定下來。到現在為止依然要投入很多的人力去維護我們配置接口的迭代、數據的保障、以及平臺化的功能建設。另一方面，正是因為有了業務體量的支撐，我們團隊的投入價值才能最大化。

過去一段時間里，我們也跟火山引擎的客戶和開發者做了一些技術上的交流，去介紹我們是怎么管理多云的。一個經常提出來的問題是，我有什么簡單的辦法實現你這套系統，我可以不要那么復雜的前臺界面、審批流程。但是那些關鍵的能力，比如質量管理、成本分析，我們怎么樣才能用最小的投入做起來。

所以在去年我們對系統又重新做了一次改造，把底層的關鍵能力，數據系統配置系統調度系統還有中間的一些核心解決方案，逐步的開放成我們的產品能力，放到火山引擎上面提供出來。這個就是我們的多云CDN產品。

-03-

火山引擎多云產品能力

多云CDN底層還是對接不同資源廠商，包含不同服務類型。但中間層正在經歷一個深度的改造，從右到左不斷地將我們的核心能力孵化為開放的產品；從左到右，以上云的形式不斷地將我們已有系統的實現以更加規范的設計和概念定義去做重構，讓一些原本比較模糊的內部概念能夠以一個內外部用戶能理解的方式去運行。

在這套系統之上，現有的融合平臺會變得越來越薄，未來可能只會保留一些跟內部業務深度耦合的部分，比如流程的審批、內部業務的預案等。業務方還是使用我們融合平臺的界面，但是這個平臺的底層未來會和火山引擎的客戶一樣是我們這個多云產品的用戶，通過它提供的開放接口能力去管理各自的資源。

3.1|資源管理

多云CDN產品去年剛剛上線，就已經完成了基本的資源管理能力。平臺現在支持已經完成接口規范化改造的國內外廠商。在接口能力上配置的統一查詢功能已經完成，也支持了像域名創建、證書更新這樣的能力，更完整的配置變更流程正在做產品化的改造。在資源管理的基礎上，業務組織、權限、統計聚合的能力也完成了，一些拓展的功能，比如在TOS文件變更的時候同時刷新多個廠商的CDN，我們稱之為聯動刷新的能力，有了多云的平臺就比較容易實現，目前正在被實際使用。

3.2|監控分析

在數據的能力上，統計的API和日志的API在第一階段都已經支持。剛剛完成了數據采集的能力，可以直接幫助用戶從API采集數據然后存下來，在這個數據能力之上，用戶可以做不同廠商數據的統一聚合，或者靈活的對比不同廠商的數據。未來我們還會開放自定義報表的能力，幫助我們的客戶分析全局的業務數據。

3.3|智能運維

在監控能力上，有了剛才說的數據采集的能力，加上我們的撥測能力，以及未來會開放的客戶數據上傳的通道，我們把內部的智能告警、根因分析、自動容災的預案也都放到了產品上，未來會結合我們自己的質量庫幫助我們的客戶更好的分析業務質量、提升服務的可靠性。

3.4|FinOps

近期，成本管理能力已經上線。總的來說就是將成本運營能力開放，結合數據采集能力和賬單分析能力，幫助客戶準確的分析賬單構成、業務成本構成和波動的原因。未來還會結合不同的計費模型，幫助業務方更好的分析成本，組成對應的優化方案。

上述就是整個多云CDN產品的演進過程。火山引擎多云CDN產品在去年上線，目前還在快速地迭代過程中。我們期望和我們的廠商、開發者一起，為火山引擎的用戶，實現一個規范、統一、安全、高效、智能的多云流量管理平臺。