用Go語言寫游戲服務器也有一個多月了，也能夠明顯的感受到兩者的區(qū)別。這篇文章就是想具體的聊聊其中的區(qū)別。當然，在了解區(qū)別之間，我們先簡單的了解一下Go語言本身。

Go語言的特點

Go語言跟其他的語言例如Java比起來，算得上一門很年輕的語言。Go語言是由Robert Griesemer、Rob Pike和Ken Thompson于2007年在Google開發(fā)。并于2009年正式發(fā)布。

Go語言的設計理念圍繞著簡潔這兩個字，認為少即是多。如果你熟悉Java，用Java那一套語法命名跟Go做對比，可以很明顯的體會到這種感覺。

Go的特點可以簡單的概括成以下幾個點。

靜態(tài)類型和編譯型

首先Go是靜態(tài)類型，靜態(tài)類型就是編譯時就知道每一個變量的類型，得益于此，在編譯的階段就能夠發(fā)現(xiàn)很多問題。而如果是動態(tài)語言，例如JavaScript，有些問題直到運行時才能發(fā)現(xiàn)。

Go是編譯型語言，看到編譯型大家腦子里可能會想到另外一個詞解釋型。兩者的區(qū)別從字面上來理解其實已經可以看出來，我用一個簡單的例子來類比一下。

編譯型 去餐館吃飯，點了菜之后，飯店會等所有的菜做好了再上

解釋型 去餐館吃飯，點了菜之后，陸陸續(xù)續(xù)的邊吃邊上

跨平臺

顧名思義，你寫的Go源碼在所有的系統(tǒng)都能夠運行。

這點其實很好理解，例如Java的口號是”Write once, run anywhere”。我們都知道Java是編譯型的語言，但是Java在編譯的時候生成的是字節(jié)碼，這個字節(jié)碼與當前的操作系統(tǒng)無關，與CPU也無關。

這種字節(jié)碼必須依賴Java虛擬機才能運行，而虛擬機會將操作系統(tǒng)和CPU之間的差異與用戶屏蔽。對于編程的人來說這個過程其實無感知的。而對Java來說，語言本身的跨平臺并不能代表代碼可以跨平臺。

Go的跨平臺從某種方面來說，與Java類型，我們需要安裝與當前操作系統(tǒng)相對應版本的Go。編譯出來的可執(zhí)行文件會根據(jù)操作系統(tǒng)的不同而有所不同。

自動垃圾回收

與JVM一樣，Go在運行時的內存管理（GC）由Go語言本身來管理，不需要程序員的參與，但是我們可以干預。

原生的并發(fā)編程

何為原生？我們都知道，在Java中如果要實現(xiàn)并發(fā)， 需要外部的類庫支持（Thread），而Go不需要從外部再引入任何依賴。支持使用關鍵字go即可。而且Java中是通過共享內存進行通信的，熟悉Go的應該都看過一句話“不要通過共享內存來通信，而應該通過通信來共享內存”

完善的構建工具

從獲取、編譯、測試、安裝、運行和分析等一系列流程都有自己的內置工具。例如獲取可以使用go get命令來下載更新指定的代碼包，并且對它們進行編譯和安裝，可以使用go build 對源碼進行編譯，用go run命令來運行Go的程序，用go fmt來快速格式化代碼，統(tǒng)一代碼風格。

多范式編程

目前主流的編程范式有命令式編程、函數(shù)式編程和我們最熟悉的面向對象編程。在編寫Go的代碼的時候，我們可以選擇使用面向對象的方法，也可以使用函數(shù)式編程的思想，相互結合，相輔相成。

例如，在Go里面也可以用接口來描述行為，也可以使用純函數(shù)來避免出現(xiàn)副作用。因此，多范式編程就是指這個語言支持多種編程范式的。

代碼風格強統(tǒng)一

使用Go的內置工具go fmt即可快速的將代碼格式化成官方統(tǒng)一的標準，以此來達到代碼風格統(tǒng)一的目的。甚至可以用golangci-lint來檢測你的語法跟內置的標準語法是否有沖突，完全可以將這個檢測工具掛在git的鉤子上，以此來達到強制的代碼風格統(tǒng)一的目的。

活躍的社區(qū)

還有一個很重要的特點是，國內的Go的社區(qū)十分的活躍，這對于Go在國內的普及起到了很大的作用。

用Go的優(yōu)勢

先說一下我對Go語言的看法，我認為Go在服務器這塊是非常有優(yōu)勢的。以后如果有高并發(fā)的應用場景，那么大概率這個服務就是用Go寫的。不知道大家有沒有發(fā)現(xiàn)，摩爾定律正在失效。近十年內，硬件的原始處理能力都沒有太大的提升。顯然，一味的增加晶體管的數(shù)量已經不是解決問題最好的方法。

NASA前不久發(fā)布到官網然后又迅速刪掉的文章透露了，Google可能已經實現(xiàn)了量子霸權，通俗一點說就是擁有超越所有傳統(tǒng)計算機的計算能力。而放置更多的晶體管的代價也越來越高，所以現(xiàn)在廠商都在向處理器中添加更多的內核來提升性能。

就像大家熟悉的Java，雖然Java本身支持多線程，但是在Java上使用多線程編程代碼算是比較昂貴的。在Java中創(chuàng)建一個新的線程就會消耗接近1M左右的內存。假如你真的需要支持運行上千個線程，那么服務很可能運行著就OOM了。除了內存消耗外，還會存在由于支持多線程帶來的并發(fā)和死鎖等問題。

而Go中，使用協(xié)程來代替線程。而且一個協(xié)程所消耗的內存比線程少了很多倍。同樣的物理設備限制，你可能只能啟動最多幾千個線程，而協(xié)程能夠啟動上百萬個。而且不同的Goroutine可以通過信channel進行安全的通信。

游戲服務器和Web服務器的區(qū)別

有些對游戲服務器的介紹可能會說，游戲服務器是一個需要長期運行的程序，然后怎么怎么樣。我個人認為Web服務器一樣的需要長期運行，也需要響應不定點不定時來自用戶的請求。兩者從宏觀上來看其實沒有本質的區(qū)別。同時Web服務器也會對于穩(wěn)定性和性能有要求，游戲服一般分為大小服，我們這里都按照小服舉例子。

狀態(tài)

首先要提到的就是狀態(tài)�？赡苣銜�聽說過一個概念，游戲服務器是有狀態(tài)的，而Web服務器是無狀態(tài)的。什么意思呢？Web服務器的數(shù)據(jù)流大多直接會到數(shù)據(jù)庫中。而游戲服務器的數(shù)據(jù)流首先會到內存中，然后定期的寫入數(shù)據(jù)庫（落地）。

換句話說，游戲服務器本身的數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)在運行期間會存在一個數(shù)據(jù)不一致的窗口。如果此時游戲服務器宕機了，那么就會造成數(shù)據(jù)首先到的內存數(shù)據(jù)與數(shù)據(jù)庫存的數(shù)據(jù)不一致。

而Web服務器則不會有這樣的問題，Web所有的數(shù)據(jù)狀態(tài)都會落地，而且可以針對操作加上事務，不用擔心因為操作失敗而引入臟數(shù)據(jù)。正因為有了狀態(tài)的約束，游戲服務器就會很慎重的使用內存、CPU。以求在資源有限的情況下，最大化的提高的承載量，并且降低服務延遲。當然，Web服務器會為了降低某個接口的響應時間而去做對應的優(yōu)化。

擴容

在Web服務器中，如果你不能評估一個服務所面臨的壓力，又不想因為瞬時的熱點訪問導致服務直接不可用的話，完全可以設置成自動擴容，因為每個服務只是單純的接收請求，然后處理請求、返回結果，不會將數(shù)據(jù)保存在服務器的內存中。要有數(shù)據(jù)存到內存，那也是在Redis中。而Redis數(shù)據(jù)丟失對數(shù)據(jù)的一致性基本沒有影響。

但是在游戲服務器這邊很難做到像Web那樣靈活。首先，數(shù)據(jù)的流向不是數(shù)據(jù)庫，而是內存。

舉個很簡單的例子，玩家的主城被攻打著火了，如果有了自動擴容，很有可能在落地的窗口內，玩家再請求一次，請求到了另一個實例。主城又沒有著火了。因為數(shù)據(jù)都會先存在內存中。

再舉一個例子，玩家氪金買了一個禮包。然后退出游戲，落地窗口內再次上線沒了。這就不是單純的數(shù)據(jù)問題了，玩家這是花了真金白銀買的道具，突然就沒了，一兩個還好處理，如果多個玩家都出現(xiàn)這樣的問題，那這就屬于嚴重的線上事故了。修復數(shù)據(jù)的工作量十分的大。

所以，對于一個游戲服務器，所能使用的內存和CPU的資源是非常有限的，不像Web服務器可以不用花很大的代價做到橫向擴展。這也就是為什么游戲服務器會十分十分的注重代碼的性能以及穩(wěn)定性。

穩(wěn)定

就像上面說的例子，如果游戲服務器運行中出了BUG，導致服務直接不可用，或者說通過這個BUG刷到了大量的道具，將是一個非常嚴重的線上事故。

而對于Web服務器來說，如果是管理系統(tǒng)之類的，有可能會有臟數(shù)據(jù)值得一提的是，臟數(shù)據(jù)對于Web來說，排查起來也是一件很頭疼的事情。如果沒有臟數(shù)據(jù)，只是服務暫且不可用，而且如果用的是微服務架構，重啟服務的代價是相對來說比較小的，只有正在重啟的服務的業(yè)務是不可用的，其余的部分則可以正常的訪問。

而對于游戲服務器來說，服務器重啟影響的是全服的玩家。玩家在停服期間，甚至連游戲都進不了，特別的影響玩家體驗。而且，如果停服之前服務器的數(shù)據(jù)落地出現(xiàn)了問題，服務重啟之后會將數(shù)據(jù)從數(shù)據(jù)庫load到內存中，此時同樣會造成數(shù)據(jù)不一致的問題。

性能

從我的經驗來看，在做Web服務器的時候，沒有為了減少GC的壓力，為了少占用內存去做過多的優(yōu)化。當然這是因為項目本身的體量不大，如果QPS很高的話，Web服務器同樣很需要注重性能，只不過游戲服務器需要一直特別注意這個方面。

不過在Web，如果訪問量很大的話導致單個服務不能扛住壓力，大部分人首先想到的解決方案應該就是搞多個實例，畢竟可以做到很輕松的橫向擴展。

在游戲服務器里，會把服務器的資源看的相當?shù)膶氋F。例如，能不落地的字段就絕對不要落地，某個字段的值可以通過已知的條件算出來的，就盡量不要定義在代碼里。不過這也要看具體情況權衡運算量和調用的頻率。因為上線之后，如果遇到了數(shù)據(jù)不一致，維護的數(shù)據(jù)越少，修復數(shù)據(jù)的難度就越小。

嚴謹

這一點上來說，我認為是兩者都很關注的一個重點。只不過，在游戲服務器的某些情況中，如果服務器拋出異�；蛘遬anic。其造成的后果會被游戲特殊的環(huán)境放大。

例如，召回你的在外部隊失敗了，那么部隊就會一直在外面且不可用。這跟在瀏覽器中點一個按鈕沒有反應比起來，影響相對較小。而且使用微服務架構，在修復問題之后可以以很低的成本來重啟對應的服務，而游戲服務器中還要修復一次數(shù)據(jù)。

再舉一個很極端的例子，點擊商店，玩家要準備氪金了。但是卻發(fā)現(xiàn)進不了商店，也可能不能獲取商品列表。這些會直接影響到游戲的體驗，甚至收入。

而對于Web來說，服務器的穩(wěn)定性同樣很重要。不然根據(jù)業(yè)務的不同，造成后果的嚴重性也有可能不同。影響了用戶體驗，就會直接影響到產品的口碑。

數(shù)據(jù)傳輸格式

熟悉Web的都知道，數(shù)據(jù)傳輸格式是JSON。而在游戲服務器中是Protobuf，是由Google開發(fā)的數(shù)據(jù)傳輸格式，與JSON類似。Protobuf是二進制的，二進制數(shù)據(jù)量會比JSON更小一點。而且，如果傳輸?shù)淖侄问强罩�，就不會被傳輸。而JSON如果是空值，一樣的也會被傳輸。

無論是在什么樣的環(huán)境中，舉個例子，Node.js和Java中，Protobuf的性能表現(xiàn)都比JSON好。在Java中，Protobuf甚至要比JSON快了接近80%。如果Java的服務之間通信有了性能瓶頸， 可以考慮服務之間使用RPC來通信。

但是凡事都具有兩面性。Protobuf的缺點仍然存在：

文檔較少

    社區(qū)與JSON的對比起來

    可讀性沒有JSON好

總結

以上就是這兩個月以來，總結的兩者的區(qū)別。只是從大體上做了一個對比，并沒有具體深入細節(jié)。細節(jié)的話有可能會在以后單獨的來介紹。（來源：SH的全棧筆記）

天下數(shù)據(jù)專業(yè)提供最安全的海外游戲解決方案、游戲數(shù)據(jù)安全解決方案、游戲服務器配置安全、游戲服務器架設方案。詳詢天下數(shù)據(jù)客服電話400-6388-808。

本文鏈接：http://51huadong.com/cloundnews/11004029.html