当前位置: 首页 > 编程笔记 >

解读golang plugin热更新尝试

龚招
2023-03-14
本文向大家介绍解读golang plugin热更新尝试,包括了解读golang plugin热更新尝试的使用技巧和注意事项,需要的朋友参考一下

当我们在使用php开发的时候,基本不需要关心热更新这件事的,因为PHP本身已经帮我处理好了,只需要提交代码,PHP重新解释一遍即可。而go则是静态语言,编译后得到的是直接被机器执行的,所有代码已经翻译成相对应的机器指令并且在运行时已经加载到内存,不能动态更新。那么如果想热更新就成了件麻烦的事,但是作为后端开发人员,很渴望支持这种功能,毕竟在线上能新增功能、修复bug客户端完全无感知是多么完美的事。

本文暂不讨论http这种无状态服务更新,网上能搜索到很多文章关于如何利用fd继承实现优雅重启。这里主要讨论使用golang 1.8新增的plugin来实现业务的更新,并且业务是类似游戏的有状态服务。官方文档中对plugin的描述比较简单,他可以动态的加载so和执行导出的方法,并且仅仅提供了两个方法:打开模块和提取符号,甚至连关闭都没有(-_-)。

一个程序包含两部分:数据和算法,那么既然是有状态服务,数据部分肯定不能动,那么热更就只能动算法部分了。这时我们需要一个容器,将这两部分隔离开,一方面是存储数据,另一方面要动态加载so。隔离了数据和算法,只要数据存在,我们就可以随意更新算法了。在开始编码之前,要先解决几个问题:

1、同一个so文件只会被打开一次

2、每个so有一个pluginpath用来标识是否重复,如果两个so文件不一样,但pluginpath一样还是会报错

3、不同so文件定义的结构体不能使用类型断言进行转换

对于上面的问题,有如下解决方案:

1、每次生成的so带一个版本号比如game.1001.so

2、编译的时候新增--ldflags="-pluginpath=xxx"参数

3、使用unsafe进行转换(下面还会有注意事项)

 代码地址:https://github.com/scgywx/myplugin

1、编译engine,这就是我们上面说的容器,他负责数据存储和so的加载与执行。

sh build.sh

2、编译第1个版本so(注意后面有个参数)

sh build_so.sh 1

3、将src/logic/main.go里面的modelVersion和modelName分别改成1002和game2(这里主要是测试两个版本的内容区别)

4、编译第2个版本so

sh build_so.sh 2

5、运行容器

./engine

6、浏览器输入127.0.0.1:12345/hello,会看到如下显示(这是使用的第一个版本so)

hello test, this is golang plugin test!, version=1001, name=game1, oldversion=0, oldName=

7、浏览器输入127.0.0.1:12345/load?name=plugin2.so(这里输出done,就说明加载so成功了)

8、再次输入127.0.0.1:12345/hello,会看到如下显示。

hello test, this is golang plugin test!, version=1002, name=game2, oldversion=1001, oldName=game1
 

到这里,我们的热更新效果已经达成,但是还是有一些限制

1、每个so不能单独保存数据,因为当另一个so加载后,前面so的数据是没办法访问到,并且由于so不能被关闭,可能会出现多个so引用同一个变量,gc没办法释放,所以需要透过容器来共享数据,那么我们就不能在模块内使用全局变量来保存数据。

2、go里面两个类型即使一样,也不能直接转换,所以两个so内定义的结构体也不能直接转换,要使用unsafe.Pointer来进行强转(见src/logic/main.go),既然是强转,那么两个版本的so使用的结构体定义就不能有区别,否则转换后数据可能会出现异常,也就是说热更新不能修改结构体。

 本文只是技术尝试,没有线上验证,还有多少坑还不知道,热更新不是必须,如若支持,便是好事。。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。

 类似资料:
  • 由于 imi 基于 Swoole 常驻内存,所以 PHP 的一大特点热更新就没有了。 为此,imi 中实现了业务代码的热更新,方便开发调试、动态部署,支持平滑重载。 有了热更新,开发时只需要保存代码,短短几秒甚至一瞬间,刷新页面,就可以立即看到效果! 配置 imi 默认开启了热更新,如果需要关闭或者个性化设置请看下文: 热更新通过配置文件中的beans节配置。 详见下面的注释: 'hotUpdat

  • “热更新”不不是简单地在您编辑文件时重新加载页面。开启着热更新,当你编辑一个*.vue 文件,这个组件所有的实例会在不刷新界面的情况下更新。 它甚至保留应用程序和这些组件相对应的当前状态!当你调整组件的模板或样式时,这大大提高了开发的体验。 当使用vue-cli构建项目时,热更新即可启用。

  • ConfigMap是用来存储配置文件的kubernetes资源对象,所有的配置内容都存储在etcd中,下文主要是探究 ConfigMap 的创建和更新流程,以及对 ConfigMap 更新后容器内挂载的内容是否同步更新的测试。 测试示例 假设我们在 default namespace 下有一个名为 nginx-config 的 ConfigMap,可以使用 kubectl命令来获取: $ kube

  • 应用更新部署无需reload或者restarthi-nginx。hi-nginx-java能根据全局配置 route { lrucache { reflect { expires = 300 size = 1024 } } } 自动实现热更新。关键值由"route.lrucache.reflect.e

  • 这篇文档将全面覆盖热更新管理器 AssetsManager 的设计思路,技术细节以及使用方式。由于热更新机制的需求对于开发者来说可能各不相同,在维护过程中开发者也提出了各个层面的各种问题,说明开发者需要充分了解热更新机制的细节才能够定制出符合自己需要的工作流。所以这篇文档比较长,也尽力循序渐进得介绍热更新机制,但是并不会介绍过多使用层面的代码,对于想要先了解具体如何使用热更新机制来更新自己游戏的开

  • 前言 之所以这篇文档的标题为教程,是因为目前 Cocos Creator 资源热更新的工作流还没有彻底集成到编辑器中,不过引擎本身对于热更新的支持是完备的,所以借助一些外围脚本和一些额外的工作就可以达成。 本篇文档的范例工程可以从 GitHub 仓库 获取。 使用场景和设计思路 资源热更新的使用场景相信游戏开发者都非常熟悉,对于已发布的游戏,在游戏内通过从服务器动态下载新的游戏内容,来时刻保持玩家