oms（訂單管理系統）是電商
erp系統中的核心模組，其中的訂單履行流程（履單流程）是消費者購物過程中有直接感知的最後一段，關係到使用者體驗，其正確性和時效性必須得到保證。同時履單流程也是電商系統中直接面對銷售高峰帶來的短時間內劇增的資料量的子系統之一，如何在流量驟增
10倍甚至更多的情況下保證
oms的正常服務，是每一家電商密切關注和不斷改進的重點。
與前端接單流程不同，履單流程無需提供秒級實時響應，但它要執行的工作不單是生成訂單儲存入庫，而要協調erp中諸多子系統、外部系統及人工處理，共同完成乙個訂單的出庫發貨，因此面臨的問題和需要的解決方案都有所區別。
在麥包包，我們經歷了一小時接單峰值從千級到萬級再到十萬級的高速增長，雖然oms中有中間表、分頁批處理等抗衝擊設計，但在一年比一年高的流量峰值衝擊下，仍不時出現阻塞甚至崩潰的跡象，讓人膽戰心驚。為解決這個問題，需要對整個履單流程所有環節進行分析，找出瓶頸和浪湧威脅，制定有針對性的解決方案，進行評估和測試，明確系統的峰值處理能力，保證在各種情況下的正確處理。
履單流程的流量治理同洪水治理道理相似，要找出高水位或者決堤的位置進行加固。加固的方法可以分為兩個方向：
疏通和拓寬河道——優化演算法、合理並行；
蓄水限流——非同步、緩衝、限量。
關注點：一致性、可用性和峰值處理能力。
最低目標：流量不高於每小時10萬單情況下，能夠保證每個無須人工確認訂單
30分鐘內提交揀貨；流量不高於每小時
100萬單情況下，能保證每個訂單最慢在
6小時內提交揀貨。
高階目標：流量高於每小時10萬單時能動態提公升吞吐能力，在流量不高於
15萬單情況下保持每個訂單
30分鐘內提交揀貨。
在討論治理方案之前，我們需要將流程抽象和分解，進行深入分析。
流程節點分析
要保證系統在流量暴增的情況下正常提供服務，整個流程不能有任意一點產生阻塞。所謂阻塞點是直接或間接造成某個共享計算資源超負荷的點。電商oms中，
cpu和記憶體的密集計算一般不多，這個超負荷的計算資源多為
db server
。到底是哪一種型別的計算資源並不是最重要的，我們需要先找到引發或可能引發超負荷的原因，再找到其所在程式位置去解決。
履單流程從業務邏輯上一般分為前後銜接的多個步驟，我們將其稱為處理節點，我們要做的就是分析流程中各個處理節點，特別是以往產生過阻塞的節點。分析時除了一般性的**、資料結構的靜態分析和單元測試，對產生過阻塞的節點還可以從現場日誌入手去分析。例如，對於db server超負荷的情況，要分析阻塞現場的
sql佇列，找到引起
db server
資源超載的主要幾條
sql，再順藤摸瓜找出觸發這些
sql的**位置和其所屬的處理節點。
麥包包的履單主流程包括訂單審核、支付確認、出庫單生成、快遞匹配等節點，簡化的流程如圖1所示。
通過**和執行日誌分析，我們發現訂單人工審核、物流匹配耗時較長，訂單的自動審核缺乏流量控制等問題。流程中節點耗時過長不僅會對整個流程的執行時間有直接影響，更重要的是當大量訂單湧入時可能堆積過多的資料庫慢查詢，造成資料庫併發過高、超負荷。人工訂單審核雖然不是自動流程的一環，但由於和自動流程訪問相同的資料庫，在面臨大量訂單時同樣也會拖慢資料庫效能，造成大量的鎖。
基本處理能力優化（單節點優化）
流程由乙個個處理節點組成，如果各節點本身還有優化的餘地，那麼整體分析就難以把握最優方向。因此在流程級優化之前應該先對各個節點進行優化，確保計算處理本身已足夠高效，也包括資源的合理使用和每個節點在架構上的可伸縮性。
流程整體調優前，首先要消除各個節點的執行效率瓶頸，做演算法優化，提高並行效率，減輕或合理分布計算資源的占用。
以針對som（銷售訂單管理）模組進行的優化為例，優化前
som模組的平均請求響應時間為
1.89
秒，優化後降低到了
0.09
秒。優化後單伺服器每分鐘可響應請求
667次，而優化前只有
32次左右，在系統架構和硬體資源不變的前提下，提高了節點的處理能力，降低了資源的占用。
做單節點的優化，主要側重於邏輯優化、演算法優化和**優化等。這個話題已被討論很多，基本原則如下。
優化演算法，選擇合適高效的演算法，降低不必要的遞迴、迴圈、多層迴圈巢狀等計算。用簡單的演算法完成大部分情況，不要為少數特例而將演算法複雜化。特例由特殊的分支處理。
避免申請過多不必要的記憶體開銷。
及時釋放資源，降低資源占用時間，包括記憶體、i/o、網路和資料庫等。
善用快取：快取常用的、不易變化的；偶有變化，可以考慮快取依賴機制。
慎用資料庫鎖。
恰當地使用事務，事務要細粒度。
選擇適當的通訊方式：socket、
remoting
、web services
（rest
和soap
）、wcf
、 named pipes
等，要特別注意長連線和短連線的恰當使用。
計算並行化。
降低系統或模組之間的通訊次數，例如工作流服務和資料庫服務。
降低系統或模組之間的傳輸資料量，不必要傳輸的不傳或少傳。
非同步計算，降低等待時間。
考慮延遲載入和提前載入兩種方式。
分離原則：分離業務模組，如分離大i/o模組、分離高耗記憶體模組和分離高耗寬頻模組。
統籌使用計算資源，如尋求記憶體計算、資料庫計算和網路開銷三者之間的最佳平衡。
在單節點優化中，以上方法都可能用到。而對於履單流程來說，計算並行化和節點伸縮性也會起到比較重要的作用。
閱讀心得9 《京東峰值系統設計 》
京東，我們都不陌生，作為第二大電商平台，已成為我們購物電子產品的最佳選擇。2013年5月6日，京東 在完成內測後，正式與消費者見面，使用者可在京東上購買食品飲料 調味品等日用品。此次京東將超市搬到線上，也是京東在 一站式購物平台 戰略布局上的又一次發力。讓消費者足不出戶，就能輕鬆實現 打醬油 買啤酒...
蘇寧安全架構演進及實踐 閱讀心得
蘇寧安全服務平台 主要是為蘇寧內部所有系統提供各類安全服務，包括漏洞掃瞄 滲透測試 系統加固 安全培訓等 蘇寧安全應急響應中心 主要負責漏洞管理和威脅情報收集，以幫助提公升蘇寧自身產品及業務的安全性，同時也希望藉此加強與安全業界的合作與交流。平時為了吸引消費者，蘇寧易購經常會送大家很多各類優惠券，也...
軟體架構實踐閱讀筆記02
軟體架構實踐在一到三章講述了一些概念內容以及例項，比如什麼是架構，架構的重要性和評判架構的準則等等。同樣，作為書的第一部分，它介紹了架構的商業週期，是分析軟體架構的基礎。而第二部分講述的就是設計師如何建立構架。概括的說，因為質量屬性的實現對系統的成功至關重要，因此我們開始對質量屬性以及設計師如何借助...