基本概念

• Golang的热更新采用什么机制?

  使用go1.8提供的plugin包机制实现

• plugin包本身设计的目的是热更新么?

  plugin包其实只是支持将代码分别编译为多个动态库,动态加载后运行 并不能完全支持类似C/C++的动态库方式处理代码

• 带状态的进程热更新的基本概念及范围是什么?

  数据部分(model)不更新, 只更新逻辑部分(函数)

• 表格和配置更新算热更新么?

  算, 但不是本文描述范围

• 热更新能在windows上使用么?

  不支持

代码及结构

• 我能将原来一个exe的代码编译为so提供给plugin使用么?

  可以, 但是必须仍然保留main包作为插件入口, 并在main包内添加提供给plugin调用入口.

• 如果动态库中没有main包, 编译出的so能用么?

  不能, 包必须包含main, 否则输出的是.a的文件, plugin包加载会报错

• 动态库中, 非main包的的代码修改能做热更新么?

  不能!(崩溃了吧, 我提了一个issue: https://github.com/golang/go/issues/20554)

  如果确实做了修改, 底层会报错: plugin was built with a different version of package

  解决方法: 修改plugin包底层实现并重新编译 打开runtime/plugin.go, 注释以下代码 for _, pkghash := range md.pkghashes { if pkghash.linktimehash != *pkghash.runtimehash { return "", nil, pkghash.modulename } } 执行/usr/local/go/run.bash 重编译+测试

• 代码中哪些可以被更新? 方法可以被更新么? 闭包呢?

  只能更新拥有静态地址的结构.例如: 包级别函数(类似于静态函数)

  例如: svc_0.so里有一个Foo函数, svc_1.so修改了Foo函数实现, 热更新可实现

  闭包=函数+捕获变量, 实际上是一个动态结构, 没有静态地址, 无法被更新

  各种包级别变量, 结构体变量, 结构体方法, 局部变量均不能被热更新, 但是变量值不会被影响

  新增结构可以被运行

• 使用结构体方法调用了包级别函数, 包级别函数能被更新么?

  可以, 虽然方法不能被更新, 但方法被调用的包级别函数的地址是固定的, 所以可以被热更新

• init包初始化函数能用么? 能被热更新么?

  官方这样描述:

  When a plugin is first opened, the init functions of all packages not already part of the program are called. The main function is not run. A plugin is only initialized once, and cannot be closed

  插件第一次被打开时, 其关联的, 没有成为程序的一部分的所有的包的init函数将被调用. 插件的main函数不会被调用. 插件只会被初始化一次, 不能被关闭

  因此, 需要手动将init函数改成自己的函数, 统一在so的main包里调用

编译

• 如何编译获得plugin包支持的动态库

  SVCNAME=$1 SVCVER=$2 TIMESTAMP=`date '+%Y%m%d_%H%M%S'` go build -v -buildmode=plugin --ldflags="-pluginpath=${SVCNAME}_${TIMESTAMP}" -o ${SVCNAME}_${SVCVER}.so ${SVCNAME}

  -buildmode=plugin是重要参数

  --ldflags里的-pluginpath的作用是: 每次编译的内部识别路径都是不同的, 避免重复加载的警告

  参考: https://github.com/golang/go/issues/19004

关键字

• 最简单的调试攻略
• 多项目调试, 适用个人开发和项目开发
• 无需修改系统环境变量

准备VSCode

在官网下载最新版的VSCode:

https://code.visualstudio.com/

安装Golang插件

• 打开扩展面板

  VSCode->查看->扩展

• 找到Go插件 在搜索框里输入Go, 找到第二行写有 Rich Go language support for Visual Studio Code的插件, 点击安装

  注意不是排名最高的

• 重启编辑器

配置启动项

• 打开调试面板

  VSCode->查看->调试

• 添加调试目标

  在"没有调试"的下拉框中点击"添加配置.."

• 添加目标调试配置

  例子:

  {
      "version": "0.2.0",
      "configurations": [
          {
              "name": "Launch",
              "type": "go",
              "request": "launch",
              "mode": "debug",
              "remotePath": "",
              "port": 2345,
              "host": "127.0.0.1",
              "program": "${fileDirname}",
              "env": {
                  "GOPATH":"D:/Develop/vscodegolang"
              },
              "args": [],
              "showLog": true
          }
      ]
  }

其中: "port", "host"都是go插件自动生成的

"env"为设置环境变量, 设置为你的工程目录就可以(包含bin, src的文件夹)

准备调试插件

此时找到main.go按F5, 会报错提示:

Failded to continue:"Cannot find Delve debugger. Install from https://github.com/derekparker/delve & ensure it is in your "GOPATH/bin" or "PATH"

我们使用go命令行编译调试器

go get github.com/derekparker/delve/cmd/dlv

将dlv调试器放在GOPATH(工程目录)的bin目录下

开始调试

选中要调试的main.go, 点击F5, 既可以开始调试

调试快捷键和Visual Studio系一致

• F9 切换断点
• F10 Step over
• F11 Step in
• Shift+F11 Step out

注意点

• 某些结构体成员无法直接显示时, 可以直接选中变量名, 添加到监视, 或者右键点击: "调试:求值"

多项目调试

在launch.json中可以添加多组调试入口, 通过调试面板中选中对应的配置开启不同目标的调试

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "client",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${fileDirname}",
            "env": {
                "GOPATH":"D:/Develop/vscodegolang"
            },
            "args": [],
            "showLog": true
        },

        {
            "name": "server",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${workspaceRoot}/src/server",
            "env": {
                "GOPATH":"D:/Develop/vscodegolang"
            },
            "args": [],
            "showLog": true
        }
    ]
}

"program"中的"${fileDirname}"是以当前选中文件作为启动点

更建议使用"program"的"${workspaceRoot}", 以包名作为启动点的方式进行配置

参考链接

https://code.visualstudio.com/Docs/editor/debugging

我们先看下构造函数的规则

构造函数调用规则

构造参数量: 0表示没有构造函数, 1表示有构造函数0个参数

普通函数重载规则

实际只用考虑最典型的一种行为: 实例化子类, 转为父类调用方法, 这个时候

如果方法是override, 调用的是子类

如果方法是virutal或者不指明, 调用的是父类

整个重载过程, 子类绝对不会隐式调用父类的行为

需要构造函数么?

构造函数的优点

• 本身属于一种特殊的成员函数
• 编译器帮你自动传导调用父级

构造函数的缺点

• 隐式的调用规则
• 虽然属于成员函数, 但是与其他成员函数调用规则完全不同, 需要特殊记忆
• 带参数的构造函数, 在父类参数多于子类时, 需要引用复杂语法来实现父级构造调用

其实我们对初始化函数的需求只有1条: 自定义

所以, 可以理解Golang不加入构造函数的设计是正确的 
即: 简单, 清晰, 有规律

他们其实还是类库功能, 都在buildin包里的, 系统默认给你做了个

import(
 . "buildin"
)

将buildin的包内容都映射到全局而已, 其实你也可以用自己的包这么做

打印的另一种写法

想跟脚本一样调试打印数据么?

println("hello world")

无需包含任何包, 因为它在buildin包里

iota不是黑科技

这是在buildin包里的定义

// iota is a predeclared identifier representing the untyped integer ordinal
// number of the current const specification in a (usually parenthesized)
// const declaration. It is zero-indexed.
const iota = 0 // Untyped int.

其实go是有泛型概念的

想想map和数组的定义 
只是泛型没有开放给用户用而已(只许XX放火,不许XX点灯)

map是支持多个key的, 而且很方便

还在为多个key转id的复杂算法而头疼么?

type myKey struct{
    number int
    str string
}
func main(){
    t := map[ myKey] int {
        myKey{ 2, "world"}: 1,
 }
    fmt.Println(t[myKey{2, "world"}])
}
输出: 1

枚举是可以转成string的

默认定义一个枚举

type MyConst int
const (
 MyConst_A MyConst = iota
 MyConst_B MyConst = iota
)
func main(){
    fmt.Println(MyConst_A)
}

输出: 0 
如果我们想自动化输出MyConst_A字符串时 
就需要使用golang的一个工具链:golang.org/x/tools/cmd/stringer 
将其下载, 编译成可执行工具后, 对代码进行生成 
生成的代码会多出一个xx_string.go 
里面就是枚举的String()string 函数

临时转换一个接口并调用的方法

type love struct{
}
func (self*love)foo(){
    fmt.Println("love")
}
func main(){
 var chaos interface{} = new(love)
    chaos.(interface{
        foo()
 }).foo()
}

Golang的receiver实际上就是this的变种实现

func( self*MyStruct) foo( p int ){
}

写不惯receiver的写法? 如果这样改下呢?

func foo( self *MyStruct, p int ){
}

所以为什么说Golang还是一个C语言嘛

关于内存分配…

• new 传入Type类型, 返回*Type类型
• make 可以在分配数组时设置预分配大小, new不可以
• make 能分配数组,map, 但不能分配结构体和原始类型
• new 能分配数组, map, 结构体和原始类型等的所有类型
• &Type等效于new
• 切片不需要分配内存(make,new), 直接声明就可以了…

Golang的反射无法通过一个类型名, 创建其实例

C#有Assembly概念, 可以在一个Assembly里搜索, 创建实例

Golang是静态类型语言, 如果需要, 只能注册你需要创建的结构体, 然后将注册好的map用于创建

Golang可以替换Python来进行复杂的工具流程处理

如果你需要跨平台的工具流程处理, 对Python不熟悉, 可以使用

go run yourcode.go 参数1 参数2

方式来进行工具处理 
觉得慢, 可以编译成可执行文件

这样做的好处: 如果有些类库本身就是go写的, Python想使用是很麻烦的, 而Golang来写则轻而易举

例子: 通过go的protobuf库, 对一些文件进行处理

Golang可以自动持有方法的接收者实例

type myType struct{
}
func (self*myType) foo( p int){
    fmt.Println("hello", p )
}
func main(){
 var callback func( int )
    ins := new(myType)
    callback = ins.foo
    callback( 100 )
}

做过lua的C++代码绑定的童鞋都清楚: lua只支持外部静态或者全局函数调用 
如果要进行C++类成员函数调用时, 要自己处理this和成员函数 
这种技巧因为早起编译器的虚表不同平台实现细节不统一需要专门处理 
后面跨平台虚表统一后, 类成员函数的调用写法也是很恶心复杂的 
但是Golang的小白式用法, 直接吊打C++, 甚至C#复杂的delegate

LiteIDE篇: 多开秘籍

• 找到 菜单->查看->选项->通用->存储->存储设置到本地ini文件

• 关闭LiteIDE

• 复制LiteIDE整个目录, 命名文件夹为你的工程名

• 每个工程所在的LiteIDE的配置将是独立的, 不会互相干扰

LiteIDE篇: 测试程序也是可以调试的

别以为程序一定要是main开始的才可以调试

Golang的测试程序虽然都是一个个Test开头的函数,但执行go test时, 还是有main入口

在LiteIDE中, 可以在 调试->开始调试测试程序里进行测试程序调试

LiteIDE篇: 在Windows上可以输出linux可执行文件

go的工具链默认支持交叉编译 
在LiteIDE中, 可以通过切换输出平台, 输出不同平台的可执行文件

Google官方为Golang的调试例子默认使用了gdb

然而, 使用gdb调试go程序会遇到goroutine的各类问题, 因为gdb不懂go

因此, 这里使用delve黑科技来进行Golang的程序调试

纯命令行调试方法在网上很容易搜索到, 本文主要以LiteIDE来进行程序调试

关闭编译器优化

正常go build/install出的go程序是完全优化过的, 强行使用调试器挂接调试时, 某些local变量/lamda表达式捕获的变量会直接进入寄存器, 无法使用调试器查看

删掉所有的pkg, 为build或install参数加入关闭编译器优化的参数 -gcflags "-N -l"

例如:

   go install -gcflags "-N -l" svc\gamesvc

delve调试器安装方法

LiteIDE自带了gdb, 但是没有delve调试器, 需要自行安装, 命令如下

go get github.com/derekparker/delve/cmd/dlv

delve调试器会被放到你的GOPATH/bin下

LiteIDE中的delve调试器配置

选择调试器

在LiteIDE菜单中选择 调试->debugger/delve

delve环境变量设置

这个时候, LiteIDE依然找不到delve, 因为它不在环境变量PATH中, 这里无需修改环境变量, 只需要LiteIDE的环境配置

在LiteIDE菜单中选择 查看->编辑当前环境, 在弹出的文档中修改

PATH=c:\mingw32\bin;%GOROOT%\bin;%PATH%;c:\your\path\to\delve

去掉PATH前的注释#, 在%PATH%添加分号, 然后和你到delve调试器的路径

开始调试

选择你的工程, 点击F5, 进入调试模式

调试器显示变量值

LiteIDE使用delve调试时, 无法在 变量 监视等窗口中正确捕捉delve调试返回数据(因为格式太复杂了…)

没关系, 我们使用命令行配合显示即可

LiteIDE控制台或调试输出窗口在delve调试时, 实际上是一个标准命令行 
命令如下

• p 变量名可以查看变量值

• locals查看局部变量

• ls可查看当前文件

• stack查看栈

• help可以查看各种帮助

调试外部程序

如果你的程序是外部程序, 或者使用go install安装到GOPATH/bin目录的程序, 那么使用delve调试器启动程序时, 可能会碰到启动路径错误的问题

使用LiteIDE菜单 调试->调试其他应用程序… 填入你要调试程序的路径以及工作目录, 可以解决这个问题

我们对Golang的结构体变量赋值, 以及单参数函数调用进行反射和native操作的测试

 
package main
 
import (
    "reflect"
    "testing"
)
 
type data struct {
    Hp int
}
 
const AssignTimes = 100000000
 
func TestNativeAssign(t *testing.T) {
 
    v := data{Hp: 2}
 
    for i := 0; i < AssignTimes; i++ {
        v.Hp = 3
    }
 
}
 
func TestReflectAssign(t *testing.T) {
 
    v := data{Hp: 2}
 
    vv := reflect.ValueOf(&v).Elem()
 
    f := vv.FieldByName("Hp")
 
    for i := 0; i < AssignTimes; i++ {
 
        f.SetInt(3)
    }
 
}
 
func TestReflectFindFieldAndAssign(t *testing.T) {
 
    v := data{Hp: 2}
 
    vv := reflect.ValueOf(&v).Elem()
 
    for i := 0; i < AssignTimes; i++ {
 
        vv.FieldByName("Hp").SetInt(3)
    }
 
}
 
func foo(v int) {
 
}
 
const CallTimes = 100000000
 
func TestNativeCall(t *testing.T) {
    for i := 0; i < CallTimes; i++ {
 
        foo(i)
    }
}
 
func TestReflectCall(t *testing.T) {
 
    v := reflect.ValueOf(foo)
 
    for i := 0; i < CallTimes; i++ {
 
        v.Call([]reflect.Value{reflect.ValueOf(2)})
    }
}

性能测试数据

=== RUN TestNativeAssign
— PASS: TestNativeAssign (0.03s)
=== RUN TestReflectAssign
— PASS: TestReflectAssign (0.41s)
=== RUN TestReflectFindFieldAndAssign
— PASS: TestReflectFindFieldAndAssign (9.86s)
=== RUN TestNativeCall
— PASS: TestNativeCall (0.03s)
=== RUN TestReflectCall
— PASS: TestReflectCall (21.46s)

测试评测

• 在结构体变量赋值测试用例中, 我们发现TestReflectFindFieldAndAssign赋值格外的耗时. 分析性能点在FieldByName这个函数上, 我们查了下底层如何实现的:

// FieldByName returns the struct field with the given name
// and a boolean to indicate if the field was found.
func (t *structType) FieldByName(name string) (f StructField, present bool) {
    // Quick check for top-level name, or struct without anonymous fields.
    hasAnon := false
    if name != "" {
        for i := range t.fields {
            tf := &t.fields[i]
            if tf.name == nil {
                hasAnon = true
                continue
            }
            if *tf.name == name {
                return t.Field(i), true
            }
        }
    }
    if !hasAnon {
        return
    }
    return t.FieldByNameFunc(func(s string) bool { return s == name })
}

各位看官必须吐槽用for来遍历获取数据, 但冷静下来分析. 这样做无可厚非.
试想如果reflect包在我们使用ValueOf时使用map缓冲好一个结构体所有字段的访问数据后, 肯定访问指定字段速度会很快
但是, 以空间换速度的需求其实最多满足了1%的需求.
同样的例子是图形API里访问Shader变量的方法, 总是默认使用字符串获取, 速度很慢. 当你想快速访问时, 请提前按需缓存字段
那么, Golang使用的也是这样的思路. 虽然暴力了一点, 但是能够让程序跑对, 性能优化的东西放在之后来做, 缓冲下就可以解决

• 在调用测试用例中, 毫无悬念的, 调用速度很慢
  因此, 我们在平时使用反射时, 尽量偏向于反射变量缓冲存在下的变量赋值或者获取
  而调用的需求尽量减少, 如果有goroutine存在的情况下, 则不必太多担心.

下面介绍下proto3的一些细节变化

Proto3的语法变化

语法标记

这个版本的protoc的protobuf编译器已经可以支持proto2语法和proto3的语法

如果你的proto文件没有添加syntax说明的话, 用这个版本的编译器会报错, 提示你默认proto2支持, 请添加语法标记

syntax = "proto2";

optional不需要了

只保留repeated标记数组类型, optional和required都被去掉了

实际使用证明, required的设计确实是蛋疼, C++的调试版会弹出assert,release版和optional也没啥区别

map支持

map编写格式为

map<key_type, value_type> map_field = N;

例如:

map<string, Project> projects = 3;

代码生成确认支持map, 这对于很多语言来说又可以偷懒了

字段default标记不能使用了

位于proto2语法的字段number后的[default=XX]

这个东西不能用了, 理由是:

对于同一段序列化后的数据, 如果序列化端的default和反序列化端的default描述不一样会导致最终结果完全不一致

即: 同一个数据两个结果, 这是不可预测的结果, 因此干掉这个特性

不过本人觉得, 对于游戏来说, 这个功能本身可以压缩很多数据,虽然会有隐患

枚举默认值一定是0

proto2里的默认值是枚举的第一个value对应的值, 不一定为0

proto3在你定义value时, 强制要求第一个值必须为0

这个修改为避免隐患还是有帮助的

泛型描述支持

any类型, 可以代表任何类型, 可以先读进来, 再进行解析, 没具体用, 步子跨大了怕扯到蛋

支持json序列化

这个极好, json再次被同化了

增加了多种语言支持

js, objc, ruby, C#等等

然而, C#版本的基础runtime库是用C# 6.0的语法写的,这对于Unity mono祖传2.0来说, 确实扯到蛋了,没法用

Protobuf现在使用CMAKE做配置系统

编译起来稍微麻烦, 还要下个被墙掉的cmake…

第三方库里对于proto3的变化

Golang的官方protobuf支持: https://github.com/golang/protobuf

生成代码中的结构体字段类型变化

对于proto2的文件, 生成的go代码中的结构体依然使用类型指针作为默认存储, 兼容老的系统

对于proto3的文件, 生成的go代码中的结构体直接使用字段作为默认存储, 不再使用GetXXX来作为字段值访问, 赋值时也无需使用proto.类型() 函数进行指针类型字段值创建.

这个调整很是方便, 但丢失了optional判断功能, 对应C++里就是hasXXX的功能, 不过好歹这个逻辑现在用的不多了

这个修改大概也是配合json序列化来做的, go默认的json序列化时, 无法使用proto2生成的结构体的, 因为都是指针,无法赋值..

新版protoc-gen-go的插件会生成descriptor的压缩数据

新插件会给每次生成的文件添加这样一段代码

var fileDescriptor0 = []byte{
    // 220 bytes of a gzipped FileDescriptorProto
    0x1f, 0x8b, 0x08, 0x00, 0x00, 0x09, 0x6e, 0x88, 0x02, 0xff, 0x64, 0x8f, 0xcd, 0x4e, 0xc5, 0x20,
    0x10, 0x85, 0x53, 0xbd, 0x35, 0x32, 0xb7, 0xdd, 0x4c, 0x5c, 0xb0, 0x70, 0x71, 0xd3, 0xb8, 0x70,
    0x75, 0x17, 0xfa, 0x04, 0xc6, 0xd8, 0xb8, 0x50, 0x63, 0xa8, 0x2f, 0x80, 0xed, 0x44, 0x89, 0x28,
    0x04, 0xc6, 0xbf, 0x47, 0xf1, 0x6d, 0x95, 0x49, 0x8d, 0x4d, 0x5c, 0x01, 0xdf, 0x39, 0x7c, 0x30,
    0x00, 0x1c, 0x82, 0xdf, 0xc6, 0x14, 0x38, 0xe0, 0xaa, 0xec, 0xbb, 0x37, 0x68, 0x2e, 0x3e, 0x62,
    0x48, 0x7c, 0x49, 0x76, 0xa2, 0x84, 0x47, 0xd0, 0xde, 0x96, 0xf8, 0xee, 0x33, 0xd2, 0x8d, 0x7d,
    0x26, 0x5d, 0x6d, 0xaa, 0x63, 0x65, 0xda, 0xb8, 0x84, 0xd8, 0x41, 0x63, 0xc2, 0x7b, 0xef, 0xc8,
    0x4f, 0x52, 0xda, 0x91, 0x52, 0x93, 0x16, 0x0c, 0x0f, 0x41, 0x89, 0xa9, 0x77, 0x9e, 0xf4, 0xae,
    0x14, 0x54, 0xfc, 0x05, 0xdd, 0x57, 0x05, 0x4a, 0xba, 0xd7, 0xc4, 0x16, 0xb7, 0x80, 0x03, 0x27,
    0xf7, 0xf2, 0x70, 0x72, 0xe5, 0x32, 0x0f, 0xd1, 0x3b, 0xa6, 0x34, 0x5b, 0x31, 0xff, 0x4b, 0x70,
    0x03, 0x6b, 0x43, 0x91, 0x2c, 0x9f, 0x3f, 0xd2, 0xf8, 0x24, 0xf6, 0x7d, 0xb3, 0x4e, 0x7f, 0x08,
    0x0f, 0xa0, 0x3e, 0xf3, 0xce, 0x66, 0xbd, 0x12, 0x49, 0x6d, 0xcb, 0xa1, 0x4c, 0x37, 0xbf, 0xf3,
    0xb3, 0xbc, 0x8e, 0xac, 0x6b, 0xb9, 0xd9, 0xe6, 0x25, 0xbc, 0xdf, 0x93, 0x6f, 0x9e, 0x7e, 0x07,
    0x00, 0x00, 0xff, 0xff, 0x0c, 0x9f, 0x10, 0xa8, 0x2e, 0x01, 0x00, 0x00,
}

对于meta信息的提取还是很方便的

然而

对于多个文件的生成, 这样做非常的麻烦, 因为这个字段会重复导致编译错误

很多人在论坛里吐槽, 官方给出的解决方法是, 使用protoc一次性传入一个package下的所有的proto直接生成一个go

而不是现在的一个proto一个go

生成代码会自动注册到全局, 并可以方便的查询

以前这个代码需要自己来做, 现在官方提供了支持, 很是方便

然而, 为什么不支持遍历… 残念啊, 又要自己动手了

https://github.com/davyxu/tabtoy

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编写较为简单，但总体看来难度不低

第三方网络库及框架数量：较多

以下是得分

从发文时的项目对这些语言使用率来说，Java，Erlang，C++编写的服务器较多，Golang，JavaScript，C#是第二梯队，Skynet由于上手不是很容易，所以仅有两位数的团队在使用，但总体表现还是比较出色的

对于老团队， C++的服务器工具链和框架已经相对成熟， 完全没必要更换新语言， 只是在对接sdk感觉困难时，可以尝试Golang这些对web有优势的语言进行混合语言开发

对于新团队，开发效率，上手度和部署效率是优先选择的，C#，Golang，JavaScript这些新兴语言会让你事半功倍

对于大规模无需选服的服务器， Skynet的actor模型对扩展会比较容易

对于大公司，好项目，上线后需要通过热更新进行bug修补的，C#，C++，Erlang会是首选

但总的一点， 还是根据团队熟悉度来选择语言，贸然的使用新语言的风险也是很大的

func server() {

    pipe := cellnet.NewEventPipe()

    evq := socket.NewAcceptor(pipe).Start("127.0.0.1:7234")

    socket.RegisterSessionMessage(evq, coredef.TestEchoACK{}, func(content interface{}, ses cellnet.Session) {

        msg := content.(*coredef.TestEchoACK)

        log.Println("server recv:", msg.String())

        ses.Send(&coredef.TestEchoACK{

            Content: proto.String(msg.String()),

        })

    })

    pipe.Start()

}

func client() {

    pipe := cellnet.NewEventPipe()

    evq := socket.NewConnector(pipe).Start("127.0.0.1:7234")

    socket.RegisterSessionMessage(evq, coredef.TestEchoACK{}, func(content interface{}, ses cellnet.Session) {

        msg := content.(*coredef.TestEchoACK)

        log.Println("client recv:", msg.String())

    })

    socket.RegisterSessionMessage(evq, coredef.SessionConnected{}, func(content interface{}, ses cellnet.Session) {

        ses.Send(&coredef.TestEchoACK{

            Content: proto.String("hello"),

        })

    })

    pipe.Start()

}

项目地址: https://github.com/davyxu/cellnet

            Action[] a = new Action[3];

            for (int i = 0; i < 3; i++)

            {

                a[i] = ( ) => { Console.WriteLine(i); };

            }

            for (int i = 0; i < 3; i++){

                a[i]();

            }

C#打印结果为3 3 3

Golang的例子

    a := make([]func(), 3 )

    for i := 0; i < 3; i++ {

        a[i]= func( ){

            fmt.Println(i)

        }    

    }

    for _, s := range a {

        s()

    }

Golang打印结果为3 3 3

最后是Lua的例子

a = {}

for i = 1, 3 do

    table.insert( a, function()

        print(i)

    end

    )

end

for _, v in ipairs(a) do

    v()

end

Lua打印结果为1 2 3

差异在于, C#和Golang将变量捕获到闭包内时, 均使用引用方式, 即当最后开始调用使用变量时, 由于变量已经结束循环, 所以是最终值

但是Lua捕获方式是值捕获, 因此比较容易理解, 是多少就是多少

在我们的游戏项目中使用的golang服务器开发方式如下

1.多线程逻辑

2.同步阻塞. 也就是说, 每个人一个线程(goroutine), io线程=逻辑线程

这种方式的优点:

1. 同步阻塞方式与人的思维方式类同

2. 逻辑处理性能有一定提升

在大规模使用这种模式编写逻辑后, 我们发现了这种模式只有1个缺点: 编写者需要处理多线程关系

但这本身确实直接致命的, 回想C++时代, 多线程处理时, 调试重现的困难… 脑补景象太惨不敢直视

单线程+异步多进程模型

在C++时代, 我曾经编写过一套asio的C++服务器框架. 采用io多线程, 逻辑单线程, 依赖着C++高性能的优势, 让开发便捷简单且无需关心线程问题.

那么到了golang时代, 为什么不能试下单线程异步多进程方式来编写逻辑?

与多线程同步阻塞对比后, 我们发现, 两者优缺点互补. 那这就回到了领域选型问题了. 对于游戏服务器需要的上手简单, 开发便捷, 压力降低(非MMO)这些特点来说, 单线程异步多进程再合适不过了

那么, 我们在用golang编写单线程异步多进程服务器应该注意哪些点呢?

1. socket处理完全封装, 只通过channel抛出到逻辑线程排队处理

2. 数据库, rpc及其他io处理, 一律改为异步回调模式, 不使用同步接口

3. 玩家存盘提交数据可以考虑复制并提交到存盘线程方式, 提高性能.

4. 采用多进程架构, 比如设网关进程, 把io压力分散到进程中

5. 逻辑编写中, 不允许使用go开线程及channel, 有需要提高性能部分需要单独编写

Actor模型的痛

cellnet在开发时本来考虑使用actor模型来进一步简化多线程逻辑的麻烦, 经历了一段时间的原型开发后, 发现了一些问题, 列举如下:

1. golang的强类型不适合actor模型这种经常需要动态生成各类消息的模型, 但skynet(C+lua)/erlang就有天生优势

2. actor模型本身不是万能的, 不能解决所有需求, 特别是游戏

3. actor模型理解到应用有一定的难度. 本身还需要搭建框架, 上手复杂

总之, 看过一些erlang及skynet的用例, 没有应用的很纯正且成熟的成功actor模型案例, 从传统socket服务器框架跨越到actor模型会扯到蛋, 因此, 后期cellnet会考虑回归到成熟的socket服务器框架. 把架构做到简单上手, 高扩展上.

概述

游戏客户端采用Cocos2dx-Lua的纯Lua编写逻辑, 服务器采用Golang作为开发语言

游戏类型类似于COC,因此无需选服. 需要使用大服务器架构进行处理

数据库

采用Mongodb做持久存储, redis做跨服通信数据交换

使用UCloud的云技术, 省去了烦人的运维工作

通信及协议

客户端和服务器通讯使用HTTP短连接, 基于json的数据封包协议

服务器间大量使用Golang自带的json+rpc进行通信

服务器类型

服务器类型大致分为逻辑服务器,战斗服务器, 中心服务器

逻辑服务器

逻辑服务器负责日常逻辑及公共逻辑处理(好友, 公会)

1个逻辑服务器对应一个区, n个区均使用Ucloud云Mongodb进行数据存储

战斗服务器

战斗服务器是一个集群, 集群会返回一个负载最低的服务器返回使用

战斗服务器通过cgo技术与客户端C++/lua的战斗逻辑进行逻辑复用, 在此技术上进行

战斗逻辑的校验

中心服务器

客户端登陆前, 在中心服务器这里获得可登陆的逻辑服务器地址, 同时做一个负载均衡

短连接

评价

由于操作系统的技术趋于稳定, 同时, 手游的弱交互型导致的游戏架构趋于简单. 因此网络负载不再是游戏服务器技术的瓶颈. 从经验看来, 游戏服务器技术, 更重要的是还是看数据库的选型及处理方式. 

虽然Mongodb的性能上不如内存数据库. 但是从存储安全性上要比个人搭建的内存数据库简单, 安全

外加上云技术的引用, 性能的瓶颈和运维的技术复杂度迎刃而解

Redis用于跨服数据交互那是再好不过的数据中介了, 保证速度和稳定性, 绝对不是造轮子能比拟的

短连接在手游上处理起来比长连接简单一些, 无需做断线重连. 服务器的底层也是由Golang的框架库保证质量的. 因此负载毫无问题. 服务器对内及对外均使用json进行数据交换, 简化了协议处理. 也方便了调试

json rpc的性能损耗对于整个逻辑的处理来说均可以忽略不计

但作为新生代语言的特点就是实战. Golang这一年里, 已经为项目提供了稳定的服务器和强大的扩展能力, 与客户端的Unity3D里的C#一样, 都是强大, 极致开发效率代表的优秀开发语言.

用途篇

Golang到底拿来做啥? 我需要么?

高效(性能,开发)的服务器语言. 包括Web, 游戏, App

编写桌面级UI暂不是很适合

我需要把现在的C++, Python, Erlang等服务器改成Golang么?

性能有瓶颈, 开发效率低, 有钱有时间的话, 完全可以

评价篇

听过太多的人对Golang的评价, 大概分为这么几类:

C/C++性能党

此类党员对任何事物都追求极致的 性能. 还好Golang是直接生成native code, 否则会被批的体无完肤. 但是由于Golang底层为并发和开发效率而做出的一些系统, 类似于GC, 调度器和分配器等, 会在语言层上损失很多性能. 因此C/C++党还是有理由批Golang性能低下

Erlang并发党

作为电信级元老, Erlang的模型和架构当之无愧, OTP扩展性超级强. 完美的Actor模型也让逻辑编写比OO更加直观

CSP与Actor区别仅仅只是在channel的归属范围而已, 但这点细微差别却对两种语言的开发变的迥然不同

Golang在并发模型上选择了CSP, 就是考虑把架构的设计留给使用者. 像C#一样建立一个类库的世界, 而不是MFC一样的框架世界. 让开发更自由

Erlang的Actor也没错. 让开发更直观, 让崩溃提前来到, 尽快处理

Rust党

Rust在发文时已经发布了1.0. 这让R粉兴奋的穿梭于各大技术论坛和讨论群

但Rust的理念在我看来有点偏执了, 一定要把各种错误在编译期暴露出来, 所以造出了很多不需要的类型和概念, 连语言都比C语言更符号话

大白话说来, 有点编程经验的人看到JavaScript完全看得懂, 但看Rust却像天书

对比同时期的TypeScript, Dart, Swift. Rust就是有点那么独辟蹊径

该党党员经常性的用各种特性对比Golang, 追求单特性的优秀.

但其实, Golang本身是一门完整哲学. 很多语言特性互相之间有关联. 有设计不当的地方, 当然更多的是完整体系. 不求和其他语言比

只追求解决问题的速度

自定义党

云风看过Golang后, 因为该语言本身就是强化版的C, 因此颇受云风喜欢. 但在一堆评价后, 云风还是果断选择了C+lua的组合写出的Skynet

虽然不知道原因, 但我猜的话, 毕竟是对语言本身的可控性还不那么看好

同时, 我们发现Skynet使用的是Actor模型, 也发现大神级的程序员就是有先见.

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

感触篇

设计

踏入Golang, 就不要尝试设计模式

传统的OO在这里是非法的, 尝试模拟只是一种搞笑

把OO在Golang里换成复合+接口

对实现者来说, 把各种结构都复合起来, 对外暴露出一个或多个接口, 接口就好像使用者在实现模型上打出的很多洞

别怕全局函数, 包(Package)可以控制全局函数使用范围.

没必要什么都用interface对外封装, struct也是一种良好的封装方法

Golang无继承, 因此无需类派生图. 没有派生这种点对点的依赖, 因此不会在大量类关系到来时, 形成繁杂不可变化的树形结构

容器

用了很长时间map, 才发现Golang把map内建为语言特性时, 已经去掉了外置型map的api特性. 一切的访问和获取都是按照语言特性来做的, 原子化

数组可以理解为底层对象, 你平时用的都是切片, 不是数组, 切片就是指针, 指向数组. 切片是轻量的, 即便值拷贝也是低损耗的

内存

Golang在实际运行中, 你会发现内存可能会疯涨. 但跑上一段时间后, 就保持稳定. 这和Golang的内存分配, 垃圾回收有一定的关系

现代的编程语言的内存管理不会很粗暴的直接从OS那边分配很多内存. 而是按需的不断分配成块的内存.

对于非海量级应用, Golang本身的内存模型完全可以撑得下来. 无需像C++一样, 每个工程必做内存池和线程池

Channel

Channel和锁谁轻量? 一句话告诉你: Channel本身用锁实现的. 因此在迫不得已时, 还是尽量减少使用Channel, 但Channel属于语言层支持, 适度使用, 可以改善代码可读写

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

错误

觉得Golang不停的处理err? 那是因为平时在其他语言根本没处理过错误, 要不然就是根部一次性try过所有的异常, 这是一种危险的行为

panic可以被捕获, 因此编写服务器时, 可以做到不挂

危险的interface{}

这东西就跟C/C++里的void*一样的危险, nil被interface{}包裹后不会等于nil相等, 但print出来确实是nil

模板估计可以解决容器内带interface{}的问题. 但新东西引入, 估计又会让现在的哲学一些凌乱

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

初学Tips

语言学习按照官网的教学走, 跑完基本就会了

下载一个LiteIDE, 配合Golang的Runtime,基本开环境就有了

Golang的类库设计方式和C#/C++都不同, 如果有Python经验的会感觉毫无违和感

有一万个理由造轮子都请住手, 类库里有你要的东西

写大工程请搜索: Golang项目目录结构组织

Golang语言本身本人没有发现bug, 即便有也早就被大神们捉住了. 唯一的一个感觉貌似bug的, 经常是结构体成员首字母小写, 但是json又无法序列化出来…

慎用cgo. 官方已经声明未来对cgo不提供完整兼容性. 任何一门语言在早期都需要对C做出支持, 但后期完善后的不兼容都是常态

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

// String returns the time formatted using the format string
//  "2006-01-02 15:04:05.999999999 -0700 MST"
func (t Time) String() string {
    return t.Format("2006-01-02 15:04:05.999999999 -0700 MST")
}

尝试将2006-01-02 15:04:05写入到自己的例子中

func nowTime() string {
    return time.Now().Format("2006-01-02 15:04:05")
}

结果返回正确. 询问了下, 据说这个日期是golang诞生的日子… 咋那么自恋呢…