• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            戰魂小筑

            討論群:309800774 知乎關注:http://zhihu.com/people/sunicdavy 開源項目:https://github.com/davyxu

               :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
              257 隨筆 :: 0 文章 :: 506 評論 :: 0 Trackbacks

            以下比較的基礎都是基于一種編程語言+一定的第三方或者自己編寫的網絡庫和底層進行的,Skynet稍微特殊,但總體比較合適放到比較中來

            C#

            開發效率:Windows下可以通過VisualStudio進行開發,其他平臺可以使用MonoDevelop,非常方便

            運行效率:JIT的性能優化比較到位,能適應90%性能環境

            部署便捷性:可以通過交叉編譯生成其他平臺的可執行文件,通過mono運行可執行文件

            調試便捷性:VisualStudio和MonoDevelop調試均很方便, 還可遠程調試

            上手度:對C系語言熟悉的幾天就可上手

            熱更新:可以通過DLL方式進行

            Web對接:可做,代碼比較啰嗦

            崩潰處理:可通過try catch捕獲錯誤

            網絡庫編寫難度:一般,需注意gc問題

            第三方網絡庫及框架數量:一般

             

            Golang

            開發效率:高

            運行效率:并發上非常有優勢,對CPU利用率比較高,原生運行無虛擬機

            部署便捷性:一次編譯到處運行,無任何運行庫依賴

            調試便捷性:實際操作中,單線程掛接調試器可行, 但變量顯示不正確,開發期基本采用日志方式進行查錯

            上手度:語言簡單,特性少, 新手1周能貢獻代碼

            熱更新:無法進行熱更新,語言無法編譯為DLL,也不支持DLL加載(linux平臺的.so加載忽略不計)

            Web對接:非常方便, 代碼精簡

            崩潰處理:崩潰后以命令行方式打印出棧,程序內可以捕獲任何崩潰錯誤并繼續運行

            網絡庫編寫難度:簡單,比C socket更簡單

            第三方網絡庫及框架數量:偏少

             

            Skynet(lua+C)

            開發效率:基于動態語言的開發初次寫比較快,后期維護和重構會耗費一定的時間在查錯上

            運行效率:基于lua jit的運行效率還是能接受的

            部署便捷性:方便, 只有底層修改需要重新編譯, 大部分時間只用更新lua文件

            調試便捷性:不是很方便,基于日志方式進行查錯

            上手度:lua語言特性有部分和C系語言有一定差異,基于Actor模型的思想學習,適應需要耗費一定的時間

            熱更新:類似于Erlang,可精確到函數級的熱更新

            Web對接:有一些http支持,通過社區慢慢進行完善

            崩潰處理:lua天生可以捕獲錯誤

            網絡庫編寫難度:自帶,無需編寫

            第三方網絡庫及框架數量:通過社區慢慢完善

             

            C++

            開發效率:編譯慢,文件多,通用庫少

            運行效率:native速度標桿

            部署便捷性:編寫各類的make門檻較高

            調試便捷性:可通過VisualStudio進行Windows平臺調試

            上手度:2~3年經驗的熟手仍然會寫出崩潰和泄露代碼

            熱更新:可通過DLL進行

            Web對接:代碼啰嗦,第三方庫少

            崩潰處理:Windows下可使用SEH捕獲段異常,其他平臺只能通過崩潰后進行coredump分析,容錯非常差

            網絡庫編寫難度:基于asio編寫較為簡單,但總體看來難度不低

            第三方網絡庫及框架數量:較多

             

            以下是得分

            image

             

            從發文時的項目對這些語言使用率來說,Java,Erlang,C++編寫的服務器較多,Golang,JavaScript,C#是第二梯隊,Skynet由于上手不是很容易,所以僅有兩位數的團隊在使用,但總體表現還是比較出色的

            對于老團隊, C++的服務器工具鏈和框架已經相對成熟, 完全沒必要更換新語言, 只是在對接sdk感覺困難時,可以嘗試Golang這些對web有優勢的語言進行混合語言開發

            對于新團隊,開發效率,上手度和部署效率是優先選擇的,C#,Golang,JavaScript這些新興語言會讓你事半功倍

            對于大規模無需選服的服務器, Skynet的actor模型對擴展會比較容易

            對于大公司,好項目,上線后需要通過熱更新進行bug修補的,C#,C++,Erlang會是首選

             

            但總的一點, 還是根據團隊熟悉度來選擇語言,貿然的使用新語言的風險也是很大的

            posted on 2016-01-05 16:51 戰魂小筑 閱讀(18933) 評論(10)  編輯 收藏 引用 所屬分類: 網絡 服務器技術C++/ 編程語言Golang

            評論

            # re: 服務器開發語言比較 2016-01-20 17:55 路人
            c#做游戲服務端, 配合unity3d簡直完美  回復  更多評論
              

            # re: 服務器開發語言比較[未登錄] 2016-05-05 15:42 shine
            居然沒有Java  回復  更多評論
              

            # re: 服務器開發語言比較 2016-05-05 16:33 戰魂小筑
            @shine
            哈哈哈, 被你發現了, 因為我這邊不用Java
            Java的分至少也和C#相當  回復  更多評論
              

            # re: 服務器開發語言比較 2016-05-10 02:56 SuperSoar
            C# 部署麻煩。
            另外 話說最近才發現 go語言真是相當不錯了。
            go不是vm語言。
            其次 go語言的網絡開發確實方便到爆 C#相與之比較還是 遜色很多。

            C#這個語言真是即嚴謹又啰嗦。
              回復  更多評論
              

            # re: 服務器開發語言比較 2016-05-10 09:08 戰魂小筑

            @SuperSoar
            部署麻煩點, 但語言和開發環境是go的軟肋, C#太方便了  回復  更多評論
              

            # re: 服務器開發語言比較 2016-06-15 21:58 witch
            我們團隊就犯了貿然更換語言的錯誤,導致現在后悔的不得了。

            golang現在用下來,遇到幾個麻煩的坑。
            1. 調試不能用斷點。我們使用新版的idea來開發golang程序,但斷點經常失敗。而lite好多人用不習慣。
            2. 第三方庫偏少,但最重要的是很多都沒有tag或版本,根本不知道獲取下來的是開發版本還是穩定版本,甚至不知道api有哪些改動。有時候需要獲取一個早期版本時不得不從git的log中仔細找。
            3. 沒有熱更新,上線后出了問題不好處理。
            4. 沒有泛型。
            5. 指針類型和值類型之間更偏向于值類型的設計對非C++出身的程序員還是容易犯錯。
            6. 切片有坑!
            7. 語法存在一種表述多種含義的模糊性。導致第一眼看代碼時容易看不懂,必須結合上下文來仔細理解。
              回復  更多評論
              

            # re: 服務器開發語言比較 2016-06-15 22:28 戰魂小筑
            @witch
            1. 調試不能用斷點。我們使用新版的idea來開發golang程序,但斷點經常失敗。而lite好多人用不習慣。
            調試不用斷點是一種基本素質, 要求代碼有一定可分析基礎, 習慣就好

            2. 第三方庫偏少,但最重要的是很多都沒有tag或版本,根本不知道獲取下來的是開發版本還是穩定版本,甚至不知道api有哪些改動。有時候需要獲取一個早期版本時不得不從git的log中仔細找。

            寫游戲服務器不存在用第三方庫, 我們最多用到mongodb, mysql等的第三方庫. 當時也出現過選擇問題, 但最終還是選到合適的了

            3. 沒有熱更新,上線后出了問題不好處理。
            這個就是和運營運維的配合, 如果服務器連停下來更新都不允許, 這個也太過了

            4. 沒有泛型。
            這是個問題, 后期應該會有所改善

            5. 指針類型和值類型之間更偏向于值類型的設計對非C++出身的程序員還是容易犯錯。
            請更多的使用指針類型

            6. 切片有坑!
            比起指針來說, 切片的坑算少的了

            7. 語法存在一種表述多種含義的模糊性。導致第一眼看代碼時容易看不懂,必須結合上下文來仔細理解。

            這是你們編寫問題吧, 我們基本上拿到任何人代碼都能馬上看得懂

              回復  更多評論
              

            # re: 服務器開發語言比較 2016-06-16 00:28 witch
            @戰魂小筑
            1. 希望delve早日完善了。

            2. 這個是吐槽下protobuf庫。redigo和gorm也有這個問題。希望官方能早日統一下庫發布時的版本規則吧,畢竟優秀的第三方庫可以提升項目的實現難度和維護性。

            3. 熱更新對于使用長連接的游戲服務器來說真的是個巨大的加分點。
            開服第一天就停服維護會讓在線掉很多,不利于數據的采集,也打擊運營的信心。服務器鋪開來后,為了一個bug而大面積停服也是挺頭大的。特別是對于游戲這類開發節奏很緊業務很復雜很容易出bug的項目。

            4. 希望版本2趕緊出來。

            6. 指針不能參與運算感覺已經比C、C++好很多了。求教指針相關的坑?

            7. 這個是我表述錯誤了。應該是go的嵌入類型特性以及非常自由的接口機制導致不太容易找到接口的實現,也不容易注意到是否誤實現了某個接口。
              回復  更多評論
              

            # re: 服務器開發語言比較 2016-06-29 05:16 SuperSoar
            @戰魂小筑
            是的 LiteIde 這種雖然勉強能用,但是相比VS 還是相差得太遠太遠了...
              回復  更多評論
              

            # re: 服務器開發語言比較[未登錄] 2016-06-29 17:18 eric
            java和erlang不用嗎  回復  更多評論
              

            久久久久亚洲精品天堂| 亚洲精品成人久久久| 亚洲性久久久影院| 国产免费久久久久久无码| 91精品国产综合久久婷婷| 久久精品午夜一区二区福利| 亚洲人成网亚洲欧洲无码久久| 亚洲国产精品嫩草影院久久| 色欲综合久久躁天天躁| 久久久久亚洲精品天堂久久久久久| 国产成人精品久久综合| 国产农村妇女毛片精品久久| 欧美一级久久久久久久大| 亚洲国产精品无码久久青草 | 性做久久久久久久久浪潮| 亚洲国产成人精品女人久久久| 亚洲成av人片不卡无码久久| 精品国产青草久久久久福利| 狠狠色丁香久久婷婷综合| 国产精品久久成人影院| 久久91这里精品国产2020| 一本色综合久久| 国产综合久久久久| 久久综合五月丁香久久激情| 精品国产乱码久久久久久人妻| 99久久成人国产精品免费| 91精品国产高清久久久久久国产嫩草| 国产L精品国产亚洲区久久| 尹人香蕉久久99天天拍| 91精品国产综合久久久久久| 久久影视综合亚洲| 无遮挡粉嫩小泬久久久久久久| 国产999精品久久久久久| 久久青青草视频| 精品无码久久久久久午夜| 久久久久亚洲爆乳少妇无| 漂亮人妻被黑人久久精品| 日韩美女18网站久久精品| 久久精品水蜜桃av综合天堂| 久久久久九九精品影院| 久久九九精品99国产精品|