游戲運維活動中少不了做的事情就是停服更新，可能是因為版本更新、也可能是修復 BUG，當然修復 BUG 還可以用熱修復（大部分熱修復是有限制的，這里就不細說）。但是傳統(tǒng)的游戲開發(fā)版本更新就避免不了停服更新了，目前也有些做的比較好的項目可以做到不停服更新版本。譬如：《王者榮耀》。

不停服更新的機制好處有如下幾點：
1.不停服更新可以給用戶更好的體驗，可以無縫更新。用戶只要在客戶端更新完畢就可以立刻進新版本。
2.可以做灰度發(fā)布，新版本上線前先讓一部分用戶先更新到新版本，可以對比兩個版本的數(shù)據(jù)，來驗證新版本是否達到預(yù)期
3.灰度發(fā)布可以在發(fā)現(xiàn)重大 BUG 的情況下減少損失，等待新版本穩(wěn)定后再對全部用戶開放。但是要防止測試人員因為有了這個機制而松懈，因為這個機制是為了提高用戶體驗，而不是讓用戶來做測試。

注意：不管是使用上述的哪種方案，抑或是其他方案，都會存在額外的服務(wù)器費用以及版本運維和運營的成本增加。這個不難理解，需要的服務(wù)器多了，同時維護的版本也多了，出錯的概率就更高了。如果沒有比較好的版本規(guī)劃或者沒有充分的測試，可能帶來反向效果。

下面是直觀的切版本流程：

C.png

《王者榮耀》可以在舊版本游戲開局的情況下同時進行新版本發(fā)布，并且可以讓舊版本玩家打完后再退出游戲，更新到最新版本從而進入新版本服務(wù)器。那他是怎么做的呢？沒有官方的答案，但是我想原理應(yīng)該很簡單，大致就是用滾動更新的思路。簡單說就是如果一臺服務(wù)器可以支撐 1w 在線，那么支撐 100w 在線就是 100 臺服務(wù)器，那么理論上來說，只要有第 101 臺服務(wù)器，就可以實現(xiàn)不停服更新。原理就是，新版本在第 101 臺服務(wù)器上發(fā)布。然后假設(shè)第 1 臺的用戶全退出了游戲，都進入到了第 101 這臺服務(wù)器，他們都是最新版本了，這時候再把第 1 臺服務(wù)器更新到最新服務(wù)器，第 2 臺的用戶全部退出了游戲都進入到了第 1 臺服務(wù)器，第 2 臺服務(wù)器又可以發(fā)布最新版本。。。 一直到所有人都更新到最新版本如圖：

1.png

原理是如此簡單，但是實際的實現(xiàn)起來卻沒那么容易，這里涉及到少量客戶端的支持和 web 后臺的一些工作以及高水準自動化運維（版本切換如果人工操作出問題的概率非常大）、還有 DB 數(shù)據(jù)同步，還有服務(wù)器確保同一時刻用戶只能在一個版本中的事宜，是一個系統(tǒng)性的工作，系統(tǒng)粒度越是細，性價比越高，譬如《王者榮耀》項目做這種方案，肯定很劃算。

小團隊想要做這種不停服更新需要付出的代價還是挺高的，一方面是來自服務(wù)器費用，一方面是需要開發(fā)人員很給力。而且運營過程也容易因為弄錯版本導致運營事故?？傊鷥r不算低。但是如果真想實現(xiàn)，換種實現(xiàn)方式也可以做到差不多的效果，就是滾動的單元是按整體來做滾動，不像理想狀態(tài)下的只滾動邏輯服，整體對開發(fā)人員相對少一些要求。兩組服務(wù)器來進行滾動更新，服務(wù)器要多一套，然后按單雙版本輪流更新切換。

這樣要處理的事情就簡單些了，只要確保用一個用戶在同一個時刻只能存在同一個版本服務(wù)器中，并且數(shù)據(jù)一致性得到保障，還有 web 后臺可以正確對不同版本進行操作就好了。

我這里以我目前的項目來舉例（數(shù)據(jù)庫用了 mongodb 和 redis，其他類型數(shù)據(jù)庫可能不同，mongodb 可以動態(tài)改變文檔的結(jié)構(gòu)，而 mysql 數(shù)據(jù)表結(jié)構(gòu)如果改動的情況下， 可能比較麻煩），做了兩個滾服更新方案，照例上圖

這是方案 A ，完全獨立的兩套系統(tǒng)。通過數(shù)據(jù)同步來達到目的。
這個方案的優(yōu)點就是兩套系統(tǒng)完全解耦，缺點就是如果 DB 同步?jīng)]做好，容易出現(xiàn)：數(shù)據(jù)混亂、或者是并發(fā)上不去，其中一種情況。

A.png

這是方案 B ，除了主數(shù)據(jù)庫外，各自獨立的兩套系統(tǒng)。
這個方案的好處就是不會出現(xiàn)數(shù)據(jù)混亂或者并發(fā)問題，而且主數(shù)據(jù)庫用高配置外，conf 庫可以使用比較低配置的實例，可以省較多的費用。缺點就是輕度的耦合，web 和 服務(wù)器 都有一部分讀寫相同的實例，一部分讀寫該版本才有的實例，在出現(xiàn)問題的時候定位稍微麻煩些，不過這個方案整體性價比還是比較高。

B.png

通過方案 A 或者 B 都可能做到新老版本的循環(huán)更新迭代，如版本 1 部署到 game A，版本 2 部署到 game B
版本 3 在 版本 2 跑起來， 版本 1 的人都下線的情況下，部署到 game A 如此類推。

既然在滾動更新的過程中有一段時間老版本和新版本是同時存在，那么多人交互就會出現(xiàn)版本不一致的情況，那么解決它的最好辦法就是不同版本的用戶不一起游戲。在新老版本共存期間，老版本只接受登出，不接受登陸，如果游戲是按一局為單位的，不更新到最新版本不可以進行匹配新游戲，即可。

最后我們敲定：
一、 conf 庫還在同個實例中，用 conf + 版本號 的方式，如：conf1、conf2、conf3 ... 這樣，每一個版本一個配置庫。

二、 web 后臺用一套，每次新版本發(fā)布，由 web 進行操作版本號的遞增，假如當前版本為 1，那么升級就是 + 1 為 2，對應(yīng)配置庫就是 conf2, 一旦執(zhí)行升級，老版本的配置就沒法改動了，只能改動新版本配置。版本號只會增加，不會減少，如果特殊情況下需要改動老配置，需要由技術(shù)一起配合。這個約定就是比較重要的環(huán)節(jié)，用這樣的方式來避免既有可能改老版本配置，又有可能改新版本配置帶來的混亂。

三、web 進行操作版本號遞增，分兩個階段，第一個階段是對內(nèi)開放新版本，這一期間測試人員進行內(nèi)部測試。配置也可以進行調(diào)整修改，不影響當前對外在線跑的版本。第二個階段就是由運營人員來正式發(fā)布新版本。通知所有玩家。這時候是正式滾服開始。

四、運維要做的事情就是把服務(wù)器分為 A系統(tǒng) 和 B系統(tǒng)。然后開發(fā)人員給到的運行程序會打包好，名字用 A 開頭
或者用 B 開頭，以區(qū)別版本是放到哪個系統(tǒng)（集群）上。如：執(zhí)行文件壓縮包 A_1_xxx.tar.gz 、 B_2_xxx.tar.gz 、 A_3_xxx.tar.gz ，這樣的格式。奇數(shù)部署到 A系統(tǒng)，偶數(shù)部署到 B系統(tǒng)，運維用自動化檢測版本和當前集群是否一致。

五、服務(wù)端要做的依然是做好多系統(tǒng)同用戶的互斥，以及出運行程序時候的打包帶上正確的版本號信息。

六、配置表每個版本都獨立全量放在一個文件夾里，避免弄混了。

下面是最終方案：（這個方案最適合我們目前的實際情況）

F.png

下面是最終方案流程圖：

D.png

選擇用 redis 訂閱發(fā)布功能來做消息通道的原因有幾個：

1. 為了保持解偶，game A 和 game B 我并不想讓它們知道彼此的存在，否則運行 game 的主機改變，都要做一些配置相關(guān)的修改。為了解決這個問題，前面的想法是每次登陸 web api 要判斷是否灰度狀態(tài)，如果灰度狀態(tài)需要先通知舊版本踢人，再請求新版本網(wǎng)關(guān)信息，但是這里會帶來性能熱點。而且因為狀態(tài)的變更容易出錯。

2.redis 作為 訂閱發(fā)布（類似觀察者模式）之前在項目中用過，效率很高，如果老版本關(guān)閉了，也無需做檢測，因為沒人訂閱踢人消息不影響流程。還有現(xiàn)成代碼，這是之前用法。
http://www.itdecent.cn/p/d865b6cd6bdb

3.對外隱藏細節(jié)，后續(xù)的維護相對容易些。web api 只需要判斷版本號，請求對應(yīng)的 game 即可，web 端的改動比較少。

下面是發(fā)布的流程：

E.png