概述

之前在一次判斷失誤的反思一文提到,從下單介面中，一次性剝離所有營銷邏輯，難度和風險都是非常大的。更好的方式是先剝離其中一到兩個，慢慢擊破。但是這種方式實施起來，難度還仍然還是很大的，下面將剝離的整個過程，描述一下。

剝離哪些營銷工具

下單介面耦合的營銷邏輯有如下幾種:

• 秒殺
• 拼團
• 砍價
• 滿減
• 優惠券
• 新人特價

那麼第一件要考慮的事情就是，先剝離哪些營銷工具。當時主要從下面兩個維度來考慮：

• 變動不頻繁的
• 就算有變動，也是變動比較小的
• 業務邏輯不復雜的

像滿減和優惠券，都跟訂單的優惠金額分攤有關係，實在太複雜，而新人特價和砍價又經常有改動，因此都排除掉。優先搞秒殺和拼團。

確定灰度方案

一般這種重構的專案，必須得灰度，降低風險。灰度策略必須儘早確定，因為不同的灰度方案，可能程式碼實現都不一樣了。當時基於公司的實際情況，想到的灰度方案有下面兩種：

1、按照userId灰度，白名單裡的userId，走新流程,非白名單的userId走舊流程；
2、直接在原來的程式碼裡進行重構，並使用nginx，調整權重，慢慢將流量打到部署有新程式碼的一臺機器上，驗證OK後，才全量。

之前採用的是第一種灰度方案，因為比較保險，也無需藉助nginx，直接在程式碼裡寫個灰度工具，判斷userId是走新程式碼還是舊程式碼即可。當然你需要基於原來的程式碼檔案，拷貝出一個新的檔案，用於實現新流程的程式碼。這種方案表面上看起來相當不錯，但是如果業務程式碼裡，有下面這幾種情況，則真心不建議用這種方案。

• 原始碼非常混亂，基本沒什麼程式碼收攏的概念，相似的邏輯滿天飛；
• 原模組改動比較頻繁,很不穩定。

像我們公司，下單模組的改動非常頻繁，有些是因為需求改動，有些是解決線上bug，一天之內釋出幾次程式碼，屬於正常情況。好了，這個時候就會出現一個程式碼合併的問題，具體如下：

1、新程式碼已經上線且已經灰度部分使用者走新流程了，這個時候，如果有線上bug，那麼兩份程式碼都得改動好後，才能上線；
2、還未灰度，那麼每次解決線上bug或者完成需求後，都得合併到擁有新程式碼的分支；

基於上面兩點，可以得出一個結論：

程式碼極度容易因為合併有問題，導致bug

當時使用第一種灰度方案後，測試人員測試一天後，就說不想測試了，因為由於程式碼合併問題，已經出現了多個bug。測試人員覺得這塊風險實在太大。因此，後面我們更換成使用第二種方案，直接改原來的程式碼，不拷貝一份了，這樣的話，程式碼有改動的時候，合併起來輕鬆了很多。至於風險，則採用機器灰度調整權重的方式，逐漸放量來降低風險。後來，我們使用這種方式，灰度了三天，成功全量上線。

程式碼設計若干細節

使用本地的結算服務與微服務營銷系統互動

一個正常商品參與了營銷活動後，就會有一個營銷價格。比如說，一個商品原來的價格是100元，參與了秒殺活動後，價格就變成了50元。因此，可以定義一個叫結算的模組service，例如：CheckoutServiceImpl，由這個類專門與營銷系統互動，獲取營銷價格，然後傳遞給下單介面，這樣，下單介面就可以直接拿到價格後下單，無需耦合複雜的營銷邏輯了。

拼團和下單的事務問題

電商的拼團，一般都是使用者下單後，才建立一個對應的團，訂單沒生成，那麼團也不生成，訂單生成了，而團建立失敗，則訂單也一併回滾掉，不產生訂單。這裡就有一個分散式事務的問題，當時為了儘量避免使用分散式事務，在營銷系統提供一個回滾拼團資訊的介面，一旦建立訂單失敗，則刪除掉原先建立的拼團資訊。

1、先建立團；
2、再建立訂單；
3、如果訂單建立失敗，則呼叫營銷系統的回滾拼團的介面，將團資訊刪除掉。

線上驗收

1、讓運維人員，調整機器權重，灰度一小部分流量到有新程式碼的機器上；
2、開發人員，通過分析日誌檔案和對比新舊程式碼的產生的訂單資料，看看是否有問題；
3、讓運維人員逐漸加大權重，開發人員重複執行第二個步驟；
4、全量，開發人員重複執行第二個步驟。