探索一种C++二进制模块的热更新机制

    现如今，提供稳定可靠且能满足人民群众日益增长的物质文化需要的服务是互联网服务商的基本责任，所以服务端软件一定要够壮够强够灵活。服务程序一旦跑起来那就最好7X24小时地永远别挂，而且多变的、不停增长的用户需求也得尽快满足。可问题是，永远也别指望程序员写出没有bug的程序，任何架构师也没有水晶球可以预测将来的花花世界，无论
当时看起来多么完美的代码，将来也会因为种种原因要被修改(或者被丢弃？)。既然如此，那么我们或许应该想办法给程序加上点进化能力，让它能永不停歇地任劳任怨地工作，而同时还不断地反省自己、纠正自己并茁壮成长。

    本文是写给C++程序员的，如果你的工具是Lisp、Erlang、Ruby这样的动态语言，那么因为它们牛B的高级动态特性，你压根就用不着象我们这样，在二进制层干刀口舔血的勾当。

    简单来说，热更新就是程序边运行边更新。有人一定觉得我在故意(象专家那样)装B，把简单的问题搞得异常复杂，因为动态链接库本身就是可以动态加载和卸载的，只要在新的动态库build和部署好后通知程序重新加载一下不就搞定了？

    在这里，我要语重心长地告诉你们：第一，我没有装B，因为不想遭雷劈；第二，这种简单的方案在少数情况下是行得通的，但在大多数情况下却不行，因为实际的程序是代码与数据结构的正确结合，代码几乎总是要操作相应的数据结构。举个例子，A库的create函数创建了数据对象data，foo函数能正确地操作data，然后我们用B库热更新了A库，这样现在的create和foo函数都是B库实现的，而且新的create产生的数据对象与data(二进制布局)格式不同，新的foo也只能正确地操作新的数据对象；假设此后应用程序又需要用(B库的)foo操作由A库创建的data(我们无法避免，因为数据的生存周期是和应用逻辑息息相关的)，这个时候严重的错误是不是就极可能发生？所以一个模块被热替换掉后，由它创建的所有数据对象也要跟着进行格式转换，转换为与新版本兼容的(二进制布局)格式。可是这又带来了新问题：如何才能找到所有由旧模块创建的数据对象？我们就象蹩脚数学家一样，把一个肮脏的问题转化成了另外一个肮脏的问题。

    换一种思路，如果在编程时愿意遵循一定的规范(规范是一种约束，但合理的约束却常常能提高总体的自由)，而这规范使我们能避开找到所有旧版本数据对象这样的棘手问题，那么就能实现安全的热更新。

    本文建议的规范是采用类似COM、XPCOM这样的组件对象模型：程序由一个个的组件对象组成，每种对象提供了若干功能，外部只能通过对象的接口来使用相应功能。接口通常都用C++抽象基类来构建，从ABI(Application Binary Interface)的角度来看，C++抽象基类最关键的是规定了子类的虚函数表的布局。也可以用其它方法来构建接口机制，但是要保证与C++的虚函数表模型(g++, vc++等主流编译器在这方面的实现都是一样的)在ABI层上兼容。模块是物理上的对象容器，可以包含一个或多个组件对象。模块最常见的形式就是动态链接库(so或dll)，本文探索的动态更新机制便是以模块为最小单位。

    从ABI层来看，通过组件对象接口来调用相关功能实际就是调用该对象虚表中对应项所指向的虚函数实现，正因为调用虚函数需要一个查表才能找到真正函数地址的中间操作，所以才使得我们能够hook住组件对象的调用，从而有机会把老版本的对象转换为新版本。那么如何才能