偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

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

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

[[342443]]

本文轉(zhuǎn)載自微信公眾號「小姐姐味道」,作者小姐姐養(yǎng)的狗 。轉(zhuǎn)載本文請聯(lián)系小姐姐味道公眾號。  

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

反正不是好事。

什么叫透明壓縮呢?OkHttp在發(fā)送請求的時候,會自動加入gzip請求頭Accept-Encoding:gzip。所以,當返回的數(shù)據(jù)帶有g(shù)zip響應頭時Content-Encoding=gzip,OkHttp會自動幫我們解壓數(shù)據(jù)。(Accept-Encoding和Content-Encoding是一對請求頭,分別對應著請求和返回)

為什么要進行壓縮呢?因為它能大幅減少傳輸?shù)娜萘?。像一些CPU資源占用不高的服務,比如Kafka,我們就可以開啟gzip壓縮,加快信息的流轉(zhuǎn)。

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

 

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

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

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

具體配置如下。

  1. server: 
  2.   port: 8082 
  3.   compression: 
  4.     enabled: true 
  5.     min-response-size: 1024 
  6.     mime-types: ["text/html","text/xml","application/xml","application/json","application/octet-stream"

它所對應的Spring配置類是org.springframework.boot.web.server.Compression。

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

 

如上圖,一個請求從瀏覽器到達真正的服務節(jié)點,可能要經(jīng)過很多環(huán)節(jié)。

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

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

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

首先,在項目中引入feign的jar包。

  1. dependency> 
  2.             <groupId>io.github.openfeign</groupId> 
  3.             <artifactId>feign-okhttp</artifactId> 
  4. </dependency> 

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

  1. feign: 
  2.   httpclient: 
  3.     enabled: false 
  4.   okhttp: 
  5.     enabled: true 

到此為止,我們就可以享受OkHttp的透明代理帶來的便捷性了。

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

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

OkHttp對于透明壓縮的處理,是通過攔截器來做的。具體的類,就是okhttp3.internal.http.BridgeInterceptor。

具體代碼如下,當判斷沒有Accept-Encoding頭的時候,就自行加入一個。

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

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

  1. if (transparentGzip 
  2.     && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding")) 
  3.     && HttpHeaders.hasBody(networkResponse)) { 
  4.   GzipSource responseBody = new GzipSource(networkResponse.body().source()); 
  5.   Headers strippedHeaders = networkResponse.headers().newBuilder() 
  6.       .removeAll("Content-Encoding"
  7.       .removeAll("Content-Length"
  8.       .build(); 
  9.   responseBuilder.headers(strippedHeaders); 
  10.   String contentType = networkResponse.header("Content-Type"); 
  11.   responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody))); 

可以看到if語句里,有三個條件。

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

只有同時滿足這三個條件,OkHttp的透明壓縮才會起作用,幫我們自動解壓。

它挖的坑有點深

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

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

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

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

也就是手動設置了Accept-Encoding頭信息。這很常見,因為這體現(xiàn)了程序員思維的嚴謹。

正是這種嚴謹,造成了問題。

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

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

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

由于OkHttp在Android上應用也非常廣泛,如果你不知道這個細節(jié),造成的后果就是災難性的??蛻舳烁侣?,只能老老實實回退服務端了。

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

 

作者簡介:小姐姐味道 (xjjdog),一個不允許程序員走彎路的公眾號。聚焦基礎架構(gòu)和Linux。十年架構(gòu),日百億流量,與你探討高并發(fā)世界,給你不一樣的味道。我的個人微信xjjdog0,歡迎添加好友,進一步交流。

 

責任編輯:武曉燕 來源: 小姐姐味道
相關(guān)推薦

2019-04-11 14:16:31

數(shù)據(jù)產(chǎn)品經(jīng)理數(shù)據(jù)科學數(shù)據(jù)

2015-01-04 15:36:52

XSS漏洞XSS

2024-09-02 14:37:50

2022-01-19 18:02:42

chrome插件使用者

2018-09-21 10:57:16

2015-04-16 09:38:23

2018-01-19 15:38:16

戴爾

2020-02-24 09:45:06

WindowsWindows 10微軟

2011-07-01 10:11:39

2018-08-16 17:20:49

小豬短租

2018-05-10 11:06:56

華為云

2022-07-27 07:54:36

網(wǎng)絡故障交換機

2014-03-26 10:00:06

RailsRails性能

2024-10-29 08:21:05

2020-10-30 07:09:52

Lombok架構(gòu)師

2011-07-22 14:07:19

設計文化視覺設計設計

2025-05-27 01:55:00

TypeScript開發(fā)者項目

2020-03-26 12:38:15

代碼節(jié)點數(shù)據(jù)
點贊
收藏

51CTO技術(shù)棧公眾號