重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
使用Go 语言开发大型 MMORPG 游戏伺服器怎么样
创新互联公司是专业的梁园网站建设公司,梁园接单;提供做网站、网站建设,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行梁园网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
如果是大型网路游戏的话,我觉得是不合适的。现阶段go语言的执行效率还是太低了。在底层编译器的优化方面做得和c++相比还是差了不少。go语言也是比较适合快速开发的专案比较合适
从2013年起,经朋友推荐开始用Golang编写游戏登陆伺服器, 配合C++做第三方平台验证. 到编写独立工具导表工具GitHub - davyxu/tabtoy: 跨平台的高效能便捷电子表格汇出器. 以及网路库GitHub - davyxu/cell: 简单,方便,高效的Go语言的游戏伺服器底层. 最终使用这些工具及库编写整个游戏伺服器框架, 我的感受是很不错的
细节看来, 有如下的几个点:
语言, 库
Golang语言特性和C很像, 简单, 一张A4纸就能写完所有特性. 你想想看, C++到了领悟阶段, 也只用那几个简单特性, 剩下的都是一大堆解决各种记忆体问题的技巧. 而Golang一开始就简单, 何必浪费生命去研究那一大堆的奇技淫巧呢?
Golang的坑只有2个:1. interface{}和nil配合使用, 2. for回圈时, 将回圈变数引入闭包(Golang, Lua, C#闭包变数捕获差异) 完全不影响正常使用, 复合语言概念, 只是看官方后面怎么有效的避免
用Golang就忘记继承那套东西, 用组合+介面
用Golang伺服器如何保证解决游戏伺服器存档一致性问题? s the world是肯定的, 但是Golang可以从语言层并发序列化玩家资料, 再通过后台存档
channel是goroutine虽然是Golang的语言特性. 但是在编写伺服器时, 其实只有底层用的比较多.
Golang的第三方库简直多如牛毛, 好的也很多
不要说模板了, C#的也不好用, 官方在纠结也不要加, 使用中, 没模板确实有点不方便. 用interface{}/反射做泛型对于Golang这种强型别语言来说,还是有点打脸
执行期
Golang和C++比效能的话, 这是C++的优势, Golang因为没虚拟机器, 只有薄薄的一层排程层. 因此效能是非常高的, 用一点效能牺牲换开发效率, 妥妥的
1.6版后的GC优化的已经很好了, 如果你不是高效能,高并发Web应用, 非要找出一堆的优化技巧的话. 只用Golang写点游戏伺服器, 那点GC损耗可以忽略不计
和其他现代语言一样, 崩溃捕捉是标配功能, 我用Golang的伺服器线上跑, 基本没碰到过崩溃情况
热更新: 官方已经有plugin系统的提交, 跨平台的. 估计很快就可以告别手动cgo做so热更新
开发, 除错, 部署, 优化
LiteIDE是我首选的Golang的IDE, 虽然有童鞋说B格不高. 但这估计实在是找不到缺点说了, 别跟我说Visual Studio, 那是宇宙级的...
曾经听说有人不看好Golang, 我问为啥: 说这么新的语言, 不好招人,后面打听到他是个策划... 好吧
真实情况是这样的: Golang对于有点程式设计基础的新人来说, 1周左右可以开始贡献程式码. 老司机2~3天.
开发效率还是不错的, 一般大的游戏功能, 2*2人一周3~4个整完. 这换C++时代, 大概也就1~2个还写不完. 对接伺服器sdk的话, 大概1天接个10多个没问题
Golang自带效能调优工具, 从记忆体, CPU, 阻塞点等几个方面直接出图进行分析, 非常直观, 可以参考我部落格几年前的分析: 使用Golang进行效能分析(Profiling)
Golang支 *** 叉编译, 跨平台部署, 什么概念? linux是吧? 不问你什么版本, 直接windows上编译输出一个elf, 甩到伺服器上开跑.不超过1分钟时间..
1.为什么golang的开发效率高?
golang是一编译型的强型别语言,它在开发上的高效率主要来自于后发优势,不用考虑旧有恶心的历史,又有一个较高的工程视角。良好的避免了程式设计师因为“ { 需不需要独占一行 ”这种革命问题打架,也解决了一部分趁编译时间找产品妹妹搭讪的阶级敌人。
它有自己的包管理机制,工具链成熟,从开发、除错到释出都很简单方便;
有反向介面、defer、coroutine等大量的syntactic sugar;
编译速度快,因为是强型别语言又有gc,只要通过编译,非业务毛病就很少了;
它在语法级别上支援了goroutine,这是大家说到最多的内容,这里重点提一下。首先,coroutine并不稀罕,语言并不能超越硬体、作业系统实现神乎其神的功能。golang可以做到事情,其他语言也可以做到,譬如c++,在boost库里面自己就有的coroutine实现(当然用起来跟其他boost库一样恶心)。golang做的事情,是把这一套东西的使用过程简化了,并且提供了一套channel的通讯模式,使得程式设计师可以忽略诸如死锁等问题。
goroutine的目的是描述并发程式设计模型。并发与并行不同,它并不需要多核的硬体支援,它不是一种物理执行状态,而是一种程式逻辑流程。它的主要目的不是利用多核提高执行效率,而是提供一种更容易理解、不容易出错的语言来描述问题。
实际上golang预设就是执行在单OS程序上面的,通过指定环境变数GOMAXPROCS才能转身跑在多OS程序上面。有人提到了网易的pomelo,开源本来是一件很不错的事情,但是基于自己对callback hell的偏见,我一直持有这种态度:敢用nodejs写大规模游戏伺服器的人,都是真正的勇士 : ) 。
2、Erlang与Golang的coroutine有啥区别,coroutine是啥?
coroutine本质上是语言开发者自己实现的、处于user space内的执行绪,无论是erlang、还是golang都是这样。需要解决没有时钟中断;碰著阻塞式i\o,整个程序都会被作业系统主动挂起;需要自己拥有排程控制能力(放在并行环境下面还是挺麻烦的一件事)等等问题。那为啥要废老大的劲自己做一套执行绪放user space里面呢?
并发是伺服器语言必须要解决的问题;
system space的程序还有执行绪排程都太慢了、占用的空间也太大了。
把执行绪放到user space的可以避免了陷入system call进行上下文切换以及高速缓冲更新,执行绪本身以及切换等操作可以做得非常的轻量。这也就是golang这类语言反复提及的超高并发能力,分分钟给你开上几千个执行绪不费力。
不同的是,golang的并发排程在i/o等易发阻塞的时候才会发生,一般是内封在库函式内;erlang则更夸张,对每个coroutine维持一个计数器,常用语句都会导致这个计数器进行reduction,一旦到点,立即切换排程函式。
中断介入程度的不同,导致erlang看上去拥有了preemptive scheduling的能力,而golang则是cooperative shceduling的。golang一旦写出纯计算死回圈,程序内所有会话必死无疑;要有大计算量少i\o的函式还得自己主动叫runtime.Sched()来进行排程切换。
3、golang的执行效率怎么样?
我是相当反感所谓的ping\pong式benchmark,执行效率需要放到具体的工作环境下面考虑。
首先,它再快也是快不过c的,毕竟底下做了那么多工作,又有排程,又有gc什么的。那为什么在那些benchmark里面,golang、nodejs、erlang的响应效率看上去那么优秀呢,响应快,并发强?并发能力强的原因上面已经提到了,响应快是因为大量非阻塞式i\o操作出现的原因。这一点c也可以做到,并且能力更强,但是得多写不少优质程式码。
然后,针对游戏伺服器这种高实时性的执行环境,GC所造成的跳帧问题确实比较麻烦,前面的大神 @达达 有比较详细的论述和缓解方案,就不累述了 。随着golang的持续开发,相信应该会有非常大的改进。一是遮蔽记忆体操作是现代语言的大势所趋,它肯定是需要被实现的;二是GC演算法已经相当的成熟,效率勉勉强强过得去;三是可以通过incremental的操作来均摊cpu消耗。
用这一点点效率损失换取一个更高的生产能力是不是值得呢?我觉得是值得的,硬体已经很便宜了,人生苦短,让自己的生活更轻松一点吧: )。
4、基于以上的论述,我认为采用go进行小范围的MMORPG开发是可行的。
如果跟C语言比,大部分指令码都胜出啊。Go, Node.js, Python ......
网易弄过一个Node.js的开源伺服器框架。
至于IDE, 不重要,做伺服器开发很少会要开着IDE除错的。最常用的手段就是打Log. 设定了断点也很难调,多个客户端并发。
那种单客户端连线进来就可以重现的bug倒是可以用IDE调,但是这种bug本来就容易解决。
用指令码语言,有一个很大的好处是容易做自动测试,可以更好地保证程式码质量。
--------------------------
开发效率当然是指令码高。执行效率,其实更重要的是并发,框架合理的话增加机器就可以直接提高效率增加人数。
用Go开发大型mmorpg服务端不会有问题的,如果掉坑里肯定不会是语言的问题。
唯一比较可能掉进去的坑就只有GC,其实很容易预防和调整的,具体细节可以看我部落格分享的文章。
但是技术选型不只是选语言,如果当时我手头有一套效能满意,开发效率OK,人员补给不会有问题的技术方案,不管是什么语言的,我肯定不会放弃它而选择冒险的。
public void actionPerformed(ActionEvent e)
{
if(e.getSource()==xinjian)
{
text.setText("");
}
if(e.getSource()==dakai)
{
openFD.show();
String s;
当客户端在 发出POST请求时/albums,您希望将请求正文中描述的专辑添加到现有专辑数据中。
为此,您将编写以下内容:
1、编写代码
a.添加代码以将专辑数据添加到专辑列表。
在此代码中:
1)用于Context.BindJSON 将请求正文绑定到newAlbum。
2) album将从 JSON 初始化的结构附加到albums 切片。
3)向响应添加201状态代码,以及表示您添加的专辑的 JSON。
b.更改您的main函数,使其包含该router.POST函数,如下所示。
在此代码中:
1)将路径中的POST方法与 /albumspostAlbums函数相关联。
使用 Gin,您可以将处理程序与 HTTP 方法和路径组合相关联。这样,您可以根据客户端使用的方法将发送到单个路径的请求单独路由。
a.如果服务器从上一节开始仍在运行,请停止它。
b.从包含 main.go 的目录中的命令行,运行代码。
c.从不同的命令行窗口,用于curl向正在运行的 Web 服务发出请求。
该命令应显示添加专辑的标题和 JSON。
d.与上一节一样,使用curl检索完整的专辑列表,您可以使用它来确认添加了新专辑。
该命令应显示专辑列表。
当客户端向 发出请求时GET /albums/[id],您希望返回 ID 与id路径参数匹配的专辑。
为此,您将:
a.在您在上一节中添加的函数下方postAlbums,粘贴以下代码以检索特定专辑。
此getAlbumByID函数将提取请求路径中的 ID,然后找到匹配的专辑。
在此代码中:
(1)Context.Param用于从 URL 中检索id路径参数。当您将此处理程序映射到路径时,您将在路径中包含参数的占位符。
(2)循环album切片中的结构,寻找其ID 字段值与id参数值匹配的结构。如果找到,则将该album结构序列化为 JSON,并将其作为带有200 OK HTTP 代码的响应返回。
如上所述,实际使用中的服务可能会使用数据库查询来执行此查找。
(3)如果找不到专辑,则返回 HTTP 404错误。
b.最后,更改您的main,使其包含对router.GET的新调用,路径现在为/albums/:id ,如以下示例所示。
在此代码中:
(1)将/albums/:id路径与getAlbumByID功能相关联。在 Gin 中,路径中项目前面的冒号表示该项目是路径参数。
a.如果服务器从上一节开始仍在运行,请停止它。
b.在包含 main.go 的目录中的命令行中,运行代码以启动服务器。
c.从不同的命令行窗口,用于curl向正在运行的 Web 服务发出请求。
该命令应显示您使用其 ID 的专辑的 JSON。如果找不到专辑,您将收到带有错误消息的 JSON。
恭喜!您刚刚使用 Go 和 Gin 编写了一个简单的 RESTful Web 服务。
本节包含您使用本教程构建的应用程序的代码。
学完了 net/http 和 fasthttp 两个HTTP协议接口的客户端实现,接下来就要开始Server的开发,不学不知道一学吓一跳,居然这两个库还支持Server的开发,太方便了。
相比于Java的HTTPServer开发基本上都是使用Spring或者Springboot框架,总是要配置各种配置类,各种 handle 对象。Golang的Server开发显得非常简单,就是因为特别简单,或者说没有形成特别统一的规范或者框架,我发现了很多实现方式,HTTP协议基于还是 net/http 和 fasthttp ,但是 handle 语法就多种多样了。
先复习一下: Golang语言HTTP客户端实践 、 Golang fasthttp实践 。
在Golang语言方面,实现某个功能的库可能会比较多,有机会还是要多跟同行交流,指不定就发现了更好用的库。下面我分享我学到的六种Server开发的实现Demo。
基于 net/http 实现,这是一种比较基础的,对于接口和 handle 映射关系处理并不优雅,不推荐使用。
第二种也是基于 net/http ,这种编写语法可以很好地解决第一种的问题,handle和path有了类似配置的语法,可读性提高了很多。
第三个基于 net/http 和 github.com/labstack/echo ,后者主要提供了 Echo 对象用来处理各类配置包括接口和handle映射,功能很丰富,可读性最佳。
第四种依然基于 net/http 实现,引入了 github.com/gin-gonic/gin 的路由,看起来接口和 handle 映射关系比较明晰了。
第五种基于 fasthttp 开发,使用都是 fasthttp 提供的API,可读性尚可,handle配置倒是更像Java了。
第六种依然基于 fasthttp ,用到了 github.com/buaazp/fasthttprouter ,有点奇怪两个居然不在一个GitHub仓库里。使用语法跟第三种方式有点类似,比较有条理,有利于阅读。