中國應(yīng)用性能管理行業(yè)盛宴——2016中國應(yīng)用性能管理大會(簡稱APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召開。APMCon由聽云、極客邦和InfoQ聯(lián)合主辦的作為國內(nèi)APM領(lǐng)域最具影響力的技術(shù)大會,首次舉辦的APMCon以“驅(qū)動應(yīng)用架構(gòu)優(yōu)化與創(chuàng)新”為主題,致力于推動APM在國內(nèi)的成長與發(fā)展。
聽云CTO Wood于CDN加速專場發(fā)表了題為《智能CDN調(diào)度系統(tǒng)實(shí)踐》的演講,現(xiàn)場解讀了面對服務(wù)商故障,運(yùn)營商劫持和區(qū)域性網(wǎng)絡(luò)故障,如何使用APM監(jiān)控?cái)?shù)據(jù)來智能調(diào)度CDN服務(wù),保障用戶體驗(yàn)。

以下為演講實(shí)錄:
Wood:很高興大家來參加今年的APMCon,本屆APMCon是我們聽云和極客邦、InfoQ聯(lián)合舉辦的,是國內(nèi)第一次大型的APM會議。今天下午我在這邊分享的是聽云昨天在CDN調(diào)度方面剛剛發(fā)布了一個全新產(chǎn)品——聽云Controller for CDN。
一、CDN的故障類型
首先我跟大家分享一組來自聽云的數(shù)據(jù),這是我們過去三個月的一些數(shù)據(jù)統(tǒng)計(jì),因?yàn)榇蠹抑缆犜圃趲虲DN做很多的監(jiān)測的事情,包含CDN自己還有它的一些客戶,幫他們?nèi)ジ玫倪x擇適合自己的CDN,以及監(jiān)控CDN的服務(wù)狀態(tài)是什么樣的。但是實(shí)際上我們也看到了在過去的一段時(shí)間之內(nèi),其實(shí)不只是CDN的玩家更多了、價(jià)格更低了,CDN的故障變得也更多了,而且非常頻繁的。下面的數(shù)據(jù)包含大概三個月的監(jiān)控時(shí)間,這里面直接跟CDN相關(guān)的大大小小的故障就有292次,大概有84個App會受到它的影響,平均故障恢復(fù)的時(shí)間是四個半小時(shí),這里是指我們拿到數(shù)據(jù)后通知用戶后的恢復(fù)時(shí)間。實(shí)際上在過去幾年之內(nèi)這些問題都是一直存在的,比如說去年蘋果App Store因?yàn)樗姆?wù)商的問題,大概在國內(nèi)9月的時(shí)候,因?yàn)镃DN故障導(dǎo)致他整個App Store完全沒法打開。那么發(fā)生這些故障應(yīng)該怎么辦?目前來說是有一些解決方案的。

我們先來看一下CDN都有哪些典型的故障類型:
CDN 服務(wù)商故障 :這也就是廠商級的故障,會導(dǎo)致廠商大面積的節(jié)點(diǎn)完全不能用,這種影響下如果你只使用了一個CDN廠商,那你的整個業(yè)務(wù)都會受到很嚴(yán)重的影響。
邊緣節(jié)點(diǎn)問題 :第二個是跟邊緣節(jié)點(diǎn)相關(guān)的問題,它有很多表現(xiàn),比如說邊緣節(jié)點(diǎn)的過載,有一個節(jié)點(diǎn)承載太多的訪問量的話,當(dāng)它過載以后它的性能就會明顯的下降。另外一個是邊緣節(jié)點(diǎn)不可達(dá),比如最后一公里的用戶他可能由于各種各樣的原因訪問不了你的邊緣節(jié)點(diǎn),這在我們之前很多的客戶案例里面都出現(xiàn)過。一個邊緣節(jié)點(diǎn)可能對其他服務(wù)是好的,但是對某些用戶就不行,比如說某個邊緣節(jié)點(diǎn)上為了承載更多的業(yè)務(wù),會同時(shí)承載視頻和圖片,這時(shí)候在一些有上網(wǎng)行為管理軟件的公司里面,比如說不讓你在上班時(shí)間看視頻,這時(shí)候就會導(dǎo)致在用同一些CDN節(jié)點(diǎn)的用戶,可能因?yàn)樽詈笠还锏膯栴}就完全訪問不了你的邊緣節(jié)點(diǎn),你的邊緣節(jié)點(diǎn)完全不可達(dá)。還有一種問題邊緣節(jié)點(diǎn)的故障,某些節(jié)點(diǎn)因?yàn)閮?nèi)部的故障而訪問不了。
DNS 劫持 :最后一個是非常有中國特色的問題,就是DNS的劫持,大家知道這里面運(yùn)營商有很大的責(zé)任。當(dāng)然他的目的有好也有壞,想提高你的速度,但是因?yàn)樗墓?jié)點(diǎn)承載能力不及時(shí),導(dǎo)致你到了這個點(diǎn)但沒有你想要的內(nèi)容。當(dāng)然還有更嚴(yán)重的劫持,比如域名劫持,一個客戶在某一個區(qū)的域名被加黑名單,這其實(shí)也是問題,既使是CDN也沒法加速他的域名。
針對這三個問題,我們有哪些的解決方案呢?目前來說大概有三種,如果是廠商故障的話,我們需要找人去重新改DNS解析,把流量切到其它的廠商上去。比如說邊緣節(jié)點(diǎn)故障,這只能我們?nèi)ネㄖ獜S商,聯(lián)系廠商去解決。最后一種劫持的問題,DNS劫持或者污染的情況下,比較有效的途徑就是投訴,你需要收集證據(jù),把證據(jù)給CDN廠商或者自己去投訴,最后通過這個廠商,或者是運(yùn)營商渠道,最終把這個問題解決掉。這整個過程所需時(shí)間是非常非常長的,一旦你被劫持了或者是被加黑名單了,都會經(jīng)歷非常長的一個時(shí)間。
二、聽云Controller for CDN
所以聽云一直在思考這個問題,下面這張圖是我們的一個24小時(shí)值班的流程圖,大家不用看里面的內(nèi)容,隨便一個新手照著在給我們客戶值班報(bào)警時(shí)候都知道應(yīng)該怎么做,我想表達(dá)的實(shí)際上是這個流程非常復(fù)雜。包括剛才我們提到的三種解決方案都是需要消耗很多溝通成本、很多的時(shí)間才能最終把你的問題解決掉。所以聽云正在思考的是,實(shí)際上我們有很多客戶端的數(shù)據(jù),有很多的CDN節(jié)點(diǎn)的性能數(shù)據(jù),我們能不能利用這些數(shù)據(jù)分析跟驅(qū)動來幫我們的客戶去更好的調(diào)度他們的CDN,調(diào)度他們的業(yè)務(wù)。

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

通過這些數(shù)據(jù)我們可以了解到每一個CDN節(jié)點(diǎn)的質(zhì)量,以及它服務(wù)的域名是哪些,通過這個分析我們就可以去實(shí)時(shí)的調(diào)度,例如去調(diào)度最終用戶的App,或者是他們的DNS的解析,來幫助他訪問更快更好的節(jié)點(diǎn)。這里面也會用到聽云的Network的30萬監(jiān)測點(diǎn),比如說某一個區(qū)域的用戶覆蓋量不夠的話,我就會通過聽云Controller去調(diào)動這些監(jiān)測節(jié)點(diǎn),對于某些域名或者某些URL單獨(dú)去訪問,把這個數(shù)據(jù)補(bǔ)充回來。如果那些地方可能沒有你的真實(shí)用戶,我們也可以通過聽云Controller把數(shù)據(jù)補(bǔ)充回來,最終這些數(shù)據(jù)都會通過后面的途徑下發(fā)到用戶的App,或者是DNS上去。
下面是我們大概整個系統(tǒng)的原理圖,一個拓?fù)浼軜?gòu)圖。就像上面我們說的,聽云Controller會從聽云App和Browser里面拿數(shù)據(jù),那里面是我們所有的聽云App、聽云Browser的真實(shí)用戶訪問數(shù)據(jù)。這些數(shù)據(jù)會經(jīng)過中間的系統(tǒng)匯聚,并且進(jìn)行一定的數(shù)據(jù)清理。在這個過程中我們會把一些不存在的,比如把解析不出來的域名通過旁邊的區(qū)域,有一個接口可以發(fā)送到其他廠商的HTTP、DNS的服務(wù)上去,補(bǔ)充我的數(shù)據(jù)。最終數(shù)據(jù)會放到數(shù)據(jù)庫里面,這部分其實(shí)現(xiàn)在是分布式的存儲,會做實(shí)時(shí)的數(shù)據(jù)區(qū)分有10分鐘、30分鐘、一個小時(shí)以上,還有24小時(shí)的數(shù)據(jù)在里面。

通過這些數(shù)據(jù)的匯聚跟聚合,我們會通過App來給大家去提供服務(wù)。這中間有一個調(diào)度系統(tǒng),實(shí)時(shí)的從數(shù)據(jù)庫里面把數(shù)據(jù)抽取出來快速做調(diào)度,這種情況下我們會提供三種服務(wù),目前我們提供是SDK的服務(wù),只要裝了聽云App的SDK,把里面的開關(guān)打開以后就可以幫助你調(diào)度CDN的服務(wù),你訪問你的CDN就不需要再去走DNS,而是通過聽云的調(diào)度系統(tǒng)幫你去調(diào)度的。同時(shí)我們也會開放一些open API,你不想用SDK,那你就可以從API那邊獲取,把數(shù)據(jù)拉出來。同時(shí)我們也會提供DNS解析服務(wù),我們會跟第三方的DNS廠商、DNS平臺做合作,我們會把結(jié)果給他,通過他去做更好的調(diào)度。所以這是整個聽云的調(diào)度系統(tǒng),也就是我們的數(shù)據(jù)是怎么處理的,以及這個數(shù)據(jù)最終輸出以后可以幫助你干什么。
所以這里其實(shí)我們就已經(jīng)繞過了DNS劫持,每次應(yīng)用啟動的時(shí)候,就會通過App的接口從聽云的調(diào)度系統(tǒng)里面拉一份數(shù)據(jù),這個數(shù)據(jù)里面就會包含各個CDN節(jié)點(diǎn)在一段時(shí)間的性能,我可以根據(jù)這個數(shù)據(jù)在訪問的時(shí)候去攔截用戶的請求,程序可以不需要任何修改,在攔截請求的時(shí)候就可以幫助你把DNS去掉,直接去連IP地址。通過這種方式的話我們可以提供基于App的加速,并且可以更好的去繞過DNS,大家知道對內(nèi)容劫持的話沒有太好的方法,通過這種方式就可以把DNS繞過去。
下面這張圖是我們后端數(shù)據(jù)的架構(gòu),保證數(shù)據(jù)可以快速的做分布式查詢,提高它的查詢效率。另外一個是服務(wù)器為了去提高一些唯一值,還有統(tǒng)計(jì)值查詢效率。最上面會有一個自己維護(hù)的分區(qū)服務(wù),會動態(tài)去擴(kuò)張整個數(shù)據(jù)庫,不需要人工的去維護(hù)來快速的擴(kuò)展,因?yàn)槲覀儗?shí)際上現(xiàn)在數(shù)據(jù)量還是非常大的,對于流失的數(shù)據(jù)實(shí)時(shí)的進(jìn)行處理。

三、最佳實(shí)踐
我們拿某個客戶的數(shù)據(jù)基于剛才的系統(tǒng)分析以后,出來的一個結(jié)果,我們可以了解到每一個最終用戶的區(qū)域,根據(jù)他的GPS信息、IP地址信息來獲取他來到了哪一個CDN的節(jié)點(diǎn)。我們可以展示每一個域名它的平均性能,以及過去一段時(shí)間它的平均的可用性是什么樣的,以及每一個CDN節(jié)點(diǎn)它的目標(biāo),設(shè)備組里面都提供了什么樣的服務(wù),都可以非常詳細(xì)的展示這些數(shù)據(jù)。這些數(shù)據(jù)實(shí)際上是就是我們CDN調(diào)度的基礎(chǔ)數(shù)據(jù),也就是什么區(qū)域的節(jié)點(diǎn)在覆蓋什么區(qū)域的用戶,通過這個我們可以去更好的調(diào)度CDN節(jié)點(diǎn)。
實(shí)際上我們對這個系統(tǒng)也做了一些測試,上面這個數(shù)據(jù)是基于一個90k左右的圖片,一開始我們用了兩家服務(wù)商,后來引入了第三家、第四家,這里面我們先去用CDN自己提供DNS解析的方式去做,另外一個是利用聽云Controller SDK做對比,這兩個都會在同一些節(jié)點(diǎn)上做監(jiān)測。最終可以發(fā)現(xiàn)整個性能的提升,大概提升了120毫秒左右的性能。同時(shí)也包含可用性的一些對比,比如說原來可能會因?yàn)镈NS解析失敗,或者是節(jié)點(diǎn)的故障失敗導(dǎo)致的問題,現(xiàn)在的可用性也有很大幅度的提升。還可以去對比節(jié)點(diǎn)的數(shù)量,我們可以去覆蓋的更多、更廣的節(jié)點(diǎn),最后承載這個服務(wù)的節(jié)點(diǎn)數(shù)比原來要多了很多。

所以通過聽云Controller,我們對剛才最開始提出來的那幾個問題給了一個比較完整的解決方案,甚至是更塊更好的方案。這時(shí)候就不需要更多的人力,也不需要聽云監(jiān)控的客服再給你打電話,讓你切換DNS、切換CDN,整個東西都可以利用這套系統(tǒng)自己完成:
如果是運(yùn)營商故障 的時(shí)候,如果你有使用多家CDN,其中有一家出現(xiàn)大面積的故障的話,可以通過聽云Controller繞過它,可以幫你快速的把故障點(diǎn)切掉。
如果是邊緣節(jié)點(diǎn)故障 ,也能幫你切掉,比如發(fā)現(xiàn)某一些區(qū)域的用戶達(dá)到不了某些節(jié)點(diǎn)的話,可以給他新的路由策略,把這部分用戶路由切到某些沒有過載、沒有故障的節(jié)點(diǎn)上去,可以幫你引導(dǎo)更好的解決方案。
剛才說過了繞過DNS劫持 ,如果你用的是SDK的話,就不會去走你的DNS,因?yàn)樵诿看螒?yīng)用啟動的時(shí)候我們都會拉一份你的配置表,告訴你應(yīng)該去訪問哪些IP地址,這個配置表實(shí)際上是可以去實(shí)時(shí)刷新的,在任何時(shí)刻只要你當(dāng)?shù)貢霈F(xiàn)一些訪問不了的情況的話,這個配置表就會在40秒的過程中更新,然后告訴你,你應(yīng)該去走哪一些好的路由。這時(shí)候因?yàn)椴辉儆肈NS解析,那DNS劫持也就不存在了。
以上就是我們整個聽云Controller for CDN的實(shí)踐分享,實(shí)際上我們做這個的目的很明確,從去年開始整個CDN行業(yè)發(fā)生了很大的變化,玩家更多、價(jià)格更低,這里面對于一些創(chuàng)業(yè)公司或者小公司的話,他不會有太大的優(yōu)勢,基本上大家選的時(shí)候都會去看一些資源比較好、或者是老品牌的公司。但實(shí)際上小公司有自己的一些服務(wù)特點(diǎn),有自己的技術(shù),并且甚至有一些區(qū)域他覆蓋的更好。用戶如果不測試是不知道的,所以聽云做這個事情的目的是幫助大家去更好的選擇符合自己需求和要求的CDN服務(wù)商,能讓你的流量在不同家的CDN之間去快速、實(shí)時(shí)的互相切換。將來在我們產(chǎn)品里面你會有一個選項(xiàng),可以選擇你是用戶體驗(yàn)優(yōu)先,還是性價(jià)比優(yōu)先,我們會根據(jù)你的需求設(shè)置一些價(jià)格策略,去幫助你做更好的調(diào)度CDN,來幫助你節(jié)省最終成本。之前需要專門溝通CDN廠商的人都不需要了,你可以依賴這套系統(tǒng)幫助你實(shí)時(shí)的切換、調(diào)度。
Q&A
Q1:請問Wood老師,除了傳統(tǒng)切入DNS,聽云Controller是怎么做的?
Wood:聽云Controller for CDN我們目前只提供SDK,后續(xù)會提供基于DNS的方案,我們會跟國內(nèi)的DNS廠商合作,把結(jié)果給他們,當(dāng)然也不排除將來聽云也會提供類似的服務(wù)。
Q1補(bǔ)充:也就是說DNS以后的方案有可能是我們的域名給到聽云,然后由聽云來進(jìn)行調(diào)度?
Wood:對。
Q2:剛才說到在不同的CDN服務(wù)商之間進(jìn)行切換的時(shí)候,一般的App可能圖片、數(shù)據(jù)都在一個CDN服務(wù)商上面。進(jìn)行不同切換的時(shí)候,是不是多個服務(wù)商上面都要有數(shù)據(jù)?
Wood:是的。我們在切換的時(shí)候會保證你在那邊實(shí)際上有數(shù)據(jù)的,因?yàn)槲覀冊谶@里面會做一些驗(yàn)證,比如說你大數(shù)據(jù)的數(shù)據(jù)在A上,我們是不會切過去的。
Q3:我想問一下我們用SDK的話,是不是我們先需要跟CDN廠商有一個賬號,有了一個服務(wù)之后再用。還是說我沒有和任何CDN有合作的話,用聽云的SDK就行?
Wood:你需要先跟CDN服務(wù)商簽合同,有他們服務(wù)。我們的SDK只做調(diào)度,不做CDN的加速。
特別提醒:本網(wǎng)信息來自于互聯(lián)網(wǎng),目的在于傳遞更多信息,并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí),對本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾,并請自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益,請及時(shí)聯(lián)系我們,本站將會在24小時(shí)內(nèi)處理完畢。