golang有哪些不错的游戏服务器框架

为什么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的函数还得自己主动叫runtimeSched()来进行调度切换。

3、golang的运行效率怎么样？

我是相当反感所谓的ping\pong式benchmark，运行效率需要放到具体的工作环境下面考虑。

首先，它再快也是快不过c的，毕竟底下做了那么多工作，又有调度，又有gc什么的。那为什么在那些benchmark里面，golang、nodejs、erlang的响应效率看上去那么优秀呢，响应快，并发强？并发能力强的原因上面已经提到了，响应快是因为大量非阻塞式i\o *** 作出现的原因。这一点c也可以做到，并且能力更强，但是得多写不少优质代码。

然后，针对游戏服务器这种高实时性的运行环境，GC所造成的跳帧问题确实比较麻烦，前面的大神 @达达 有比较详细的论述和缓解方案，就不累述了 。随着golang的持续开发，相信应该会有非常大的改进。一是屏蔽内存 *** 作是现代语言的大势所趋，它肯定是需要被实现的；二是GC算法已经相当的成熟，效率勉勉强强过得去；三是可以通过incremental的 *** 作来均摊cpu消耗。

用这一点点效率损失换取一个更高的生产能力是不是值得呢？我觉得是值得的，硬件已经很便宜了，人生苦短，让自己的生活更轻松一点吧: )。

4、基于以上的论述，我认为采用go进行小范围的MMORPG开发是可行的。

这样一个宽泛的问题在这里根本就让人无法回答
你要是初学c++就根本不用考虑这个问题，而是需要把基础弄结实了，
如果你已经有c++基础了就可以弄一套开源的服务器框架学习一下，远比在贴吧，论坛上问这样的问题来的有效率。
比如腾讯开源的: >

分享10个最好的工具、框架和库，以帮助 Java 开发人员在不同的 Java 项目中更好地执行单元测试和集成测试。

▌JUnit

JUnit 应该不需要过多介绍。哪怕你是一位 Java 初学者，我想你也应该听说过它，它能够让你为 Java 代码编写单元测试。

几乎所有常用的 IDE，比如 Eclipse、NetBeans 和 IntelliJ，都能够集成 JUnit，这意味着开发者直接可以在这些 IDE 中编写并运行单元测试。

目前大多数人仍然在使用 JUnit 4，事实上新的 JUnit 5 已经发布。你可以用 JUnit 进行单元测试和集成测试，此外，它还支持 Java 8 功能。

▌REST Assured

相比于 Groovy 这类动态语言，在 Java 中测试和验证 REST 服务更难。

REST Assured 为 Java 带来了这些语言的简单性。这对于 REST API 集成测试来说是一个很好的工具。

▌Selenium

Selenium 应该是最受欢迎的 Java UI 测试工具，有了它，你不需要在浏览器中启动 JSP 页面即可对其进行测试。

你可以使用 JUnit 和 Selenium 来测试 Web 应用程序 UI。还可以使用它进行 Web 应用程序验收测试。

▌TestNG

TestNG 这款测试框架最早源于 JUnit 和 NUnit 的启发，但它在这两者的基础上引入了许多新的功能，其功能更强大，也更易于使用，提供了注解功能，支持在任意大型线程池中运行各种可用策略的测试（所有方法都在自己的线程中，每个测试类对应一个线程）。

随着 JUnit 4 中注解功能的引入以及 Hamcrest 框架的整合，JUnit 4 和 TestNG 之间的差距已经很小。

▌Mockito

Java 有许多 Mock 框架，例如 PowerMock 和 JMock，但我个人更喜欢 Mockito，它具有简单的 API、优秀的文档以及大量示例。

Mock 测试是现代单元测试的关键技术之一，开发者不需要依赖其他情况也可独立测试代码，因此我建议每个 Java 开发人员都应该学习 Mock 框架来与 JUnit 结合使用。

我个人最喜欢的 Mock 框架是 Mockito，如果你喜欢的话，也可以了解一下 PowerMock或者 JMock。

▌Spock 框架

Spock 是一款用于 Java 和 Groovy 应用程序的测试和规范框架。它用 Groovy 编写，因此它具有很强的表现力，并且非常规范。

使用 Spock 时，测试将变得更加易读易维护。此外，得益于它的 JUnit 运行器，Spock能够兼容大多数 IDE、构建工具和持续集成服务器。

不过遗憾的是，线上讲述 Spock 框架的课程好像不多，“使用 Spock 进行 Java 测试”这本书倒是一个不错的学习资源。

▌Cucumber

Cucumber 是一款很好的自动化集成测试工具，与其他同类工具相比，它的规范功能是一大特色。

Cucumber 将规范和测试文档合并为一个文档，由于文档也会被 Cucumber 自动测试，因此规范文档始终会被更新为最新版本。

▌Spring 测试

Spring MVC 自带了一个非常有用的测试框架，可以在不涉及 Web 容器的情况下进行深入测试。

这个是一个非常有用的库，可以为 Spring 应用程序编写自动化测试。它为 Spring 应用程序（包括 MVC 控制器）编写单元和集成测试提供了强有力的支持。

还有一个 Spring Test DbUnit，它将 Spring 测试框架与 DbUnit 以及 HtmlUnit 集成在了一起。

使用这些工具，你可以轻松完成 Spring MVC 应用程序的自动化测试。

▌DBUnit

对于大多数的 Java 应用程序，不管是核心 Java 程序还是 Java Web 应用，数据库都是其不可或缺的重要组成部分，并且数据库还很可能是单元测试的最大障碍。

连接到 Dev 或者 UAT 数据库进行集成测试是不可靠的，因为任何人都可以更改数据和模式，比如表和存储过程，这都会导致自动化集成测试的失败。

DbUnit 是 JUnit 的扩展，在每次集成测试之前它可以将数据库初始化为已知状态，从而确保数据库包含正确的数据。

DbUnit 是一个非常有用的工具，它可以帮助我们将测试数据和测试代码分开。

▌Robot 框架

Robot 框架是一个基于 Python 的通用自动化测试框架，主要用于验收测试以及验收测试驱动开发。

它采用表格测试数据语法，是一个关键字驱动的测试框架。分布式异构应用程序的验证往往需要多种技术和接口，非常适合用 Robot 来测试。

---