分布式系统的兼容性

以前一直做单机系统，考虑到的兼容性往往是存储在硬盘的数据结构要考虑兼容性的。但是目前在进行分布式存储系统的设计时，遇到消息体的兼容性。

因为分布式系统中，升级过程不能和单机系统一样，停业务，升级，开业务(reboot)。在分布式系统中的，是不能随便将所有系统全部停掉进行升级。采用的策略一般是逐步升级，那么就会出现新旧系统。这不光要考虑存储持久化的兼容性，而且也要考虑消息体的兼容性。新旧系统可以相互兼容彼此的消息体。

所以在修改系统中存在的消息体是，就必须要考虑兼容性：老系统用老代码如何处理新系统的消息体；反之，新系统如何处老系统的消息体。

根据ceph代码中的兼容性发现有这几种实现策略

• 消息体的设计

消息头包含两个字段：version和compact_version。version表示当前消息版本，如果修改消息体，该值应该加1；compact_version表示可以兼容的最低版本号；如果peer收到消息后，发现自己当前版本< compact_version，那么就属于不兼容的系统，就无法进行解析。

新系统比较好处理老消息体，但是老系统在不改代码情况下，就很难处理新消息体。

• 增加新字段

对于新加字段的是最经常，如果在不修改老系统代码的情况下，只能将新字段加在消息体的最后面。老系统放弃这部分信息，作为无用数据。

• 修改中间数据结构

这种情况，在消息体中间进行修改，那么老系统安装原来的方式就会解析出错误的消息。对于这种情况，往往采用对老系统发送老消息体结构，新系统发送新消息体。这样就会带来一个问题，如何获取peer的信息。

  a：简单是用version版本，但是在同一个version版本可能修改了很多的消息体，很难控制

  b：使用feature来表示，如果出现这种情况下，新增一个feature根据这个feature就很容易判断peer是否支持这个功能

• 设计新的消息体

随着发展会发现老的消息体太out了，需要重构，这样的话使用前面两种方法就不合适了。那么就会设计新的消息体和老消息共存。但是这样也是会判断peer的feature来判断发送新旧消息。

现在才发现设计消息结构是多么复杂的事情，不然以后就是无尽的麻烦。

如果在后续中发现有其他分布式系统消息的其他兼容方式也会及时更新。