它和云風過往放出來的東西一樣，是非常具有實踐性的，可以解決實際開發問題的。目前我所在的手游項目使用 Erlang 進行服務器端開發的，如果重新開始，我會選擇使用 skynet。

游戲服務器開發中的難點，上面 @無瞳已經提到了兩個，我再加一個：隔離性。比如說，在C/C++寫的服務器中，一行代碼中的空指針訪問，就會導致整個服務器進程crash，這就是很差的隔離性，在服務一個玩家的過程中發生的錯誤，會影響到對其他玩家提供服務的能力。

傳統的端游服務器開發中，性能是硬性指標，語言上幾乎沒有選擇，必須使用C/C++。但是頁游和手游對單機性能的要求降到了非常低的水平。這個時候，Erlang在解決異步通信以及強隔離性上的優勢就體現了出來。

但是 Erlang 也有它的問題。

首先，就是很難招人。

一方面，國內小公司很難招到靠譜的程序員。Erlang 本來就比較小眾，所以大多數情況下只能是招進來不會 Erlang 的，讓他自學+一些指導。

在我從某大廠出來以后面試的十幾個人中，能好好用C語言寫完一個 atoi 函數的，只有一兩個。倒不是 Erlang 有多難學，只是功底差成這樣的人，他會不會有意愿去學就是個很大的問題，你敢不敢相信他能學好都是其次了。

其次，Erlang 的一些特性確實降低開發效率。

這是一句非常招黑的話，我也沒有時間寫太詳細，只是一些個人感受。

首先就是 Immutable。這個特性對游戲發開來說非常頭疼。目前的手游服務器里數值計算占的比重不多，更多的是對狀態的修改。玩家要升個級，你要Level+1，玩家做做這，做做那，最終體現到代碼上的，都是對狀態的修改。而 Erlang 的 Immutable，配合很費鍵盤的Record語法，讓寫這些代碼的過程非常繁瑣。

另外就是 Erlang 不支持在函數中間直接return，在寫很多游戲邏輯的時候，是非常蛋疼的。

因為上面這些原因，我覺得最適合目前手游的服務器開發語言是這樣的：

(1). 和 Erlang 一樣的進程模型，強隔離性。

(2). 類似 C 的命令式語言。

但是要寫出這樣的一門語言，需要非常大的工作量(可以參考 Erlang 虛擬機的代碼量。)

skynet 在我看來是做了一個trade off。它不支持如 Erlang 般便宜的進程(因此在隔離性上有所降低，但依然比C/C++強。)，但是開發 skynet 本身所需的工作量大大降低。

總結

以上是生活随笔為你收集整理的go hive skynet_云风的skynet在国内外来看究竟算什么水平？可以一统国内游戏服务端框架吗？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。