联系
Knight's Tale » 思考

项目上线的一些思考

2014-10-31 16:17

做大项目,一定会涉及到上下游依赖,上线的顺序就尤为重要。一般来说,无非有以下两种

  1. 下游先上线,此版本需要兼容上游旧版本。然后上游就可以放松的上线。
  2. 上游先上线。此种做法要求下游旧版本需要能支持上游新版本。然后下游的新版本需要考虑新版本数据(某些情况下,亦需要考虑旧版本数据)。

第一种做法,好处就是几乎可以应对所有情况。因为我们在做项目时可能都无法预期未来的变化的,让下游来做旧版本兼容,可以应对所有情况。不好的地方就是下游代码恶心。

第二种做法,好处就是下游和上游代码均是相对clean的。但是,它需要上下游在做设计的时候均要考虑到未来的设计,换句话说,就是上游上线什么的,下游不会出问题。

我们需要注意到,为什么这里说是相对的而不是绝对的clean? 上游上线后,一般来说,接口数据将是新数据格式。但是在某些特殊情况下,会出现新旧数据交融的情况。这时下游在上线时就需要以“支持新数据,同时兼容旧数据“为准则。支持新数据是代码核心重点,兼容旧数据是处理边界情况。在这种特殊情况下,下游代码较为“恶心“,和第一种做法一样,但是这也是无法避免的。

第一种方法风险小点;第二种风险大些,需要做较多回归性测试,保证下游可以hold住上游的变化。

具体选择哪种办法,还是要看项目而定。我个人是比较推荐第二种做法,因为这样可以保证代码的相对clean。当然,这对接口的设计就会有些特殊的要求,比如,接口尽量以增量的方式来完成,下游在读取字段时以尽量小的范围方式来读取。

遇到新旧数据交融的情况下,谁先上线都无法避免代码恶心的问题。但是我还是推荐第二种做法。我们写代码时均需要保证自己心里有“面向未来开放”的设计原则。因此好的设计是,上游上线新功能,下游可以做到兼容。

以我在百度多年经验为例,上线新系统比升级旧系统容易很多。在较大规模的平台上线中,新旧数据”交融“的情况均为常见情况。下游的设计则需要多担当责任。

如果出现上游升级2.0之类更新非常之大,新旧数据非常复杂,差异非常之大的情况下(例如DAN1.0的升级),也可以考虑的一种做法是,上游新旧系统同时运行,新系统采用新数据格式,旧系统采用旧数据格式。在上游上线新系统后(此时上游旧系统亦同时在运行,下游亦在运行),下游上线,对接上游新系统,这时接口数据均是fresh的,不需要考虑新旧数据的兼容性。下游在上线过程中,要随时准备切换回上游旧系统数据接口。这种上线模式,风险非常之大,但是也只有这样,才能保持,上线新系统的过程中,整个服务平台不会断流。

本文链接地址:项目上线的一些思考