現如今為什麼大多數遊戲服務端還是用C++來寫？
其實現在遊戲服務端基本上都是多語言組合開發的，C++已經不再是唯一選擇，Java、Python、Golang、Erlang、C#以及各種指令碼語言都會涉及。但是為什麼現如今大多數遊戲服務端還是用C++來寫呢？我認為一個專案在做技術選型時把C++作為遊戲服務端的主要開發語言主要基於以下原因：
十多年前，技術棧，包含程式語言的選擇還不是很多。C++是當時看來少數，被證明穩定，可靠，高效能，具備豐富功能的高階語言。所以理所當然被選擇作為開發主力。基於此，程序框架，諸如執行緒模型，定時器，容器等；IPC，比如socket，共享記憶體，並由共享記憶體進一步衍生出的資料恢復技術等都蓬勃發展。而且大廠之前都有封閉的思想，這和現在開源流行完全不同。生怕別人知道自己的技術優勢，也非常不信任社群產品的質量。結果就是——造輪子，各種造。從資料庫，到序列化工具，從xml解析器到負載均衡元件，凡是遊戲開發碰到的，全部自己造，而且都拿C++造。
遊戲存在高效能需求場景目前無可替代。別的不說，一個簡單的幀同步，每秒30/60幀，多人資料同步。現在我們用C++也只能支援單機小几千，大概就是每秒十多萬個包吧。所以沒有很強的信心換成別的語言。因為成本已經是這樣了，為何要在機器成本沒法明顯優化的情況下，再去增加技術風險和遷移成本？在一些卡牌型別遊戲中，後端也存在大量的數值密集型計算。雖然在架構上可以分散式，可以擴充套件，但降低機器成本同樣非常重要。特別是對線上規模很大的遊戲而言尤其重要，因為即使能優化10%，背後的機器數量恐怕也不是一個可以忽略的數目。
但總體上，隨著技術的發展，百花齊放應該是大趨勢。選擇合適的語言，在合適的場景，做合適的事情，這是大家逐漸認同的。而且很多嘗試都在解耦，從庫依賴變成服務間通訊，這樣更有助於不同語言共生。現在基本形成，高效能C/C++，靈活邏輯指令碼化，運維工具Python，大資料用spark，日誌流用elk，旁路檢索或查詢用jvm系的局面。對開發人員而言，語言的要求慢慢從一招鮮變成了一專多能。唯一不變的是，業務需求永遠在變，解決問題的技術就是好的技術。
最後附一張遊戲開發學習線路圖，希望對大家的學習有幫助~
