蘇寧11.11：系統拆分的一些經驗談

「平京戰役」一發布使原本就熱鬧的電商促銷大戰嗆出了火藥味，也爲雙11的大促增添了許多談資，更讓消費者享受到實實在在的優惠。而在技術上這種競爭則溫和許多。

技術上的壓力來源於業務的需求。蘇寧阿里戰略合做後，易購贏得了社會的普遍關注，系統的流量在蘇寧的傳統促銷節8.18顯現出來；加上蘇寧的雙11銷售目標，使得咱們系統承擔的壓力更大了。

技術上的準備不是一蹴而就的，尤爲像易購這樣的大系統，更須要長期的積累和演變。歷經多年的大促，目前蘇寧在技術線上的準備變得也很是清晰和嚴謹。接下來咱們將分享下在系統拆分、基礎平臺、研發流程和系統保障四個方面的經驗。

另，ArchSummit全球架構師峯會北京站將於2015年12月18日~19日在北京國際會議中心召開，大會設置了《揭祕雙十一背後的技術較量》專題來深刻解讀雙十一背後的技術故事，歡迎關注。

1、 系統拆分方面

目前蘇寧易購在線業務有至關多的系統，不少系統的TPS（每秒鐘的請求數量）都很是高，並且作到了水平擴展。這些都是不斷拆分和重構的結果，幾年之前則是另外一番景象。

之前蘇寧易購的主站系統都在基於IBM的Commerce開發的B2C平臺上。爲了方便擴容，線上獨立部署了不少套這樣的系統。當用戶瀏覽時，會根據用戶ID選擇其中的一個系統。這個系統很是龐大，它包含了全部的業務代碼、單個包超過幾百MB、啓動時間很是長、部署這樣的系統花費了更多時間。每當大促來的時候，秒殺、搶購和正常的交易蜂擁而至，宕機就在所不免了。駕馭龐大的系統意味着高超的能力，大牛也許可以輕鬆地理清各類邏輯關係，可是對普通工程師而言變有至關難度。修改頻繁出錯、那種錯牽一髮而毀全身的痛使得工程師們對業務的變動畏手畏腳。大促中的幾回宕機、新業務難以在老系統上擴展促使咱們走上了系統拆分的道路。

進行系統拆分是須要充分準備的，沒有一個合理的規劃只會讓系統的職責扯不斷、理還亂，外加各類抱怨。系統拆分要分析主流程、分離主幹系統和枝葉系統、把主幹系統根據業務的內聚性獨立出來，作到分別部署。咱們分析了電商的主要功能和重運營的特色。咱們根據業務功能拆分了幾大核心系統：會員、商品、庫存、價格、購物車、交易、訂單和內容管理等，而且組建了對應的研發中心來維護。根據交易環節的系統壓力，獨立出搶購和秒殺系統，還拆分出購物券、雲鑽等營銷類的系統，並組建了營銷中心。

系統職責明確了，可以獨立發佈了，進而快速響應新業務。系統變小了，新人只要瞭解不多的邏輯就能上手，並且模塊小了、關注度高了，新人更能深刻了解和優化系統。

2、 基礎平臺方面

系統拆分只是把系統的職責理順了，接踵而來的是系統間的通信問題和各個系統重複造輪子的問題。針對這些問題，蘇寧成立了基礎研發中心。基礎研發中心屬於一級中心，這也顯示了蘇寧對基礎研發的重視。

蘇寧的基礎平臺主要集中解決了如下方面的問題：基礎架構方面包括自建CDN、雲計算和雲存儲；通用系統方面包括短信、郵件、驗證等系統；系統集成包方面括系統之間的通信、統一驗證和內部管理系統的統一權限；中間件方面包括Session共享、分佈式調用鏈、Redis分片存儲、數據庫的分庫分表中間件、統一配置管理和流控；平臺方面：運維監控平臺，持續集成平臺，大數據分析平臺；還有針對安全的風控系統等。由於內容繁多，這裏選取其中幾個作簡要介紹。

雲計算平臺、雲存儲平臺已經成爲互聯網的標配。雲計算平臺提供了KVM、Docker的中間件服務，用來部署着蘇寧大量的系統。雲存儲存支持文件存儲和對象存儲兩種方式，支撐着蘇寧的海量存儲需求。

蘇寧易購內部通信方式主要有兩套系統：MYESB和RSF。 MYESB是一個安全的集中消息轉發服務系統，提供了同步和異步兩種服務接口。其中同步基於HTTP+XML，異步基於MQ。RSF相似阿里的Dubbo，提供遠程調用的機制，支持HTTP和TCP通信服務。它的優勢是使消費方直接調用服務方，不須要像MYESB須要代理轉發，減小了系統延遲。 RSF的TCP通信是長鏈的，能夠減小網絡開銷。因爲歷史的緣由蘇寧有不少異構的系統，這些系統一般須要MYESB來解決異構環境通信問題；通常系統內部都是用RSF做爲通信方式。

持續交付平臺主要包括了代碼基礎框架自動生成、代碼質量分析、代碼的自動化部署和代碼權限管理。有了上面的準備，構建一個新系統就變得容易起來。

監控是系統的眼睛，尤爲是針對線上的系統。監控能讓咱們知道系統的運行狀態，在系統出問題時，也能讓咱們知道系統那時發生了什麼。目前採集監控數據的手段基本都是定時採樣、日誌收集分析和及時消息觸發。分析監控數據手段基本上有實時和離線兩種。實時監控分析偏重於實時性，分析的緯度有侷限性；離線的監控分析系統偏重於一些定製統計和分析，可以對系統作出比較全面的分析。蘇寧的監控平臺包括了對硬件資源、操做系統、中間件以及業務系統的監控。蘇寧目前有實時日誌系統，偏向分析的LogMonitor系統以及針對移動端的監控系統。實時日誌分析系統基於ELK技術, 能夠實時監測請求狀態、系統錯誤和進行多維度查詢分析；LogMonitor能夠統計分析接口最大、平均處理時間和歷史接口的性能對比；新上線的CloudyTrace能更好地識別tp90、tp99等高級功能。

目前蘇寧自建的CDN服務承擔的流量也至關的多。當流量比較大的時候，自身的業務會受到第三方CDN的質量和價格約束。選擇自建也是大型電商系統選擇的必經之路。

當基礎平臺解決了共性問題後，上層業務系統只須要集中關注業務領域。這樣一來業務系統開發的週期大大縮短，因此蘇寧不少系統的開發週期都很短。當基礎平臺支撐能力越強，它爲業務系統提供的可擴展性、可靠性、性能就越好，也可以保證業務系統的飛速發展，從而使業務真正站在巨人的肩上。從以往的資料來看，阿里、京東的業務和人員也都是在創建了基礎平臺以後快速發展起來的。

3、 研發流程

近兩年蘇寧進入了快速發展期，各類系統不斷地被拆分和研發。僅消費者研發中心就有上百個系統，各個系統的質量良莠不齊。越靠近用戶端的系統，越容易成爲用戶反饋和抱怨的密集地。如何把控系統的質量？對此，中心在研發流程上下了大力氣。總結起來就是在關鍵的研發點制定了對應的檢查單和組織會議對其檢查。 

經得起推敲的產品纔是好產品。對於產品的評審，力度也是至關大。不單是對產品需求，大到產品的運營指標，小到產品的文字都會反覆評審。

經過架構設計模版和設計檢查單，確保這些問題在設計系統時候都認真思考過。這樣一來架構設計變得簡單、有序。

除了經過代碼走查、sonar平臺、各類測試等手段，中心也採用代碼飛檢來確保代碼質量。 代碼飛檢就是按期快速評審系統的核心代碼。與面向項目組內的代碼走查不一樣的是參加代碼飛檢人員的級別比較高，都是各個系統負責人、架構師以及總監。當各個系統裸露在你們面前的時候，系統的美與醜很容易被區分出來。經過這種方式，咱們發現了不少優秀的代碼，也發現了幕後的高手。意想不到的效果是優秀的人才很快浮出水面，而不是靠挖掘了。

流程發佈檢查單是系統的最後一關，它須要通過產品負責人、開發負責人、QA、測試負責人、DBA、運維人員和線上驗證人員對各個環節進行確認，讓系統上線過程少出問題，出現了問題也能及時下架。 

其實不少公司有這樣的流程，可是受抵觸情緒或者投入力度不夠的影響，不免流於形式。而經驗告訴咱們，這些實踐起來真的不難，並且很是有效。

4、 系統保障方面

雙11期間，除了開發新業務， 咱們主要的工做就是確保系統可以頂住流量的壓力。爲此咱們作了兩手準備：一個是提升系統的負載能力，另外一個就是作應急預案准備。

系統的壓力來自流量。 首先咱們根據歷史數據對雙11的流量進行了預估，細化到每一個系統的PV、UV、峯值TPS，要求每一個系統要努力達到這些指標。而後咱們對目前系統的壓力、容量和相關指標進行統計，按照預期的流量判斷系統的服務是否知足要求。若是不知足就須要經過優化和擴容來完成，能優化則優先經過優化解決，由於擴容意味更多的服務器資源。

優化方面，咱們對系統進行自上而下的體檢，針對體檢發現的問題制定了相關的方案。具體是對系統架構梳理、關鍵代碼優化以及中間件調優。

好的架構能夠節約不少資源。架構梳理主要對重點業務的處理流程和處理的鏈路進行審覈。系統依賴問題是咱們常常遇到，一個系統常常依賴多個系統，一個業務須要屢次調用第三方服務，流程鏈至關長。有時候這種依賴不是必須的，能夠經過依賴調用改爲第三方主動推送數據來消除這種依賴。

在壓測過程當中，咱們常常發現接口的性能不夠高。主要是由於長長的調用鏈、不分層次壘代碼、沒有良好的處理模型。不少人由於經驗和時間的緣由，驗證完功能就認爲搞定了，形成性能有很大的問題，更別說可擴展性和可維護性。作代碼優化要靜下心來，深刻了解業務特色，構建優化方案。消息推送系統是咱們重點優化的一個系統。咱們對其進行了改造：從數據庫中取用戶列表，改爲把用戶列表存儲在Redis緩存中，性能一會兒提升不少；之前都是一股腦的隨機發送，如今則是首先推送重點城市，保證重點城市的用戶在幾分鐘內接收到數據。

中間件主要針對JVM策略、各類連接池、系統連接數、緩存和讀寫分離作一些調正。經過壓測最容易找到性能的瓶頸，爲了讓數據更真實，重要系統在夜深人靜的時候還在生產系統上直接壓測，幫助了咱們快速發現系統的真實能力和系統瓶頸。優化和測試驗證是個反覆的過程，這期間的過程也至關辛苦。

系統若是可以按照預期流量來，咱們大部分系統是能夠支撐的。但問題是你不清楚實際會來多少，尤爲是峯值的時候；並且這些流量除了正經常使用戶的訪問流量，還有一些異常的流量。爲此咱們準備了應急預案和相應的操做手冊。咱們的應急預案主要包括幾個方面黑名單、限流和降級。

黑名單主要是拒絕惡意的系統訪問，如：IP黑名單、用戶黑名單。

限流則是在流量超過系統負載警惕線時，主動丟棄相關的請求，以保全系統。如今的系統的都是分層部署的，限流能夠經過防火牆流控功能、中間件的流控功能和流控組件來實現。蘇寧的流控組件還支持IP、用戶、URL三個緯度來控制的訪問頻度，以防止過分請求。

降級可讓系統臨時承擔更大的流量壓力。咱們常常經過下面策略進行降級：屏蔽非關鍵業務的入口、關閉影響性能非關鍵業務功能、頁面靜態化、開啓驗證碼策略延緩系統壓力、延長緩存的時間犧牲實時性、放棄後端的補償機制以減小調用鏈時間等。在多大壓力的狀況下開啓什麼的降級策略，須要再定義和演練。在實踐過程當中，咱們定義了不一樣級別的降級策略、每一個級別對應不一樣的流量壓力。

另外很重要的一點是這些應急預案必定要演練，不然預案就變得不可靠，也極有可能出現重大問題。

技術上的準備要經得起考驗。雙11就要到了，正是咱們大考的時候，咱們將嚴陣以待，確保系統平穩運行。雙11以後，相信有更多的文章和數據會分享出來，讓你們更多瞭解咱們是如何一路走來的。

http://www.infoq.com/cn/articles/suning-11-11-system-split-experience