劉慎寶：京東財務研發部架構師，主要負責財務研發部的基礎組件和各系統技術方案支持，10+年互聯網研發專家。

2010年入職京東并歷經幾乎所有618和雙11挑戰。精通高并發服務搭建和業務建模，曾多次主導京東財務系統架構升級和數據庫升級，主導結算魔方重構，訂單臺賬優化、價保優化等重大研發項目，對財務系統有深刻理解。

引言

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

?

首先：守住你的底線

• 底線？單體實例的最大處理量

• 單體實例？泛指單個應用實例、單個緩存實例，單個存儲實例

• 底線從何而來？壓測

• 底線恒定不變？隨著服務的架構變化隨時調整

  如：一個實例【java實例+DB】的處理峰值為500/秒，在緩存化數據后處理峰值可以調整的5000/秒，但是緩存異常情況下，系統降級，那峰值必須要回到500/秒。

• 守不住底線？打怪如同碰見一個大 BOSS，經由負載均衡一個個秒掉你的服務，最終全局502

• 怎么守住底線？限流、限流、限流！

• 限流：一個系統穩定的最底層的護城河，永遠不要輕視它。

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

  如我們的限流拆分：

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

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

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

?

其次：不斷提高底線

提高單位處理量

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

常用手段：

• 網站靜態流量分流：頁面靜態化、APP本地緩存、CDN分發

• 數據緩存化：配置性數據本地預加載緩存，熱點數據redis預加載緩存[注意：緩存也是吞吐量閥值和容量閥值]

• 流程簡化：收單流程和生產流程拆分

• 請求流量清理：啟用gzip壓縮、ajax清理掉多余的數據信息

無狀態化

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

對內依賴數據的多源化

對上游實現無依賴化

對下游實現數據的自動傳遞

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

最后：統籌變化，橫向擴展

1、監控為眼

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

2、流程優化

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

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

3、橫向擴展

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

?

系統練級標準

1、單實例不死

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

2、分類型限流

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

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

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

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

4、外部依賴無感化

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

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

總結

以上是生活随笔為你收集整理的系统练级攻略 | 京东架构师倾情解读的全部內容，希望文章能夠幫你解決所遇到的問題。

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