lithbitren 发表于 2024-09-03 00:21
Tags：热重载
之前简单看过一些热重载动态链库的文章，简单范例代码很多，但都不深入。
这次正好刷到一个热重载的视频：rust热重载插件
里面提到了不同文件夹定义或引入的相同的结构体，但在类型识别上typeid是不一致的（其实很符合逻辑），然后up主一顿操作就可以一致了，可是看起来还是有点trick，有没有更好的方法，还是说这个问题本身是个伪需求？
程序热重载还有什么需要注意的点？
其实还有用wasm进行热重载的，看到一个wasmedge的项目，不过文档没太看懂，不知道如何让wasm沙箱化，尽可能的保证内存安全。
A: dylib 动态加载，确保模块能卸载干净，比如rayon就不能完整drop
B: 基于tokio或类似形态的多线程，外部发送 SIGHUP 即可
C: 多进程，之间共享内存等等策略，性能稍差
思路打开！手动寻址确实可以解决大部分问题！不过肯定涉及很多unsafe过程，动态链库对于大多数业务项目来说，需求太小众，最佳实践遥遥无期。
-- 👇 mrwait: 这是系统特性导致的，和语言无关，解决方法和 C/C++ 一样，手动传递变量就可以了，不要依赖编译期自动寻址。
-- 👇 lithbitren: 还有动态链库的全局变量问题，rust就妹看明白怎么搞，不过这个在C/C++里也算是个坑。
这是系统特性导致的，和语言无关，解决方法和 C/C++ 一样，手动传递变量就可以了，不要依赖编译期自动寻址。
还有动态链库的全局变量问题，rust就妹看明白怎么搞，不过这个在C/C++里也算是个坑。
这种热重载的需求，很像一个 k8s 的单机版。不知道这个思路有没有帮助
qs，热重载在静态语言里本身就是挺费神的，其他某些语言很多时候也都是只重载动态脚本部分，rust里更是没啥人搞，但其实还是有需求的。
我之前想过的是服务器路由热重载，差不多就是监听指定目录的二进制文件变更然后自动更新，不过一直没有付诸实践。
但其实需要解决的问题很多：
1、原路由优雅关闭，新路由不停机无缝accept监听；
2、需要提供即时回滚功能，新路由出现bug时尽可能不停机回滚；
3、服务器虽然原则上不保存状态，但偶尔也需要用到，比如网关限流有时候就是在本地实现的，限流状态最好能够保存；
4、部分热重载涉及到很多unsafe代码，不知道是否存在内存泄漏的问题，还需要详细测试。
5、主楼提到的typeid不一致的问题也是个问题，比如重载了路由，路由句柄内部用到状态是否会和不停机的状态出现类型冲突，比如句柄里访问数据库时引用连接池，和不停机的连接池是否能够兼容。
想来想去觉得都很复杂，不如直接重启，也不过就是停机个几秒而已，对于多余绝大部分业务来说基本可以说没啥影响。
对于普通业务后端来说，其实真正需要实现不停机热重载的可能就只有反代网关，而业务后端可以通过灰度来发布和销毁，其实问题不大。
虽然rust实现的网关性能比nginx好，不过nginx太易用了，大多数业务连nginx的极限都突破不了，也没啥必要因为一些额外的性能就成rust，而且改参数重启nginx也不是特别复杂。
可能游戏服务器更有需求一些，游戏服务器一般都有状态，而且热更新更频繁。
-- 👇 gcalgoz: 想过，但是感觉很困难放弃了。用了另外一种trick的方式：systemd + 软链接 的方式，在主动退出前建立新的软链接指向新执行文件，这样方式做自动更新
想过，但是感觉很困难放弃了。用了另外一种trick的方式：systemd + 软链接 的方式，在主动退出前建立新的软链接指向新执行文件，这样方式做自动更新
评论区
写评论其实还有用wasm进行热重载的，看到一个wasmedge的项目，不过文档没太看懂，不知道如何让wasm沙箱化，尽可能的保证内存安全。
A: dylib 动态加载，确保模块能卸载干净，比如rayon就不能完整drop
B: 基于tokio或类似形态的多线程，外部发送 SIGHUP 即可
C: 多进程，之间共享内存等等策略，性能稍差
思路打开！手动寻址确实可以解决大部分问题！不过肯定涉及很多unsafe过程，动态链库对于大多数业务项目来说，需求太小众，最佳实践遥遥无期。
--
👇
mrwait: 这是系统特性导致的，和语言无关，解决方法和 C/C++ 一样，手动传递变量就可以了，不要依赖编译期自动寻址。
--
👇
lithbitren: 还有动态链库的全局变量问题，rust就妹看明白怎么搞，不过这个在C/C++里也算是个坑。
这是系统特性导致的，和语言无关，解决方法和 C/C++ 一样，手动传递变量就可以了，不要依赖编译期自动寻址。
--
👇
lithbitren: 还有动态链库的全局变量问题，rust就妹看明白怎么搞，不过这个在C/C++里也算是个坑。
还有动态链库的全局变量问题，rust就妹看明白怎么搞，不过这个在C/C++里也算是个坑。
这种热重载的需求，很像一个 k8s 的单机版。不知道这个思路有没有帮助
qs，热重载在静态语言里本身就是挺费神的，其他某些语言很多时候也都是只重载动态脚本部分，rust里更是没啥人搞，但其实还是有需求的。
我之前想过的是服务器路由热重载，差不多就是监听指定目录的二进制文件变更然后自动更新，不过一直没有付诸实践。
但其实需要解决的问题很多：
1、原路由优雅关闭，新路由不停机无缝accept监听；
2、需要提供即时回滚功能，新路由出现bug时尽可能不停机回滚；
3、服务器虽然原则上不保存状态，但偶尔也需要用到，比如网关限流有时候就是在本地实现的，限流状态最好能够保存；
4、部分热重载涉及到很多unsafe代码，不知道是否存在内存泄漏的问题，还需要详细测试。
5、主楼提到的typeid不一致的问题也是个问题，比如重载了路由，路由句柄内部用到状态是否会和不停机的状态出现类型冲突，比如句柄里访问数据库时引用连接池，和不停机的连接池是否能够兼容。
想来想去觉得都很复杂，不如直接重启，也不过就是停机个几秒而已，对于多余绝大部分业务来说基本可以说没啥影响。
对于普通业务后端来说，其实真正需要实现不停机热重载的可能就只有反代网关，而业务后端可以通过灰度来发布和销毁，其实问题不大。
虽然rust实现的网关性能比nginx好，不过nginx太易用了，大多数业务连nginx的极限都突破不了，也没啥必要因为一些额外的性能就成rust，而且改参数重启nginx也不是特别复杂。
可能游戏服务器更有需求一些，游戏服务器一般都有状态，而且热更新更频繁。
--
👇
gcalgoz: 想过，但是感觉很困难放弃了。用了另外一种trick的方式：systemd + 软链接 的方式，在主动退出前建立新的软链接指向新执行文件，这样方式做自动更新
想过，但是感觉很困难放弃了。用了另外一种trick的方式：systemd + 软链接 的方式，在主动退出前建立新的软链接指向新执行文件，这样方式做自动更新