如何做到不停服維護？不停服維護在運維上會帶來哪些改變和公升級？作為 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 協議實現互通。
經過一些列研發與測試，gon sdn方案可以 較好滿足內部的網路要求，在並且在虛擬網路內部通訊中，能做到接近物理網路效能。
解決網路問題之後，整體測試順利，實現方式也相對優雅。不過如上面提到的，我們是需要對宿主機進行超賣的。這並不符合 docker 一般的使用習慣。在容器編排上，需要有一定的特殊調整。要求對於乙個業務群組（10001），需要嚴格按照乙個pod a和乙個pod b同時出現在一台計算節點。不然無法實現維護期間集群內計算資源的復用。
基於需求的特殊性，除了使用 docker 常用的 podaffinity 外，還需要結合 nodeselector 特性來完成容器親和性操作。
我們給需要復用的集群資源打上集群標籤，然後通過nodeselector的特性，進行例項編排，之後運用podantiaffinity的特性，保證不會出現aa 或 bb 分配到同乙個宿主的情況。可以實現ab服的執行要求。但依舊有很多待優化的問題，包括資源層和應用層耦合，方案的通用性低。
經歷了一系列之後，我們終於完成了不停服維護。以下就是完成的效果，在維護的同時，是不影響玩家的正常遊戲的，使玩家體驗上公升，據我了解，整個產品團隊的工作滿意度也有了比較大的提公升，大家都不需要熬夜維護了。
除了不停服維護，基於 docker 虛擬化環境的特性我們也取得了其他一些收穫：包括從物理網路變成vpc隔離，新服準備耗時縮短，故障節點可自癒，系統環境公升級做到不耗時，資源排程api化。
與大家回顧一下不停服維護運維方案的實現，包括對資源的復用、docker 下 sdn 的**以及特殊情況下容器編排的嘗試。其實整個方案基於 docker 實現，但不是常見的 cicd，能夠根據需求想到用法這一塊是最難得的，而後的技術問題反而比較好解決。
作為技術人員盡量不要被固有思維禁錮想象力，要知道技術能落地到業務才能產生價值。
運維的工作也已經不再是傳統的勞動力密集行業，更多的工程化業務，驅使技術人員不斷深入基礎環境與業務內容。我們需要與各個部門的高度協作，結合各自專業一同完成共同目標。
入群方式：鏈結進入【網易互娛|校招知識儲備&新遊體驗館探營無限福利群】：
如何做到專業
要想成為頂級的足球前鋒，需要速度 敏捷和門前敏銳的嗅覺，不放過任何乙個破門的機會，做一名足球運動員也是乙份工作，如何把這份工作做到極致，如何成為身價最高的球員，就如同如何成為薪水最高的職業經理人一樣，需要的是專業，不管從事什麼樣的工作，要想把工作做到極致，首先要做的就是專業。如何讓自己變得更專業，這...
面試官 如何做到不停機分庫分表遷移？
類似訂單表，使用者表這種未來規模上億甚至上十億百億的海量資料表，在專案初期為了快速上線，一般只是單錶設計，不需要考慮分庫分表。隨著業務的發展，單錶容量超過千萬甚至達到億級別以上，這時候就需要考慮分庫分表這個問題了，而不停機分庫分表遷移，這應該是分庫分表最基本的需求，畢竟網際網路專案不可能掛個廣告牌 ...
如何做到物件導向
首先，物件導向的概念 物件導向 object oriented 是將現實問題構建關係，然後抽象成 類 class 給類定義屬性和方法後，再將類例項化成 例項 instance 通過訪問例項的屬性和呼叫方法來進行使用。其次，物件導向的三個基本要素 1.繼承 2.封裝 3.多型 再次，物件導向的五個基本...