為什麼要做增量更新
美團金融的業務在過去的一段時間裡發展非常快速。在業務增長的同時，我們也注意到，很多用戶的支付環境，其實是在弱網環境中的。
大家知道，前端能夠服務用戶的前提是 JavaScript 和 CSS 等靜態資源能夠正確加載。如果網絡環境惡劣，那麼我們的靜態資源尺寸越大，用戶下載失敗的概率就越高。
根據我們的數據統計，我們的業務中有2%的用戶流失與資源加載有關。因此每次更新的代價越小、加載成功率越高，用戶流失率也就會越低，從而就能夠變相提高訂單的轉化率。
作為一個發版頻繁的業務，要降低發版的影響，可以做兩方面優化：
- 更高效地使用緩存，減少靜態資源的重複下載。使用增量更新，降低單次發版時下發的內容尺寸。
針對第一點，我們有自己的模塊加載器來做，這裡先按下不表，我們來重點聊聊增量更新的問題。
增量更新是怎麼一個過程
看圖說話。
圖1 增量更新的客戶端流程圖
我們的增量更新通過在瀏覽器端部署一個 SDK 來發起，這個 SDK 我們稱之為 Thunder.js 。
Thunder.js 在頁面加載時，會從頁面中讀取最新靜態資源的版本號。同時， Thunder.js 也會從瀏覽器的緩存（通常是 localStorage）中讀取我們已經緩存的版本號。這兩個版本號進行匹配，如果發現一致，那麼我們可以直接使用緩存當中的版本；反之，我們會向增量更新服務發起一個增量補丁的請求。
增量服務收到請求後，會調取新舊兩個版本的文件進行對比，將差異作為補丁返回。Thunder.js 拿到請求後，即可將補丁打在老文件上，這樣就得到了新文件。
總之一句話：老文件 + 補丁 = 新文件。
增量補丁的生成，主要依賴於 Myers 的 diff 算法。生成增量補丁的過程，就是尋找兩個字符串最短編輯路徑的過程。算法本身比較複雜，大家可以在網上找一些比較詳細的算法描述，比如這篇 《The Myers diff algorithm》，這裡就不詳細介紹了。
補丁本身是一個微型的 DSL（Domain Specific Language）。這個 DSL 一共有三種微指令，分別對應保留、插入、刪除三種字符串操作，每種指令都有自己的操作數。
例如，我們要生成從字符串“abcdefg”到“acdz”的增量補丁，那麼一個補丁的全文就類似如下：
=1\t-1\t=2\t-3\t+z
這個補丁當中，製表符\t是指令的分隔符，=表示保留，-表示刪除，+表示插入。整個補丁解析出來就是：
- 保留1個字符刪除1個字符保留2個字符刪除3個字符插入1個字符：z
具體的 JavaScript 代碼就不在這裡粘貼了，流程比較簡單，相信大家都可以自己寫出來，只需要注意轉義和字符串下標的維護即可。
增量更新其實不是前端的新鮮技術，在客戶端領域，增量更新早已經應用多年。看過我們《美團金融掃碼付靜態資源加載優化實踐》的朋友，應該知道我們其實之前已有實踐，在當時僅僅靠增量更新，日均節省流量達30多GB。而現在這個數字已經隨著業務量變得更高了。
那麼我們是不是就已經做到萬事無憂了呢？
我們之前的增量更新實踐遇到了什麼問題
我們最主要的問題是增量計算的速度不夠快。
之前的優化實踐中，我們絕大部分的優化其實都是為了優化增量計算的速度。文本增量計算的速度確實慢，慢到什麼程度呢？以前端比較常見的JS資源尺寸——200KB——來進行增量計算，進行一次增量計算的時間依據文本不同的數量，從數十毫秒到十幾秒甚至幾十秒都有可能。
對於小流量業務來說，計算一次增量補丁然後緩存起來，即使第一次計算耗時一些也不會有太大影響。但用戶側的業務流量都較大，每月的增量計算次數超過 10 萬次，併發計算峰值超過 100 QPS 。
那麼不夠快的影響是什麼呢？
圖2 Node.js 的事件循環
我們之前的設計大致思想是用一個服務來承接流量，再用另一個服務來進行增量計算。這兩個服務均由 Node.js 來實現。對於前者， Node.js 的事件循環模型本就適合進行 I/O 密集型業務；然而對於後者，則實際為 Node.js 的軟肋。 Node.js 的事件循環模型，要求 Node.js 的使用必須時刻保證 Node.js 的循環能夠運轉，如果出現非常耗時的函數，那麼事件循環就會陷入進去，無法及時處理其他的任務。常見的手法是在機器上多開幾個 Node.js 進程。然而一臺普通的服務器也就8個邏輯CPU而已，對於增量計算來說，當我們遇到大計算量的任務時，8個併發可能就會讓 Node.js 服務很難繼續響應了。如果進一步增加進程數量，則會帶來額外的進程切換成本，這並不是我們的最優選擇。
更高性能的可能方案
“讓 JavaScript 跑的更快”這個問題，很多前輩已經有所研究。在我們思考這個問題時，考慮過三種方案。
Node.js Addon
Node.js Addon 是 Node.js 官方的插件方案，這個方案允許開發者使用 C/C++ 編寫代碼，而後再由 Node.js 來加載調用。由於原生代碼的性能本身就比較不錯，這是一種非常直接的優化方案。
ASM.js / WebAssembly
後兩種方案是瀏覽器側的方案。
其中 ASM.js 由 Mozilla 提出，使用的是 JavaScript 的一個易於優化的子集。這個方案目前已經被廢棄了。
取而代之的 WebAssembly ，由 W3C 來領導，採用的是更加緊湊、接近彙編的字節碼來提速。目前在市面上剛剛嶄露頭角，相關的工具鏈還在完善中。 Mozilla 自己已經有一些嘗試案例了，例如將 Rust 代碼編譯到 WebAssembly 來提速 sourcemap 的解析。
然而在考慮了這三種方案之後，我們並沒有得到一個很好的結論。這三個方案的都可以提升 JavaScript 的運行性能，但是無論採取哪一種，都無法將單個補丁的計算耗時從數十秒降到毫秒級。況且，這三種方案如果不加以複雜的改造，依然會運行在 JavaScript 的主線程之中，這對 Node.js 來說，依然會發生嚴重的阻塞。
於是我們開始考慮 Node.js 之外的方案。換語言這一想法應運而生。
換語言
更換編程語言，是一個很慎重的事情，要考慮的點很多。在增量計算這件事上，我們主要考慮新語言以下方面：
- 運行速度併發處理類型系統依賴管理社區
當然，除了這些點之外，我們還考慮了調優、部署的難易程度，以及語言本身是否能夠快速駕馭等因素。
最終，我們決定使用 Go 語言進行增量計算服務的新實踐。
選擇Go，帶來了什麼
高性能
增量補丁的生成算法，在 Node.js 的實現中，對應 diff 包；而在 Go 的實現中，對應 go-diff包。
在動手之前，我們首先用實際的兩組文件，對 Go 和 Node.js 的增量模塊進行了性能評測，以確定我們的方向是對的。
結果顯示，儘管針對不同的文件會出現不同的情況，Go 的高性能依然在計算性能上碾壓了 Node.js 。這裡需要注意，文件長度並不是影響計算耗時的唯一因素，另一個很重要的因素是文件差異的大小。
不一樣的併發模型
Go 語言是 Google 推出的一門系統編程語言。它語法簡單，易於調試，性能優異，有良好的社區生態環境。和 Node.js 進行併發的方式不同， Go 語言使用的是輕量級線程，或者叫協程，來進行併發的。
專注於瀏覽器端的前端同學，可能對這種併發模型不太瞭解。這裡我根據我自己的理解來簡要介紹一下它和 Node.js 事件驅動併發的區別。
如上文所說， Node.js 的主線程如果陷入在某個大計算量的函數中，那麼整個事件循環就會阻塞。協程則與此不同，每個協程中都有計算任務，這些計算任務隨著協程的調度而調度。一般來說，調度系統不會把所有的 CPU 資源都給同一個協程，而是會協調各個協程的資源佔用，儘可能平分 CPU 資源。
圖4 Go 的 goroutine
相比 Node.js ，這種方式更加適合計算密集與 I/O 密集兼有的服務。
當然這種方式也有它的缺點，那就是由於每個協程隨時會被暫停，因此協程之間會和傳統的線程一樣，有發生競態的風險。所幸我們的業務並沒有多少需要共享數據的場景，競態的情況非常少。
實際上 Web 服務類型的應用，通常以請求 -> 返回為模型運行，每個請求很少會和其他請求發生聯繫，因此使用鎖的場景很少。一些“計數器”類的需求，靠原子變量也可以很容易地完成。
不一樣的模塊機制
Go 語言的模塊依賴管理並不像 Node.js 那麼成熟。儘管吐槽 node_modules 的人很多，但卻不得不承認，Node.js 的 CMD 機制對於我們來說不僅易於學習，同時每個模塊的職責和邊界也是非常清晰的。
具體來說，一個 Node.js 模塊，它只需關心它自己依賴的模塊是什麼、在哪裡，而不關心自己是如何被別人依賴的。這一點，可以從 require 調用看出：
const util = require('./util');
const http = require('http');
module.exports = {};
這是一個非常簡單的模塊，它依賴兩個其他模塊，其中 util 來自我們本地的目錄，而 http 則來自於 Node.js 內置。在這種情形下，只要你有良好的模塊依賴關係，一個自己寫好的模塊想要給別人複用，只需要把整個目錄獨立上傳到 npm 上即可。
簡單來說， Node.js 的模塊體系是一棵樹，最終本地模塊就是這樣：
|- src
|- module-a
|- submodule-aa
|- submodule-ab
|- module-b
|- module-c
|- submodule-ca
|- subsubmodule-caa
|- bin
|- docs
但 Go 語言就不同了。在 Go 語言中，每個模塊不僅有一個短的模塊名，同時還有一個項目中的“唯一路徑”。如果你需要引用一個模塊，那麼你需要使用這個“唯一路徑”來進行引用。比如：
package main
import (
"fmt"
"github.com/valyala/fasthttp"
"path/to/another/local/module"
)
第一個依賴的 fmt 是 Go 自帶的模塊，簡單明瞭。第二個模塊是一個位於 Github 的開源第三方模塊，看路徑形式就能夠大致推斷出來它是第三方的。而第三個，則是我們項目中一個可複用模塊，這就有點不太合適了。其實如果 Go 支持嵌套的模塊關係的話，相當於每個依賴從根目錄算起就可以了，能夠避免出現 ../../../../root/something 這種尷尬的向上查找。但是， Go 是不支持本地依賴之間的文件夾嵌套的。這樣一來，所有的本地模塊，都會平鋪在同一個目錄裡，最終會變成這樣：
|- src
|- module-a
|- submodule-aa
|- submodule-ab
|- module-b
|- module-c
|- submodule-ca
|- subsubmodule-caa
|- bin
|- docs
現在你不太可能直接把某個模塊按目錄拆出去了，因為它們之間的關係完全無法靠目錄來斷定了。
較新版本的 Go 推薦將第三方模塊放在 vendor 目錄下，和 src 是平級關係。而之前，這些第三方依賴也是放在 src 下面，非常令人困惑。
目前我們項目的代碼規模還不算很大，可以通過命名來進行區分，但當項目繼續增長下去，就需要更好的方案了。
過於簡單的去中心化第三方包管理
和有 npm 的 Node.js 另一個不一樣是： Go 語言沒有自己的包管理平臺。對於 Go 的工具鏈來說，它並不關心你的第三方包到底是誰來託管的。 社區裡 Go 的第三方包遍佈各個 Git 託管平臺，這不僅讓我們在搜索包時花費更多時間，更麻煩的是，我們無法通過在企業內部搭建一個類似 npm 鏡像的平臺，來降低大家每次下載第三方包的耗時，同時也難以在不依賴外網的情況下，進行包的自由安裝。
Go 有一個命令行工具，專門負責下載第三方包，叫做“ go-get ”。和大家想的不一樣，這個工具沒有版本描述文件。在 Go 的世界裡並沒有 package.json 這種文件。這給我們帶來的直接影響就是我們的依賴不僅在外網放著，同時還無法有效地約束版本。同一個go-get命令，這個月下載的版本，可能到下個月就已經悄悄地變了。
目前 Go 社區有很多種不同的第三方工具來做，我們最終選擇了 glide 。這是我們能找到的最接近npm 的工具了。目前官方也在孕育一個新的方案來進行統一，我們拭目以待吧。
圖5 Go 社區的各種第三方包管理工具
對於鏡像，目前也沒有太好的方案，我們參考了 moby （就是 docker ）的做法，將第三方包直接存入我們自己項目的 Git 。這樣雖然項目的源代碼尺寸變得更大了，但無論是新人參與項目，還是上線發版，都不需要去外網拉取依賴了。
匱乏的內部基礎設施支持
Go 語言在美團內部的應用較少，直接結果就是，美團內部相當一部分基礎設施，是缺少 Go 語言 SDK 支持的。例如公司自建的 Redis Cluster ，由於根據公司業務需求進行了一些改動，導致開源的 Redis Cluster SDK ，是無法直接使用的。再例如公司使用了淘寶開源出 KV 數據庫—— Tair ，大概由於開源較早，也是沒有 Go 的 SDK 的。
由於我們的架構設計中，需要依賴 KV 數據庫進行存儲，最終我們還是選擇用 Go 語言實現了 Tair 的 SDK。所謂“工欲善其事，必先利其器”，在 SDK 的編寫過程中，我們逐漸熟悉了 Go 的一些編程範式，這對之後我們系統的實現，起到了非常有益的作用。所以有時候手頭可用的設施少，並不一定是壞事，但也不能盲目去製造輪子，而是要思考自己造輪子的意義是什麼，以結果來評判。
語言之外
要經受生產環境的考驗，只靠更換語言是不夠的。對於我們來說，語言其實只是一個工具，它幫我們解決的是一個局部問題，而增量更新服務有很多語言之外的考量。
如何面對海量突發流量
因為有前車之鑑，我們很清楚自己面對的流量是什麼級別的。因此這一次從系統的架構設計上，就優先考慮瞭如何面對突發的海量流量。
首先我們來聊聊為什麼我們會有突發流量。
對於前端來說，網頁每次更新發版，其實就是發佈了新的靜態資源，和與之對應的 HTML 文件。而對於增量更新服務來說，新的靜態資源也就意味著需要進行新的計算。
有經驗的前端同學可能會說，雖然新版上線會創造新的計算，但只要前面放一層 CDN ，緩存住計算結果，就可以輕鬆緩解壓力了不是嗎？
這是有一定道理的，但並不是這麼簡單。面向普通消費者的 C 端產品，有一個特點，那就是用戶的訪問頻度千差萬別。具體到增量更新上來說，就是會出現大量不同的增量請求。因此我們做了更多的設計，來緩解這種情況。
圖6 增量服務架構設計
這是我們對增量更新系統的設計。
放在首位的自然是 CDN 。面對海量請求，除了幫助我們削峰之外，也可以幫助不同地域的用戶更快地獲取資源。
圖7 增量服務 API 層
在 CDN 之後，我們將增量更新系統劃分成了兩個獨立的層，稱作 API 層和計算層。為什麼要劃分開呢？在過往的實踐當中，我們發現即使我們再小心再謹慎，仍然還是會有犯錯誤的時候，這就需要我們在部署和上線上足夠靈活；另一方面，對於海量的計算任務，如果實在扛不住，我們需要保有最基本的響應能力。基於這樣的考慮，我們把 CDN 的回源服務獨立成一個服務。這層服務有三個作用：
- 通過對存儲系統的訪問，如果有已經計算好的增量補丁，那麼可以直接返回，只把最需要計算的任務傳遞給計算層。如果計算層出現問題，API 層保有響應能力，能夠進行服務降級，返回全量文件內容。將對外的接口管理起來，避免接口變更對核心服務的影響。在這個基礎上可以進行一些簡單的聚合服務，提供諸如請求合併之類的服務。
那如果 API 層沒能將流量攔截下來，進一步傳遞到了計算層呢？
圖8 增量服務計算層
為了防止過量的計算請求進入到計算環節，我們還針對性地進行了流量控制。通過壓測，我們找到了單機計算量的瓶頸，然後將這個限制配置到了系統中。一旦計算量逼近這個數字，系統就會對超量的計算請求進行降級，不再進行增量計算，直接返回全量文件。
圖9 預熱的設計
另一方面，我們也有相應的線下預熱機制。我們為業務方提供了一個預熱工具，業務方在上線前調用我們的預熱工具，就可以在上線前預先得到增量補丁並將其緩存起來。我們的預熱集群和線上計算集群是分離的，只共享分佈式存儲，因此雙方在實際應用中互不影響。
如何容災
有關容災，我們總結了以往見到的一些常見故障，分了四個門類來處理。
- 線路故障。我們在每一層服務中都內置了單機緩存，這個緩存的作用一方面是可以洩洪，另一方面，如果線路出現故障，單機緩存也能在一定程度上降低對線路的依賴。存儲故障。對於存儲，我們直接採用了兩種公司內非常成熟的分佈式存儲系統，它們互為備份。CDN 故障。做前端的同學或多或少都遇到過 CDN 出故障的時候，我們也不例外。因此我們準備了兩個不同的 CDN ，有效隔離了來自 CDN 故障的風險。
最後，在這套服務之外，我們瀏覽器端的 SDK 也有自己的容災機制。我們在增量更新系統之外，單獨部署了一套 CDN ，這套 CDN 只存儲全量文件。一旦增量更新系統無法工作， SDK 就會去這套 CDN 上拉取全量文件，保障前端的可用性。
回顧與總結
服務上線運轉一段時間後，我們總結了新實踐所帶來的效果：
日均增量計算成功率日均增量更新佔比單日人均節省流量峰值項目靜態文件總量99.97%64.91%164.07 KB1184KB
考慮到每個業務實際的靜態文件總量不同，在這份數據裡我們刻意包含了總量和人均節省流量兩個不同的值。在實際業務當中，業務方自己也會將靜態文件根據頁面進行拆分（例如通過 webpack 中的 chunk 來分），每次更新實際不會需要全部更新。
由於一些邊界情況，增量計算的成功率受到了影響，但隨著問題的一一修正，未來增量計算的成功率會越來越高。
現在來回顧一下，在我們的新實踐中，都有哪些大家可以真正借鑑的點：
- 不同的語言和工具有不同的用武之地，不要試圖用錘子去鋸木頭。該換語言就換，不要想著一個語言或工具解決一切。更換語言是一個重要的決定，在決定之前首先需要思考是否應當這麼做。語言解決更多的是局部問題，架構解決更多的是系統問題。換了語言也不代表就萬事大吉了。構建一個系統時，首先思考它是如何垮的。想清楚你的系統潛在瓶頸會出現在哪，如何加強它，如何考慮它的備用方案。
對於 Go 語言，我們也是摸著石頭過河，希望我們這點經驗能夠對大家有所幫助。
閱讀更多 前端小學生 的文章
