網(wǎng)游服務器和Web服務器的區(qū)別

??網(wǎng)游服務器租用商提供的服務器從幾百元到上萬元的都有，所以在這里要提醒用戶朋友們在選擇時千萬不要被價格所左右，主要看兩點就行了，一是看用戶你這個網(wǎng)游的規(guī)模的大小，二是網(wǎng)游的競爭情況。玩家規(guī)模的大小主要從網(wǎng)游服務器配置和帶寬兩個方面來考慮。當然如果配置越高，服務器性能當然也就越好，不用說其價格相差也越大;帶寬是影響用戶體驗的最重要的一個因素，帶寬的價格也隨著大小、獨享和共享、地區(qū)而不同。下面就由新網(wǎng)小編和大家講一講網(wǎng)游服務器和Web服務器的區(qū)別。

??一、Go語言的特點

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

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

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

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

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

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

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

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

??2、跨平臺

??顧名思義，你寫的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)的不同而有所不同。

??3、自動垃圾回收

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

??4、原生的并發(fā)編程

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

??二、用Go的優(yōu)勢

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

??NASA前不久發(fā)布到官網(wǎng)然后又迅速刪掉的文章透露了，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)定性和性能有要求，游戲服一般分為大小服，我們這里都按照小服舉例子。

??1、狀態(tài)

??首先要提到的就是狀態(tài)?？赡苣銜犝f過一個概念，游戲服務器是有狀態(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)化。

??2、擴容

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

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

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

??3、穩(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ù)不一致的問題。

??4、性能

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

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

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

??以上就是總結網(wǎng)游服務器和Web服務器兩者的區(qū)別。只是從大體上做了一個對比，并沒有具體深入細節(jié)。小伙伴們要想獲得更多網(wǎng)游服務器的內容，請關注新網(wǎng)。