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

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

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

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

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

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

問題分析

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

如圖：

存在的問題：

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

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

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

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

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

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

改造方案

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

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

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

實(shí)現(xiàn)方案：

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

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

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

處理流程，如圖：

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

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

如圖：

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

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

如圖：

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

3. 橫向擴(kuò)展服務(wù)器，分散壓力

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

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

如圖：

接口壓測

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

壓測環(huán)境

服務(wù)器數(shù)量配置

Nginx24C 4G

Wildfly84C 4G

Zedis54C 32G

MySQL58C 16G

測試場景

測試場景1

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

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

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

測試時(shí)間： 2018-10-01 22：40：23 ~2018-10-01 22：45：23

事務(wù)執(zhí)行總量：2355622次;失敗：0次; 成功率：100%

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

事務(wù)的平均響應(yīng)時(shí)間：624.75ms

TPS：平均 8264.4

測試場景2

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

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

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

測試時(shí)間： 2018-10-07 16：18：30~2018-10-07 16：23：30

事務(wù)執(zhí)行總量：3653576次;失敗：0次; 成功率：100%

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

事務(wù)的平均響應(yīng)時(shí)間：403.72ms

TPS：平均 12818.3

測試場景3

模擬場景： 全緩存壓測

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

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

測試時(shí)間： 2018-09-13 11：42：13~2018-09-13 11：47：13

事務(wù)執(zhí)行總量：10519551次;失敗：0次; 成功率：100%

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

事務(wù)的平均響應(yīng)時(shí)間：140.43ms

TPS：平均 36907.3

小結(jié)

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

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

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

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

3. 利用分布式可擴(kuò)展的特點(diǎn)，擴(kuò)展服務(wù)器，分散壓力。

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

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

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

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

結(jié)束語

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

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

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

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