skynet热更新-clearcache的使用体会

skynet热更新-clearcache的使用体会

skynet 热更新主要有2种方法

• 第一种：使用clearcache
• 第二种：使用console inject lua脚本

动态创建的服务的热更新

• 如果一个skynet服务是在业务流程中动态创建的，那么在修改代码后，使用clearcache就可以保证下次再创建的新的服务是使用的新的代码。

创建后长期不销毁重建的服务，如何热更新？

• 如果是在进程启动时创建，或创建后就一直存在的服务需要热更新怎么办呢？

  • 方法1: 对于这种情况目前inject是首选。但是有时候需要修改的代码量比较大，inject 脚本的方式就非常复杂且容易出错。
  • 方法2: 当然，还有一种方式就是采用轮服的机制解决。从进程级别解决问题。但是这个代价又太大了，比clearcache的成本还高。

• 这里我们还有一个思路就是可以在业务服前加一个管理调度服务。例如A1 skynet服务需要发消息给B1 skynet服务来实现某个功能。消息流为：

A1 ---> B1

• 我们可以在B1前加一个B_manager服务，A服务通过B_manager服来传递消息给B1服务， 消息流为：

A1 ---> B_Manager ---> B1

• 这个时候如果B1的业务有大量需要修改的。只需要clearcache一下，让后创建一个新的B1服务，这里称为B2,B_Manager再讲A1的请求转发到B2即可，这个时候的消息流为:

A1 ---> B_Manager ---> B2

• 这个时候B1就不会接收到新的消息了。介意B1的存在可以销毁它，如果资源暂用不大，也可以不销毁。

• 当然这里有几个必须要注意的问题:

  • 如果B1服务是有状态的，那么这个方法是有很大限制的，需要把B1服务的数据通过消息或共享内存，缓存等方式转移到B2服务上。
  • 如果B1服务上有定时器等可能会影响业务的逻辑时时，必须要关闭定时器或销毁B2服务。
  • 如果B1是无状态的那就简单多了，创建新的服务B2后，B_mananger将所有需要转发给B1的请求全都转发给B2即可。
  • 消息中间多了一层B_Manager会不会损失性能，这个需要视业务要求来具体分析，大部分情况，这点新能损失都可以忽略不计的；当然如果你很介意的话，还是建议业务刚上线前使用中的B_Manager，业务稳定后，再在某次更新可以将这层转发层去掉。

• 上面的方法也是一种折中的方法，个人感觉还是比较好用的，但是也是不完美的。

• 关于skynet的热更新，如果你有什么更好的方案，希望能够指点一二！

• 个人的一点想法，分享给大家！如果你也在使用skynet，关注我，一起学习，交流一下！