遊戲停服維護更新一直是在線遊戲的難題，這個過程會面臨維護當天日新增減少等問題。目前，網易遊戲在《一夢江湖》等幾款大型遊戲中實現了不停服維護，節省了用戶時間、大幅度提高了運維效率。
如何做到不停服維護？不停服維護在運維上會帶來哪些改變和升級？作爲 SRE 該如何應對？1月20日，網易遊戲高級運維經理Richard在2019網易遊戲開發者峯會上，爲大家分享了網易遊戲半年來的積累的一些經驗。
以下是分享實錄：
我在這裏要和大家分享的是遊戲不停服維護運維實踐。遊戲維護是我工作以來一直無法迴避的一個話題，遊戲會面臨維護當天日新增減少，維護當天日流水減少的問題。
以前遊戲項目人員會從兩方面出發：第一，挑選維護的時間；第二，縮短維護時間。項目人員需要在很不清醒的時間內（如凌晨四點）快速地完成操作，故障率就很容易升高。
業界有兩種較爲通用的不間斷維護方案，一種是灰度更新，另一種是紅藍更新。但爲什麼一直以來我們沒有用這兩種方案，一是因爲服務端的開發進度，二是因爲在運維上存在資源利用率不足，成本有限，集羣又過大的問題。
經過思考，維護時其實用戶在線總數是不變的，也就是雖然需要兩套環境，但計算資源總量不變。用一套的資源實現兩個服務端。我們先嚐試了在一個服務器上進程多開的方案。不過，實施起來還是有問題，很難將各種計費、周邊分佈端口、網絡開關服都結合起來，與實際的運維體系也不匹配。
對比研究後，我們想通過docker虛擬化資源，宿主超賣的形式實現資源環境的隔離，宿主配置兩套 docker 實例，運行 AB 服新兩套服務端，這時用戶下線後從舊服登出，再登錄時即進入新服務器，一套資源即可實現紅藍服更新。
在確立了方案之後就開始進行了一系列的調研工作。包括 Docker 的性能測試、兼容性測試、K8S 集羣的部署以及內部專用的 Image 管理平臺搭建。整個過程都比較順利。
但隨着部署服務器規模的增長，我們遇到了第二個問題：虛擬網絡設備增加導致的，網絡擁塞。
因爲時間緊任務重，開始時想通過最短平快的方式實現虛擬網絡間的互通，於是採用了一個最簡單的網絡方案“Host Network”將遊戲服務器的虛擬IP也配置成實體IP，並注入到主路由中。但這使得主路由的設備條目數比設計容量多了三倍。硬件設備不足以支撐虛擬網絡設備，是否有比較好的解決方案哪？我們又調研了docker環境下較常的Calico 網絡方案。
這是簡化之後的網絡圖。這其中有幾個模塊：在宿主上的BGPClient，Felix，在網絡集羣內又多了Route Reflector和ETCD， 分別負責宿主路由表的更新以及將虛擬機路由通過 Reflector 注入到主路由。這種方法可以使虛擬機通過主路由進行通信。
但通過仔細對比可以發現，其實 Calico 方案只是把 hostnetwork 方案配置自動化了。由於還是通過物理設備進行虛擬設備的管理和通信，所以整個網絡依然受物理設備的限制影響；另外因爲項目及設備數量的增加，內網IP也面臨耗盡問題。所以必須有一套凌駕於物理網絡的虛擬網絡方案（Overlay），因此我們也對比了 docker 下另一個虛擬網絡方案：Flannel。
Flannel 是一套覆蓋網絡 Overlay network，通過上圖可以看出，主要的實現原理是將數據包通過隧道方式進行再封裝，從而實現虛擬網絡數據在物理網絡上的通信。虛擬網絡的信息主要通過 ETCD 進行查詢與互通。總體來說 Flannel 可以解決虛擬設備佔用物理網絡設備數的問題，但依然無法滿足大規模部署要求。
總結來說我們在搭建大規模 docker 虛擬網絡的時候遇到了這些問題：網絡沒有隔離，網關性能不足，物理網絡無法承載虛擬網絡衝擊，沒有與宿主網絡配置隔離。結合內部需求，總結了幾點對網絡的要求：
首先是不需要改造現有物理網絡，其次是需要高性能網關，並且可以擴展。可以支持VPC，支持IP漂移，支持docker 與私有云網絡混布。
爲支持上述需求，我們基於openflow 協議開發了一套自研的SDN方案（Gon）。在宿主機上引入了 OVS（Open vSwitch） 用於管理宿主機內所有虛擬網絡設備，OVS模塊通過集羣中NVC（Network Virtualization Controller）模塊基於 openflow 協議實現互通。
我們同時引入了兩個彈性虛擬網關設備 IGW 與 BGW，對內外網流量進行分離管理。整套 SDN 方案可以做到全局流控。根據網絡組同事的測試，目前整套SDN單網關支持10G BPS，80W PPS、500W連接數，虛擬網關可依據需求在線彈性擴容，支持VPC，支持 IP 複用、支持 docker 虛擬網絡與私有云的混布。
經過一些列研發與測試，Gon SDN方案可以 較好滿足內部的網絡要求，在並且在虛擬網絡內部通信中，能做到接近物理網絡性能。
解決網絡問題之後，整體測試順利，實現方式也相對優雅。不過如上面提到的，我們是需要對宿主機進行超賣的。這並不符合 Docker 一般的使用習慣。在容器編排上，需要有一定的特殊調整。要求對於一個業務羣組（10001），需要嚴格按照一個pod A和一個pod B同時出現在一臺計算節點。不然無法實現維護期間集羣內計算資源的複用。
基於需求的特殊性，除了使用 docker 常用的 podAffinity 外，還需要結合 nodeSelector 特性來完成容器親和性操作。
我們給需要複用的集羣資源打上集羣標籤，然後通過NodeSelector的特性，進行實例編排，之後運用PodAntiAffinity的特性，保證不會出現AA 或 BB 分配到同一個宿主的情況。可以實現AB服的運行要求。但依舊有很多待優化的問題，包括資源層和應用層耦合，方案的通用性低。
經歷了一系列之後，我們終於完成了不停服維護。以下就是完成的效果，在維護的同時，是不影響玩家的正常遊戲的，使玩家體驗上升，據我瞭解，整個產品團隊的工作滿意度也有了比較大的提升，大家都不需要熬夜維護了。
除了不停服維護，基於 docker 虛擬化環境的特性我們也取得了其他一些收穫：包括從物理網絡變成VPC隔離，新服準備耗時縮短，故障節點可自愈，系統環境升級做到不耗時，資源調度API化。
總結
與大家回顧一下不停服維護運維方案的實現，包括對資源的複用、docker 下 SDN 的探討以及特殊情況下容器編排的嘗試。其實整個方案基於 docker 實現，但不是常見的 CICD，能夠根據需求想到用法這一塊是最難得的，而後的技術問題反而比較好解決。
作爲技術人員儘量不要被固有思維禁錮想象力，要知道技術能落地到業務才能產生價值。
運維的工作也已經不再是傳統的勞動力密集行業，更多的工程化業務，驅使技術人員不斷深入基礎環境與業務內容。我們需要與各個部門的高度協作，結合各自專業一同完成共同目標。
網易遊戲內推及內部職業乾貨交流羣，入羣即可享受超多福利！！
入羣方式：鏈接進入【網易互娛|校招知識儲備&新遊體驗館探營無限福利羣】：https://jq.qq.com/?_wv=1027&k=5dJP4EB
還可以添加“網易遊戲學院菌”微信號（NetEase_study）及時獲取更多知識乾貨哦！