Edgemesh提供了一種基于WebRTC協(xié)議族的P2P Web加速服務(wù),可將通常由傳統(tǒng)CDN處理的部分流量分流給一些基于瀏覽器在P2P網(wǎng)絡(luò)上共享的緩存。在最近幾個月中,Edgemesh實現(xiàn)了將版本推送到生產(chǎn)環(huán)境,他們分享了這一做法。
Edgemesh的技術(shù)依賴于一種“中繼”網(wǎng)絡(luò),該網(wǎng)絡(luò)由使用WebRTC協(xié)議族的終端用戶瀏覽器創(chuàng)建。傳統(tǒng)的CDN具有全球范圍內(nèi)的邊緣節(jié)點(Edge Location),通過定位接近終端用戶的邊緣節(jié)點,降低了對終端用戶的延遲。Edgemesh的緩存內(nèi)容位于用戶瀏覽器上,通常瀏覽器也是這樣做的,只是位于二級緩存上。該緩存內(nèi)容使瀏覽器可以相互通信而提供內(nèi)容,而非通過CDN定位并獲取內(nèi)容。要啟用Edgemesh,需要在Web頁面上運行一個JavaScript小程序。這在生產(chǎn)環(huán)境中意味著Edgemesh的客戶端JavaScript可運行于上千的瀏覽器上,跨越多個地理區(qū)域。這種中繼網(wǎng)絡(luò)被稱為“網(wǎng)格”(Mesh)。
Edgemesh使用了Docker容器作為基礎(chǔ)開發(fā)單元。其架構(gòu)運行于SmartOS區(qū)域的Joyent公開云上,是運行在真實的物理機上,而非在虛擬機上。Edgemesh使用Joyent的Autopilot模式管理容器,這使得容器可獲得更高度的操作自治性。數(shù)據(jù)庫系統(tǒng)同樣也通過Triton運行在容器內(nèi)。數(shù)據(jù)庫文件、日志文件等的狀態(tài)信息通過Joyent Manta存儲在穩(wěn)定存儲中,并在Google's Storage Platform上具有二級備份。
在4月1日啟動向生產(chǎn)系統(tǒng)的遷移之前,Edgemesh的工程團隊就認識到了其中的主要挑戰(zhàn),包括:無需客戶輸入就能調(diào)試生產(chǎn)環(huán)境中錯誤的能力、自動化受限于時間的更新發(fā)布、跨五百個網(wǎng)絡(luò)的“網(wǎng)格”、跨五十個國家的近1TB數(shù)據(jù)下線到“網(wǎng)格”中。到5月26日,團隊開始讓傳入流量全面進入到“網(wǎng)格”中。在一周的時間內(nèi),來自于原始客戶服務(wù)器的TB級流量已有半數(shù)以上被下載到“網(wǎng)格”中,平均客戶頁面的加載時間下降了33%。期間,團隊持續(xù)地測量和監(jiān)控著各種度量,包括“網(wǎng)格”的大小,及獨立頁面的加載時間。一旦Edgemesh客戶遇上錯誤,Edgemesh就會退出,讓瀏覽器恢復(fù)正常的操作。從錯誤中采集的數(shù)據(jù)會匯報給Edgemesh,用于對錯誤的分析。
在部署軟件到生產(chǎn)環(huán)境的過程中,團隊使用了三個指導(dǎo)原則。前兩個原則分別是通過自動化維持一致性,以及通過周期性重建基礎(chǔ)設(shè)施減少異常實體的攻擊表面。第三個原則是從最小可能值啟動而節(jié)約成本,這更像是前兩個原則的輸出。
為深入了解Edgemesh在推出到生產(chǎn)環(huán)境中所面對的DevOps挑戰(zhàn),InfoQ采訪了Edgemesh的CEO Jacob Loveless。在問及Edgemesh對Docker基礎(chǔ)設(shè)施所使用的監(jiān)控工具類型時,Loveless給出了如下的回答:
對系統(tǒng)狀態(tài),我們使用了Prometheus。此外我們還具有一個內(nèi)部系統(tǒng),用于給出錯誤和消息類型記錄等信息(例如,來自于客戶的WebRTC統(tǒng)計)。這些度量有助于每個應(yīng)用確定請求向上擴展的時機。
Edgemesh的大部分代碼存在于客戶端,這一分布特性使得如何確保發(fā)布到生產(chǎn)環(huán)境前系統(tǒng)的純潔性成為一個重要挑戰(zhàn)。Loveless詳細解釋了他們的試機(即生產(chǎn)系統(tǒng)前)設(shè)置:
我們具有一個標準的CI/CD平臺,我們在其中實現(xiàn)了Docker構(gòu)建,并將這些部署到開發(fā)環(huán)境。一旦抵達“試機”階段,我們就將鏡像標記為“試機”,這樣的鏡像就進入到一個“全新設(shè)計”(Clean Slate)狀態(tài)。我們有一個運行試機的數(shù)據(jù)中心,在該數(shù)據(jù)中心處理了近10%的全球流量。一旦我們可對發(fā)布版本做標記,我們就將Docker鏡像標簽修改為“master”,并將該鏡像在所有的數(shù)據(jù)中心中滾動到生產(chǎn)環(huán)境。當需要回滾時,我們僅需要在注冊項中更改Docker鏡像標簽,這樣鏡像將在下一次運行“全新設(shè)計”時得以重置。因此,可以說我們每日都會做一次部署,但是這在很多情況下并非一個新的發(fā)布版。可以說我們每五到十天發(fā)布一個完全發(fā)布版到生產(chǎn)環(huán)境。
這里的“全新設(shè)計”指的是Edgemesh日常重建數(shù)據(jù)中心容器的方式。這確保Edgemesh可以堅持執(zhí)行上面所提出的三個部署原則。
通過允許試機設(shè)置去接收生產(chǎn)環(huán)境數(shù)據(jù),并輔以易于回滾更改的機制,Edgemesh模擬了代碼會在生產(chǎn)環(huán)境中遇上的一些生產(chǎn)環(huán)境負載和流量模式。但這通常是不夠的,對此Loveless指出,Edgemesh的策略是“確保軟件版本可以快速地遷移到生產(chǎn)環(huán)境”。
每天都重置那些在基礎(chǔ)規(guī)模上會自動向上擴展的實例的規(guī)模,這是“全新設(shè)計”策略的一部分,并在每個數(shù)據(jù)中心得以實施。如果數(shù)據(jù)中心正承受著高流量和重置后基線(開始)狀態(tài)無法處理的問題,Edgemesh需要確保客戶不會察覺這些錯誤。Loveless解釋了這一實現(xiàn)機制:
當數(shù)據(jù)中心A開始“全新設(shè)計”時,首先要做的就是從DNS條目中注銷自身。我們在DNS記錄上運行低TTL(每30秒),中間暫停五分鐘,使得有時間確保所有流量被重定向到數(shù)據(jù)中心B和C。五分鐘后,數(shù)據(jù)中心A開始“全新設(shè)計”。當A重新在線后,它重新注冊到DNS服務(wù)器,開始接收流量。進而數(shù)據(jù)中心B開始“全新設(shè)計”(這是在A發(fā)送允許B知道A重新恢復(fù)在線并接收流量的消息后)。在這一轉(zhuǎn)換中,為處理一些額外的負載,數(shù)據(jù)中心B和C通常將會向上擴展。
查看英文原文: How Edgemesh Rolled Out Its P2P Web Acceleration Service to Production