京東話費充值系統架構演進實踐

背景：

話費充值業務線的訂單量也‘水漲船高 ’，同時對系統的各項運行指標要求更高，老的系統架構不足以支撐新的業務量，需要對系統進行升級。

1、應用層面

引入緩存

在應用層和數據庫層增加緩存層：熱點數據放入緩存。

編寫并發處理程序：多任務并發處理，充分利用CPU資源。無依賴關系的多條任務可以并行處理，提高系統處理能力。

系統結構優化：

核心生成流程異步處理，接收用戶訂單和給用戶充值兩個流程異步化處理，提高系統處理能力。拆解大應用，使其微服務化。應用拆解為PC端、Server端、MQ消息處理端、后臺管理端、worker端等五個應用

應用之間功能獨立，依賴公司的RPC框架（JSF）和消息框架（JMQ）進行通信。單個應用的內聚性更高，應用之間的耦合度更低。再實現一個后臺的需求時，開發、測試、部署都只需要關注后臺管理端系統即可，無需再關注其他四個系統。

系統微服務化設計，關鍵點是如何尋找限界。除了可以從功能上進行切分還可以根據關注點上進行拆解為生產端和支撐端，業務場景不同，尋找限界的方法也不相同，關鍵是微服務后單個應用的內聚性更高，應用之間的耦合度更低。

使大系統微服務化的方案有很多種，重點是制定好目標，逐步向目標靠攏。

讀寫分離

實時性要求不高的數據讀取從庫，降低主庫壓力。

變化頻率低的頁面靜態化

頁面上的數據變化的只有廣告位。這種類型的頁面就可以靜態化，定時更新頁面，推送到存儲介質上，nginx配置location，直接讀取頁面，降低后端服務的壓力。

2. 數據庫層面（當業務量發展到一定程度后，數據庫就會成為系統的瓶頸）

話費充值應用包含企業訂單業務和普通用戶訂單業務，正是由于其業務的特殊性，采用了垂直+水平分庫方案。根據業務類型進行垂直切分，不同業務類型訂單數據獨立存儲，同一種業務類型在水平上由多個庫保存。垂直+水平的分庫方案能夠最大限度的降低不同業務類型訂單數據之間的相互影響，提高數據讀寫并發量。

普通用戶訂單業務，根據賬戶PIN進行hash打散可以均勻的分布到每個庫中.

企業訂單業務，每個企業賬戶的訂單量不均，根據本地訂單號進行hash，然后再作為本地訂單號的前綴。創建ERP訂單成功后，同樣需要保存本地訂單號和ERP訂單號的映射關系到JmiDB中，以保證在后續的業務流程中，能夠根據ERP訂單號路由到數據庫。

拆分完成后，有的業務場景需要聚合查詢數據。通用的聚合方案是從每個庫中查詢一頁數據，在內存中根據條件排序，返回一頁數據，如果需要翻頁的話，邏輯更為復雜。話費充值應用采用了第三方存儲，把每個分庫中的訂單數據聚合到ElasticSearch中，查詢聚合數據的場景讀取ElasticSearch。

通用的聚合方案是從每個庫中查詢一頁數據，在內存中根據條件排序，返回一頁數據，如果需要翻頁的話，邏輯更為復雜。話費充值應用采用了第三方存儲，把每個分庫中的訂單數據聚合到ElasticSearch中，查詢聚合數據的場景讀取ElasticSearch。

3應用部署

計算機資源的隔離顯得尤為重要，在JVM內部隔離分為信號量隔離和線程池隔離，Netflix Hystrix插件提供了完美的支持。JD-Peer（多機房公網出口路由系統）中使用了Hystrix對每一個商家進行了隔離。

版本發布

灰度發布，平滑過渡，異常情況下的版本回滾，要確保回滾前的數據在老版本中可用。在保證系統服務正常可用的情況下，進行上述一系列的升級。

轉載于:https://www.cnblogs.com/luohaochi/p/11054420.html

總結

以上是生活随笔為你收集整理的软件架构阅读笔记15的全部內容，希望文章能夠幫你解決所遇到的問題。

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