SpringCloud從入門到進階（七）——踩坑實戰之Zuul服務調用失敗與文件上傳問題

內容

　　上一節搭建了具備服務熔斷、負載均衡的微服務架構1.0 ，可是在經過路由調用微服務時出現了一些直接調用微服務沒有的問題，這也是筆者項目中遇到的真實問題。本文查閱了官方文檔等資料，介紹該問題的解決方法。

版本

　　IDE：IDEA 2017.2.2 x64

　　JDK：1.8.0_171

　　manve：3.3.3

　　SpringBoot：1.5.9.RELEASE

　　SpringCloud：Dalston.SR1

說明

　　轉載請說明出處：SpringCloud從入門到進階（七）——踩坑實戰之Zuul服務調用失敗與文件上傳問題

服務調用失敗問題

　　在起初部署Zuul作路由時，出現過直接訪問微服務正常，可是通過Zuul轉發調用微服務時出現服務熔斷的問題。通過排查Zuul的日誌，發現Zuul已經從Eureka中獲取到了微服務實例（application-serviceA）的地址（hostname:8881, hostname:8883, hostname:8882），地址信息是主機名的形式。

2018-10-23 19:09:01.809  INFO 9621 --- [http-nio-7082-exec-1] INFO  c.n.loadbalancer.DynamicServerListLoadBalancer - 
DynamicServerListLoadBalancer for client #微服務名application-serviceA
application-serviceA initialized: DynamicServerListLoadBalancer: {NFLoadBalancer:name=application-serviceA,current list of #微服務的三個實例（主機名的形式）
Servers=[hostname:8881, hostname:8883, hostname:8882],Load balancer stats=Zone stats: {defaultzone=[Zone:defaultzone;     
Instance count:3;       Active connections count: 0;   Circuit breaker tripped count: 0;   Active connections per server: 0.0;]

解決問題的兩個方法

　　從日誌中咱們看到路由Zuul已經從Eureka中讀取到了「主機名：端口號」形式的微服務實例的地址，那麼爲何會Zuul仍是沒法訪問微服務呢？通過排查，該問題是因爲筆者沒有在Zuul這臺主機的hosts文件中配置微服務實例主機的DNS信息形成的。將全部微服務的主機名和內網IP地址的映射添加到路由接入服務器的hosts中便可解決該問題。另外，也能夠修改微服務實例的配置文件（preferIpAddress ），使其以ip地址的方式註冊到eureka中。

　　將微服務的IP註冊到Eureka中，能夠在Zuul的日誌中看到以下信息：

2018-11-14 22:34:23.523  INFO [bootstrap,6968de15a96e1c3c,64e6af59a5d186a9,false] 30406 --- [nio-7082-exec-1] c.n.l.DynamicServerListLoadBalancer
: DynamicServerListLoadBalancer for 
#微服務名application-serviceA
client application-serviceA initialized: DynamicServerListLoadBalancer:{NFLoadBalancer:name=application-serviceA,current list of #微服務的三個實例（ip地址的形式）
Servers=[172.26.125.115:8882, 172.26.125.115:8883, 172.26.125.115:8881],Load balancer stats=Zone stats: {defaultzone=[Zone:defaultzone;   
Instance count:3;       Active connections count: 0;   Circuit breaker tripped count: 0;       Active connections per server: 0.0;]

文件上傳問題回顧

　　在上一節的最後，咱們經過路由Zuul調用微服務測試文件上傳。在測試過程當中，咱們發現當上傳文件大小超過1MB時，服務會報500錯誤。而且同時當上傳文件名包含中文時，會出現中文亂碼的問題。

　　文件大小超過1MB的500問題：

　　中文文件名亂碼問題：

解讀官方文檔

　　上述錯誤在直接調用微服務的時候是沒有的。是在引入路由Zuul轉發請求以後引入了這些潛在的問題。帶着問題，咱們在官方文檔中找一找，看看有沒有相關的說明。

　　官方文檔的Zuul這一章中的"Uploading Files through Zuul"一節講到，「若是使用Zuul進行文件的上傳，只容許很小的文件上傳成功。若是想上傳大文件，一種可選的方式爲在請求的url中路徑前加上"/zuul"，這樣能夠繞過Zuul的攔截」。那麼咱們使用http://172.26.125.20:7081/zuul/v1/routea/test/upload接口再次測試上傳大文件和中文名稱文件。

大文件

中文名稱文件

　　因而可知，在請求的url路徑前加上"/zuul"的效果，等同於直接訪問對應微服務。此外，官方文檔中也說明，若是上傳太大的文件時，可能請求時間過長，致使Zuul超時熔斷服務。針對超時熔斷的問題，能夠增長以下參數調節Zuul超時的時間閾值：

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 60000 ribbon: ConnectTimeout: 3000 ReadTimeout: 60000

　　固然，除了官方文檔中給的這些方法，咱們也能夠在zuul的項目中增長一些配置，解決相應的問題。

　　好比解決大文件上傳的問題，能夠增長以下配置限定上傳文件體積的閾值：

spring: http: multipart:
      #上傳文件總的最大值爲30MB
     max-request-size: 30MB #單個文件的最大值爲10MB
     max-file-size: 10MB

　　關於中文亂碼問題，找了一些配置，可是都沒有解決。對於此類型問題的解決儘可能不要多此一舉，建議按照官方文檔進行處理，使Zuul的配置儘量簡單。