版本发布中的风险控制
版本发布】这个名词，对于涉及软件行业的伙伴们都是很熟悉的，【版本发布】是产品交付和线上迭代的一个里程碑。
在互联网公司中，因为很多系统是直接面向C端用户的，对于系统是24小时不中断的。所以，版本的版本如果涉及到多个系统的影响，同时要上线好几个系统
那么怎么做到平滑切换，特别有些是涉及到版本更新前的旧数据和版本更新后的旧数据怎么兼容，怎么保证用户使用中无感知，还有更重要的时候怎么保证在
发布版本中出现灾难情况的风险控制。这些都是要我们做发布方案的时候要深入思考的。
这边直接拿真实产品迭代中的一个实践例子给大家描述讲解下，通过这个例子，让大家有个比较深入的理解。
项目的背景：
上面的图，总体描述了【库存可售量】在下单冻结，取消订单解冻，erp出入库的数据流的流程。然后因为历史原因，我们系统中的商品，有个属性叫【是否跟踪属性】，
这个属性到底是啥用处，这个是我们业务上的历史原因造成的，我这边简单解释下，比如商品10001，如果【是跟踪属性】，那么下单，取消订单的时候，是都需要操作
可售量的，商品10002，是【非跟踪属性】，那么下单，取消订单的时候，不需要操作可售量，所以下单的时候，如果同时选择 商品10001，商品10002，那么调用库存
接口的时候，组成请求体json的时候，是不需要把商品10002组装进去请求的。到这边大家应该了解了【是否跟踪属性】的用意。但是这样的做法是有问题的，因为【非跟踪】
改成【跟踪】，需要把可售量重新计算，这就造成了逻辑的复杂性，而且在系统请求负载大的情况下，容易在重新计算可售量的时候，造成脏读，而到底可售量，冻结量
出错。
修改方案
无论【跟踪】还是【非跟踪】都调用库存接口，【跟踪】的商品可售量扣到0为止，【非跟踪】的商品可售量可以扣成负的。对于【非跟踪】的商品，erp这边可售量为0的时候，
仍然可以出库，销售出库的时候，无论【跟踪】还是【非跟踪】商品都是要释放冻结量的，因为下单的时候，都冻结了。
上述修改涉及的系统有【toc订单】，【tob订单】，【库存接口】，【erp库存系统】，【配单系统】(这里主要计算销售出库的冻结量)。所以如果整个方案上线，是需要
这么多系统全部上完，并且上线的时候，需要把【非跟踪】的商品重新初始化，因为原来【非跟踪】的商品的可售量是不实时计算的。而且上面涉及的系统都是比较核心的系统，
如果有问题，都不能是小问题。
首先思考下，订单对于，商品10001，商品10002，原来调用库存接口，只要传商品10001就可以，现在全部要传递，这就涉及订单的上线，但是订单是24小时候都是会有订单
的，怎么让订单上线的时候保证可控，上线如果要停订单，怎么来使停单时间更短。所以第一思路，是否能让订单的部分先上线。然后订单上线后，【库存接口】怎么来兼容老的逻辑
和新的逻辑，然后真正上线的时候，是否能够快速切换。
综上思路，最终整理的方案：
