【51CTO.com原創(chuàng)稿件】背景

蘇寧易購合同數(shù)據(jù)中心系統(tǒng)是蘇寧合同管理系統(tǒng)中的一個子系統(tǒng)，主要為蘇寧價格、結(jié)算、商戶平臺、調(diào)撥等系統(tǒng)提供銷售、扣點、賬期等數(shù)據(jù)，用于指導銷售、賬期結(jié)算、采購流程管庫等。

隨著公司業(yè)務的快速發(fā)展，各系統(tǒng)的調(diào)用量和并發(fā)量明顯增長，現(xiàn)有的合同數(shù)據(jù)服務接口已不能滿足某些系統(tǒng)的性能要求，急需升級和優(yōu)化該服務接口，提高系統(tǒng)的可用性和穩(wěn)定性。

系統(tǒng)面臨兩個緊迫訴求：

1. 接口性能要從原有的并發(fā)量1000TPS提升到10000+TPS以上，滿足高性能。

2. 系統(tǒng)可以橫向擴展，隨著業(yè)務發(fā)展，可以動態(tài)的擴容，滿足可擴展。

問題分析

未改造前的蘇寧合同子系統(tǒng)扣點服務查詢邏輯

如圖：

存在的問題：

1. 大量的連接查庫，造成數(shù)據(jù)庫負載較高

扣點服務查詢業(yè)務邏輯比較復雜，通常一條數(shù)據(jù)調(diào)用需要多次對數(shù)據(jù)庫進行查詢，在調(diào)用量大的時候，經(jīng)常會出現(xiàn)數(shù)據(jù)庫連接不夠，數(shù)據(jù)庫負載過高等問題，給數(shù)據(jù)庫造成很大壓力。

2. 串行化查詢，效率較低

接口調(diào)用的時候，通常是一個報文里包含幾十條數(shù)據(jù)，由于是串行查詢，每條報文都是逐條查詢，導致處理效率較低。

3. 大量的服務調(diào)用，造成服務器壓力過大

現(xiàn)有的4臺Wildfly服務器在并發(fā)量大的時候，每臺機器的壓力都比較大，需要更多的機器來分擔壓力。

改造方案

1. 增加緩存，預先將熱點數(shù)據(jù)放入緩存

(1) 系統(tǒng)最大的問題，就是IO比較密集，服務并發(fā)調(diào)用的時候，需要大量的查詢數(shù)據(jù)庫。我們想到的方案就是能否把一部分數(shù)據(jù)提前計算好，放入緩存，當系統(tǒng)調(diào)用的時候直接從緩存中取。

(2) 考慮到數(shù)據(jù)量比較大，生產(chǎn)環(huán)境有將近10億的數(shù)據(jù)，單臺Redis無法容納這么大的數(shù)據(jù)，需要做分布式存儲。借助蘇寧自研的Zedis分布式緩存來實現(xiàn)對數(shù)據(jù)的存儲。

實現(xiàn)方案：

(1)后臺通過定時任務預先將做過價格的商品(熱點數(shù)據(jù))計算好之后，將結(jié)果數(shù)據(jù)寫到zedis緩存集群中。

(2)有新的熱點數(shù)據(jù)變動的時候，先將緩存數(shù)據(jù)清除，再將數(shù)據(jù)插入庫中，更新該商品緩存狀態(tài)(防止緩存數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)不一致)。

(3)后臺定時任務查詢到緩存狀態(tài)未處理的數(shù)據(jù)重新計算結(jié)果，將最新的數(shù)據(jù)寫入緩存中。

處理流程，如圖：

2. 串行改并行，多線程并發(fā)處理數(shù)據(jù)

(1)調(diào)用扣點服務的報文通常都是實時的，也存在一些批量調(diào)用的數(shù)據(jù)，一個報文存在多條調(diào)用的數(shù)據(jù)，未改造前，整個調(diào)用都是串行的。

如圖：

調(diào)用之前花費的時間是各條數(shù)據(jù)處理時間的總和

(2)多線程改造之后可以并行的處理一個報文的多條數(shù)據(jù)

如圖：

改造后，在后臺維護一個線程池，并發(fā)處理一個報文的多條數(shù)據(jù)，花費的時間是處理時間最長的一條數(shù)據(jù)，處理時間上相較于串行處理有了顯著提高。

3. 橫向擴展服務器，分散壓力

蘇寧易購合同管理數(shù)據(jù)中心子系統(tǒng)是一個分布式系統(tǒng)，天然具備擴展性。隨著調(diào)用量，并發(fā)量的增加，單臺Wildfly服務器壓力增大，為滿足性能要求，根據(jù)壓測結(jié)果，對服務器進行了橫向擴展，從以前的4臺擴容到30臺，分散系統(tǒng)壓力。

4. 改造之后的接口調(diào)用方案

如圖：

接口壓測

改造之后，對扣點服務接口進行了壓測，壓測借助于公司內(nèi)部的蛙測平臺。

壓測環(huán)境

服務器數(shù)量配置

Nginx24C 4G

Wildfly84C 4G

Zedis54C 32G

MySQL58C 16G

測試場景

測試場景1

模擬場景： 無緩存數(shù)據(jù)庫壓測

并發(fā)用戶數(shù)： 8000

測試結(jié)果界面如下：

測試時間： 2018-10-01 22：40：23 ~2018-10-01 22：45：23

事務執(zhí)行總量：2355622次;失?。?次; 成功率：100%

wildfly服務器利用率穩(wěn)定在5%~10%

事務的平均響應時間：624.75ms

TPS：平均 8264.4

測試場景2

模擬場景： 半緩存半數(shù)據(jù)庫壓測

并發(fā)用戶數(shù)： 8000

測試結(jié)果的界面如下：

測試時間： 2018-10-07 16：18：30~2018-10-07 16：23：30

事務執(zhí)行總量：3653576次;失?。?次; 成功率：100%

Wildfly服務器利用率穩(wěn)定在5%~10%

事務的平均響應時間：403.72ms

TPS：平均 12818.3

測試場景3

模擬場景： 全緩存壓測

并發(fā)用戶數(shù)： 8000

測試結(jié)果界面如下：

測試時間： 2018-09-13 11：42：13~2018-09-13 11：47：13

事務執(zhí)行總量：10519551次;失?。?次; 成功率：100%

Wildfly服務器利用率穩(wěn)定在5%~10%

事務的平均響應時間：140.43ms

TPS：平均 36907.3

小結(jié)

從壓測結(jié)果中可以得出，改造之后的服務接口的TPS有了顯著提升，從以前的1000TPS提升到10000+TPS以上，滿足蘇寧外圍系統(tǒng)對合同扣點服務接口的性能要求。

回顧這次性能優(yōu)化，主要從三方面入手：

1. 利用Redis內(nèi)存級別的存儲，實現(xiàn)數(shù)據(jù)的快速讀取。

2. 從程序內(nèi)部優(yōu)化，將串行化的處理改成并行化異步處理。

3. 利用分布式可擴展的特點，擴展服務器，分散壓力。

從這次扣點服務升級改造中得出，性能優(yōu)化不僅僅是單一的利用某個技術就可以提升系統(tǒng)的性能，需要全方位綜合的解決性能問題，總結(jié)的思路有三點：

1. 找到系統(tǒng)性能的瓶頸。

2. 針對性能瓶頸有的放矢做技術方案，選取合適的技術方案。

3. 一定要壓測，優(yōu)化之后是否真正的提升了系統(tǒng)性能，提升了多少。

結(jié)束語

2018年是集團高速發(fā)展的一年，隨著智慧零售，大開發(fā)等戰(zhàn)略的逐漸落地，公司的業(yè)務量數(shù)據(jù)量不斷的增長，同時對系統(tǒng)的性能和穩(wěn)定性提出來更高的要求。為響應公司提出的“造極”精神，我們也對現(xiàn)有系統(tǒng)進行了迭代升級，不斷優(yōu)化，不斷升級。

在造極精神的鼓舞下，圍繞快速迭代、質(zhì)量保證和穩(wěn)定服務，把極客、極物、極速的造極精神當作我們的工作態(tài)度，唯有挑戰(zhàn)不可能，才能超越一切可能，沖破極限，進而登峰造極。

作者：張冀平，蘇寧易購IT總部員工平臺研發(fā)中心技術經(jīng)理，負責公司內(nèi)部ERP系統(tǒng)的規(guī)劃架構(gòu)開發(fā)工作。資深碼農(nóng)，十年軟件開發(fā)經(jīng)驗，對系統(tǒng)架構(gòu)，性能優(yōu)化，分布式系統(tǒng)設計有著豐富的實戰(zhàn)經(jīng)驗。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】