吐槽升级－rpm方式升级的一些经历

升级在很多人眼里非常的普通。智能移动的时代，升级几乎是天天都发生。app的升级、手机系统版本的升级，实时升级或者静默升级（就是你睡觉的半夜偷偷给你升）。访问一个网站暂停服务，提示在升级中（最牛逼的属12306吧，每天凌晨都不能用）。鄙人工作内容跟产品升级有关，因此也关注了不少升级相关内容。在此跟大伙吐槽一下，当然更希望能抛砖引玉，吸引有经验同行讨论，共同进步。

1、rpm管理

升级是个很宽的概念，软件有个bug，直接修改代码、配置修复bug也叫升级。规范的升级方式应该走发布流程，像微软会在官网发布补丁，说明修复了啥啥问题。Linux系统的升级一般都以包的粒度来进行。Linux包管理主要有rpm和dpk两种，主流商业发行版都用的是rpm包管理机制。这是个缩写，全称能看出是RedHat设计出来的。比rpm更高级的封装就是zypper或yum，可以一键升级系统所有可更新的软件。但是这两个方式无法适配我们产品的升级，我们只用了rpm，所以吐槽点也只有rpm。

rpm其实吐槽真不多，bug不多，功能也刚刚够用。我们开发功能也都只深入到用的层面，不会去动rpm本身的代码。用来用去觉着rpm有两大弱点，一个是数据库管理，一个是配置的保护。配置保护在第二个主题再吐槽。

rpm数据库不算是真正的数据库，就是用一个简单的方式实现了包数据的管理，对数据一致性保护方面做的不够，不支持rpm的并发执行，也会在特殊条件下容易rpm数据库内容不一致，数据库损坏。下面举一些例子

不支持并发

rpm的build都是按spec文件里的设置进行的，spec文件规范不赘述。最初遇到过一个情况，一个同事写了一个空壳rpm spec，在%post里下载开源的rpm包，接着使用rpm命令去安装。结果整个升级就卡在升级这个空壳rpm包，查了文档后确认了不能这么玩。

rpm数据库不一致

在linux系统里查有没有安装一个包用rpm命令，用法如rpm -q linux-aaa。这种用法要求你记住rpm包的名字。很多时候我们更习惯用rpm -qa | grep linux-aaa，qa参数列出了所有的rpm包，然后根据一些关键字过滤出自己要的结果。这两个查询命令底层读取的文件不是一个！这就是rpm的实现机制，也正如此曾经遇到过有个rpm包，rpm -q查不到，rpm -qa却查到了，但是版本不是我们预期的版本。原因也定位出了，就是rpm对数据一致性保护方面的弱势。

rpm数据库损坏

这个更特殊了，客户有些要求还是很独特的。一次客户交流时客户提出升级过程如果这些机子停电了咋办？于是我们的测试总监就增加了掉电可靠性用例，测试mm们疯狂掉电一周啊。确实发现一些问题，也把rpm数据库搞坏了。求助开源社区问问该咋办呢，搜了一些之前的讨论，还是红帽的高级工程师呢，说要保证不发生这些特殊情况下进行rpm升级。看了真是一口血喷出来，开源和商用的区别么，玩开源真不错，啥可靠性、健壮性都不用care。

2、升级机制

rpm只能算一个最原子的命令操作，产品一次升级更新那么多包，总不能挨着敲rpm命令，而且产品的集群架构，动辄上百个节点。商业Linux很贵，中国没多少公司能付得起动辄百万刀一年的服务费。我们也没有渠道了解这些软件巨头的升级方案，都是土八路抹黑造枪啊。

前面提过rpm更高级的封装如zypper和yum，他们可以一键升级，解决rpm包之间复杂的依赖关系。但是商业级产品和消费者级产品最大区别也决定了产品升级方式的差异。商业产品升级要解决的最大问题我个人认为就是在线和配置兼容性。在线要求产品升级过程还能提供服务（貌似没见过第二家）、配置兼容性比较容易理解，但是rpm对这个功能支持不够，天生残疾。

在线

我们整个产品采用集群架构，其实每个节点升级软件也就几分钟，难道几分钟都不能忍吗？非要搞个业务的节点迁移，先把业务迁移到没升级或者升级好的节点，迁移时间30秒。没有业务的节点升级完成后，再迁移回来，升级剩余的节点。这个方案也是对的，没毛病，问题在烂到家的集群管理架构。业务迁移失败率很高，不同版本的集群管理软件不支持迁移业务，这些硬伤就先天悲剧了。做到最后等于是升级框架把整个集群管理功能都给包进来了，还不得不增加很多可靠性保证。就为了一个在线的需求，整体升级功能变得非常复杂和沉重，几次提出要重构升级框架都不了了之。

配置保留

这个是合理的需求，但是rpm办不到，目前看社区似乎也没有要办的意思。总是开源的套路就是他们自己玩吧。

先说说rpm的玩法，spec里有%config参数定义一个文件叫配置文件。举例来说，一个软件最初版本里配置文件内容为A，下一个版本升级了，配置文件有更新变成了B版本，正常升级就会从A更新为B。但是A版本被客户改了，加了几个配置变成了C的模样，那升级就出事了，一升级B就把C覆盖了，C带了个rpmsave的后缀还保留在节点上，客户的配置丢了。这样肯定有人跳了，所以不能丢失C的配置，于是spec支持一个功能%config(no replace)，这样B只会覆盖A（原始版本没有更改，直接更新），不会覆盖C（原始版本有更改，保留原始配置）。C留住了，B带了个rpmnew的后缀。客户要的东西没丢，拍手鼓掌吧。结果被扇了一嘴巴。B比A增加了几个参数，C里没有新参数。这时候rpm说话了，要么留B，要么留C，没有B＋C。技术上我也同情，做merge的功能应该复杂一些吧，但是嘴巴扇在我们的脸上啊，于是只能土八路方式想办法解决。

以上是这段时间做产品升级功能的一些吐槽和感悟，自己很想知道一些软件巨头升级处理这些问题的方案和思路，也很想认识认识国内也在做这块内容的同行。升级不简单，也需要钻研，希望共同进步。