構(gòu)建自身的CDN會出現(xiàn)什么快樂和益處？

假如你所聞,我也喜歡網(wǎng)頁頁面能迅速載入,越是快就越好.但我們開始探討以前,需先有一個清晰的認(rèn)知能力:CDN并非全能的.假如由于槽糕的前端工作造成你網(wǎng)址減緩,CDN根本無法幫到你過多,你必須先搞好前端工作.但一旦你早已搞好了每一個提升,就必須來探討一下具體內(nèi)容傳送這方面了.

我碰見的關(guān)鍵問題是即便可以通過一次HTTP要求來進行原始網(wǎng)址的載入,但由于我的主機托管在佛羅倫薩,在澳大利亞得人仍必須等候2-3秒后才可以瀏覽到它.超出300ms的來回延遲和正中間很多的服務(wù)供應(yīng)商促使頁面加載就跟WordPress網(wǎng)站一樣慢.

那怎樣擺脫困境呢?一種解決方法是采用傳統(tǒng)化的CDN.但是大部分商業(yè)服務(wù)CDN在從服務(wù)器要求到信息以后,都是會緩存文件一段時間.

因為CDN的存有,在具體內(nèi)容獲得上略微繞道了一下,造成使用傳統(tǒng)式CDN以后,原始網(wǎng)頁頁面的載入反倒減緩了.如果你的網(wǎng)站訪問量高,具體內(nèi)容一直緩存文件著,這沒有什么問題.但換個角度來看,假如和我一樣只是運作一個小博主,具體內(nèi)容并不會長駐緩存文件,傳統(tǒng)式的pull-CDN反倒會使網(wǎng)址越來越變慢.自然,我也可以根據(jù)push-CDN立即提交具體內(nèi)容,但跟我要構(gòu)建的CDN對比,這類成本費要價格昂貴很多.

CDN是如何工作的?

他們的計劃方案很確立:為了能擴張全球知名度,我們應(yīng)該確保具體內(nèi)容在任意部位都能被桌面搜索.這代表著具體內(nèi)容地理位置應(yīng)當(dāng)盡可能挨近來訪者.便捷是指,許多云服務(wù)商在好幾個地域都帶來了便宜的云服務(wù)器.大家是不是僅必須把信息放進例如6臺服務(wù)器上,就萬事如意了呢?

行吧,沒那么快.那怎樣把客戶路由器到準(zhǔn)確的服務(wù)器上呢?大家看一下具體訪問網(wǎng)站的全過程.最先,電腦瀏覽器根據(jù)DNS查詢系統(tǒng)的IP地址,得到到IP以后,就能夠聯(lián)接網(wǎng)址并免費下載要求的網(wǎng)頁.

頂層的解決方法其實不是很難:要一臺智能化DNS服務(wù)器,對申請的IP做GeoIP查看并回到離它近期的IP地址.實際上,幾乎所有的商業(yè)服務(wù)CDN全是這么做的.盡管還牽涉到很多水利學(xué)行業(yè)的具體內(nèi)容,例如延遲時間精確測量等,但基本概念還是這個.

讓DNS服務(wù)器快起來

下面一個新的難題出現(xiàn)了:怎么讓DNS服務(wù)器快起來?從近期連接點上訪問網(wǎng)站只是解決了一半難題,假如DNS搜索迫不得已繞道地球上一周,或是會出現(xiàn)巨大的延遲時間.

事實上,支撐點互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施建設(shè)特別適合擺脫困境.互聯(lián)網(wǎng)服務(wù)提供商應(yīng)用界限網(wǎng)關(guān)協(xié)議來互相告之可聯(lián)接的互聯(lián)網(wǎng)和躍點的是多少.大部分前提下,最后互聯(lián)網(wǎng)技術(shù)服務(wù)提供商會選用最短路線來抵達(dá)總體目標(biāo)詳細(xì)地址.

要是在好幾個部位應(yīng)用一個IP地址,DNS一直會路由器到近期的連接點,這就是BGPAnycast.

為什么網(wǎng)站不使用BGPAnycast?

假如能做到,大家為什么不容易應(yīng)用BGP來路由器數(shù)據(jù)流量呢?主要是有三個緣故.

最先,應(yīng)用BGPAnycast必須在網(wǎng)絡(luò)硬件上做操縱,而且必須一個最少包括256個IP地址的水池,這超過了他們的費用預(yù)算.

次之,BGP路由器并不那么平穩(wěn).有別于DNS要求只是只必須向2個方位推送單獨數(shù)據(jù)文件,HTTPweb要求必須建立一個聯(lián)接來下載內(nèi)容.期內(nèi)假如路由器更改或是聯(lián)接不穩(wěn)定,HTTP聯(lián)接便會斷掉.對這些經(jīng)營規(guī)模的項目而言反倒增強了許多多元性.

最終,躍點做為BGP路由器測算基本,它數(shù)量的減少根本無法確保來回延遲時間的減少.一個跨現(xiàn)大洋的躍點很有可能只是一個躍點,但卻是時間最長的一個.

建立DNS

即然早已確定不可以運作我們自己的BGPAnycast,也代表一樣不可以運作我們自己的DNS服務(wù)器.讓我們?nèi)フ艺沂召M標(biāo)準(zhǔn)的!…事實上,與此同時給予BGPAnycast和延遲時間路由器的DNS服務(wù)提供商難以尋找.我只檢索到2個:非常價格昂貴的Dyn和非常便宜的AmazonRoute53.(升級:后來發(fā)現(xiàn),DNSMadeEasy也可以完成延遲時間路由器)即然想劃算,就選Route53了.加上網(wǎng)站域名以后逐漸為設(shè)備設(shè)定IP.我們應(yīng)該設(shè)定跟大家遍及全世界的(邊沿連接點)網(wǎng)絡(luò)服務(wù)器一樣多的是DNS紀(jì)錄,每一條紀(jì)錄設(shè)定如下所示:

提醒:最好是對每一個邊沿連接點都建立一個健康體檢便于在她們無效后開展清除.

派發(fā)具體內(nèi)容

我們應(yīng)該處理的下一個問題是派發(fā)具體內(nèi)容.每一個邊沿連接點都要有同樣的信息.假如你使用的是Jekyll這種靜態(tài)網(wǎng)頁制作器,工作中非常簡單:只必須將產(chǎn)生的HTML文件復(fù)制到每一個服務(wù)器上就可以.一個簡易的rsync就可解決.

如果要應(yīng)用WordPress這種內(nèi)容編輯系統(tǒng)軟件,工作艱難的多,因為它根本無法在CDN上運作.自然也能做,但難免會有缺點,靜態(tài)數(shù)據(jù)具體內(nèi)容的派發(fā)仍是一個問題.你很有可能一定要建立一個分布式系統(tǒng)才可以正常工作.

應(yīng)用SSL/TLS資格證書

下一個困擾是應(yīng)用SSL/TLS資格證書.事實上,能夠通稱她們?yōu)?x509資格證書.每一個邊沿連接點都要為網(wǎng)站域名設(shè)定合理的資格證書.自然,最簡單的解決方法是應(yīng)用LetsEncrypt來形成不一樣的資格證書.但需要注意,我還在其中一個邊沿連接點上碰上了LE有效期限的難題,造成在每星期額度期滿以前我不得不臨時把英國倫敦連接點下掉.

我應(yīng)用Traefik做為我們的選擇代理商,它適用分布式系統(tǒng)健值儲存,乃至適用ApacheZookeeper后面同歩.盡管這須要一些編程設(shè)計,可在長久看來會更平穩(wěn)一些.

結(jié)論

現(xiàn)在是時候檢測一下結(jié)果了,我自己的CDN主要表現(xiàn)如何呢?應(yīng)用這一專用工具,看一下整體數(shù)據(jù)信息:

假如你所聞,相當(dāng)不錯的結(jié)論.我或許還要在亞洲地區(qū)和南美洲加2個連接點來提升載入時長.

升級:在把它遞交到HackerNews主頁以后,我可以用GoogleAnalytics來整理一些具體應(yīng)用數(shù)據(jù)信息:

結(jié)果:我的確必須一個馬來西亞連接點.在印尼的讀取時長超過了預(yù)估的1秒.

疑難問題

我還在做此項工作的時候,大家常常跟我說:”你為什么要做這個呢?你這是怨天尤人啊“.的確,在某種意義上,我喜歡做不一樣的事兒來探尋新方向和新技術(shù)性,創(chuàng)建自身的CDN很有可能具備較大的作用.使我們來談一談有關(guān)設(shè)定的一些問題.

最先聲明:假如商業(yè)服務(wù)服務(wù)提供商能發(fā)布價格實惠的pushCDN,要我能解決niceURLs,SSL和自定頭信息內(nèi)容,我肯定愿意掏錢解決困難并停用我自己的基礎(chǔ)設(shè)施建設(shè).構(gòu)建它非常有趣,但我還有很多網(wǎng)絡(luò)服務(wù)器并沒有運作它.

為什么無需CloudFlare?

對好多人而言CloudFlare是一個挺不錯的專用工具,但如上所述,CDN是從緩存文件中清除未使用的具體內(nèi)容.我管理方法的其他網(wǎng)站,在恰當(dāng)配備的前提下緩存文件準(zhǔn)確率大約能做到75%.擁有自己的CDN則代表著具體內(nèi)容會長駐緩存文件,不容易有瀏覽虛擬服務(wù)器而致使的來回延遲.

為什么無需S3或CloudFront?

AmazonS3有代管靜態(tài)網(wǎng)頁的選擇項,同時能夠與CloudFront融合著應(yīng)用.但是,它不允許你自定緩存文件頭信息內(nèi)容,設(shè)定niceURLs等.因此,你必須應(yīng)用Lambda@Edge,這也是一個可以使你在CloudFront邊沿連接點上運行代碼的專用工具.但Lambda@Edge跟CDN有同樣的問題:假如它在一段時間內(nèi)并沒有接受到要求,運作它器皿便會關(guān)掉,再度重新啟動則必須一秒鐘的的時間.

為什么無需GoogleAMP?

GoogleAMP只會在客戶根據(jù)Google搜索模塊瀏覽你網(wǎng)址時才能產(chǎn)生實際效果.可是我的絕大多數(shù)總流量并不是來源于Google,因此它根本無法解決困難.它只是對Google有實際效果,無論別的.而且我徹底有實力在不使用她們帶來的簡單化HTML的前提下構(gòu)建一個迅速網(wǎng)址.

誰在意?3秒的載入時長早已非常好了!

我是一個善于具體內(nèi)容傳送的DevOps技術(shù)工程師.無論別人怎樣,我還應(yīng)當(dāng)有一個全世界都可以桌面搜索的網(wǎng)址,不是嗎?我一般都會將GoogleAMP關(guān)掉,由于跟他們所希望的不一樣,這也是一項糟心的技術(shù)性.

構(gòu)建

現(xiàn)在看你的了:是不是要構(gòu)建你自己的CDN?源碼在GitHub上,拿走吧!