版本發布中的風險控制
版本發布】這個名詞，對於涉及軟件行業的夥伴們都是很熟悉的，【版本發布】是產品交付和線上叠代的一個裏程碑。
在互聯網公司中，因為很多系統是直接面向C端用戶的，對於系統是24小時不中斷的。所以，版本的版本如果涉及到多個系統的影響，同時要上線好幾個系統
那麽怎麽做到平滑切換，特別有些是涉及到版本更新前的舊數據和版本更新後的舊數據怎麽兼容，怎麽保證用戶使用中無感知，還有更重要的時候怎麽保證在
發布版本中出現災難情況的風險控制。這些都是要我們做發布方案的時候要深入思考的。
這邊直接拿真實產品叠代中的一個實踐例子給大家描述講解下，通過這個例子，讓大家有個比較深入的理解。
項目的背景：
上面的圖，總體描述了【庫存可售量】在下單凍結，取消訂單解凍，erp出入庫的數據流的流程。然後因為歷史原因，我們系統中的商品，有個屬性叫【是否跟蹤屬性】，
這個屬性到底是啥用處，這個是我們業務上的歷史原因造成的，我這邊簡單解釋下，比如商品10001，如果【是跟蹤屬性】，那麽下單，取消訂單的時候，是都需要操作
可售量的，商品10002，是【非跟蹤屬性】，那麽下單，取消訂單的時候，不需要操作可售量，所以下單的時候，如果同時選擇 商品10001，商品10002，那麽調用庫存
接口的時候，組成請求體json的時候，是不需要把商品10002組裝進去請求的。到這邊大家應該了解了【是否跟蹤屬性】的用意。但是這樣的做法是有問題的，因為【非跟蹤】
改成【跟蹤】，需要把可售量重新計算，這就造成了邏輯的復雜性，而且在系統請求負載大的情況下，容易在重新計算可售量的時候，造成臟讀，而到底可售量，凍結量
出錯。
修改方案
無論【跟蹤】還是【非跟蹤】都調用庫存接口，【跟蹤】的商品可售量扣到0為止，【非跟蹤】的商品可售量可以扣成負的。對於【非跟蹤】的商品，erp這邊可售量為0的時候，
仍然可以出庫，銷售出庫的時候，無論【跟蹤】還是【非跟蹤】商品都是要釋放凍結量的，因為下單的時候，都凍結了。
上述修改涉及的系統有【toc訂單】，【tob訂單】，【庫存接口】，【erp庫存系統】，【配單系統】(這裏主要計算銷售出庫的凍結量)。所以如果整個方案上線，是需要
這麽多系統全部上完，並且上線的時候，需要把【非跟蹤】的商品重新初始化，因為原來【非跟蹤】的商品的可售量是不實時計算的。而且上面涉及的系統都是比較核心的系統，
如果有問題，都不能是小問題。
首先思考下，訂單對於，商品10001，商品10002，原來調用庫存接口，只要傳商品10001就可以，現在全部要傳遞，這就涉及訂單的上線，但是訂單是24小時候都是會有訂單
的，怎麽讓訂單上線的時候保證可控，上線如果要停訂單，怎麽來使停單時間更短。所以第一思路，是否能讓訂單的部分先上線。然後訂單上線後，【庫存接口】怎麽來兼容老的邏輯
和新的邏輯，然後真正上線的時候，是否能夠快速切換。
綜上思路，最終整理的方案：
第一階段 tob/toc修改上線 InventoryData做兼容性配置化修改上線 第二階段 1. 暫停銷售出庫服務 --銷售出庫會釋放凍結量，所以肯定先要暫停 2. 暫停 tob，toc下單，取消訂單接口 3. 發布erp涉及的修改點發布 4. 修改庫存接口與服務，設置成【全跟蹤模式】 5. 利用工具初始化全部的【非跟蹤】商品的可售量的修改 6. 開啟tob.toc下單，取消訂單接口 7.開啟erp銷售出庫服務 第三階段 1. 上線配單部分 2. 利用腳本把凍結量全部修復掉 第二階段出現問題回滾方案 1.暫停tob,toc下單，取消訂單接口 2.Erp相關功能切換到發布前的版本 3.庫存接口和服務切換到【非跟蹤模式】 4.開始toc,tob下單，取消訂單功能 上面的核心思想是將整個版本發布，分成3個階段，每個步驟都在可控範圍之內，即使階段性有問題，也知識階段性的發布失敗，針對第二階段 有回滾方案，而且回滾方案盡量能快速回滾。 實施這個方案的時候，還有一些小細節上面的一些障礙點，比如【初始化工具】需要重新獲取訂單銷量，但是當時訂單銷量的接口查詢效率不是很 快，那要初始化的商品有獎金2700個，那麽初始化會花很多時間，這個在發布中是不可容忍的，所以針對銷量，我們做了隊列後面實時計算銷售的 方案，這樣拉取銷量直接是已經算好的銷量，效率很高。 一切障礙排除後，後來發布也相對順利，整個發布過程中時間也很短。數據也平滑了切換。當然這個裏面其實還有改進的地方，比如第二階段的時候， 可以在不停訂單，在庫存接口裏做【截單】功能，這樣發布就不需要訂單那邊配合停單。 發布過程中，有很多復雜的情況，上面只是實踐中的給大家展示的一個思路和過程，希望能給大家有理解上的幫助。
版本發布中的風險控制