用Go語言寫游戲服務器也有一個多月了，也能夠明顯的感受到兩者的區別。這篇文章就是想具體的聊聊其中的區別。當然，在了解區別之間，我們先簡單的了解一下Go語言本身。
PS：這里僅拿SLG手游舉例子
1. Go語言的特點
Go語言跟其他的語言例如Java比起來，算得上一門很年輕的語言。Go語言是由Robert Griesemer、Rob Pike和Ken Thompson於2007年在Google開發。並於2009年正式發布。
Go語言的設計理念圍繞着簡潔這兩個字，認為少即是多。如果你熟悉Java，用Java那一套語法命名跟Go做對比，可以很明顯的體會到這種感覺。
Go的特點可以簡單的概括成以下幾個點。
1.1 靜態類型和編譯型
首先Go是靜態類型，靜態類型就是編譯時就知道每一個變量的類型，得益於此，在編譯的階段就能夠發現很多問題。而如果是動態語言，例如JavaScript，有些問題直到運行時才能發現。
Go是編譯型語言，看到編譯型大家腦子里可能會想到另外一個詞解釋型。兩者的區別從字面上來理解其實已經可以看出來，我用一個簡單的例子來類比一下。
- 編譯型 去餐館吃飯，點了菜之后，飯店會等所有的菜做好了再上
- 解釋型 去餐館吃飯，點了菜之后，陸陸續續的邊吃邊上
1.2 跨平台
顧名思義，你寫的Go源碼在所有的系統都能夠運行。
這點其實很好理解，例如Java的口號是"Write once, run anywhere"。我們都知道Java是編譯型的語言，但是Java在編譯的時候生成的是字節碼，這個字節碼與當前的操作系統無關，與CPU也無關。
這種字節碼必須依賴Java虛擬機才能運行，而虛擬機會將操作系統和CPU之間的差異與用戶屏蔽。對於編程的人來說這個過程其實無感知的。而對Java來說，語言本身的跨平台並不能代表代碼可以跨平台。
Go的跨平台從某種方面來說，與Java類型，我們需要安裝與當前操作系統相對應版本的Go。編譯出來的可執行文件會根據操作系統的不同而有所不同。
1.3 自動垃圾回收
與JVM一樣，Go在運行時的內存管理（GC）由Go語言本身來管理，不需要程序員的參與，但是我們可以干預。
1.4 原生的並發編程
何為原生？我們都知道，在Java中如果要實現並發， 需要外部的類庫支持（Thread），而Go不需要從外部再引入任何依賴。支持使用關鍵字go即可。而且Java中是通過共享內存進行通信的，熟悉Go的應該都看過一句話“不要通過共享內存來通信，而應該通過通信來共享內存”
1.5 完善的構建工具
從獲取、編譯、測試、安裝、運行和分析等一系列流程都有自己的內置工具。例如獲取可以使用go get命令來下載更新指定的代碼包，並且對它們進行編譯和安裝，可以使用go build 對源碼進行編譯，用go run命令來運行Go的程序，用go fmt來快速格式化代碼，統一代碼風格。
1.6 多范式編程
目前主流的編程范式有命令式編程、函數式編程和我們最熟悉的面向對象編程。在編寫Go的代碼的時候，我們可以選擇使用面向對象的方法，也可以使用函數式編程的思想，相互結合，相輔相成。
例如，在Go里面也可以用接口來描述行為，也可以使用純函數來避免出現副作用。因此，多范式編程就是指這個語言支持多種編程范式的。
1.7 代碼風格強統一
使用Go的內置工具go fmt即可快速的將代碼格式化成官方統一的標准，以此來達到代碼風格統一的目的。甚至可以用golangci-lint來檢測你的語法跟內置的標准語法是否有沖突，完全可以將這個檢測工具掛在git的鈎子上，以此來達到強制的代碼風格統一的目的。
1.8 活躍的社區
還有一個很重要的特點是，國內的Go的社區十分的活躍，這對於Go在國內的普及起到了很大的作用。
2. 用Go的優勢
先說一下我對Go語言的看法，我認為Go在服務器這塊是非常有優勢的。以后如果有高並發的應用場景，那么大概率這個服務就是用Go寫的。不知道大家有沒有發現，摩爾定律正在失效。近十年內，硬件的原始處理能力都沒有太大的提升。顯然，一味的增加晶體管的數量已經不是解決問題最好的方法。
NASA前不久發布到官網然后又迅速刪掉的文章透露了，Google可能已經實現了量子霸權，通俗一點說就是擁有超越所有傳統計算機的計算能力。而放置更多的晶體管的代價也越來越高，所以現在廠商都在向處理器中添加更多的內核來提升性能。
就像大家熟悉的Java，雖然Java本身支持多線程，但是在Java上使用多線程編程代碼算是比較昂貴的。在Java中創建一個新的線程就會消耗接近1M左右的內存。假如你真的需要支持運行上千個線程，那么服務很可能運行着就OOM了。除了內存消耗外，還會存在由於支持多線程帶來的並發和死鎖等問題。
而Go中，使用協程來代替線程。而且一個協程所消耗的內存比線程少了很多倍。同樣的物理設備限制，你可能只能啟動最多幾千個線程，而協程能夠啟動上百萬個。而且不同的Goroutine可以通過信channel進行安全的通信。
3. 游戲服務器和Web服務器的區別
有些對游戲服務器的介紹可能會說，游戲服務器是一個需要長期運行的程序，然后怎么怎么樣。我個人認為Web服務器一樣的需要長期運行，也需要響應不定點不定時來自用戶的請求。兩者從宏觀上來看其實沒有本質的區別。同時Web服務器也會對於穩定性和性能有要求，游戲服一般分為大小服，我們這里都按照小服舉例子。
3.1 狀態
首先要提到的就是狀態。可能你會聽說過一個概念，游戲服務器是有狀態的，而Web服務器是無狀態的。什么意思呢？Web服務器的數據流大多直接會到數據庫中。而游戲服務器的數據流首先會到內存中，然后定期的寫入數據庫（落地）。
換句話說，游戲服務器本身的數據與數據庫中的數據在運行期間會存在一個數據不一致的窗口。如果此時游戲服務器宕機了，那么就會造成數據首先到的內存數據與數據庫存的數據不一致。
而Web服務器則不會有這樣的問題，Web所有的數據狀態都會落地，而且可以針對操作加上事務，不用擔心因為操作失敗而引入臟數據。正因為有了狀態的約束，游戲服務器就會很慎重的使用內存、CPU。以求在資源有限的情況下，最大化的提高的承載量，並且降低服務延遲。當然，Web服務器會為了降低某個接口的響應時間而去做對應的優化。
3.2 擴容
在Web服務器中，如果你不能評估一個服務所面臨的壓力，又不想因為瞬時的熱點訪問導致服務直接不可用的話，完全可以設置成自動擴容，因為每個服務只是單純的接收請求，然后處理請求、返回結果，不會將數據保存在服務器的內存中。要有數據存到內存，那也是在Redis中。而Redis數據丟失對數據的一致性基本沒有影響。
但是在游戲服務器這邊很難做到像Web那樣靈活。首先，數據的流向不是數據庫，而是內存。
舉個很簡單的例子，玩家的主城被攻打着火了，如果有了自動擴容，很有可能在落地的窗口內，玩家再請求一次，請求到了另一個實例。主城又沒有着火了。因為數據都會先存在內存中。
再舉一個例子，玩家氪金買了一個禮包。然后退出游戲，落地窗口內再次上線沒了。這就不是單純的數據問題了，玩家這是花了真金白銀買的道具，突然就沒了，一兩個還好處理，如果多個玩家都出現這樣的問題，那這就屬於嚴重的線上事故了。修復數據的工作量十分的大。
所以，對於一個游戲服務器，所能使用的內存和CPU的資源是非常有限的，不像Web服務器可以不用花很大的代價做到橫向擴展。這也就是為什么游戲服務器會十分十分的注重代碼的性能以及穩定性。
3.3 穩定
就像上面說的例子，如果游戲服務器運行中出了BUG，導致服務直接不可用，或者說通過這個BUG刷到了大量的道具，將是一個非常嚴重的線上事故。
而對於Web服務器來說，如果是管理系統之類的，有可能會有臟數據值得一提的是，臟數據對於Web來說，排查起來也是一件很頭疼的事情。如果沒有臟數據，只是服務暫且不可用，而且如果用的是微服務架構，重啟服務的代價是相對來說比較小的，只有正在重啟的服務的業務是不可用的，其余的部分則可以正常的訪問。
而對於游戲服務器來說，服務器重啟影響的是全服的玩家。玩家在停服期間，甚至連游戲都進不了，特別的影響玩家體驗。而且，如果停服之前服務器的數據落地出現了問題，服務重啟之后會將數據從數據庫load到內存中，此時同樣會造成數據不一致的問題。
3.4 性能
從我的經驗來看，在做Web服務器的時候，沒有為了減少GC的壓力，為了少占用內存去做過多的優化。當然這是因為項目本身的體量不大，如果QPS很高的話，Web服務器同樣很需要注重性能，只不過游戲服務器需要一直特別注意這個方面。
不過在Web，如果訪問量很大的話導致單個服務不能扛住壓力，大部分人首先想到的解決方案應該就是搞多個實例，畢竟可以做到很輕松的橫向擴展。
在游戲服務器里，會把服務器的資源看的相當的寶貴。例如，能不落地的字段就絕對不要落地，某個字段的值可以通過已知的條件算出來的，就盡量不要定義在代碼里。不過這也要看具體情況權衡運算量和調用的頻率。因為上線之后，如果遇到了數據不一致，維護的數據越少，修復數據的難度就越小。
3.5 嚴謹
這一點上來說，我認為是兩者都很關注的一個重點。只不過，在游戲服務器的某些情況中，如果服務器拋出異常或者panic。其造成的后果會被游戲特殊的環境放大。
例如，召回你的在外部隊失敗了，那么部隊就會一直在外面且不可用。這跟在瀏覽器中點一個按鈕沒有反應比起來，影響相對較小。而且使用微服務架構，在修復問題之后可以以很低的成本來重啟對應的服務，而游戲服務器中還要修復一次數據。
再舉一個很極端的例子，點擊商店，玩家要准備氪金了。但是卻發現進不了商店，也可能不能獲取商品列表。這些會直接影響到游戲的體驗，甚至收入。
而對於Web來說，服務器的穩定性同樣很重要。不然根據業務的不同，造成后果的嚴重性也有可能不同。影響了用戶體驗，就會直接影響到產品的口碑。
3.6 數據傳輸格式
熟悉Web的都知道，數據傳輸格式是JSON。而在游戲服務器中是Protobuf，是由Google開發的數據傳輸格式，與JSON類似。Protobuf是二進制的，二進制數據量會比JSON更小一點。而且，如果傳輸的字段是空值，就不會被傳輸。而JSON如果是空值，一樣的也會被傳輸。
無論是在什么樣的環境中，舉個例子，Node.js和Java中，Protobuf的性能表現都比JSON好。在Java中，Protobuf甚至要比JSON快了接近80%。如果Java的服務之間通信有了性能瓶頸， 可以考慮服務之間使用RPC來通信。
但是凡事都具有兩面性。Protobuf的缺點仍然存在：
- 文檔較少
- 社區與JSON的對比起來
- 可讀性沒有JSON好
4 總結
以上就是這兩個月以來，總結的兩者的區別。只是從大體上做了一個對比，並沒有具體深入細節。細節的話有可能會在以后單獨的來介紹。
往期文章：
- Go中使用Seed得到重復隨機數的問題
- 從Web轉到游戲之后
- go源碼解析-Println的故事
- 用go-module作為包管理器搭建go的web服務器
- WebAssembly完全入門——了解wasm的前世今身
- 小強開飯店-從單體應用到微服務
相關：
- 微信公眾號： SH的全棧筆記（或直接在添加公眾號界面搜索微信號LunhaoHu）