京東話費充值系統(tǒng)架構演進實踐

背景：

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

1、應用層面

引入緩存

在應用層和數(shù)據(jù)庫層增加緩存層：熱點數(shù)據(jù)放入緩存。

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

系統(tǒng)結構優(yōu)化：

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

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

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

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

讀寫分離

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

變化頻率低的頁面靜態(tài)化

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

2. 數(shù)據(jù)庫層面（當業(yè)務量發(fā)展到一定程度后，數(shù)據(jù)庫就會成為系統(tǒng)的瓶頸）

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

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

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

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

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

3應用部署

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

版本發(fā)布

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

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

總結

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

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