前言：本文介紹了餓了麼交付中心由python語言棧轉換到java語言棧大致過程,一來是對前段時間的工作做下總結，另外也是想透過此次總結為其他應用服務轉型提供些借鑑。寫的不好，歡迎板磚。

背景

餓了麼併入阿里集團,為了能高效與集團內部系統協同對接,同時方便利用集團優勢技術資源,更好的融入阿里集團技術生態圈,餓了麼交易中臺在上半年啟動了交易領域的四大應用語言棧轉型專案，為阿里集團本地生活服務平臺打好技術平臺基礎做準備。另外，隨著業務量的激增,餓了麼平臺支援的品類不僅僅是最初的外賣單品，整個交易中臺也需要一次相對大的重構來快速應對複雜多變的業務需求。而本文中的交付中心即是餓了麼交易領域四大應用之一。

準備

在開展相關工作之前，首先必須得清楚我們是要將一個系統從什麼樣變成什麼樣，新的系統相較老的系統在哪些方面做的更好，同時必須保證新老系統的無縫切換，做到業務無感不影響交易系統的穩定性。

系統價值

外賣訂單的業務特點是重交易,c端使用者從下單選餐到騎手完成餐品交付過程，目前大部分都能在半小時左右完成，對即時配送實時性要求較高。整個訂單交易過程大致劃分為:1.新增購物車確認訂單，2.訂單生成及訂單支付，3.接單及訂單交付，4.可能的售後退單。而要更好的服務使用者，對四個系統穩定的協同能力提出很高的要求。

如前文所述，我們知道履約環節對交易訂單的價值是什麼，即是將外賣訂單對應的餐品交付到使用者手中，技術層面上來講，交付對交易訂單遮蔽了一切其他履約細節，使訂單更專注訂單領域業務。

核心分析

接下來，我們再進一步詳細的剖析下轉型前交付系統所承載的功能。  

如上圖所示，原交付履約領域中包含了三個較大板塊：

1.訂單對接運力線模組
2.商戶訂單資訊模組
3.部分金額計算模組

可以看出原系統所承載功能並非真正聚焦在訂單交付過程。怎麼辦？轉型重構是個契機。商戶訂單迴歸到訂單，金額計算下沉至結算，這兩部分的相關轉型重構這裡不再贅述，相關部分也已由兄弟團隊完成。其實到這裡交付履約應該關注的已經很明顯：把外賣訂單給運力線，使其完成交付履約。

基於剛才提取後的交付履約核心領域，我們對主要的場景用例進行了詳細的梳理。如下圖所示，可以看到：

參與交付過程的主要角色有四個:
1.商戶
2.訂單
3.履約運力線
4.使用者

交付提供的主要支撐能力有：
1.乎單交付能力
2.運單狀態同步能力
3.運單資訊透出能力
4.履約方式切換能力
5.運單狀態廣播觸達下游能力等。

部分運單取消或異常管理。

系統核心用例分析如下圖所示:

更詳細的系統用例梳理或系統上下游互動時序這裡不再一一列舉，需要說明一點，當大流量系統轉型遇到重構，要想走的夠遠夠穩，前期的仔細調研工作及功能對齊過程非常重要。特別是生產環境已經跑了好幾年核心功能系統，實際業務情況錯綜複雜。例如要轉型重構系統介面能力，介面含義，場景必須都要詳細掌握。

設計

至此，我們的目標已經很明確:1.語言棧轉型，2.過程中要將不屬於交付的東西從原系統中分離出去，使得交付領域更乾淨。結合交付未來可能的發展方向，其中交付能力可複用的，履約運力線可擴充套件的。這對整個交付可快速迭代對接提出了更高要求。另外，我們也在領域建模設計思想指導下做了些實踐嘗試，於是有了以下框架結構。

系統設計

轉型是把python方言轉換到java方言，交付系統核心能力不會有變化。能力的複用是透過介面維度的抽象聚合產生，履約運力線能力可擴充套件透過利用業務框架擴充套件點特性滿足。拆分後的業務框架應如下圖所示：

系統架構

業務框架結合當前餓場基礎元件支援我們不難給出以下系統內部模組劃分：

簡單對各組成模組做簡要說明：

api：處於業務框架中上游系統接入層，對外暴漏契約遮蔽細節，對內定義系統能力。
starter：啟動專案
service：rpc服務暴漏
domain：核心業務能力實現，聚合層
infra：基礎資料支撐能力層
extension：履約能力擴充套件層
tester：單元測試包

到此，我們可以按照設計與既定的計劃擼程式碼了。

嗯，程式碼擼完了測完了，從調研到開發完成歷時兩個半月，程式碼倉庫總行數約4.7w行，提交1000次左右，完成63個介面+16個訊息消費入口轉型遷移，共計測出117+bug，期間有喜有憂，奮戰兩點多是常態。職業生涯中濃重的一筆。此時尤記起與超哥@鄒超週末代理聯調於北14樓小黑屋之畔，和明龍@張明龍並肩作戰對接服務介面，還有曉波@俞曉波凌晨一同壓測觀察總結問題第二天分析反饋提升最佳化，當然還有傑哥@湯良傑的用例設計全面不失細節、對bug常常究其根本，對程式碼review邏輯核對一絲不苟明察秋毫。凡此種種，歷歷在目。一起走來，真心感謝。 ------ 不由自主的感概下 ≧◇≦

平穩過渡

程式碼擼完測完才做好轉型工作的第一步，將流量穩步平滑過渡到新的服務中，做到上下游無感是轉型過程中面臨的另一大挑戰。
說到這裡,要達到系統的語言轉型前後的平穩過渡其實是在說轉型前後對我們系統的使用者SLA(Service Level Agreement)提供一致性的保證。這裡先簡單聊聊系統服務的SLA。

服務可用性級別服務正常執行時間百分比年當機時間日當機時間190%36.5day2.4 hour299%3.65day14 min399.9%8.76day86sec499.99%52.6min8.6sec599.999%5.25min0.86sec699.9999%31.5sec8.6msec

上表格是業界服務高可用的幾個級別的衡量標準，例如：服務可用性是3個9時，全年當機時長約為8.76天的統計機率。另外，我們需要明確的是不同的系統，不同的場景以及不同的使用者規模對系統可用性要求是不一樣的。如：某些業務的支付鏈路場景可能tps不是很高，但是作為交易的核型鏈路必須得保證高階別的可用性。
怎麼保證或者提升系統服務的SLA呢？在明確我們目標後，接下來就是拆解目標量化目標。

you cant measure it,you cant fix it and improve it.

一般來說，影響系統服務可用性有兩個重要因子:

MTBF：Mean Time Between Failures,系統服務平均故障時間間隔。
MTTR：Mean Time To Recover,系統服務平均故障恢復時間時長。

所以大致可以簡單歸納為這樣的一個函式關係:

可能無法給到一個精確的數學描述，但是可以做定性的分析:恢復時長因子與系統可用度成正相關，故障間隔因子與系統可用度成逆相關。也即：
_問題出現時恢復時長要儘可能的短，儘可能降低故障頻率以增大故障間隔。基於以上理論，我們在做系統平穩過渡無縫切換時，無論資源使用，業務內部邏輯實現及灰度方案，我們都需要著眼於這兩個方面。接下來我們將從這兩個點出發分析轉型過程存在的挑戰及我們的應對方式。

快速響應，降低恢復時長

要做到恢復時長儘可能的短，首先我們需要保證在前期出現問題時流量切換過程中流量規模儘可能的小，即需要一個相對的合理的灰度梯度方案。其次當問題出現後我門需要能立即回切到原系統，不至於反應過慢導致大量增量問題產生，即需要一個響應高效的開關回滾方案。由於轉型過程中涉及的介面和訊息消費入口較多，另外我們還需要考慮到後期問題排障和快速定位的可能耗時。

針對灰度梯度合理制定，根據業務特徵，開始階段我們選擇了較冷門城市(訂單量較低)進行了各個運力標品業務的邏輯驗證。標品驗證完後說明我們新遷移實現的邏輯和原系統具有一致性。隨後我們拉取了當前訂單城市分佈，根據城市訂單分佈佔比制定灰度梯度，由小到大逐步增加。
針對回切需要響應高效，我們應該有一個總的開關可以控制流量，回切應該是一鍵控制的。
針對排障快速定位，灰度單生命週期內的操作能在單應用內自閉合，不至於排障時還需要確認灰度單某個狀態到底走的原系統服務還是新系統服務。另外我們還希望，寫操作灰度和查詢灰度能單獨隔離開，等寫資料完全一致的情況下我們再開啟新資料新介面查的灰度，將風險控制到最低。

所以我們採用瞭如下的老系統服務代理方案：

如上圖所示，訂單系統建立訂單時根據既定的灰度計劃讀取配置給訂單打標，灰度計劃分為前期分標品，門店維度驗證，後期按城市訂單分佈維度配置。若新系統服務出現問題可一鍵切掉灰度流量，止血增量問題。接著，原交付老服務識別標記做代理轉發,訂單不存在遷移標記則原流程操作處理,否則轉發到新交付中心新服務操作處理，相應的訊息監聽處理同樣也是參照訂單標記，這樣保證了同一個訂單的交付過程能在一個應用中完成，有利於後期處理流量上來後的快速問題定位。
另外，我們的介面灰度過程是寫與查分離的，整個遷移過程大致分為三個階段，如下圖所示：

第一階段灰度寫階段,灰度策略:餐廳維度,城市維度小範圍灰度,讀流量以老服務為準,問題出現及時切掉灰度寫流量,邏輯回滾至老服務。
第二階段灰度查詢階段,灰度標記流量以新服務為準,非灰度標記以老服務透出為準,灰度策略:各個查詢介面按照百分比逐步增加灰度佔比。
第三階段遷移階段,完成讀寫灰度,原系統老服務只是代理的一層皮,接下來就是上游系統遷移到新服務,去掉對原原系統服務的依賴,遷移完成。

最大努力降低故障風險

平均故障間隔是一個後驗時長資料，要做到間隔時長儘可能的長，日常裡就需做好釋出控制，風險巡檢及持續監控等工作。

1.釋出控制

轉型期間新系統服務必須遵循釋出sop，餓場釋出sop已經形成共識，我們只需嚴格遵守，這裡不再贅述。

2.風險巡檢

系統邏輯核對，多人多次code review。
變更釋出前主幹場景自動化用例全透過。
週期性壓測。

3.多層次持續監控

部署機器，快取叢集，訊息佇列，資料庫表等基礎資源的基準監控。
業務曲線成功率，日同比，周同比，曲線波動比，及主要介面入口流量到下游出口流量轉換率監控，業務系統成熟後還應對各個服務響應時間指標做監控等。
系統中很多情況下重試都是以異常中斷為依據，這必然會對系統異常點帶來較大的噪音。為此我們還需要細化各個中斷異常的打點，排除不必要的干擾。

一致性問題

轉型過程中我們實際上同時做了資料模型最佳化遷移，對外為了保證新老系統行為屬性的一致性，我們還面臨以下幾個挑戰：

灰度資料需要雙寫新老交付系統庫表，如何保證雙側底層資料的一致性？
底層資料一致不等於對外服務介面資料透出一致，雙側服務應用層面怎麼保證資料的一致性？
訂單阿波羅履約線和交付的上下游資料資料最終一致性怎麼保證怎麼驗證？

一致性的保證，別無他法，只能透過比對來做。但在做比對的時候我們還需要考慮到比對本身只是我們驗證遷移系統正確性及穩定性的一部分屬旁路，並非生產環境的必須功能。即我們得考慮這部分功能對現有系統可能造成的壓力。這部分壓力應該是隨著系統驗證完畢是可開關的，壓力大小應隨系統的表現可隨時調節。不至於因為驗證拖垮了生產應用。所以我們對比對的基本要求是：能一鍵開關，可監控可追溯。除了這些共性，具體還應做到以下幾點：

針對底層資料比對：
比對應是準實時的，如只比對30分鐘前的資料。
比對資料是基於時間可分段取樣的，如只比對10分鐘以內產生的資料。
為了方便控制，根據情況以上策略又可以是及時調節的。即準實時偏移量可調節，分段取樣視窗大小可調節。

具體實施方案如下：

針對應用層資料比對：
代理層接收請求後，比對應是非同步的，不影響介面響應耗時。
比對粒度要小，應細化到介面。
識別灰度資料，只做有效比對。

具體實施方案如下：

無論資料層面還是介面層面出現比對不一致，應立刻去分析是什麼原因導致不一致。解決根因逐步降噪，只至比對差異在我們認為可接受的範圍內。

針對上下游資料最終一致性：
全量資料核對
主幹鏈路最終一致性核對

經過資料準實時比對，介面實時非同步比對，其實基本可以確認新老系統能力行為屬性對等性。然而穩定大於一切，要百分百確定還需要t+1資料核驗。即從全域性資料角度看新老系統轉換的影響。這裡以主幹鏈路呼單多日成功率為例做簡要說明。如下圖所示，多日乎單成功率基本在99.9977%左右，可以認為新老系統代理切換交付成功率基本表現穩定。

未來

截止此文攥寫時間，餓了麼交付中心已經完成了整個系統的語言轉換，流量也已經100%切換代理到新系統，處於流量切換的第三階段。結合日常系統維護與需求迭代實踐，我們仍需要再以下幾個方面進行更深入的思考：

轉型過程中為了在易測，可核對同時與python的“魔法”姿勢鬥爭中找平衡，部分邏輯是"純翻譯"的，後期維護過程很痛苦，所以我們需要幾次不小的重構來達到程式碼層面的和諧。
不斷監控降噪，持續細化監控粒度，監控是服務穩定基石。
交付中心資料大盤建設，從資料層面量化觀測我們的交付質量。資料驅動,數字運營從資料化思維最佳化我們的流程，提高我們的服務。

方法論沉澱

凡此以上，服務系統轉型遷移歸結於開發者理解與認知，專案的穩定實施歸結於開發者套路方法運用。可以簡單進一步提煉為以下方法論：

詳細調研，客觀問題及滿足業務的系統是複雜的，詳細調研做好準備是必須的。
持續監控，感知系統的質量是服務質量度量的第一步，不斷持續的監控才能走的更穩。
穩步過渡，網際網路系統服務高可用穩定不容商量。
問題發現根因解決，小的問題可能隱藏大的bug，認真對待究其根本，覆盤->總結->提升。
歸納總結業務再認知。

關於認知提升的幾個小點：

對於每一位工程師，開發高併發大流量系統是挑戰也是機遇。時刻保持進取學習心態，增強自身軟素質。
分散式情況下，承認系統並非絕對100%可靠，每一個環節都要考慮“失敗”了怎麼辦，不同的場景我們需要在AP和CP之間作出抉擇。如雙鏈路呼叫保證可靠，非同步重試保證順序最終一致等。
出了問題快速恢復是個永恆的話題，沒有“怎麼樣“最快只有”這樣”更快。精準定位立即恢復，如何將這個過程耗時降到更低值得深入思考。

作者資訊：李傑，花名項庭，當前主要負責餓了麼交付領域系統。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。

餓了麼交付中心語言棧轉型總結

背景

準備

系統價值

核心分析

設計

系統設計

系統架構

平穩過渡

快速響應，降低恢復時長

最大努力降低故障風險

1.釋出控制

2.風險巡檢

3.多層次持續監控

一致性問題

未來

方法論沉澱

相關文章