為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？

其實(shí)現(xiàn)在游戲服務(wù)端基本上都是多語(yǔ)言組合開(kāi)發(fā)的，C++已經(jīng)不再是唯一選擇，Java、Python、Golang、Erlang、C#以及各種腳本語(yǔ)言都會(huì)涉及。但是為什么現(xiàn)如今大多數(shù)游戲服務(wù)端還是用C++來(lái)寫(xiě)呢？我認(rèn)為一個(gè)項(xiàng)目在做技術(shù)選型時(shí)把C++作為游戲服務(wù)端的主要開(kāi)發(fā)語(yǔ)言主要基于以下原因：
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？


十多年前，技術(shù)棧，包含編程語(yǔ)言的選擇還不是很多。C++是當(dāng)時(shí)看來(lái)少數(shù)，被證明穩(wěn)定，可靠，高性能，具備豐富功能的高級(jí)語(yǔ)言。所以理所當(dāng)然被選擇作為開(kāi)發(fā)主力。基于此，進(jìn)程框架，諸如線程模型，定時(shí)器，容器等；IPC，比如socket，共享內(nèi)存，并由共享內(nèi)存進(jìn)一步衍生出的數(shù)據(jù)恢復(fù)技術(shù)等都蓬勃發(fā)展。而且大廠之前都有封閉的思想，這和現(xiàn)在開(kāi)源流行完全不同。生怕別人知道自己的技術(shù)優(yōu)勢(shì)，也非常不信任社區(qū)產(chǎn)品的質(zhì)量。結(jié)果就是——造輪子，各種造。從數(shù)據(jù)庫(kù)，到序列化工具，從xml解析器到負(fù)載均衡組件，凡是游戲開(kāi)發(fā)碰到的，全部自己造，而且都拿C++造。
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？


游戲存在高性能需求場(chǎng)景目前無(wú)可替代。別的不說(shuō)，一個(gè)簡(jiǎn)單的幀同步，每秒30/60幀，多人數(shù)據(jù)同步?，F(xiàn)在我們用C++也只能支持單機(jī)小幾千，大概就是每秒十多萬(wàn)個(gè)包吧。所以沒(méi)有很強(qiáng)的信心換成別的語(yǔ)言。因?yàn)槌杀疽呀?jīng)是這樣了，為何要在機(jī)器成本沒(méi)法明顯優(yōu)化的情況下，再去增加技術(shù)風(fēng)險(xiǎn)和遷移成本？在一些卡牌類型游戲中，后端也存在大量的數(shù)值密集型計(jì)算。雖然在架構(gòu)上可以分布式，可以擴(kuò)展，但降低機(jī)器成本同樣非常重要。特別是對(duì)在線規(guī)模很大的游戲而言尤其重要，因?yàn)榧词鼓軆?yōu)化10%，背后的機(jī)器數(shù)量恐怕也不是一個(gè)可以忽略的數(shù)目。
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？


但總體上，隨著技術(shù)的發(fā)展，百花齊放應(yīng)該是大趨勢(shì)。選擇合適的語(yǔ)言，在合適的場(chǎng)景，做合適的事情，這是大家逐漸認(rèn)同的。而且很多嘗試都在解耦，從庫(kù)依賴變成服務(wù)間通信，這樣更有助于不同語(yǔ)言共生?，F(xiàn)在基本形成，高性能C/C++，靈活邏輯腳本化，運(yùn)維工具Python，大數(shù)據(jù)用spark，日志流用elk，旁路檢索或查詢用jvm系的局面。對(duì)開(kāi)發(fā)人員而言，語(yǔ)言的要求慢慢從一招鮮變成了一專多能。唯一不變的是，業(yè)務(wù)需求永遠(yuǎn)在變，解決問(wèn)題的技術(shù)就是好的技術(shù)。
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？

那么C++和其他編程語(yǔ)言在游戲開(kāi)發(fā)上的優(yōu)劣勢(shì)對(duì)比：
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？

C++：

網(wǎng)絡(luò) IO：歷史上這方面曾經(jīng)是考量的主要因素，近年來(lái)幾乎所有主流后端語(yǔ)言都封裝有高效的網(wǎng)絡(luò) IO 庫(kù)，C++ 已不具備獨(dú)特優(yōu)勢(shì)。

CPU 利用率：C++ 在這方面的優(yōu)勢(shì)不需要討論了。

實(shí)時(shí)性：無(wú) GC，內(nèi)存分配延遲可控（內(nèi)存池、預(yù)分配等），毫秒級(jí)延遲需求的高頻交易都在用。


穩(wěn)定性和容災(zāi)：用C++寫(xiě)出長(zhǎng)期穩(wěn)定運(yùn)行的服務(wù)器程序，對(duì)開(kāi)發(fā)團(tuán)隊(duì)而言是件要求比較高的事情，尤其在邏輯復(fù)雜又變更頻繁的前提下。語(yǔ)言本身也不保證內(nèi)存訪問(wèn)的安全性，如果有內(nèi)存寫(xiě)越界導(dǎo)致的Crash也很難定位。國(guó)內(nèi)某大廠采用了分離數(shù)據(jù)和邏輯進(jìn)程，通過(guò)進(jìn)程間共享內(nèi)存來(lái)通信的方式，來(lái)實(shí)現(xiàn)邏輯進(jìn)程崩潰重啟不丟失數(shù)據(jù)。不過(guò)這種做法有一定門(mén)檻，存在性能開(kāi)銷(xiāo)，而且對(duì)開(kāi)發(fā)效率和靈活性也有比較大的約束，也不易整合第三方庫(kù)，不能算是通用的最佳實(shí)踐。


開(kāi)發(fā)效率：如果有良好的內(nèi)力和C++編程素養(yǎng)，并且配合現(xiàn)代C++的一些語(yǔ)法（auto、lambda、智能指針等），開(kāi)發(fā)效率尚可算是勉強(qiáng)及格，但相對(duì)以下討論的其他語(yǔ)言來(lái)說(shuō)仍處于劣勢(shì)，然而達(dá)到上述水準(zhǔn)的人力資源成本卻要比其它語(yǔ)言要高出不少（人員補(bǔ)充速度、培訓(xùn)周期和薪資）。綜合而言，這方面可算
C++的一大短板。
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？

Java：

優(yōu)點(diǎn)：
生態(tài)圈成熟，庫(kù)豐富。 Netty 網(wǎng)絡(luò)庫(kù)性能強(qiáng)悍。 不爽語(yǔ)法還可以用 scala 和 kotlin...
缺點(diǎn)：

·
除了原始類型外，不支持自定義值類型。而且泛型是以類型擦除的方式實(shí)現(xiàn)。這樣的特性導(dǎo)致了：難以把數(shù)據(jù)連續(xù)緊湊地進(jìn)行表示來(lái)優(yōu)化算法的緩存命中率，比如2D地圖的每個(gè)格子坐標(biāo)都是個(gè)object。3D
場(chǎng)景的碰撞體每個(gè)頂點(diǎn)都是個(gè)object。對(duì)原本對(duì)實(shí)時(shí)性不甚友好的 GC 造成了更大壓力。

· 成熟的 JVM 實(shí)現(xiàn)并不怎么側(cè)重 GC 的實(shí)時(shí)性。如果觸發(fā)了百毫秒以上的世界凍結(jié) GC 延遲，所有在線玩家都會(huì)受到影響。

· JIT 在預(yù)熱不足的情況下，偶爾會(huì)導(dǎo)致性能曲線不平滑，引入預(yù)料之外的響應(yīng)延遲。
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？

C#：

優(yōu)點(diǎn)：
開(kāi)發(fā)友好，語(yǔ)法糖甜。 有真正的泛型和值類型。特定算法好優(yōu)化。
缺點(diǎn)：

· 微軟家的。微軟家的。微軟家的。跑在 Windows Server下沒(méi)什么問(wèn)題，然而拋開(kāi)授權(quán)費(fèi)不談，大部分主流的開(kāi)源好物都是優(yōu)先考慮 Unix /
Linux，比如 Redis（長(zhǎng)期沒(méi)有 Windows 版本的官方支持）、MongoDB（Windows 下性能要弱于 Linux 下），而且 Windows
Server 的網(wǎng)絡(luò)性能也要弱一些。除非解決方案都用微軟全家桶，不然部署和運(yùn)維就需要同時(shí)維護(hù)兩個(gè)平臺(tái)...至于 Mono，跟 JVM 比起來(lái)就像玩具。只能期待
Rosalyn 成熟了。

· GC 實(shí)時(shí)性類似 Java。
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？

Go：

優(yōu)點(diǎn)：
語(yǔ)法簡(jiǎn)單易掌握。 開(kāi)發(fā)體驗(yàn)友好。 有值類型。 新版本的 Go，GC 實(shí)時(shí)性良好（1.8 號(hào)稱 STW 控制在 1ms 以內(nèi)）。
缺點(diǎn)：

· 沒(méi)有范型，某些地方需要轉(zhuǎn)型成 interface{}，不過(guò)編譯器會(huì)做逃逸分析，不必要的地方不會(huì)自動(dòng) boxing，影響不算太嚴(yán)重。
為什么游戲服務(wù)端用開(kāi)發(fā)效率低的C++來(lái)寫(xiě)，其他語(yǔ)言無(wú)法勝任嗎？

Rust：

優(yōu)點(diǎn)：
運(yùn)行效率比肩 C++。 語(yǔ)言特性優(yōu)秀。 編譯期保證了內(nèi)存安全，沒(méi)有 GC 開(kāi)銷(xiāo)。 編譯期保證線程安全，可以放心大膽地并發(fā)，容易寫(xiě)出高效的多線程代碼。
缺點(diǎn)：
上手曲線較陡。 太年輕，生態(tài)圈尚未成熟。 較小眾，人員補(bǔ)充困難。
經(jīng)過(guò)近幾年的發(fā)展，C++開(kāi)發(fā)效率也不算低，雖然對(duì)新人依然不怎么友好，但是從技術(shù)選型的角度來(lái)看依然是很多領(lǐng)域的不二之選。

小編推薦一個(gè)學(xué)C/C++的學(xué)習(xí)qun 5999，45900
學(xué)習(xí)從來(lái)不是一個(gè)人的事情，要有個(gè)相互監(jiān)督的伙伴，工作需要學(xué)習(xí)或者為了入行、轉(zhuǎn)行
都可以，qun內(nèi)有開(kāi)發(fā)工具，很多干貨和技術(shù)資料。

• ? 上一篇： GO編程程序員修煉秘籍：十本經(jīng)典書(shū)單
• ? 下一篇：ES6躬行記（24）——代理和反射