关于简单、正确的热更新

[JackLeeDev]

热更新其实没那么复杂，很多童鞋看了skynet的热更新示例代码，思维已经固化，把问题想复杂了，其实可以跳出skynet的热更思路，仔细分析下需求，那么热更就很简单了。
一、热更新无非就是解决小版本迭代过程中配置表和代码以及数据结构的更新，至于大版本更新直接停服就好。
二、配置热更新，对比配置文件md5或时间戳，只更新有变化的就好。
三、代码热更新
1、大部分代码热更新不应该写任何辅助热更新代码，比如修复upvalue等，仅当数据结构有变化写点兼容或者数据转换代码。
2、代码热更新没办法做到100%正确更新，能覆盖99%的情况即可。如果剩下的1%遇到了，如果响很大，可以考虑停服更新，实际一个项目周期可能不会遇到一次。
3、擎框架、基础库、c代码一般都是比较稳定，小版本迭代几乎无热更需求，万一有(概率极低)停服更新就好，所以我们只需要关注业务层代码。
4、业务代码可以考虑大量采用class的形式，业务层的service为一个class object，service中的某些数据对象也可以为class object，比如agent中的玩家，battle中的scene、object等。这样热更新我们只需要替换这些class object的原表即可。
5、业务层采用大量的class，upvalue用的相对就比较少了，如果有，一般是某个消息处理代码使用了rpc，在消息处理中间执行了热更新。一般出现这种情况的概率极低，万一出现了，我们需要评估下影响是否停服(概率几乎为0)，如果只是简单的报错或者返回客户端的数据是热更新之前的数据，那么其实可以不用处理(比如玩家查看排行榜数据，顶多是命中的玩家本次查看排行榜提示错误或者依然返回热更之前的错误数据格式)。
6、codecache其实可以不用clear，根据单个文件的文件名+md5作为key来加载，可以减少热更新时间也可以节省一些内存。
7、一个service跑多个玩家agent，减少热更新压力，如果一个service跑一个agent，那么本方案可能存在一定的性能压力，这个没有详细测试，可自行测试下。
四、目前这套方案多个项目跑了六七年了，几乎没有遇到热更不正确的情况，很少遇到需要写何辅助热更新代码的情况。