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

前言：
本文介紹了餓了麼交付中心由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。

服務可用性級別	服務正常運行時間百分比	年宕機時間	日宕機時間
1	90%	36.5day	2.4 hour
2	99%	3.65day	14 min
3	99.9%	8.76day	86sec
4	99.99%	52.6min	8.6sec
5	99.999%	5.25min	0.86sec
6	99.9999%	31.5sec	8.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之間做出抉擇。如雙鏈路調用保證可靠，異步重試保證順序最終一致等。
• 出了問題快速恢復是個永恆的話題，沒有「怎麼樣「最快只有」這樣」更快。精準定位當即恢復，如何將這個過程耗時降到更低值得深刻思考。

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

 

 

 

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。