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的配置盡可能簡單。