本文目录一览：
- 1、使用Go 语言开发大型 MMORPG 游戏服务器怎么样
- 2、嵌入式golang占用内存高
- 3、golang如何去封装外部接口
- 4、socket 通信粘包怎么处理
- 5、Golang中的自定义json序列化
- 6、深入理解golang
使用Go 语言开发大型 MMORPG 游戏服务器怎么样
从2013年起,经朋友推荐开始用Golang编写游戏登陆服务器, 配合C++做第三方平台验证. 到编写独立工具导表工具GitHub - davyxu/tabtoy: 跨平台的高性能便捷电子表格导出器. 以及网络库GitHub - davyxu/cellnet: 简单,方便,高效的Go语言的游戏服务器底层. 最终使用这些工具及库编写整个游戏服务器框架, 我的感受是很不错的
细节看来, 有如下的几个点:
语言, 库
Golang语言特性和C很像, 简单, 一张A4纸就能写完所有特性. 你想想看, C++到了领悟阶段, 也只用那几个简单特性, 剩下的都是一大堆解决各种内存问题的技巧. 而Golang一开始就简单, 何必浪费生命去研究那一大堆的奇技淫巧呢?
Golang的坑只有2个:1. interface{}和nil配合使用, 2. for循环时, 将循环变量引入闭包(Golang, Lua, C#闭包变量捕获差异) 完全不影响正常使用, 复合语言概念, 只是看官方后面怎么有效的避免
用Golang就忘记继承那套东西, 用组合+接口
用Golang服务器如何保证解决游戏服务器存盘一致性问题? stop 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分钟时间..
嵌入式golang占用内存高
嵌入式golang占用内存高可能问题在于缓存。
清空日志后比较惊喜地发现，内存瞬间暴降至20M。
嵌入式系统由硬件和软件组成．是能够独立进行运作的器件。其软件内容只包括软件运行环境及其操作系统。硬件内容包括信号处理器、存储器、通信模块等在内的多方面的内容。相比于一般的计算机处理系统而言，嵌入式系统存在较大的差异性，它不能实现大容量的存储功能，因为没有与之相匹配的大容量介质，大部分采用的存储介质有E-PROM、EEPROM等，软件部分以API编程接口作为开发平台的核心。嵌入式系统最核心的层次是中央处理单元部分，它包含运算器和控制器模块，在cpu的基础上进一步配上存储器模块、电源模块、复位模块等就构成了通常所说的最小系统。由于技术的进步，集成电路生产商通常会把许多外设做进同一个集成电路中，这样在使用上更加方便，这样一个芯片通常称之为微控制器。在微控制器的基础上进一步扩展电源传感与检测、执行器模块以及配套软件并构成一个具有特定功能的完整单元，就称之为一个嵌入式系统或嵌入式应用。
golang如何去封装外部接口
1.为什么golang的开发效率高？golang是一编译型的强类型语言，它在开发上的高效率主要来自于后发优势，不用考虑旧有恶心的历史，又有一个较高的工程视角。良好的避免了程序员因为“{需不需要独占一行”这种革命问题打架，也解决了一部分趁编译时间找产品妹妹搭讪的阶级敌人。它有自己的包管理机制，工具链成熟，从开发、调试到发布都很简单方便；有反向接口、defer、coroutine等大量的syntacticsugar；编译速度快，因为是强类型语言又有gc，只要通过编译，非业务毛病就很少了；它在语法级别上支持了goroutine，这是大家说到最多的内容，这里重点提一下。首先，coroutine并不稀罕，语言并不能超越硬件、操作系统实现神乎其神的功能。golang可以做到事情，其他语言也可以做到，譬如c++，在boost库里面自己就有的coroutine实现（当然用起来跟其他boost库一样恶心）。golang做的事情，是把这一套东西的使用过程简化了，并且提供了一套channel的通信模式，使得程序员可以忽略诸如死锁等问题。goroutine的目的是描述并发编程模型。并发与并行不同，它并不需要多核的硬件支持，它不是一种物理运行状态，而是一种程序逻辑流程。它的主要目的不是利用多核提高运行效率，而是提供一种更容易理解、不容易出错的语言来描述问题。实际上golang默认就是运行在单OS进程上面的，通过指定环境变量GOMAXPROCS才能转身跑在多OS进程上面。有人提到了网易的pomelo，开源本来是一件很不错的事情，但是基于自己对callbackhell的偏见，我一直持有这种态度：敢用nodejs写大规模游戏服务器的人，都是真正的勇士:)。2、Erlang与Golang的coroutine有啥区别，coroutine是啥？coroutine本质上是语言开发者自己实现的、处于userspace内的线程，无论是erlang、还是golang都是这样。需要解决没有时钟中断；碰着阻塞式i\o，整个进程都会被操作系统主动挂起；需要自己拥有调度控制能力（放在并行环境下面还是挺麻烦的一件事）等等问题。那为啥要废老大的劲自己做一套线程放userspace里面呢？并发是服务器语言必须要解决的问题；systemspace的进程还有线程调度都太慢了、占用的空间也太大了。把线程放到userspace的可以避免了陷入systemcall进行上下文切换以及高速缓冲更新，线程本身以及切换等操作可以做得非常的轻量。这也就是golang这类语言反复提及的超高并发能力，分分钟给你开上几千个线程不费力。不同的是，golang的并发调度在i/o等易发阻塞的时候才会发生，一般是内封在库函数内；erlang则更夸张，对每个coroutine维持一个计数器，常用语句都会导致这个计数器进行reduction，一旦到点，立即切换调度函数。中断介入程度的不同，导致erlang看上去拥有了preemptivescheduling的能力，而golang则是cooperativeshceduling的。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开发是可行的。
socket 通信粘包怎么处理
一、socket 通信粘包的处理方法：
1、对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；
2、对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；
3、由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。
二、实现代码：
三、方法注意事项：
1、第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。
2、第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包；
3、第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。
四、实验环境
1、硬件环境：服务器：pentium 350 微机 、客户机：pentium 166微机、网络平台：由10兆共享式hub连接而成的局域网；
2、软件环境：操作系统：windows 98 、编程语言：visual c++ 5.0
Golang中的自定义json序列化
后端开发人员跟前端对接接口的时候，或多或少都会面临一些沟通问题，比如说枚举字符的定义，比如有整形状态字段： state
通常给前端的时候，前段要做的是将1，2，3以及对应的中文释义存储为key/value的形式，key与value单看都无法知道对方的语义，
比如我只知道状态值为“1”， 是无法将其与“成功”对应起来的（当然这套状态的设计者肯定是知道的），后端通常给到前端的restful api
接口定义也是key/value的形式，这乍一看其实也没啥毛病，只要有key/value也没问题，后端定义通常会是
但数字的表现形式终归是不不太明确的，如果对状态的定义换成以下形式：
基本可以理解为中英文互译了，理解起来也会更清晰一些不是，如果这么做的话，后端给到前端的响应字段状态的类型就需要修改成字符器格式
后端还是要做一层字符串到整型的转换，从目的来讲，我们只是想返给前端的 state 字段是字符串而已，也就是在做json序列化的时候将整型与字符串做一层转换，有更优雅的做法如下所示
只需要做两件事，自定义类型 MyState ，实现 MarshalJSON 方法
只要类型实现了 MarshalJSON 方法，在json序列化时就会调用此方法，如此一来，我们就轻松实现了自定义json序列化，反序列化同样如此
实现起来也很简单
需要注意的是， UnmarshalJSON 方法操作过程需要给 receiver 也就是 u 赋值，所以必须是指针类型，同样的，在实现
MarshalJSON 方法， receiver 的类型需要与结构体定义中的类型保持一致，否则自定义序列化会失败
参考：
深入理解golang
最近三年，在工作中使用go开发了不少服务。深感go的便捷，以及它的runtime的复杂。我觉得需要定期的进行总结，因此决定写这篇文章，也许更准确的，应该叫笔记。
最近终于解决了一个和cgo有关的问题。这个问题从发现到解决前后经历了接近4个月，当然，和人手不足也有关系。而对于我个人而言，这个问题其实历时2年！这得从头说起。
在上一家公司的一个项目里，有一个服务做音视频数据的提取，这个服务运行在嵌入式设备TX2上。音视频提取这一关键功能主要利用nvidia基于gstreamer开发的插件，这个插件可以发挥nvidia gpu的硬件解码功能。当时这个服务使用go和c混编的方式，问题的症状是服务运行一段时间后，不输出音视频数据。遗憾的是，由于疫情，项目停止，因此没有机会继续研究这个问题。
时间来到去年底。当前这个项目进行压力测试，发现关键的语音处理服务运行一段时间后，会出现不拉流的情况，因此也没有后续的结果输出。症状和上一个项目非常像。虽然使用的第三方SDK不一样，但同样用了go和c混编的方式。一开始，焦点就放在go的运行时上，觉得可能是go和c相互调用的方式不对。经过合理猜测，并用测试进行验证后，发现问题还是在第三方拉流的SDK上，它们的回调函数必须要快，否则有可能会阻塞它们的回调线程。当然，在go调用c的时候，如果耗时比较长，会对go的运行时造成一些副作用；在c回调go的时候，go的运行时也有可能阻塞c的回调线程。但go的运行时已经比较成熟，因此我觉得它对这个问题的贡献不大。以上采用了假设-验证的方法，主要的原因还是第三方的拉流SDK不开源。在定位问题的过程中，使用了gdb的gcore来生成堆栈；也搭建了灰度环境来进行压力测试，以及完善监控，这些都是解决方法的一部分。
正是这一问题，促使我更多的了解go的运行时。而我看得越多，越觉得go的运行时是一个庞大的怪物。因此，抱着能了解一点是一点的心态，不断的完善这篇笔记。
