「平京戰役」一發布使本來就熱鬧的電商**大戰嗆出了火藥味，也為雙11的大促增添了許多談資，更讓消費者享受到實實在在的優惠。而在技術上這種競爭則溫和許多。
技術上的壓力**於業務的需求。蘇寧阿里戰略合作後，易購贏得了社會的廣泛關注，系統的流量在蘇寧的傳統**節8.18顯現出來；加上蘇寧的雙11銷售目標，使得我們系統承擔的壓力更大了。
技術上的準備不是一蹴而就的，尤其像易購這樣的大系統，更需要長期的積累和演變。歷經多年的大促，目前蘇寧在技術線上的準備變得也非常清晰和嚴謹。接下來我們將分享下在系統拆分、基礎平台、研發流程和系統保障四個方面的經驗。
另，archsummit全球架構師峰會北京站將於2023年12月18日~19日在北京國際會議中心召開，大會設定了《揭秘雙十一背後的技術較量》專題來深入解讀雙十一背後的技術故事，歡迎關注。
以前蘇寧易購的主站系統都在基於ibm的commerce開發的b2c平台上。為了方便擴容，線上獨立部署了很多套這樣的系統。當使用者瀏覽時，會根據使用者id選擇其中的乙個系統。這個系統非常龐大，它包含了所有的業務**、單個包超過幾百mb、啟動時間非常長、部署這樣的系統花費了更多時間。每當大促來的時候，秒殺、搶購和正常的交易蜂擁而至，宕機就在所難免了。駕馭龐大的系統意味著高超的能力，大牛也許能夠輕鬆地理清各種邏輯關係，但是對普通工程師而言變有相當難度。修改頻繁出錯、那種錯牽一髮而毀全身的痛使得工程師們對業務的變更畏手畏腳。大促中的幾次宕機、新業務難以在老系統上擴充套件促使我們走上了系統拆分的道路。
進行系統拆分是需要充分準備的，沒有乙個合理的規劃只會讓系統的職責扯不斷、理還亂，外加各種抱怨。系統拆分要分析主流程、分離主幹系統和枝葉系統、把主幹系統根據業務的內聚性獨立出來，做到分別部署。我們分析了電商的主要功能和重運營的特點。我們根據業務功能拆分了幾大核心系統：會員、商品、庫存、**、購物車、交易、訂單和內容管理等，並且組建了對應的研發中心來維護。根據交易環節的系統壓力，獨立出搶購和秒殺系統，還拆分出購物券、雲鑽等營銷類的系統，並組建了營銷中心。
系統職責明確了，能夠獨立發布了，進而快速響應新業務。系統變小了，新人只要了解很少的邏輯就能上手，而且模組小了、關注度高了，新人更能深入了解和優化系統。
系統拆分只是把系統的職責理順了，接踵而來的是系統間的通訊問題和各個系統重複造輪子的問題。針對這些問題，蘇寧成立了基礎研發中心。基礎研發中心屬於一級中心，這也顯示了蘇寧對基礎研發的重視。
蘇寧的基礎平台主要集中解決了以下方面的問題：基礎架構方面包括自建cdn、雲計算和雲儲存；通用系統方面包括簡訊、郵件、驗證等系統；系統整合包方面括系統之間的通訊、統一驗證和內部管理系統的統一許可權；中介軟體方面包括session共享、分布式呼叫鏈、redis分片儲存、資料庫的分庫分表中介軟體、統一配置管理和流控；平台方面：運維監控平台，持續整合平台，大資料分析平台；還有針對安全的風控系統等。因為內容繁多，這裡選取其中幾個做簡要介紹。
雲計算平台、雲儲存平台已經成為網際網路的標配。雲計算平台提供了kvm、docker的中介軟體服務，用來部署著蘇寧大量的系統。雲存儲存支援檔案儲存和物件儲存兩種方式，支撐著蘇寧的海量儲存需求。
持續交付平台主要包括了**基礎框架自動生成、**質量分析、**的自動化部署和**許可權管理。有了上面的準備，構建乙個新系統就變得容易起來。
監控是系統的眼睛，尤其是針對線上的系統。監控能讓我們知道系統的執行狀態，在系統出問題時，也能讓我們知道系統那時發生了什麼。目前採集監控資料的手段基本都是定時取樣、日誌收集分析和及時訊息觸發。分析監控資料手段基本上有實時和離線兩種。實時監控分析偏重於實時性，分析的緯度有侷限性；離線的監控分析系統偏重於一些定製統計和分析，能夠對系統做出比較全面的分析。蘇寧的監控平台包括了對硬體資源、作業系統、中介軟體以及業務系統的監控。蘇寧目前有實時日誌系統，偏向分析的logmonitor系統以及針對移動端的監控系統。實時日誌分析系統基於elk技術, 可以實時監測請求狀態、系統錯誤和進行多維度查詢分析；logmonitor可以統計分析介面最大、平均處理時間和歷史介面的效能對比；新上線的cloudytrace能更好地識別tp90、tp99等高階功能。
目前蘇寧自建的cdn服務承擔的流量也相當的多。當流量比較大的時候，自身的業務會受到第三方cdn的質量和**約束。選擇自建也是大型電商系統選擇的必經之路。
當基礎平台解決了共性問題後，上層業務系統只需要集中關注業務領域。這樣一來業務系統開發的週期大大縮短，所以蘇寧很多系統的開發周期都很短。當基礎平台支撐能力越強，它為業務系統提供的可擴充套件性、可靠性、效能就越好，也能夠保證業務系統的飛速發展，從而使業務真正站在巨人的肩上。從以往的資料來看，阿里、京東的業務和人員也都是在建立了基礎平台之後快速發展起來的。
近兩年蘇寧進入了快速發展期，各種系統不斷地被拆分和研發。僅消費者研發中心就有上百個系統，各個系統的質量參差不齊。越靠近使用者端的系統，越容易成為使用者反饋和抱怨的密集地。如何把控系統的質量？對此，中心在研發流程上下了大力氣。總結起來就是在關鍵的研發點制定了對應的檢查單和組織會議對其檢查。
經得起推敲的產品才是好產品。對於產品的評審，力度也是相當大。不單是對產品需求，大到產品的運營指標，小到產品的文字都會反覆評審。
通過架構設計模版和設計檢查單，確保這些問題在設計系統時候都認真思考過。這樣一來架構設計變得簡單、有序。
除了通過**走查、sonar平台、各種測試等手段，中心也採用**飛檢來確保**質量。 **飛檢就是定期快速評審系統的核心**。與面向專案組內的**走查不同的是參加**飛檢人員的級別比較高，都是各個系統負責人、架構師以及總監。當各個系統裸露在大家面前的時候，系統的美與醜很容易被區分出來。通過這種方式，我們發現了很多優秀的**，也發現了幕後的高手。意想不到的效果是優秀的人才很快浮出水面，而不是靠挖掘了。
流程發布檢查單是系統的最後一關，它需要經過產品負責人、開發負責人、qa、測試負責人、dba、運維人員和線上驗證人員對各個環節進行確認，讓系統上線過程少出問題，出現了問題也能及時下架。
其實很多公司有這樣的流程，但是受牴觸情緒或者投入力度不夠的影響，難免流於形式。而經驗告訴我們，這些實踐起來真的不難，而且非常有效。
雙11期間，除了開發新業務， 我們主要的工作就是確保系統能夠頂住流量的壓力。為此我們做了兩手準備：乙個是提高系統的負載能力，另乙個就是做應急預案準備。
系統的壓力來自流量。 首先我們根據歷史資料對雙11的流量進行了預估，細化到每個系統的pv、uv、峰值tps，要求每個系統要努力達到這些指標。然後我們對目前系統的壓力、容量和相關指標進行統計，按照預期的流量判斷系統的服務是否滿足要求。如果不滿足就需要通過優化和擴容來完成，能優化則優先通過優化解決，因為擴容意味更多的伺服器資源。
優化方面，我們對系統進行自上而下的體檢，針對體檢發現的問題制定了相關的方案。具體是對系統架構梳理、關鍵**優化以及中介軟體調優。
好的架構可以節約很多資源。架構梳理主要對重點業務的處理流程和處理的鏈路進行審核。系統依賴問題是我們經常遇到，乙個系統經常依賴多個系統，乙個業務需要多次呼叫第三方服務，流程鏈相當長。有時候這種依賴不是必須的，可以通過依賴呼叫改成第三方主動推送資料來消除這種依賴。
在壓測過程中，我們經常發現介面的效能不夠高。主要是因為長長的呼叫鏈、不分層次壘**、沒有良好的處理模型。很多人因為經驗和時間的原因，驗證完功能就認為搞定了，造成效能有很大的問題，更別說可擴充套件性和可維護性。做**優化要靜下心來，深入了解業務特點，構建優化方案。訊息推送系統是我們重點優化的乙個系統。我們對其進行了改造：從資料庫中取使用者列表，改成把使用者列表儲存在redis快取中，效能一下子提高很多；以前都是一股腦的隨機傳送，現在則是首先推送重點城市，保證重點城市的使用者在幾分鐘內接收到資料。
中介軟體主要針對jvm策略、各種鏈結池、系統鏈結數、快取和讀寫分離做一些調正。通過壓測最容易找到效能的瓶頸，為了讓資料更真實，重要系統在夜深人靜的時候還在生產系統上直接壓測，幫助了我們快速發現系統的真實能力和系統瓶頸。優化和測試驗證是個反覆的過程，這期間的過程也相當辛苦。
系統如果能夠按照預期流量來，我們大部分系統是可以支撐的。但問題是你不清楚實際會來多少，尤其是峰值的時候；而且這些流量除了正常使用者的訪問流量，還有一些異常的流量。為此我們準備了應急預案和相應的操作手冊。我們的應急預案主要包括幾個方面黑名單、限流和降級。
黑名單主要是拒絕惡意的系統訪問，如：ip黑名單、使用者黑名單。
限流則是在流量超過系統負載警戒線時，主動丟棄相關的請求，以保全系統。現在的系統的都是分層部署的，限流可以通過防火牆流控功能、中介軟體的流控功能和流控元件來實現。蘇寧的流控元件還支援ip、使用者、url三個緯度來控制的訪問頻度，以防止過度請求。
降級可以讓系統臨時承擔更大的流量壓力。我們經常通過下面策略進行降級：遮蔽非關鍵業務的入口、關閉影響效能非關鍵業務功能、頁面靜態化、開啟驗證碼策略延緩系統壓力、延長快取的時間犧牲實時性、放棄後端的補償機制以減少呼叫鏈時間等。在多大壓力的情況下開啟什麼的降級策略，需要再定義和演練。在實踐過程中，我們定義了不同級別的降級策略、每個級別對應不同的流量壓力。
另外很重要的一點是這些應急預案一定要演練，否則預案就變得不可靠，也極有可能出現重大問題。
一些古怪的想法 經驗系統
這兩天陪老婆逛商場很累，但是也累出了一些莫名其妙的想法來。我在想，去商場裡逛，挑衣服，自己去挑的話很費時間，而且一些看上去好看的衣服穿取來卻不好看，有些看上去不好看的衣服，穿上去卻有意外之喜。而對於這個，有經驗的櫃員就可以幫你找到很適合你的衣服，我想她們 厲害的櫃員 肯定是有一套比較成熟的經驗的，比...
debug的一些經驗
1.儘量減少debug，少用debug，優秀的程式設計師總是花80 的時間來思考如何解決問題，20 的時間來動手完成 而糟糕的程式設計師總是用20 的時間去寫 80 的時間去除錯 動手之前盡量想好如何去做，並且已經為你自己的思路做了充分的實驗。2.盡可能的提高debug的效率，設定合適的斷點，使用快...
重構的一些經驗
當我們已經對設計模式倒背如流時，卻往往發現在實際 編寫中有生搬硬套的感覺。設計模式是前人經驗的總結，直接拿來用合不合適呢？這讓我想起了大學一位老師告訴我們的一條學習的道路 知識,理論,智慧型 設計模式是很一種優雅的 智慧型 但對於我們初學者來說還僅僅是留存於文字的 知識 把 知識 融合到自己的開發中...