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

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

引言

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

首先：守住你的底線

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

• 單體例項？泛指單個應用例項、單個快取例項，單個儲存例項

• 底線從何而來？壓測

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

  如：一個例項【java例項+DB】的處理峰值為500/秒，在快取化資料後處理峰值可以調整的5000/秒，但是快取異常情況下，系統降級，那峰值必須要回到500/秒。

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

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

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

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

  如我們的限流拆分：

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

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

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

其次：不斷提高底線

提高單位處理量

優化資料結構和使用快取等手段，提升單體例項的最大吞吐量。

常用手段：

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

• 資料快取化：配置性資料本地預載入快取，熱點資料redis預載入快取[注意：快取也是吞吐量閥值和容量閥值]

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

• 請求流量清理：啟用gzip壓縮、ajax清理掉多餘的資料資訊

無狀態化

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

1. 對內依賴資料的多源化

2. 對上游實現無依賴化

3. 對下游實現資料的自動傳遞

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

最後：統籌變化，橫向擴充套件

1、監控為眼

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

2、流程優化

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

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

3、橫向擴充套件

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

系統練級標準

1、單例項不死

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

2、分型別限流

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

3、叢集擴充套件【DB+例項】

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

該叢集具備標準：對上游通過介面擴容，資料流內部自我驅動流轉，對下游主動同步。

4、外部依賴無感化

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

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