引言

系統搭建，小有小的靈活，大有大的難處，從小到大，系統該怎么打怪練級呢?

首先：守住你的底線

• 底線?單體實例的***處理量
• 單體實例?泛指單個應用實例、單個緩存實例，單個存儲實例
• 底線從何而來?壓測
• 底線恒定不變?隨著服務的架構變化隨時調整
• 如：一個實例【java實例+DB】的處理峰值為500/秒，在緩存化數據后處理峰值可以調整的5000/秒，但是緩存異常情況下，系統降級，那峰值必須要回到500/秒。
• 守不住底線?打怪如同碰見一個大 BOSS，經由負載均衡一個個秒掉你的服務，最終全局502
• 怎么守住底線?限流、限流、限流!
• 限流：一個系統穩定的***層的護城河，永遠不要輕視它。

線上的情況千變萬化，交易峰值你可以規劃，但是異常流量永遠不可預測

如我們的限流拆分：

• 調整線上限流依據?監控，分流監控

監控的力度也是根據限流層次同步細化

PS：我們搭建了一個流量分析平臺，通過接入系統，可以通過自定義規則定義流量拆分報表，并且實現精細化流量控制

其次：不斷提高底線

1. 提高單位處理量

優化數據結構和使用緩存等手段，提升單體實例的***吞吐量。

常用手段：

• 網站靜態流量分流：頁面靜態化、APP本地緩存、CDN分發
• 數據緩存化：配置性數據本地預加載緩存，熱點數據redis預加載緩存[注意：緩存也是吞吐量閥值和容量閥值]
• 流程簡化：收單流程和生產流程拆分
• 請求流量清理：啟用gzip壓縮、ajax清理掉多余的數據信息

2. 無狀態化

高內聚，低耦合，將應用+DB打包成一個對外可擴展的服務模塊，標準有三：

• 對內依賴數據的多源化
• 對上游實現無依賴化
• 對下游實現數據的自動傳遞

價保系統流程處理中心樣例：

***：統籌變化，橫向擴展

1. 監控為眼

統籌變化，首先要對系統的流量情況了若指掌，是通過監控系統來實現的。

2. 流程優化

只有簡單的業務流程才是穩定可靠的，將業務流程和接單流程拆分，針對性配置資源，才能實現性能和資源的靈活安排。

針對現在的微服務化，要根據系統所處階段靈活拆分，任何過度設計都會導致開發量和運維量飆升，最終影響系統的穩定性。

3. 橫向擴展

集群化計算中心【容器+DB】，橫向擴容縮容，外部依賴異常可靈活切換。

系統練級標準

1. 單實例不死

通過DB限流和應用限流，保證單實例在大流量下沖擊下，會出現服務性能變差，但是不會死掉。

2. 分類型限流

在細化監控基礎上，針對不同業務不同流程配置不同的限流閥值，保證異常流量可監控，可阻截，高效的提供正常服務。

3. 集群擴展【DB+實例】

將DB和實例打包成一個集群，可以根據服務流量動態調整擴容縮容。

該集群具備標準：對上游通過接口擴容，數據流內部自我驅動流轉，對下游主動同步。

4. 外部依賴無感化

簡而言之就是外部依賴接口掛掉不影響系統的核心功能，通過將相關依賴數據預抓取實現熱數據備份，保證接口掛掉后自我降級，保證服務的可用性。

每個階段都是應該隨著系統的流量的增加，逐級優化，反之就是過度設計，導致研發和線上運維成本等上升，反而影響系統穩定性。

劉慎寶：京東財務研發部架構師，主要負責財務研發部的基礎組件和各系統技術方案支持，10+年互聯網研發專家。2010年入職京東并歷經幾乎所有618和雙11挑戰。精通高并發服務搭建和業務建模，曾多次主導京東財務系統架構升級和數據庫升級，主導結算魔方重構，訂單臺賬優化、價保優化等重大研發項目，對財務系統有深刻理解。

【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】

戳這里，看該作者更多好文