最近在使用spring cloud zuul進行一些服務網關的搭建和改造，由于一些原因，所以沒有使用config server和eureka做統(tǒng)一的配置管理和服務發(fā)現(xiàn)注冊，而是直接在zuul server上配置了db進行routes的配置，因此使用的是static routing的模式，即直接指定一個route的url而不是serviceId。而我們url指向的地址，是一個nginx地址，相當于通過nginx來做的一個service的負載均衡。
但在實際使用過程中我們發(fā)現(xiàn)一些問題，當下游服務返回的消息大小超過下游nginx設置的gzip閾值的時候，會觸發(fā)響應報文的壓縮，而zuul所接收到的報文，竟然是沒有解壓縮的！如果這時候我們需要對響應報文進行一些解析甚至是加密處理的話，會發(fā)現(xiàn)我們拿到的報文是二進制碼，無法進行下一步操作。而我們知道在我們平時使用的一些HttpClient工具的時候，這些工具能夠自動幫我們處理響應的解壓。那zuul這一塊是怎么處理的呢？我們有什么辦法去配置自動解壓呢？
首先我在github上找到了這個issue：
https://github.com/spring-cloud/spring-cloud-netflix/issues/2363
里面這一段話引起了我的注意：
納尼？RibbonRoutingFilter是自動解壓的？SimpleHostRoutingFilter默認不解壓？其實也想得通。你就把zuul當做一個nginx嘛。但是我們本身的業(yè)務流程怎么辦呀？那我們就深入到代碼里面去看看這個disableContentCompression是怎么調用的。
在SimpleHostRoutingFilter中我們看到了創(chuàng)建HttpClient的過程，看到沒有調用我們要找的disableContentCompression方法。那我就放心了，這個方法肯定是在httpClientFactory中創(chuàng)建的，那我們再去找這個httpClientFactory在哪里創(chuàng)建的？這里可以告訴大家一個小技巧。先直接對這個httpClientFactory對應的ApacheHttpClientFactory來find usage，如果發(fā)現(xiàn)不是很好找的話，可以先找ApacheHttpClientFactory這個接口的實現(xiàn)，你spring容器要注入，總的有個實現(xiàn)吧。我們查找實現(xiàn)，找到了這么個類：
金燦燦的disableContentCompression有木有啊。我們大致確定了這個類就是我們要找的factory，那這個類在哪里用到呢？我們對這個類find usage，就到了這里。
而這個configuration是被ZuulProxyAutoConfiguration所引入的，一切都聯(lián)系起來了
到這兒，我們知道了為什么SimpleHostRoutingFilter是默認不執(zhí)行解壓的，那對于我們需要解壓的邏輯我們應該怎么處理呢？不知道大家有沒有注意apacheHttpClientFactory這個方法上面，有個ConditionalOnMissingBean注解？有這個注解一切都好辦了，你只需要在你的scan path下加上一個configuration，并且定義自己的一個ApacheHttpClientFactory的bean方法就行了，代碼如下：
親測可用。
以上是目前使用到zuul的一個問題小結，如果大家有什么問題歡迎留言和討論。
