前言

蘇寧售后服務運營能力承諾服務系統（簡稱“ASAP”）是物流研發中心建設的針對蘇寧售后服務的時效承諾管理和服務運營能力管理的核心支撐系統，ASAP系統經歷兩年多的線上考驗與技術迭代，目前服務著成萬級商家，億級SKU。

系統定位及核心業務場景分析

首先介紹一下系統的定位，蘇寧售后服務運營能力承諾服務系統（ASAP,下稱“系統”），是售后服務能力的“庫存系統”，主要為售后服務的服務時效承諾和運營服務能力提供管理，與易購商城及線下門店的商品銷售及售后服務履約相關聯，系統定位為蘇寧易購核心銷售鏈路上的核心服務之一。在商品銷售和售后服務履約過程，為消費者、蘇寧客服、蘇寧自營售后服務商、廠家售后服務商和平臺售后服務商提供能力服務支撐，為售后服務能力均勻有序的釋放提供了系統支撐，從而保障了售后服務質量。

然后介紹一下系統的主要功能及業務模式，系統主要提供服務承諾和服務能力的實時接口查詢，服務能力的實時增加和扣減接口服務。從業務模式上又分為蘇寧自營售后服務、廠家售后服務、平臺服務商售后服務，其中蘇寧自營售后服務是指由蘇寧自營的幫客公司提供的售后服務業務，廠家售后服務是指由商品的原廠商（比如海爾、華為）提供的售后服務業務，平臺服務商售后服務是指由平臺服務商（比如閃修俠）提供的售后服務，針對這三種業務類型，系統提供全面支撐。

系統的特點

庫存系統主要面臨以下幾個挑戰：

高并發，熱點爭搶?
涉及商品四級頁的時效針對同一個商品，比如秒殺、團購、打折促銷等活動商品，如何支撐高并發時效能力查詢與扣減服務。

盡可能減少能力超扣，保證數據一致性。
區別與實物商品庫存，售后服務能力主要是為了減小下單環節的依賴，能力控制可以放寬限制，服務的能力異步扣除，允許并發情況的少量超扣，但從服務上要保證扣完后的實際能力與查詢能力保持一致性，這是底線原則。

系統擴展性?
如何建設出可無限擴展的架構，在系統擴展過程中，各部署節點都需要具備無限擴展能力，而常見的瓶頸如數據庫的連接數、隊列的連接數等。

架構設計目標

應用架構

業務流程：

1）服務商的運營人員針對服務類型進行服務承諾和服務能力的維護
2）消費者在蘇寧易購APP或是網站上選購商品，打開商品四級詳情頁，調用SOLP進行時效查詢
3）SOLP調用ASAP提供的時效查詢接口進行查詢。
4）消費者完成下單支付，訂單由訂單中心下發到“售后服務接單管理系統”，由“售后服務接單系統”調用ASAP系統進行能力扣減。
5）如后續的售后服務訂單有取消或另約服務時間請求，則會調用ASAP的能力的回滾接口進行能力回滾。

系統架構

ASAP架構主要涉及：
1）ASAP服務：主要提供能力的加減服務包括能力新增和能力扣減接口，
2）ASAP后臺：主要提供系統給運營人員進行承諾和時效服務的
3）中間件：主要涉及分布式服務框架RSF、任務調度平臺UTS、消息隊列WindQ
4）數據層：主要用到了Redis集群，mysql數據庫集群。
5）基礎服務：主要依托蘇寧的基礎DEVOPS工具鏈完成開發和運維工作。

技術框架

開發框架

系統采用蘇寧SNF技術框架開發，蘇寧SNF框架基于MAVEN項目管理，提供各種的骨架組件。在這些骨架組件中，基本的依賴和基本設置都在模板中做好，無需各項目重復工作。本框架也包括了基本的項目框架結構和各種基本設置，同時也集成了蘇寧框架組統一的日志記錄、異常捕獲、數據訪問等蘇寧自己的基礎組件。

項目組在SNF框架的基礎上，進行少量的裁剪和擴充就可以進行開發，既能統一項目設置和架構，又能大量節省開發人員搭建框架的時間。

開發環境

STS+Maven+SVN +JDK1.7+JBoss。

分布式服務框架RSF

系統提供的核心的服務接口均采用蘇寧自研的RSF框架實現，RSF框架 解決了分布式系統間的服務調用問題，提供一種透明的、高性能的RPC服務調用方案。

主要功能：

支持同步、異步Future、異步Callback三種客戶端調用模型；

支持TCP協議及Hessian、JSON、KRYO序列化機制；

服務節點的自動注冊和發現;

多種負載均衡方式;

服務路由;

容錯重試機制；

流控，熔斷等機制；

統一的服務配置管理，支持配置的動態修改。

總體架構：

系統面臨的挑戰及應對

雖然系統采用了SNF框架，基于蘇寧組件和基礎設施，搭建了高并發的分布式架構，但隨著蘇寧易購電商業務高速發展，訂單屢創新高的背景下，系統依然面臨一些挑戰：

擴展痛點：受限于數據庫的連接數瓶頸、Redis服務器的連接數瓶頸等因素，導致應用集群無法無限擴展；

機房容災及機房容量：機房斷電，電纜被挖，造成整個蘇寧易購交易系統癱瘓；單個機房容量受限，無法創建更多的服務器；

熱點瓶頸：雖然通過構建緩存化支持能力服務，但單個商品的并發查詢和扣減仍然存在上限

為了解決上述問題，我們啟用了應用的本機分布式緩式，并在公司規劃下正在進行多活架構構建。

應用服務器內存緩存

我們通過Ehcache框架，對于一些配置主數據和能力總量在應用服務器進行內存緩存，從生產壓測情況來看效果明顯，在不新增服務器的條件下tps成倍增加，redis熱點消失。

后續也計劃對于已約數量等實時能力數據，通過分布式緩存實現共享，以進一步提升單個商品并發查詢和扣減的熱點瓶頸。

多活架構

目前ASAP系統在公司統一部署下實現了多活的支持，在多個機房之間建立數據庫和Redis緩存數據的準實時同步，支持多個機房間的流量切換，當A機房出現故障，可由B機房完全接管，具體多活的生產應用還在聯調中。

雙11等大促活動保障

經過兩年多的大促實戰，基本形成了事前、事中、事后完整的大促保障工作機制，工作項標準化，越來越細致，組織上有專人牽頭負責具體工作項事務，形成了完整的閉環。

容量和性能評估

對公司雙11大促的 活動預告及銷售目標進行詳細評估和分解，轉化成ASAP系統的核心服務的SLA，確定庫存系統的核心服務的TPS目標。

性能壓測達標

大促前，我們會進行多輪的生產壓測，最重要的是單系統的接口壓測和端到端全鏈路壓測。通過單系統服務接口壓測，我們排除接口潛在的性能瓶頸并針對性的優化，能夠清楚認識負責系統的單接口所能支持的并發上限；通過生產真實流量回放的端到端全鏈路壓測平臺，進行全鏈路的生產壓測，發現真實流量下的系統壓力情況，和資源情況，提前發現性能瓶頸和潛在的系統風險。性能測試是大促籌備最為關鍵的一環。

系統健康體檢

提前對系統的各方面進行全面的健康檢查，比如db磁盤的容量、連接數、topsql，緩存的內存使用率、并發命令數和連接數，消息隊列的連接數，各節點的cpu負載情況，排除單點故障，排除虛擬機的資源爭用問題，排除高可用問題（同一物理機多應用節點）等。

機器擴容

基于容量預估出來的各服務接口的TPS目標，根據壓測結果評估系統的服務器是否需要擴容，比如jboss集群是否需要擴容，redis集群是否需要擴容，數據庫服務器性能是否有足夠等。

梳理流控與降級方案

所有服務接口需要設定合理的流控閥值，以確保系統不會掛死；梳理所有接口的調用系統和業務場景并明確業務的優先級，假設系統因為某服務導致性能出現瓶頸，根據業務優先級逐步調整流控閥值；業務流控或系統流控要實現用戶的友好提示；對于依賴系統，如果出現超時或宕機，則定義降級策略，確保服務請求的快進快出。

作者：汪成偉，蘇寧易購IT總部物流研發中心技術總監，目前負責蘇寧物流研發中心售后相關系統的架構與開發管理工作，具有十多年互聯網一線研發及管理經驗。曾負責過B2C電商平臺、移動新聞資訊平臺，用戶上網行為分析大數據平臺及O2O社交應用的研發工作。是DevOps的踐行者，在企業應用架構設計、高并發系統設計、大促保障、研發過程管理、穩定性治理、安全開發上有豐富的經驗。

總結

以上是生活随笔為你收集整理的苏宁大促高并发要求下的售后服务运营能力承诺服务系统架构实战\n的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。