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的工程團隊就認(rèn)識到了其中的主要挑戰(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詳細(xì)解釋了他們的試機（即生產(chǎn)系統(tǒng)前）設(shè)置：

我們具有一個標(biāo)準(zhǔn)的CI/CD平臺，我們在其中實現(xiàn)了Docker構(gòu)建，并將這些部署到開發(fā)環(huán)境。一旦抵達“試機”階段，我們就將鏡像標(biāo)記為“試機”，這樣的鏡像就進入到一個“全新設(shè)計”（Clean Slate）狀態(tài)。我們有一個運行試機的數(shù)據(jù)中心，在該數(shù)據(jù)中心處理了近10%的全球流量。一旦我們可對發(fā)布版本做標(biāo)記，我們就將Docker鏡像標(biāo)簽修改為“master”，并將該鏡像在所有的數(shù)據(jù)中心中滾動到生產(chǎn)環(huán)境。當(dāng)需要回滾時，我們僅需要在注冊項中更改Docker鏡像標(biāo)簽，這樣鏡像將在下一次運行“全新設(shè)計”時得以重置。因此，可以說我們每日都會做一次部署，但是這在很多情況下并非一個新的發(fā)布版?？梢哉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)境負(fù)載和流量模式。但這通常是不夠的，對此Loveless指出，Edgemesh的策略是“確保軟件版本可以快速地遷移到生產(chǎn)環(huán)境”。

每天都重置那些在基礎(chǔ)規(guī)模上會自動向上擴展的實例的規(guī)模，這是“全新設(shè)計”策略的一部分，并在每個數(shù)據(jù)中心得以實施。如果數(shù)據(jù)中心正承受著高流量和重置后基線（開始）狀態(tài)無法處理的問題，Edgemesh需要確保客戶不會察覺這些錯誤。Loveless解釋了這一實現(xiàn)機制：

當(dāng)數(shù)據(jù)中心A開始“全新設(shè)計”時，首先要做的就是從DNS條目中注銷自身。我們在DNS記錄上運行低TTL（每30秒），中間暫停五分鐘，使得有時間確保所有流量被重定向到數(shù)據(jù)中心B和C。五分鐘后，數(shù)據(jù)中心A開始“全新設(shè)計”。當(dāng)A重新在線后，它重新注冊到DNS服務(wù)器，開始接收流量。進而數(shù)據(jù)中心B開始“全新設(shè)計”（這是在A發(fā)送允許B知道A重新恢復(fù)在線并接收流量的消息后）。在這一轉(zhuǎn)換中，為處理一些額外的負(fù)載，數(shù)據(jù)中心B和C通常將會向上擴展。

查看英文原文： How Edgemesh Rolled Out Its P2P Web Acceleration Service to Production