中國應用性能管理行業盛宴——2016中國應用性能管理大會(簡稱APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召開。APMCon由聽云、極客邦和InfoQ聯合主辦的作為國內APM領域最具影響力的技術大會，首次舉辦的APMCon以“驅動應用架構優化與創新”為主題，致力于推動APM在國內的成長與發展。

　　聽云CTO Wood于CDN加速專場發表了題為《智能CDN調度系統實踐》的演講，現場解讀了面對服務商故障，運營商劫持和區域性網絡故障，如何使用APM監控數據來智能調度CDN服務，保障用戶體驗。

　　以下為演講實錄：

　　Wood：很高興大家來參加今年的APMCon，本屆APMCon是我們聽云和極客邦、InfoQ聯合舉辦的，是國內第一次大型的APM會議。今天下午我在這邊分享的是聽云昨天在CDN調度方面剛剛發布了一個全新產品——聽云Controller for CDN。

　　一、CDN的故障類型

　　首先我跟大家分享一組來自聽云的數據，這是我們過去三個月的一些數據統計，因為大家知道聽云在幫CDN做很多的監測的事情，包含CDN自己還有它的一些客戶，幫他們去更好的選擇適合自己的CDN，以及監控CDN的服務狀態是什么樣的。但是實際上我們也看到了在過去的一段時間之內，其實不只是CDN的玩家更多了、價格更低了，CDN的故障變得也更多了，而且非常頻繁的。下面的數據包含大概三個月的監控時間，這里面直接跟CDN相關的大大小小的故障就有292次，大概有84個App會受到它的影響，平均故障恢復的時間是四個半小時，這里是指我們拿到數據后通知用戶后的恢復時間。實際上在過去幾年之內這些問題都是一直存在的，比如說去年蘋果App Store因為它的服務商的問題，大概在國內9月的時候，因為CDN故障導致他整個App Store完全沒法打開。那么發生這些故障應該怎么辦?目前來說是有一些解決方案的。

　　我們先來看一下CDN都有哪些典型的故障類型：

　　CDN 服務商故障 ：這也就是廠商級的故障，會導致廠商大面積的節點完全不能用，這種影響下如果你只使用了一個CDN廠商，那你的整個業務都會受到很嚴重的影響。

　　邊緣節點問題 ：第二個是跟邊緣節點相關的問題，它有很多表現，比如說邊緣節點的過載，有一個節點承載太多的訪問量的話，當它過載以后它的性能就會明顯的下降。另外一個是邊緣節點不可達，比如最后一公里的用戶他可能由于各種各樣的原因訪問不了你的邊緣節點，這在我們之前很多的客戶案例里面都出現過。一個邊緣節點可能對其他服務是好的，但是對某些用戶就不行，比如說某個邊緣節點上為了承載更多的業務，會同時承載視頻和圖片，這時候在一些有上網行為管理軟件的公司里面，比如說不讓你在上班時間看視頻，這時候就會導致在用同一些CDN節點的用戶，可能因為最后一公里的問題就完全訪問不了你的邊緣節點，你的邊緣節點完全不可達。還有一種問題邊緣節點的故障，某些節點因為內部的故障而訪問不了。

　　DNS 劫持 ：最后一個是非常有中國特色的問題，就是DNS的劫持，大家知道這里面運營商有很大的責任。當然他的目的有好也有壞，想提高你的速度，但是因為他的節點承載能力不及時，導致你到了這個點但沒有你想要的內容。當然還有更嚴重的劫持，比如域名劫持，一個客戶在某一個區的域名被加黑名單，這其實也是問題，既使是CDN也沒法加速他的域名。

　　針對這三個問題，我們有哪些的解決方案呢?目前來說大概有三種，如果是廠商故障的話，我們需要找人去重新改DNS解析，把流量切到其它的廠商上去。比如說邊緣節點故障，這只能我們去通知廠商，聯系廠商去解決。最后一種劫持的問題，DNS劫持或者污染的情況下，比較有效的途徑就是投訴，你需要收集證據，把證據給CDN廠商或者自己去投訴，最后通過這個廠商，或者是運營商渠道，最終把這個問題解決掉。這整個過程所需時間是非常非常長的，一旦你被劫持了或者是被加黑名單了，都會經歷非常長的一個時間。

　　二、聽云Controller for CDN

　　所以聽云一直在思考這個問題，下面這張圖是我們的一個24小時值班的流程圖，大家不用看里面的內容，隨便一個新手照著在給我們客戶值班報警時候都知道應該怎么做，我想表達的實際上是這個流程非常復雜。包括剛才我們提到的三種解決方案都是需要消耗很多溝通成本、很多的時間才能最終把你的問題解決掉。所以聽云正在思考的是，實際上我們有很多客戶端的數據，有很多的CDN節點的性能數據，我們能不能利用這些數據分析跟驅動來幫我們的客戶去更好的調度他們的CDN，調度他們的業務。

　　基于以上的思考，所以才有了我們的最新產品——聽云Controller for CDN。以下這些是我們目前有的數據量，目前聽云Browser監控最終用戶，從Browser來打開網站的性能，目前每天是3億的訪問量，3億的數據上傳。聽云App目前比較大，大概每天會有200億的數據上傳到我們的數據中心。同時聽云有30萬的監測節點，分布在全國以及世界各地。這些數據，聽云Controller都會用到，我們會從真實用戶的體驗數據來分析最終用戶對每一個CDN的服務節點的訪問質量，比如每張圖片訪問到的是哪個IP，哪個設備組，以及每個設備組的性能等等，這些都可以采集到。同時這些數據我們會去做全網的分析，會分析運營商的維度、目標主機的維度，以及我的接入方式，比如說3G、2G、wifi的方式。

　　通過這些數據我們可以了解到每一個CDN節點的質量，以及它服務的域名是哪些，通過這個分析我們就可以去實時的調度，例如去調度最終用戶的App，或者是他們的DNS的解析，來幫助他訪問更快更好的節點。這里面也會用到聽云的Network的30萬監測點，比如說某一個區域的用戶覆蓋量不夠的話，我就會通過聽云Controller去調動這些監測節點，對于某些域名或者某些URL單獨去訪問，把這個數據補充回來。如果那些地方可能沒有你的真實用戶，我們也可以通過聽云Controller把數據補充回來，最終這些數據都會通過后面的途徑下發到用戶的App，或者是DNS上去。

　　下面是我們大概整個系統的原理圖，一個拓撲架構圖。就像上面我們說的，聽云Controller會從聽云App和Browser里面拿數據，那里面是我們所有的聽云App、聽云Browser的真實用戶訪問數據。這些數據會經過中間的系統匯聚，并且進行一定的數據清理。在這個過程中我們會把一些不存在的，比如把解析不出來的域名通過旁邊的區域，有一個接口可以發送到其他廠商的HTTP、DNS的服務上去，補充我的數據。最終數據會放到數據庫里面，這部分其實現在是分布式的存儲，會做實時的數據區分有10分鐘、30分鐘、一個小時以上，還有24小時的數據在里面。

　　通過這些數據的匯聚跟聚合，我們會通過App來給大家去提供服務。這中間有一個調度系統，實時的從數據庫里面把數據抽取出來快速做調度，這種情況下我們會提供三種服務，目前我們提供是SDK的服務，只要裝了聽云App的SDK，把里面的開關打開以后就可以幫助你調度CDN的服務，你訪問你的CDN就不需要再去走DNS，而是通過聽云的調度系統幫你去調度的。同時我們也會開放一些open API，你不想用SDK，那你就可以從API那邊獲取，把數據拉出來。同時我們也會提供DNS解析服務，我們會跟第三方的DNS廠商、DNS平臺做合作，我們會把結果給他，通過他去做更好的調度。所以這是整個聽云的調度系統，也就是我們的數據是怎么處理的，以及這個數據最終輸出以后可以幫助你干什么。

　　所以這里其實我們就已經繞過了DNS劫持，每次應用啟動的時候，就會通過App的接口從聽云的調度系統里面拉一份數據，這個數據里面就會包含各個CDN節點在一段時間的性能，我可以根據這個數據在訪問的時候去攔截用戶的請求，程序可以不需要任何修改，在攔截請求的時候就可以幫助你把DNS去掉，直接去連IP地址。通過這種方式的話我們可以提供基于App的加速，并且可以更好的去繞過DNS，大家知道對內容劫持的話沒有太好的方法，通過這種方式就可以把DNS繞過去。

　　下面這張圖是我們后端數據的架構，保證數據可以快速的做分布式查詢，提高它的查詢效率。另外一個是服務器為了去提高一些唯一值，還有統計值查詢效率。最上面會有一個自己維護的分區服務，會動態去擴張整個數據庫，不需要人工的去維護來快速的擴展，因為我們實際上現在數據量還是非常大的，對于流失的數據實時的進行處理。

　　三、最佳實踐

　　我們拿某個客戶的數據基于剛才的系統分析以后，出來的一個結果，我們可以了解到每一個最終用戶的區域，根據他的GPS信息、IP地址信息來獲取他來到了哪一個CDN的節點。我們可以展示每一個域名它的平均性能，以及過去一段時間它的平均的可用性是什么樣的，以及每一個CDN節點它的目標，設備組里面都提供了什么樣的服務，都可以非常詳細的展示這些數據。這些數據實際上是就是我們CDN調度的基礎數據，也就是什么區域的節點在覆蓋什么區域的用戶，通過這個我們可以去更好的調度CDN節點。

　　實際上我們對這個系統也做了一些測試，上面這個數據是基于一個90k左右的圖片，一開始我們用了兩家服務商，后來引入了第三家、第四家，這里面我們先去用CDN自己提供DNS解析的方式去做，另外一個是利用聽云Controller SDK做對比，這兩個都會在同一些節點上做監測。最終可以發現整個性能的提升，大概提升了120毫秒左右的性能。同時也包含可用性的一些對比，比如說原來可能會因為DNS解析失敗，或者是節點的故障失敗導致的問題，現在的可用性也有很大幅度的提升。還可以去對比節點的數量，我們可以去覆蓋的更多、更廣的節點，最后承載這個服務的節點數比原來要多了很多。

　　所以通過聽云Controller，我們對剛才最開始提出來的那幾個問題給了一個比較完整的解決方案，甚至是更塊更好的方案。這時候就不需要更多的人力，也不需要聽云監控的客服再給你打電話，讓你切換DNS、切換CDN，整個東西都可以利用這套系統自己完成：

　　如果是運營商故障 的時候，如果你有使用多家CDN，其中有一家出現大面積的故障的話，可以通過聽云Controller繞過它，可以幫你快速的把故障點切掉。

　　如果是邊緣節點故障 ，也能幫你切掉，比如發現某一些區域的用戶達到不了某些節點的話，可以給他新的路由策略，把這部分用戶路由切到某些沒有過載、沒有故障的節點上去，可以幫你引導更好的解決方案。

　　剛才說過了繞過DNS劫持 ，如果你用的是SDK的話，就不會去走你的DNS，因為在每次應用啟動的時候我們都會拉一份你的配置表，告訴你應該去訪問哪些IP地址，這個配置表實際上是可以去實時刷新的，在任何時刻只要你當地會出現一些訪問不了的情況的話，這個配置表就會在40秒的過程中更新，然后告訴你，你應該去走哪一些好的路由。這時候因為不再用DNS解析，那DNS劫持也就不存在了。

　　以上就是我們整個聽云Controller for CDN的實踐分享，實際上我們做這個的目的很明確，從去年開始整個CDN行業發生了很大的變化，玩家更多、價格更低，這里面對于一些創業公司或者小公司的話，他不會有太大的優勢，基本上大家選的時候都會去看一些資源比較好、或者是老品牌的公司。但實際上小公司有自己的一些服務特點，有自己的技術，并且甚至有一些區域他覆蓋的更好。用戶如果不測試是不知道的，所以聽云做這個事情的目的是幫助大家去更好的選擇符合自己需求和要求的CDN服務商，能讓你的流量在不同家的CDN之間去快速、實時的互相切換。將來在我們產品里面你會有一個選項，可以選擇你是用戶體驗優先，還是性價比優先，我們會根據你的需求設置一些價格策略，去幫助你做更好的調度CDN，來幫助你節省最終成本。之前需要專門溝通CDN廠商的人都不需要了，你可以依賴這套系統幫助你實時的切換、調度。

　　Q&A

　　Q1：請問Wood老師，除了傳統切入DNS，聽云Controller是怎么做的?

　　Wood：聽云Controller for CDN我們目前只提供SDK，后續會提供基于DNS的方案，我們會跟國內的DNS廠商合作，把結果給他們，當然也不排除將來聽云也會提供類似的服務。

　　Q1補充：也就是說DNS以后的方案有可能是我們的域名給到聽云，然后由聽云來進行調度?

　　Wood：對。

　　Q2：剛才說到在不同的CDN服務商之間進行切換的時候，一般的App可能圖片、數據都在一個CDN服務商上面。進行不同切換的時候，是不是多個服務商上面都要有數據?

　　Wood：是的。我們在切換的時候會保證你在那邊實際上有數據的，因為我們在這里面會做一些驗證，比如說你大數據的數據在A上，我們是不會切過去的。

　　Q3：我想問一下我們用SDK的話，是不是我們先需要跟CDN廠商有一個賬號，有了一個服務之后再用。還是說我沒有和任何CDN有合作的話，用聽云的SDK就行?

　　Wood：你需要先跟CDN服務商簽合同，有他們服務。我們的SDK只做調度，不做CDN的加速。

特別提醒：本網信息來自于互聯網，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。