黄色av一区,日本韩国欧美在线,久久精品视频网站

蘇寧零售云app下載（蘇寧零售云平臺介紹）

香香 ? 2023年9月22日 16:17:08 ? 好文推薦 ? 閱讀 356

零售云目標T4-T6級市場的業務，定位更靠譜的智慧零售解決方案和零售服務集成商，實戰式跨界賦能。蘇寧易購TOC的經驗豐富，相關的方案很完善，但是零售云TOB相關業務啟動后，業務增長迅速，App相關的穩定保障方案缺失。 2 零售云業務的特殊性 零售云主要是TOB的業務，目標T4-T6級市場的加盟店，授權店，跟TOC業務相比，有以下有個不同點： 1）用戶量不多，但是每個用戶強依賴零售云相關App。 2）每筆訂單金額巨大。 3）需要系統穩定。零售云的每個用戶都是一家門店的一個角色人員（老板，店長，收銀員…），每家門店每天的進銷存都依賴零售云配套App（零售云，零售云店員，零售云管家）。零售云App提供進貨服務，零售云店員提供銷售服務，零售云管家提供庫存管理，報表查詢等服務。可以看出，一個用戶使用出現問題，就會影響到一家門店的日常銷售，導致不能正常銷售，每一家門店每天都付著店面租金和人員酬勞，不能營業的后果非常嚴重。 3 前期快速迭代滿足業務遇到的問題 1）系統問題需要門店上報給運營，運營再同步給研發負責人，問題的流程較長響應比較慢。 2）研發需要跟門店人員確認操作過程，甚至借用登錄賬號，體驗不好。 3）App到數量的灰度發布，不能精確試點，一旦出錯，影響范圍較大。 4 App穩定保障思路 系統穩定的三個特點：可監控，可灰度，可回溯。對于App來說，一旦新包發出去后，想回溯就不太現實了，辦法無非是提示更新或者熱更新，所以我們主要針對前面兩點來實現。 4.1 可監控在監控上我們做了兩個方面的工作： 1）云跡性能監控，類似友盟或者Buggly的性能統計，包括崩潰，卡頓，日活等等； 2）云跡實時日志統計分析。 4.2 可灰度 1）實現到店鋪層面的灰度更新下面我們來展開講講這兩點的實現方式。 5 到人的請求監控（可監控） 類似友盟或者Buggly的性能統計，我相信大部分App也都接入了，這邊不做解釋了，不管TOB還是TOC業務都一樣。正是基于上面的性能統計，我們得知，零售云App的使用用戶，60%左右是在WIFI環境下。上面也解釋了TOB業務對系統的強依賴性，但是對于流量消耗的敏感度卻不高。基于前提條件，我們決定把客戶端所有的網絡請求數據和業務錯誤軌跡都記錄在云跡平臺，并且配置錯誤告警。這樣做的好處有兩個：1）通過短信和郵件告警，可以快速知道錯誤。2）通過實時日志埋點可以知道每個用戶的行為和操作軌跡，方便快速定位錯誤。流程圖如下所示：

5.1異常告警我們根據自己的需求，配置搜索條件，告警觸發條件，并以短信和郵件的方式通知給對應的負責人。如下圖所示：

當有異常觸發告警條件時，對應負責人會短信和郵件收到告警通知，第一時間發現問題。 5.2日志查詢 1. 當收到告警后，對應負責人需要登錄到云跡實時日志分析平臺 1）選擇對應的系統名 2）選擇日志類型 3）選擇查詢時間 4）通過kibana查詢語法，即可查詢到該條件下的日志。

2.我們隨便點開一條日志，可以看到詳細的用戶信息。

根據上圖日志內容可以快速獲取如下關鍵信息： 1）app版本 2）手機版本，手機型號 3）業務信息（請求地址，請求參數，返回參數，堆棧信息） 4）賬號通過上面信息可以快速定位到某個時間點下錯誤的請求。 3.某個用戶軌跡很多時候，某些錯誤是在用戶特定操作下才會觸發，這個時候，需要知道用戶的操作軌跡，我們可以通過kibana查詢語法，篩選出某個用戶的所有日志，根據請求時間可以很方便的知道，用戶的整個操作軌跡。如圖所示，該用戶最近三小時的操作行為都可以查到。

得到用戶的行為軌跡，很多錯誤場景，研發可以自己模擬，不需要再遠程咨詢門店用戶，方便高效定位問題。 6.到店的移動App灰度發布（可灰度） TOC的場景一般是用戶量的灰度，比如一次灰度10000個用戶，但是對于TOB卻不適合，比如一次灰度100個用戶，可能覆蓋到100家店鋪，一旦出問題這100家店鋪正常銷售受到影響，而且統計哪些店鋪受到影響也很困難。針對零售云特殊的情況，我們制定了特殊的灰度發布流程。每個app在蘇寧升級平臺（MPCS）上面配置兩個appid，一個為正式版本包，一個為灰度版本包，客戶端根據分銷前臺返回的appId（0/1），區分取正式包還是灰度包的appid，進行版本更新請求。灰度期間，通過分銷前臺配置店鋪白名單，在白名單文件中的店鋪下的用戶提示升級到最新版本，其他用戶無影響。在灰度成功后，分銷前臺關閉灰度開關，進行全量升級。流程圖如下所示：

灰度期間只有白名單用戶才調用灰度包更新接口，其他用戶調用正式包升級接口。逐步增加灰度的店鋪，10個->20個->50個->100個->全量，期間注意觀察云跡異常。 7.避免的生產問題 通過上面的穩定保障，我們避免了不少生產問題，這邊舉兩個例子： 1）四月份的一個下午，突然收到很多告警，打開云跡實時日志查到一個小時內報大量的請求超時，而且集中在某個區域，通過這些關鍵信息，最后定位是運營商網絡的問題，當天就快速修復，對于用戶來說對于整個修復過程無感知。 2）云跡告警商品詳情頁接口會偶爾失敗，通過云跡查詢到日志信息發現，商品詳情頁需要傳的店鋪編碼，某些時候客戶端傳的是空，但是review客戶端相關模塊代碼，確認每次都是傳了店鋪編碼，這個時候就需要模擬用戶的操作軌跡。通過查詢該用戶所有操作日志，分析出失敗接口前面幾分鐘的操作行為得知，在四級頁停留了很長時間后登陸失效，再次登陸后店鋪編碼為空，知道具體錯誤后，就可以在下個版本修復避免生產問題。 8.目標展望 為了保障零售云App的穩定，我們其實還做了很多工作，這里不一一列舉了，當然我們還有很多的提升空間，未來我們會不斷優化監控和灰度方案，加強數據收集和分析，保障零售云App的穩定。再穩定的系統也不能保證百分之百不出問題，所以在應對可能出現的問題時，我們必須要在第一時間發現問題，快速響應解決問題。

聲明：本文由網站用戶香香發表，超夢電商平臺僅提供信息存儲服務，版權歸原作者所有。若發現本站文章存在版權問題，如發現文章、圖片等侵權行為，請聯系我們刪除。