golang有沒(méi)有好的開(kāi)源游戲框架

Go作為近兩年迅速流行起來(lái)的編程語(yǔ)言始終致力于使事情簡(jiǎn)單化。它并未引入很多新概念，而是聚焦于打造一門(mén)簡(jiǎn)單的語(yǔ)言，讓開(kāi)發(fā)者使用起來(lái)感覺(jué)異常快速且簡(jiǎn)單。相信有意向深入學(xué)習(xí)Go語(yǔ)言的小伙伴都在研究Go的開(kāi)源項(xiàng)目，今天我就把自己覺(jué)得不錯(cuò)的6個(gè)Go開(kāi)源項(xiàng)目推薦給大家，希望大家能獲得收獲和成長(zhǎng)。

成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站設(shè)計(jì)制作、網(wǎng)站建設(shè)、華容網(wǎng)絡(luò)推廣、小程序定制開(kāi)發(fā)、華容網(wǎng)絡(luò)營(yíng)銷、華容企業(yè)策劃、華容品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；成都創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供華容建站搭建服務(wù)，24小時(shí)服務(wù)熱線：13518219792，官方網(wǎng)址：chinadenli.net

推薦一：kubernetes 【Star：44418】

Kubernetes基于Docker，其目的是讓用戶通過(guò)Kubernetes集群來(lái)進(jìn)行云端容器集群的管理，而無(wú)需用戶進(jìn)行復(fù)雜的設(shè)置工作。系統(tǒng)會(huì)自動(dòng)選取合適的工作節(jié)點(diǎn)來(lái)執(zhí)行具體的容器集群調(diào)度處理工作。

推薦二：etcd 【Star：21408】

etcd是由CoreOS開(kāi)發(fā)并維護(hù)鍵值存儲(chǔ)系統(tǒng)，它使用Go語(yǔ)言編寫(xiě)，并通過(guò)Raft一致性算法處理日志復(fù)制以保證強(qiáng)一致性。目前，Google的容器集群管理系統(tǒng)Kubernetes、開(kāi)源PaaS平臺(tái)Cloud Foundry和CoreOS的Fleet都廣泛使用了etcd。

推薦三：deis 【Star：6093】

Deis是一個(gè)基于Docker和CoreOS的開(kāi)源PaaS平臺(tái)，旨在讓部屬和管理服務(wù)器上的應(yīng)用變得輕松容易。它可以運(yùn)行在AWS、GCE以及Openstack平臺(tái)下。

推薦四：flynn 【Star：6936】

Flynn是一個(gè)使用Go語(yǔ)言編寫(xiě)的開(kāi)源PaaS平臺(tái)，可自動(dòng)構(gòu)建部署任何應(yīng)用到Docker容器集群上運(yùn)行。Flynn項(xiàng)目受到Y(jié) Combinator的支持，目前仍在開(kāi)發(fā)中，被稱為是下一代的開(kāi)源PaaS平臺(tái)。

推薦五：lime 【Star：13775】

相對(duì)上面的幾款Go語(yǔ)言在云端和服務(wù)器端之外，Lime則顯得比較特殊。Lime，則是一款用Go語(yǔ)言寫(xiě)的桌面編輯器程序，被看做是著名編輯器Sublime Text的開(kāi)源實(shí)現(xiàn)。

六：revel 【Star：10508】

Revel是一個(gè)高生產(chǎn)力的Go語(yǔ)言Web框架。Revel框架支持熱編譯，當(dāng)編輯、保存和刷新源碼時(shí)，Revel會(huì)自動(dòng)編譯代碼和模板；全棧特性，支持路由、參數(shù)解析、緩存、測(cè)試、國(guó)際化等功能。

golang有哪些不錯(cuò)的游戲服務(wù)器框架

為什么golang的開(kāi)發(fā)效率高看

golang是一編譯型的強(qiáng)類型語(yǔ)言，它在開(kāi)發(fā)上的高效率主要來(lái)自于后發(fā)優(yōu)勢(shì)，不用考慮舊有惡心的歷史，又有一個(gè)較高的工程視角。良好的避免了程序員因?yàn)槎?{ 需不需要獨(dú)占一行 地這種革命問(wèn)題打架，也解決了一部分趁編譯時(shí)間找產(chǎn)品妹妹搭訕的階級(jí)敵人。

它有自己的包管理機(jī)制，工具鏈成熟，從開(kāi)發(fā)、調(diào)試到發(fā)布都很簡(jiǎn)單方便；

有反向接口、defer、coroutine等大量的syntactic sugar；

編譯速度快，因?yàn)槭菑?qiáng)類型語(yǔ)言又有g(shù)c，只要通過(guò)編譯，非業(yè)務(wù)毛病就很少了；

它在語(yǔ)法級(jí)別上支持了goroutine，這是大家說(shuō)到最多的內(nèi)容，這里重點(diǎn)提一下。首先，coroutine并不稀罕，語(yǔ)言并不能超越硬件、操作系統(tǒng)實(shí)現(xiàn)神乎其神的功能。golang可以做到事情，其他語(yǔ)言也可以做到，譬如c++，在boost庫(kù)里面自己就有的coroutine實(shí)現(xiàn)（當(dāng)然用起來(lái)跟其他boost庫(kù)一樣惡心）。golang做的事情，是把這一套東西的使用過(guò)程簡(jiǎn)化了，并且提供了一套channel的通信模式，使得程序員可以忽略諸如死鎖等問(wèn)題。

goroutine的目的是描述并發(fā)編程模型。并發(fā)與并行不同，它并不需要多核的硬件支持，它不是一種物理運(yùn)行狀態(tài)，而是一種程序邏輯流程。它的主要目的不是利用多核提高運(yùn)行效率，而是提供一種更容易理解、不容易出錯(cuò)的語(yǔ)言來(lái)描述問(wèn)題。

實(shí)際上golang默認(rèn)就是運(yùn)行在單OS進(jìn)程上面的，通過(guò)指定環(huán)境變量GOMAXPROCS才能轉(zhuǎn)身跑在多OS進(jìn)程上面。有人提到了的pomelo，開(kāi)源本來(lái)是一件很不錯(cuò)的事情，但是基于自己對(duì)callback hell的偏見(jiàn)，我一直持有這種態(tài)度：敢用nodejs寫(xiě)大規(guī)模游戲服務(wù)器的人，都是真正的勇士 : ) 。

2、Erlang與Golang的coroutine有啥區(qū)別，coroutine是啥看

coroutine本質(zhì)上是語(yǔ)言開(kāi)發(fā)者自己實(shí)現(xiàn)的、處于user space內(nèi)的線程，無(wú)論是erlang、還是golang都是這樣。需要解決沒(méi)有時(shí)鐘中斷；碰著阻塞式i\o，整個(gè)進(jìn)程都會(huì)被操作系統(tǒng)主動(dòng)掛起；需要自己擁有調(diào)度控制能力（放在并行環(huán)境下面還是挺麻煩的一件事）等等問(wèn)題。那為啥要廢老大的勁自己做一套線程放user space里面呢看

并發(fā)是服務(wù)器語(yǔ)言必須要解決的問(wèn)題；

system space的進(jìn)程還有線程調(diào)度都太慢了、占用的空間也太大了。

把線程放到user space的可以避免了陷入system call進(jìn)行上下文切換以及高速緩沖更新，線程本身以及切換等操作可以做得非常的輕量。這也就是golang這類語(yǔ)言反復(fù)提及的超高并發(fā)能力，分分鐘給你開(kāi)上幾千個(gè)線程不費(fèi)力。

不同的是，golang的并發(fā)調(diào)度在i/o等易發(fā)阻塞的時(shí)候才會(huì)發(fā)生，一般是內(nèi)封在庫(kù)函數(shù)內(nèi)；erlang則更夸張，對(duì)每個(gè)coroutine維持一個(gè)計(jì)數(shù)器，常用語(yǔ)句都會(huì)導(dǎo)致這個(gè)計(jì)數(shù)器進(jìn)行reduction，一旦到點(diǎn)，立即切換調(diào)度函數(shù)。

中斷介入程度的不同，導(dǎo)致erlang看上去擁有了preemptive scheduling的能力，而golang則是cooperative shceduling的。golang一旦寫(xiě)出純計(jì)算死循環(huán)，進(jìn)程內(nèi)所有會(huì)話必死無(wú)疑；要有大計(jì)算量少i\o的函數(shù)還得自己主動(dòng)叫runtime.Sched()來(lái)進(jìn)行調(diào)度切換。

3、golang的運(yùn)行效率怎么樣看

我是相當(dāng)反感所謂的ping\pong式benchmark，運(yùn)行效率需要放到具體的工作環(huán)境下面考慮。

首先，它再快也是快不過(guò)c的，畢竟底下做了那么多工作，又有調(diào)度，又有g(shù)c什么的。那為什么在那些benchmark里面，golang、nodejs、erlang的響應(yīng)效率看上去那么優(yōu)秀呢，響應(yīng)快，并發(fā)強(qiáng)看并發(fā)能力強(qiáng)的原因上面已經(jīng)提到了，響應(yīng)快是因?yàn)榇罅糠亲枞絠\o操作出現(xiàn)的原因。這一點(diǎn)c也可以做到，并且能力更強(qiáng)，但是得多寫(xiě)不少優(yōu)質(zhì)代碼。

然后，針對(duì)游戲服務(wù)器這種高實(shí)時(shí)性的運(yùn)行環(huán)境，GC所造成的跳幀問(wèn)題確實(shí)比較麻煩，前面的大神 @達(dá)達(dá) 有比較詳細(xì)的論述和緩解方案，就不累述了 。隨著golang的持續(xù)開(kāi)發(fā)，相信應(yīng)該會(huì)有非常大的改進(jìn)。一是屏蔽內(nèi)存操作是現(xiàn)代語(yǔ)言的大勢(shì)所趨，它肯定是需要被實(shí)現(xiàn)的；二是GC算法已經(jīng)相當(dāng)?shù)某墒欤拭忝銖?qiáng)強(qiáng)過(guò)得去；三是可以通過(guò)incremental的操作來(lái)均攤cpu消耗。

用這一點(diǎn)點(diǎn)效率損失換取一個(gè)更高的生產(chǎn)能力是不是值得呢看我覺(jué)得是值得的，硬件已經(jīng)很便宜了，人生苦短，讓自己的生活更輕松一點(diǎn)吧: )。

4、基于以上的論述，我認(rèn)為采用go進(jìn)行小范圍的MMORPG開(kāi)發(fā)是可行的。

使用Go 語(yǔ)言開(kāi)發(fā)大型 MMORPG 游戲服務(wù)器怎么樣

從2013年起,經(jīng)朋友推薦開(kāi)始用Golang編寫(xiě)游戲登陸服務(wù)器, 配合C++做第三方平臺(tái)驗(yàn)證. 到編寫(xiě)?yīng)毩⒐ぞ邔?dǎo)表工具GitHub - davyxu/tabtoy: 跨平臺(tái)的高性能便捷電子表格導(dǎo)出器. 以及網(wǎng)絡(luò)庫(kù)GitHub - davyxu/cellnet: 簡(jiǎn)單,方便,高效的Go語(yǔ)言的游戲服務(wù)器底層. 最終使用這些工具及庫(kù)編寫(xiě)整個(gè)游戲服務(wù)器框架, 我的感受是很不錯(cuò)的

細(xì)節(jié)看來(lái), 有如下的幾個(gè)點(diǎn):

語(yǔ)言, 庫(kù)

Golang語(yǔ)言特性和C很像, 簡(jiǎn)單, 一張A4紙就能寫(xiě)完所有特性. 你想想看, C++到了領(lǐng)悟階段, 也只用那幾個(gè)簡(jiǎn)單特性, 剩下的都是一大堆解決各種內(nèi)存問(wèn)題的技巧. 而Golang一開(kāi)始就簡(jiǎn)單, 何必浪費(fèi)生命去研究那一大堆的奇技淫巧呢?

Golang的坑只有2個(gè):1. interface{}和nil配合使用, 2. for循環(huán)時(shí), 將循環(huán)變量引入閉包(Golang, Lua, C#閉包變量捕獲差異) 完全不影響正常使用, 復(fù)合語(yǔ)言概念, 只是看官方后面怎么有效的避免

用Golang就忘記繼承那套東西, 用組合+接口

用Golang服務(wù)器如何保證解決游戲服務(wù)器存盤(pán)一致性問(wèn)題? stop the world是肯定的, 但是Golang可以從語(yǔ)言層并發(fā)序列化玩家數(shù)據(jù), 再通過(guò)后臺(tái)存盤(pán)

channel是goroutine雖然是Golang的語(yǔ)言特性. 但是在編寫(xiě)服務(wù)器時(shí), 其實(shí)只有底層用的比較多.

Golang的第三方庫(kù)簡(jiǎn)直多如牛毛, 好的也很多

不要說(shuō)模板了, C#的也不好用, 官方在糾結(jié)也不要加, 使用中, 沒(méi)模板確實(shí)有點(diǎn)不方便. 用interface{}/反射做泛型對(duì)于Golang這種強(qiáng)類型語(yǔ)言來(lái)說(shuō),還是有點(diǎn)打臉

運(yùn)行期

Golang和C++比性能的話, 這是C++的優(yōu)勢(shì), Golang因?yàn)闆](méi)虛擬機(jī), 只有薄薄的一層調(diào)度層. 因此性能是非常高的, 用一點(diǎn)性能犧牲換開(kāi)發(fā)效率, 妥妥的

1.6版后的GC優(yōu)化的已經(jīng)很好了, 如果你不是高性能,高并發(fā)Web應(yīng)用, 非要找出一堆的優(yōu)化技巧的話. 只用Golang寫(xiě)點(diǎn)游戲服務(wù)器, 那點(diǎn)GC損耗可以忽略不計(jì)

和其他現(xiàn)代語(yǔ)言一樣, 崩潰捕捉是標(biāo)配功能, 我用Golang的服務(wù)器線上跑, 基本沒(méi)碰到過(guò)崩潰情況

熱更新: 官方已經(jīng)有plugin系統(tǒng)的提交, 跨平臺(tái)的. 估計(jì)很快就可以告別手動(dòng)cgo做so熱更新

開(kāi)發(fā), 調(diào)試, 部署, 優(yōu)化

LiteIDE是我首選的Golang的IDE, 雖然有童鞋說(shuō)B格不高. 但這估計(jì)實(shí)在是找不到缺點(diǎn)說(shuō)了, 別跟我說(shuō)Visual Studio, 那是宇宙級(jí)的...

曾經(jīng)聽(tīng)說(shuō)有人不看好Golang, 我問(wèn)為啥: 說(shuō)這么新的語(yǔ)言, 不好招人,后面打聽(tīng)到他是個(gè)策劃... 好吧

真實(shí)情況是這樣的: Golang對(duì)于有點(diǎn)編程基礎(chǔ)的新人來(lái)說(shuō), 1周左右可以開(kāi)始貢獻(xiàn)代碼. 老司機(jī)2~3天.

開(kāi)發(fā)效率還是不錯(cuò)的, 一般大的游戲功能, 2*2人一周3~4個(gè)整完. 這換C++時(shí)代, 大概也就1~2個(gè)還寫(xiě)不完. 對(duì)接服務(wù)器sdk的話, 大概1天接個(gè)10多個(gè)沒(méi)問(wèn)題

Golang自帶性能調(diào)優(yōu)工具, 從內(nèi)存, CPU, 阻塞點(diǎn)等幾個(gè)方面直接出圖進(jìn)行分析, 非常直觀, 可以參考我博客幾年前的分析: 使用Golang進(jìn)行性能分析(Profiling)

Golang支持交叉編譯, 跨平臺(tái)部署, 什么概念? linux是吧? 不問(wèn)你什么版本, 直接windows上編譯輸出一個(gè)elf, 甩到服務(wù)器上開(kāi)跑.不超過(guò)1分鐘時(shí)間..

GoLang -- gRPC框架四大服務(wù)

在 gRPC 里客戶端應(yīng)用可以像調(diào)用本地對(duì)象一樣直接調(diào)用另一臺(tái)不同的機(jī)器上服務(wù)端 應(yīng)用的方法，使得您能夠更容易地創(chuàng)建分布式應(yīng)用和服務(wù)。與許多 RPC 系統(tǒng)類似，gRPC 也是基于以下理念：定義一個(gè)服務(wù)，指定其能夠被遠(yuǎn)程調(diào)用的方法（包含參數(shù)和返回類型）。在服務(wù)端實(shí)現(xiàn)這個(gè)接口，并運(yùn)行一個(gè) gRPC 服務(wù)器來(lái)處理客戶端調(diào)用。在客戶端擁有一個(gè)存根能夠像服務(wù)端一樣的方法。

gRPC 客戶端和服務(wù)端可以在多種環(huán)境中運(yùn)行和交互 - 從 google 內(nèi)部的服務(wù)器到你自己的筆記本，并且可以用任何 gRPC 支持的語(yǔ)言來(lái)編寫(xiě)。所以，你可以很容易地用 Java 創(chuàng)建一個(gè) gRPC 服務(wù)端，用 Go、Python、Ruby 來(lái)創(chuàng)建客戶端。此外，Google 最新 API 將有 gRPC 版本的接口，使你很容易地將 Google 的功能集成到你的應(yīng)用里。

gRPC 默認(rèn)使用 protocol buffers，這是 Google 開(kāi)源的一套成熟的結(jié)構(gòu)數(shù)據(jù)序列化機(jī)制（當(dāng)然也可以使用其他數(shù)據(jù)格式如 JSON）。名叫 proto3 的新風(fēng)格的 protocol buffers，它擁有輕量簡(jiǎn)化的語(yǔ)法、一些有用的新功能，并且支持更多新語(yǔ)言。當(dāng)前針對(duì) Java 和 C++ 發(fā)布了 beta 版本，針對(duì) JavaNano（即 Android Java）發(fā)布 alpha 版本，在protocol buffers Github 源碼庫(kù)里有 Ruby 支持， 在golang/protobuf Github 源碼庫(kù)里還有針對(duì) Go 語(yǔ)言的生成器， 對(duì)更多語(yǔ)言的支持正在開(kāi)發(fā)中。

有了 gRPC， 我們可以一次性的在一個(gè) .proto 文件中定義服務(wù)并使用任何支持它的語(yǔ)言去實(shí)現(xiàn)客戶端和服務(wù)器，反過(guò)來(lái)，它們可以在各種環(huán)境中，從Google的服務(wù)器到你自己的平板電腦—— gRPC 幫你解決了不同語(yǔ)言及環(huán)境間通信的復(fù)雜性.使用 protocol buffers 還能獲得其他好處，包括高效的序列號(hào)，簡(jiǎn)單的 IDL 以及容易進(jìn)行接口更新。

現(xiàn)在讓我們來(lái)仔細(xì)了解一下當(dāng) gRPC 客戶端調(diào)用 gRPC 服務(wù)端的方法時(shí)到底發(fā)生了什么。我們不究其實(shí)現(xiàn)細(xì)節(jié)，關(guān)于實(shí)現(xiàn)細(xì)節(jié)的部分，你可以在我們的特定語(yǔ)言頁(yè)面里找到更為詳盡的內(nèi)容。

首先我們來(lái)了解一下最簡(jiǎn)單的 RPC 形式：客戶端發(fā)出單個(gè)請(qǐng)求，獲得單個(gè)響應(yīng)。

服務(wù)端流式 RPC 除了在得到客戶端請(qǐng)求信息后發(fā)送回一個(gè)應(yīng)答流之外，與我們的簡(jiǎn)單例子一樣。在發(fā)送完所有應(yīng)答后，服務(wù)端的狀態(tài)詳情(狀態(tài)碼和可選的狀態(tài)信息)和可選的跟蹤元數(shù)據(jù)被發(fā)送回客戶端，以此來(lái)完成服務(wù)端的工作。客戶端在接收到所有服務(wù)端的應(yīng)答后也完成了工作。

客戶端流式 RPC 也基本與我們的簡(jiǎn)單例子一樣，區(qū)別在于客戶端通過(guò)發(fā)送一個(gè)請(qǐng)求流給服務(wù)端，取代了原先發(fā)送的單個(gè)請(qǐng)求。服務(wù)端通常（但并不必須）會(huì)在接收到客戶端所有的請(qǐng)求后發(fā)送回一個(gè)應(yīng)答，其中附帶有它的狀態(tài)詳情和可選的跟蹤數(shù)據(jù)。

雙向流式 RPC ，調(diào)用由客戶端調(diào)用方法來(lái)初始化，而服務(wù)端則接收到客戶端的元數(shù)據(jù)，方法名和截止時(shí)間。服務(wù)端可以選擇發(fā)送回它的初始元數(shù)據(jù)或等待客戶端發(fā)送請(qǐng)求。 下一步怎樣發(fā)展取決于應(yīng)用，因?yàn)榭蛻舳撕头?wù)端能在任意順序上讀寫(xiě) - 這些流的操作是完全獨(dú)立的。例如服務(wù)端可以一直等直到它接收到所有客戶端的消息才寫(xiě)應(yīng)答，或者服務(wù)端和客戶端可以像"乒乓球"一樣：服務(wù)端后得到一個(gè)請(qǐng)求就回送一個(gè)應(yīng)答，接著客戶端根據(jù)應(yīng)答來(lái)發(fā)送另一個(gè)請(qǐng)求，以此類推。

通過(guò)運(yùn)行下面的命令克隆并安裝grpc-go代碼庫(kù)：

下載protobuf源碼包

安裝golang-protobuf

第一步使用 protocol buffers去定義 gRPC service 和方法 request 以及 response 的類型。

要定義一個(gè)服務(wù)，必須在.proto 文件中指定 service：

然后在服務(wù)中定義 rpc 方法，指定請(qǐng)求的和響應(yīng)類型，gRPC 允許定義4種類型的 service 方法。

服務(wù).proto文件如下所示：

網(wǎng)站標(biāo)題：go語(yǔ)言流媒體服務(wù)器框架,go語(yǔ)言流媒體開(kāi)發(fā)
瀏覽地址：http://chinadenli.net/article37/dsihdsj.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、網(wǎng)頁(yè)設(shè)計(jì)公司、標(biāo)簽優(yōu)化、定制開(kāi)發(fā)、營(yíng)銷型網(wǎng)站建設(shè)、動(dòng)態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)