服务怎么升级

我们做商业化服务或者中台服务的，都会面临服务升级的挑战。由于业务和客户诉求的升级，就需要同步的做服务升级。但是服务升级面临众多的挑战，包括兼容性、稳定性、维护多个版本的开发工作量等。综合在支付资金领域多年的服务化实践，服务升级最好的做法其实是有限升级模式。

首先，对于服务升级，我们需要先定义一下升级的类型。我将服务升级的类别划分成了三类：缺陷修复、功能优化、代际升级。

对于不同的升级类型，我们建议采用不同的模式应对：

• 缺陷修复：理论上不应该影响对外契约，对使用方无感。服务提供方内部兼容。这里主要设计代码逻辑的兼容。

• 功能优化：可能会带来契约上的变化，对使用方有打扰。服务提供方升级的服务契约需要兼容老的版本，同时内部需要兼容两套服务。这里需要考虑契约、模型和代码的兼容。

• 代际升级：会带来契约上的变化，同时兼容的成本比较大。服务提供方建议定义和分别维护两套服务，中间不需要做绝对的兼容，逐步引导下线老服务。可以提供迁移能力，将老服务的数据迁移到新服务。

这个策略，其实和通用操作系统升级的策略是类似的。比如 Windows，目前微软也不会再维护 Win 3.1 了。同时，每个大版本的迭代，微软也不完全保证应用程序都能兼容。

在这套升级模式下，有几个能力需要重点考虑：契约兼容性、模型兼容性、代码兼容性、模型升级和迁移。

在非代际升级下，契约需要做到兼容。所以，对于功能的小迭代升级，我们对于契约，应该只能做加法不能做减法。对于字段，只能新增字段，不能删除字段。对于数据字典，只能增加，不能减少。对于字段长度，只能扩充不能缩减。做到这几点，基本上契约就可以做到向下兼容。

对于模型的兼容，也是一样的道理。字段只能新增不能减少，字段取值约束只能放宽不能收紧，字段长度只能扩展不能缩减。同时，对于模型的升级，我们需要考虑顺序问题：

• 存储模型需要最先升级，否则新的流量会无法持久化。

• 老的领域模型需要适配新的存储模型。对于新增的字段，老的领域模型为空，存储模型需要支持。

• 同时，老的代码逻辑一般不能处理新的领域模型。所以需要控制只有代码全部升级完毕，才能出现新的领域模型（有新服务的流量）。

对于代码兼容性，主要需要考虑服务依赖兼容性。这里有两类解决方式：

• 下层服务先发，同时兼容上游的新旧服务调用。

• 或者上游进行开关控制，保证下游更新有再出现新服务流量。但是下游新服务兼容上游老服务调用必须考虑。

通过上面的描述，模型的兼容的难度其实相对是较大的，所以对于代际的升级，建议采用两套服务+迁移的策略。模型迁移可以采用离线和在线两类模式，根据服务的特性决定。

• 离线模式：通过离线清洗的方式将老模型转换为新模型。这个模式适用于有一定停服时间的场景。这种场景是服务提供方主导的模式。迁移后，引导使用方用新模式访问。这种方式前一复杂度会较低，但是限制较大，同时使用场景有限。

• 在线模式：通过双读的方式，将模型从老模型迁移到新模型。这种场景是服务使用方主导的模式。迁移由服务使用方切换到新服务请求触发。这个时候，我们先读新模型，如果新模型中没有记录，切换到老模型进行读取，同时完成数据到新模型的迁移。这里重点需要考虑事务性问题。因为我们根据新模型中是否存在数据进行判断，所以要保证老模型需要在一个事务中被迁移到新模型，不然就会存在数据不完整的风险。

总是，对于商业化服务这样一个 infinite game，我们对于无时不刻不存在的服务升级问题，可以采用三类不同的方式进行应对，同时在服务契约设计、模型设计、代码逻辑设计上考虑兼容性，最后采用模型迁移的方式来应对代际升级。