如果你在使用golang的plugin模式进行代码热更新时会发现protobuf编译生成的xxxxx.pb.go文件中会生成2个init方法。这2个init方法会向"github.com/golang/protobuf/proto"包的全局变量进行注册,原本这种注册在常规的golang程序中是没有任何问题的,因为一个package的init方法只会调用一次。但是在使用plugin模式时,如果xxxxx.pb.go文件是在plugin插件代码中,那么每次新插件加载的时候都会调用对应包的init方法,并且因为需要热更新plugin,所以就会进行多次调用了。因为在"github.com/golang/protobuf/proto"包中多次进行注册同名的类型名会触发panic,因此起初我要解决的问题是如何可以避免这个panic? 我们先看看触发panic的代码片段:

  每次golang宿主程序加载新的插件hotswap_myplugin.so(该插件包含error.pb.go代码文件)都会调用上面的init方法中的RegisterEnum进行枚举类型的注册触发panic。为了解决这个问题我想到2个思路:

  1. 每次新的插件变更error.pb.go中的变量的命名

  2. 去除init方法中的注册代码

  根据实际应用场景的分析,第一种方法不太适用,因为每次都变更error.pb.go的命名的话意味着插件中的其他代码引用error.pb.go中的类型或者变量的代码都需要全部修改,这对于需要经常热更的代码场景来说显得比较麻烦,一个原因是类似error.pb.go的文件会非常多,每次所有的proto文件都需要修改,另一个原因是所有引用代码也需要全盘修改。这个方式显得非常鸡肋,因为大多数时候如果我只想修改一行代码去修复某个bug,却要花费大量的时间代价去重命名proto定义文件去避免重名注册panic。

  那么如此只好使用第二种方式了,第二种方式是希望能够不要执行init方法中的注册方法那么就不会触发重复注册panic了。好家伙,这意思是要从源头解决问题了,no code no bug(panic) !!!!  大多数人看到这里应该都会质疑error.pb.go是由protobuf编译工具protoc自动生成的代码,那么如果去除其中的代码是否会引起其他问题呢?  分析了一波"github.com/golang/protobuf/proto"包的源代码发现这个只是proto这个包想为外部提供一个全局的枚举类型的获取接口返回enumValueMaps = make(map[string]map[string]int32)数据,那么我么的应用场景中并没有使用这个全局的枚举类型数据,因为到这里我们就可以大胆的去除这部分代码了。

  当方法确定了剩下的就是执行了,不用多想执行的过程中必定会产生新的问题!   类似error.pb.go的文件有很多,而且可能还会逐渐增加,因此手动修改代码变得很不现实!那只能考虑用脚本或者程序进行修改了,起初的想法是通过正则表达式匹配到func init() {} 代码段,然后进行文本替换。说干就干,然而写一个匹配一个代码段的正则表达式我想正则表达式水平一般的人应该已经开始望而却步或者已经开始疯狂使用google尝试搜索答案了。我选择去请教我一个正则表达式学的不错的同学,有意思的是他给我提供了另外一个思路。 把init方面改了!!! 这想法真是惊为天人啊!!!  匹配一个代码段的正则非常难写,但是匹配init方法名然后替换方法名却变得格外轻松。然而正当我觉得难题迎刃而解并且进行了一次尝试之后发现。不用多想执行的过程中必定又产生新的问题! 每个xxxx.pb.go文件中init方法不止一个,替换后会出现方法重定义的编译问题(golang允许重定义多个init方法)。

  100米赛跑跑出去50米告诉我抢跑了要重新开始。又回到最开始的方法了,正则表达式匹配代码段,然后进行文本替换。经过千辛万苦(这里省略了大约16000字吧)终于google出一个匹配javascript代码段的正则表达式,只要稍加改造就可以匹配golang代码了。正则表达式:/func init() \s*([A-z0-9]+)?\s*\((?:[^)(]+|\((?:[^)(]+|\([^)(]*\))*\))*\)\s*\{(?:[^}{]+|\{(?:[^}{]+|\{[^}{]*\})*\})*\}/g

  利用这个正则表达式我们写一个python脚本来对所有xxxx.pb.pb扫描并且进修修改,示例代码:

到这里便大功告成了,将pb.go文件嵌入插件hotswap_myplugin.so中,可以随时方便热增减proto协议了。

  

发表评论

电子邮件地址不会被公开。 必填项已用*标注