1. 程式人生 > >使用Golang開發手遊伺服器的感想

使用Golang開發手遊伺服器的感想

        從最初決定使用Golang開發遊戲伺服器(參考這裡),到伺服器基本成型,經過了兩個多禮拜的時間。這裡記錄一下感想和心得。具體Golang的使用經驗將來有時間會再開篇文章來寫。

        兩個禮拜的時間,完成了Golang的入門,伺服器框架設計,功能的完整移植,從我個人角度來說,要給Golang和我自己100個贊。

        最初我選定Golang就是考慮到它有以下優點;

1、靜態編譯型語言。這個是我最看重的,不選擇skynet(c+lua)和KBEngine(c++ python)有很大一個原因是動態指令碼語言維護邏輯複雜了維護起來非常困難。 靜態語言基本編譯通過後就沒有太大問題了,剩下的就是思考不周導致的bug。

2、堪比python的開發效率。  不選java很大的一個原因是這個。  我不需要最優方案,也不需要最穩妥的方案,只需要一個合適的方案。

3、併發模型,可以輕易利用起多核。 不選Node.js的原因是callback還沒有真正完善的解決方案

4、有現成的開源伺服器。即便不說有成功案例,至少是有可行的案例

5、優異的跨平臺能力。  我想部署KBEngine到linux,結果python編譯了半天都沒成功。(順便吐槽下linux,不同發行版本,軟體源中的軟體名不一樣,操作命令和習慣也不一樣,簡直是作)

6、部署方便,只要把執行檔案拷貝一下就可以了,沒有太多的依賴或者動態庫。同樣參考上一條。

7、支援protobuf、mongoDB。KBEngine中我一直想做這個修改,不過改動太大,完全Hold不住。這個不算特別的優點,因為很多其他的方案也都支援,只不過恰好不謀而合而已。

       而最後的結果也基本滿意。

       Golang並不是一個完美的語言,甚至從c++系轉過來的人會感覺很多不爽,尤其是詭異的變數命名規則。

       不過Golang是一個解決實際問題的工業級語言。可能語法上面看各種粗糙,但是習慣後使用起來非常順手。它在解決網路大併發問題的基礎上(go 協程),同時兼顧了靜態語言的優勢和堪比Python的開發效率,從這點上來說再怎麼稱讚它都不為過。 在這個巨大優勢的前提下,其他的一些不爽都是可以接受和忽略的。 其他的如Rust、Scala等,雖然語法、語義更棒,但是並不能解決我碰到的實際問題(並不是說它不能解決任何問題),只有Golang將這三者完美的融合在一起。

        關於Golang的入門,我總結了三點需要注意的:

1、包和GOPATH。  

      Golang並沒有專案工程檔案,它通過自動解析包引用構建整個專案。一個資料夾對應一個包,一個包對應一個模組,模組內可以定義各種結構和函式。  而main包就是程式的主入口,它包含一個main函式。 

      GOPATH是go查詢包的路徑,我現在設定兩個路徑,一個是當前專案路徑,一個是公共包的路徑。go在編譯的時候會依次查詢對應路徑下有沒有這個包。  go build和go install可以構建程式。 一個專案中可以包含多個main包,也就對應多個程序。比如我的伺服器專案中就對應login gate game三個程序。

      理解了包和GOPATH就可以非常方便的維護整個專案

2、指標和記憶體

      Golang中有指標的概念(這點我並不喜歡,感覺還不如像c#或者java一樣直接幹掉指標,只有物件的概念)。但是指標的功能極度弱化,你可以像正常物件呼叫一樣使用指標,不能操作指標的記憶體,也不能對指標進行自增等操作。 指標的意義就是傳遞引數是防止值傳遞,也就說Golang的指標就相當於c++中的引用。

      同樣的,你並不能控制一個物件是在堆上建立還是在棧上建立。Golang中new(TestStruct)和&TestStruct{}是完全等價的寫法。只不過後一個寫法可以同時進行初始化操作。 創建出的記憶體都是交給GC來進行管理的。 所以返回區域性物件的指標是完全合法和正確的。

3、Struct和interface{}

type User Struct {
    name string
}

func (self *User) login(account string, token string) {
}

     通過這樣的寫法就定義了一個結構User,並且這個結構有一個成員函式login。  通過包、Struct、包函式、成員函式這四個元素就可以輕鬆的處理物件和框架設計。

      介面是Golang中非常強大的語法特性,一個Struct只要實現了一個介面(函式名和引數相同)就可以當做這個介面來使用。 通過介面,大大減輕了設計負擔,不需要設計模式,一樣可以寫出高質量的優雅的程式碼