App下載

OkHttp透明壓縮,收獲性能10倍,外加故障一枚

猿友 2020-09-18 14:27:32 瀏覽數(shù) (2258)
反饋

文章來(lái)源于公眾號(hào):小姐姐味道 ,作者小姐姐養(yǎng)的狗

要使用OkHttp,一定要知道它的透明壓縮,否則死都不知道怎么死的;或者活也不知道為什么活的不舒坦。

反正不是好事。

什么叫透明壓縮呢?OkHttps 在發(fā)送請(qǐng)求的時(shí)候,會(huì)自動(dòng)加入 gzip 請(qǐng)求頭Accept-Encoding:gzip。所以,當(dāng)返回的數(shù)據(jù)帶有 gzip 響應(yīng)頭時(shí)Content-Encoding=gzip,OkHttps 會(huì)自動(dòng)幫我們解壓數(shù)據(jù)。(Accept-EncodingContent-Encoding是一對(duì)請(qǐng)求頭,分別對(duì)應(yīng)著請(qǐng)求和返回)

為什么要進(jìn)行壓縮呢?因?yàn)樗艽蠓鶞p少傳輸?shù)娜萘?。像一?CPU 資源占用不高的服務(wù),比如 Kafka ,我們就可以開啟 gzip 壓縮,加快信息的流轉(zhuǎn)。

這個(gè)壓縮比有多高呢?可以看下下面實(shí)實(shí)在在的截圖,對(duì)于普通的xml或者json,數(shù)據(jù)可以由9MB壓縮到350KB左右,壓縮比足足達(dá)到了26。

壓縮比有多高

它讓系統(tǒng)性能飛起來(lái)

SpringCloud微服務(wù)體系,現(xiàn)在有非常多的公司在用。即使是一些傳統(tǒng)企業(yè),一些大數(shù)據(jù)量的toB企業(yè),也想嘗一嘗螃蟹。

對(duì)于一個(gè)簡(jiǎn)單的 SpringBoot 服務(wù),我們只需要在 yml 文件中配置上相應(yīng)的壓縮就可以了。這樣,我們就打通了瀏覽器到 Web 服務(wù)的這一環(huán)。這種壓縮方式,對(duì)于大數(shù)據(jù)量的服務(wù)來(lái)說(shuō),是救命式的!

具體配置如下。

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

它所對(duì)應(yīng)的 Spring 配置類是org.springframework.boot.web.server.Compression。

但是不要高興太早。由于是分布式環(huán)境,這里面調(diào)用鏈就會(huì)長(zhǎng)一些。即使是在內(nèi)網(wǎng),動(dòng)輒十幾MB的網(wǎng)絡(luò)傳輸,也會(huì)耗費(fèi)可觀的時(shí)間。

請(qǐng)求從瀏覽器到達(dá)服務(wù)節(jié)點(diǎn)

如上圖,一個(gè)請(qǐng)求從瀏覽器到達(dá)真正的服務(wù)節(jié)點(diǎn),可能要經(jīng)過(guò)很多環(huán)節(jié)。

  • nginx轉(zhuǎn)發(fā)請(qǐng)求到微服務(wù)網(wǎng)關(guān)zuul
  • zuul轉(zhuǎn)發(fā)到具體的微服務(wù)A
  • 微服務(wù)A通過(guò)Feign接口調(diào)用微服務(wù)B

如果我們的數(shù)據(jù),大多數(shù)是由微服務(wù)B提供的,那么上面的任何一個(gè)環(huán)節(jié)傳輸效率慢,都會(huì)影響請(qǐng)求的性能。

所以,我們需要開啟 Feign 接口的 gzip 壓縮。使用 OkHttps 的透明代理是最簡(jiǎn)單的方式。

首先,在項(xiàng)目中引入 feign 的 jar 包。

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

其次,在 yml 文件中啟用 OkHttps 作為 feign 的客戶端請(qǐng)求工具包。穩(wěn)妥起見,我們同時(shí)屏蔽了 httpclient ,這個(gè)東西太重太老了。

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

到此為止,我們就可以享受 OkHttps 的透明代理帶來(lái)的便捷性了。

假如你的應(yīng)用數(shù)據(jù)包大,調(diào)用鏈長(zhǎng),這種方式甚至?xí)o你的服務(wù)帶來(lái)數(shù)秒的性能提升。 xjjdog 就曾經(jīng)靠調(diào)整幾個(gè)參數(shù),就讓一個(gè)蝸牛系統(tǒng)飛了起來(lái)。大家驚呼:原來(lái)B端也可以C一下。

OkHttp是如何實(shí)現(xiàn)透明壓縮的?

OkHttps 對(duì)于透明壓縮的處理,是通過(guò)攔截器來(lái)做的。具體的類,就是okhttp3.internal.http.BridgeInterceptor。

具體代碼如下,當(dāng)判斷沒有Accept-Encoding頭的時(shí)候,就自行加入一個(gè)。

// If we add an "Accept-Encoding: gzip" header field we're responsible for also decompressing
// the transfer stream.
boolean transparentGzip = false;
if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {
  transparentGzip = true;
  requestBuilder.header("Accept-Encoding", "gzip");
}

最關(guān)鍵的代碼在下面。

if (transparentGzip
    && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding"))
    && HttpHeaders.hasBody(networkResponse)) {
  GzipSource responseBody = new GzipSource(networkResponse.body().source());
  Headers strippedHeaders = networkResponse.headers().newBuilder()
      .removeAll("Content-Encoding")
      .removeAll("Content-Length")
      .build();
  responseBuilder.headers(strippedHeaders);
  String contentType = networkResponse.header("Content-Type");
  responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody)));
}

可以看到if語(yǔ)句里,有三個(gè)條件。

  • 程序沒有設(shè)置Accept-Encoding,啟用了透明壓縮
  • 服務(wù)端有Content-Encoding頭,并啟用了gzip壓縮
  • 有數(shù)據(jù)包

只有同時(shí)滿足這三個(gè)條件,OkHttps 的透明壓縮才會(huì)起作用,幫我們自動(dòng)解壓。

它挖的坑有點(diǎn)深

可惜的是,上面的關(guān)鍵代碼,只有if,沒有else,也就是當(dāng)其中的任何一個(gè)條件不滿足,后端的數(shù)據(jù)包將原封不動(dòng)的返回。

2、3兩個(gè)條件是沒有什么問(wèn)題的,原樣返回后端數(shù)據(jù)并沒有什么損害,問(wèn)題就出在第一個(gè)條件里。

如果你在代碼中,使用了下面的代碼:

Request.Builder builder = chain.request()
                .newBuilder()
                .addHeader("Accept", "application/json")
                .addHeader("Accept-Encoding", "gzip");

也就是手動(dòng)設(shè)置了Accept-Encoding頭信息。這很常見,因?yàn)檫@體現(xiàn)了程序員思維的嚴(yán)謹(jǐn)。

正是這種嚴(yán)謹(jǐn),造成了問(wèn)題。

假如你的后端應(yīng)用剛開始是沒有開啟gzip壓縮的,這時(shí)候兩者相安無(wú)事;但如果你的后端應(yīng)用突然有一天開啟了gzip壓縮,你的這段代碼將全部over。

原因就是,服務(wù)端gzip數(shù)據(jù)包會(huì)原樣返回,你需要手動(dòng)處理gzip數(shù)據(jù)包。

所以,不加是好事,加了反而會(huì)壞事,除非你想自己處理gzip數(shù)據(jù)。

由于OkHttpAndroid上應(yīng)用也非常廣泛,如果你不知道這個(gè)細(xì)節(jié),造成的后果就是災(zāi)難性的。客戶端更新慢,只能老老實(shí)實(shí)回退服務(wù)端了。

智能的背后,總有些肉眼不可見的細(xì)節(jié)。就像是xjjdog純情的背后,總有一份羞澀。只有深入了解,你才會(huì)知道它的美。

以上就是W3Cschool編程獅關(guān)于OkHttp透明壓縮,收獲性能10倍,外加故障一枚的相關(guān)介紹了,希望對(duì)大家有所幫助。

0 人點(diǎn)贊