平均響應(yīng)時(shí)間自然是越小越好_她越小_吞吐量越高。吞吐量的增加還可以合理利用多核_通過并行度增加單位時(shí)間內(nèi)的發(fā)生次數(shù)。

我們本次優(yōu)化的目標(biāo)_就是減少某些接口的平均響應(yīng)時(shí)間_降低到1秒以內(nèi)；增加吞吐量_也就是提高QPS_讓單實(shí)例系統(tǒng)能夠承接更多的并發(fā)請求。

2._通過壓縮讓耗時(shí)急劇減少

我想要先介紹讓系統(tǒng)飛起來最重要的一個(gè)優(yōu)化手段_壓縮。

通過在chrome的inspect中查看請求的數(shù)據(jù)_我們發(fā)現(xiàn)一個(gè)關(guān)鍵的請求接口_每次要傳輸大約10MB的數(shù)據(jù)。這得塞了多少東西。

這么大的數(shù)據(jù)_光下載就需要耗費(fèi)大量時(shí)間。如下圖所示_是我請求juejin主頁的某一個(gè)請求_其中的content_download_就代表了數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸時(shí)間。如果用戶的帶寬非常慢_那么這個(gè)請求的耗時(shí)_將會是非常長的。

為了減少數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸時(shí)間_可以啟用gzip壓縮。gzip壓縮是屬于時(shí)間換空間的做法。對于大多數(shù)服務(wù)來說_最后一環(huán)是nginx_大多數(shù)人都會在nginx這一層去做壓縮。她的主要配置如下_

gzip_on;gzip_vary_on;gzip_min_length_10240;gzip_proxied_expired_no-cache_no-store_private_auth;gzip_types_text/plain_text/css_text/xml_text/javascript_application/x-javascript_application/xml;gzip_disable_"MSIE_[1-6]\.";

壓縮率有多驚人呢？我們可以看一下這張截圖。可以看到_數(shù)據(jù)壓縮后_由8.95MB縮減到了368KB！瞬間就能夠被瀏覽器下載下來。

但是等等_nginx只是最外面的一環(huán)_還沒完_我們還可以讓請求更快一些。

請看下面的請求路徑_由于采用了微服務(wù)_請求的流轉(zhuǎn)就變得復(fù)雜起來_nginx并不是直接調(diào)用了相關(guān)得服務(wù)_她調(diào)用的是zuul網(wǎng)關(guān)_zuul網(wǎng)關(guān)才真正調(diào)用的目標(biāo)服務(wù)_目標(biāo)服務(wù)又另外調(diào)用了其他服務(wù)。內(nèi)網(wǎng)帶寬也是帶寬_網(wǎng)絡(luò)延遲也會影響調(diào)用速度_同樣也要壓縮起來。

nginx->zuul->服務(wù)A->服務(wù)E

要想Feign之間的調(diào)用全部都走壓縮通道_還需要額外的配置。我們是springboot服務(wù)_可以通過okhttp的透明壓縮進(jìn)行處理。

加入她的依賴_

<dependency> <groupId>io.github.openfeign</groupId> <artifactId>feign-okhttp</artifactId></dependency>

開啟服務(wù)端配置_

server:  port:8888  compression:    enabled:true    min-response-size:1024    mime-types:["text/html","text/xml","application/xml","application/json","application/octet-stream"]

開啟客戶端配置_

feign:  httpclient:    enabled:false  okhttp:    enabled:true

經(jīng)過這些壓縮之后_我們的接口平均響應(yīng)時(shí)間_直接從5-6秒降低到了2-3秒_優(yōu)化效果非常顯著。

當(dāng)然_我們也在結(jié)果集上做了文章_在返回給前端的數(shù)據(jù)中_不被使用的對象和字段_都進(jìn)行了精簡。但一般情況下_這些改動都是傷筋動骨的_需要調(diào)整大量代碼_所以我們在這上面用的精力有限_效果自然也有限。

3._并行獲取數(shù)據(jù)_響應(yīng)飛快

接下來_就要深入到代碼邏輯內(nèi)部進(jìn)行分析了。上面我們提到_面向用戶的接口_其實(shí)是一個(gè)數(shù)據(jù)聚合接口。她的每次請求_通過Feign_調(diào)用了幾十個(gè)其他服務(wù)的接口_進(jìn)行數(shù)據(jù)獲取_然后拼接結(jié)果集合。

為什么慢？因?yàn)檫@些請求全部是串行的！Feign調(diào)用屬于遠(yuǎn)程調(diào)用_也就是網(wǎng)絡(luò)I/O密集型調(diào)用_多數(shù)時(shí)間都在等待_如果數(shù)據(jù)滿足的話_是非常適合并行調(diào)用的。

首先_我們需要分析這幾十個(gè)子接口的依賴關(guān)系_看一下她們是否具有嚴(yán)格的順序性要求。如果大多數(shù)沒有_那就再好不過了。

分析結(jié)果喜憂參半_這堆接口_按照調(diào)用邏輯_大體上可以分為A_B類。首先_需要請求A類接口_拼接數(shù)據(jù)后_這些數(shù)據(jù)再供B類使用。但在A_B類內(nèi)部_是沒有順序性要求的。

也就是說_我們可以把這個(gè)接口_拆分成順序執(zhí)行的兩部分_在某個(gè)部分都可以并行的獲取數(shù)據(jù)。

那就按照這種分析結(jié)果改造試試吧_使用concurrent包里的CountDownLatch_很容易的就實(shí)現(xiàn)了并取功能。

CountDownLatch latch _ new CountDownLatch(jobSize);//submit jobexecutor.execute(() -> {     //job code latch.countDown(); }); executor.execute(() -> {  latch.countDown(); }); ...//end submitlatch.await(timeout, TimeUnit.MILLISECONDS); 

結(jié)果非常讓人滿意_我們的接口耗時(shí)_又減少了接近一半！此時(shí)_接口耗時(shí)已經(jīng)降低到2秒以下。

你可能會問_為什么不用Java的并行流呢？關(guān)于并行流的坑_可以參考這篇文章。非常不建議你使用她。

《parallelStream的坑_不踩不知道_一踩嚇一跳》

并發(fā)編程一定要小心_尤其是在業(yè)務(wù)代碼中的并發(fā)編程。我們構(gòu)造了專用的線程池_來支撐這個(gè)并發(fā)獲取的功能。

final ThreadPoolExecutor executor _ new ThreadPoolExecutor(100, 200, 1,             TimeUnit.HOURS, new ArrayBlockingQueue<>(100)); 

壓縮和并行化_是我們本次優(yōu)化中_最有效的手段。她們直接砍掉了請求大半部分的耗時(shí)_非常的有效。但我們還是不滿足_因?yàn)槊看握埱骭依然有1秒鐘以上呢。

4._緩存分類_進(jìn)一步加速

我們發(fā)現(xiàn)_有些數(shù)據(jù)的獲取_是放在循環(huán)中的_有很多無效請求_這不能忍。

for(List){    client.getData();}

如果將這些常用的結(jié)果緩存起來_那么就可以大大減少網(wǎng)絡(luò)IO請求的次數(shù)_增加程序的運(yùn)行效率。

緩存在大多數(shù)應(yīng)用程序的優(yōu)化中_作用非常大。但由于壓縮和并行效果的對比_緩存在我們這個(gè)場景中_效果不是非常的明顯_但依然減少了大約三四十毫秒的請求時(shí)間。

我們是這么做的。

首先_我們將一部分代碼邏輯簡單_適合Cache_Aside_Pattern模式的數(shù)據(jù)_放在了分布式緩存Redis中。具體來說_就是讀取的時(shí)候_先讀緩存_緩存讀不到的時(shí)候_再讀數(shù)據(jù)庫；更新的時(shí)候_先更新數(shù)據(jù)庫_再刪除緩存（延時(shí)雙刪）。使用這種方式_能夠解決大部分業(yè)務(wù)邏輯簡單的緩存場景_并能解決數(shù)據(jù)的一致性問題。

但是_僅僅這么做是不夠的_因?yàn)橛行I(yè)務(wù)邏輯非常的復(fù)雜_更新的代碼發(fā)非常的分散_不適合使用Cache_Aside_Pattern進(jìn)行改造。我們了解到_有部分?jǐn)?shù)據(jù)_具有以下特點(diǎn)_

1. 這些數(shù)據(jù)_通過耗時(shí)的獲取之后_在極端的時(shí)間內(nèi)_會被再次用到
2. 業(yè)務(wù)數(shù)據(jù)對她們的一致性要求_可以控制在秒級別以內(nèi)
3. 對于這些數(shù)據(jù)的使用_跨代碼、跨線程_使用方式多樣

針對于這種情況_我們設(shè)計(jì)了存在時(shí)間極短的堆內(nèi)內(nèi)存緩存_數(shù)據(jù)在1秒之后_就會失效_然后重新從數(shù)據(jù)庫中讀取。加入某個(gè)節(jié)點(diǎn)調(diào)用服務(wù)端接口是1秒鐘1k次_我們直接給降低到了1次。

在這里_使用了Guava的LoadingCache_減少的Feign接口調(diào)用_是數(shù)量級的。

LoadingCache<String, String> lc _ CacheBuilder      .newBuilder()      .expireAfterWrite(1,TimeUnit.SECONDS)      .build(new CacheLoader<String, String>() {      @Override      public String load(String key) throws Exception {            return slowMethod(key);}});

5._MySQL索引的優(yōu)化

我們的業(yè)務(wù)系統(tǒng)_使用的是MySQL數(shù)據(jù)庫_由于沒有專業(yè)DBA介入_而且數(shù)據(jù)表是使用JPA生成的。在優(yōu)化的時(shí)候_發(fā)現(xiàn)了大量不合理的索引_當(dāng)然是要優(yōu)化掉。

由于SQL具有很強(qiáng)的敏感性_我這里只談一些在優(yōu)化過程中碰到的索引優(yōu)化規(guī)則問題_相信你一樣能夠在自己的業(yè)務(wù)系統(tǒng)中進(jìn)行類比。

索引非常有用_但是要注意_如果你對字段做了函數(shù)運(yùn)算_那索引就用不上了。常見的索引失效_還有下面兩種情況_

MySQL的索引優(yōu)化_最基本的是遵循最左前綴原則_當(dāng)有a、b、c三個(gè)字段的時(shí)候_如果查詢條件用到了a_或者a、b_或者a、b、c_那么我們就可以創(chuàng)建（a_b_c）一個(gè)索引即可_她包含了a和ab。當(dāng)然_字符串也是可以加前綴索引的_但在平常應(yīng)用中較少。

有時(shí)候_MySQL的優(yōu)化器_會選擇了錯(cuò)誤的索引_我們需要使用force_index指定所使用的索引。在JPA中_就要使用nativeQuery_來書寫綁定到MySQL數(shù)據(jù)庫的SQL語句_我們盡量的去避免這種情況。

另外一個(gè)優(yōu)化是減少回表。由于InnoDB采用了B+樹_但是如果不使用非主鍵索引_會通過二級索引（secondary_index）先查到聚簇索引（clustered_index）_然后再定位到數(shù)據(jù)。多了一步_產(chǎn)生回表。使用覆蓋索引_可以一定程度上避免回表_是常用的優(yōu)化手段。具體做法_就是把要查詢的字段_與索引放在一起做聯(lián)合索引_是一種空間換時(shí)間的做法。

6._JVM優(yōu)化

我通常將JVM的優(yōu)化放在最后一環(huán)。而且_除非系統(tǒng)發(fā)生了嚴(yán)重的卡頓_或者OOM問題_都不會主動對其進(jìn)行過度優(yōu)化。

很不幸的是_我們的應(yīng)用_由于開啟了大內(nèi)存（8GB+）_在JDK1.8默認(rèn)的并行收集器下_經(jīng)常發(fā)生卡頓。雖然不是很頻繁_但動輒幾秒鐘_已經(jīng)嚴(yán)重影響到部分請求的平滑性。

程序剛開始_是光禿禿跑在JVM下的_GC信息_還有OOM_什么都沒留下。為了記錄GC信息_我們做了如下的改造。

第一步_加入GC問題排查的各種參數(shù)。

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath_/opt/xxx.hprof  -DlogPath_/opt/logs/ -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution -Xloggc:/opt/logs/gc__p.log -XX:ErrorFile_/opt/logs/hs_error_pid_p.log

這樣_我們就可以拿著生成的GC文件_上傳到gceasy等平臺進(jìn)行分析。可以查看JVM的吞吐量和每個(gè)階段的延時(shí)等。

第二步_開啟SpringBoot的GC信息_接入Promethus監(jiān)控。

在pom中加入依賴。

<dependency>  <groupId>org.springframework.boot</groupId>  <artifactId>spring-boot-starter-actuator</artifactId></dependency>

然后配置暴露點(diǎn)就可以了。這樣_我們就擁有了實(shí)時(shí)的分析數(shù)據(jù)_有了優(yōu)化的依據(jù)。

management.endpoints.web.exposure.include_health,info,prometheus

在觀測了JVM的表現(xiàn)之后_我們切換成了G1垃圾回收器。G1有最大停頓目標(biāo)_可以讓我們的GC時(shí)間更加的平滑。她主要有以下幾個(gè)調(diào)優(yōu)參數(shù)_

切換成G1之后_這種不間斷的停頓_竟然神奇的消失了！期間_還發(fā)生過很多次內(nèi)存溢出的問題_不過有MAT這種神器的加持_最終都很easy的被解決了。

7._其他優(yōu)化

在工程結(jié)構(gòu)和架構(gòu)方面_如果有硬傷的話_那么代碼優(yōu)化方面_起到的作用其實(shí)是有限的_就比如我們這種情況。

但主要代碼還是要整一下容得。有些處于高耗時(shí)邏輯中的關(guān)鍵的代碼_我們對其進(jìn)行了格外的關(guān)照。按照開發(fā)規(guī)范_對代碼進(jìn)行了一次統(tǒng)一的清理。其中_有幾個(gè)印象比較深深刻的點(diǎn)。

有同學(xué)為了能夠復(fù)用map集合_每次用完之后_都使用clear方法進(jìn)行清理。

map1.clear();map2.clear();map3.clear();map4.clear();

這些map中的數(shù)據(jù)_特別的多_而clear方法有點(diǎn)特殊_她的時(shí)間復(fù)雜度事O(n)的_造成了較高的耗時(shí)。

public void clear() {    Node<K,V>[] tab;    modCount++;    if ((tab _ table) !_ null && size > 0) {        size _ 0;        for (int i _ 0; i < tab.length; ++i)            tab[i] _ null;    }}

同樣的線程安全的隊(duì)列_有ConcurrentlinkedQueue_她的size()方法_時(shí)間復(fù)雜度非常高_(dá)不知怎么就被同事給用上了_這都是些性能殺手。

public int size() {        restartFromHead: for (;;) {            int count _ 0;            for (Node<E> p _ first(); p !_ null;) {                if (p.item !_ null)                    if (++count __ Integer.MAX_VALUE)                        break;  // @see Collection.size()                if (p __ (p _ p.next))                    continue restartFromHead;            }            return count;        }}

另外_有些服務(wù)的web頁面_本身響應(yīng)就非常的慢_這是由于業(yè)務(wù)邏輯復(fù)雜_前端Javascript本身就執(zhí)行緩慢。這部分代碼優(yōu)化_就需要前端的同事去處理了_如圖_使用chrome或者firefox的performance選項(xiàng)卡_可以很容易發(fā)現(xiàn)耗時(shí)的前端_代碼。

8._總結(jié)

性能優(yōu)化_其實(shí)也是有套路的_但一般團(tuán)隊(duì)都是等發(fā)生了問題才去優(yōu)化_鮮有未雨綢繆的。但有了監(jiān)控和APM就不一樣_我們能夠隨時(shí)拿到數(shù)據(jù)_反向推動優(yōu)化過程。

有些性能問題_能夠在業(yè)務(wù)需求層面_或者架構(gòu)層面去解決。凡是已經(jīng)帶到代碼層_需要程序員介入的優(yōu)化_都已經(jīng)到了需求方和架構(gòu)方不能再亂動_或者不想再動的境地。

性能優(yōu)化首先要收集信息_找出瓶頸點(diǎn)_權(quán)衡CPU、內(nèi)存、網(wǎng)絡(luò)、、IO等資源_然后盡量的減少平均響應(yīng)時(shí)間_提高吞吐量。

緩存、緩沖、池化、減少鎖沖突、異步、并行、壓縮_都是常見的優(yōu)化方式。在我們的這個(gè)場景中_起到最大作用的_就是數(shù)據(jù)壓縮和并行請求。當(dāng)然_加上其他優(yōu)化方法的協(xié)助_我們的業(yè)務(wù)接口_由5-6秒的耗時(shí)_直接降低到了1秒之內(nèi)_這個(gè)優(yōu)化效果還是非常可觀的。估計(jì)在未來很長一段時(shí)間內(nèi)_都不會再對她進(jìn)行優(yōu)化了。

推薦閱讀_

1._玩轉(zhuǎn)Linux
2._什么味道專輯

3._藍(lán)牙如夢
4._殺機(jī)！
5._失聯(lián)的架構(gòu)師_只留下一段腳本
6._架構(gòu)師寫的BUG_非比尋常