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

　　聽云CTO Wood于CDN加速專場發(fā)表了題為《智能CDN調度系統(tǒng)實踐》的演講，現(xiàn)場解讀了面對服務商故障，運營商劫持和區(qū)域性網(wǎng)絡故障，如何使用APM監(jiān)控數(shù)據(jù)來智能調度CDN服務，保障用戶體驗。

　　以下為演講實錄：

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

　　一、CDN的故障類型

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

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

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

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

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

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

　　二、聽云Controller for CDN

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

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

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

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

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

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

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

　　三、最佳實踐

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

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

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

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

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

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

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

　　Q&A

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

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

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

　　Wood：對。

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

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

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

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

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