問題起因
最近參與的一個項目，客戶基于EDAS開發的微服務應用，應用間提供的都是Restful接口。
總所周知，EDAS是基于内部HSF接口的分布式服務架構，HSF的特點是服務調用者和服務提供者直接連接配接，不經過網關層轉發，HSF接口無需引入網關層，EDAS會承擔服務注冊與服務發現功能，服務調用時由HSF-Client根據從configserver推送過來的服務提供方ip，直接發起調用。
但是後端的微服務應用提供Restful接口的話，不可能把每一個微服務所提供的Restful接口都直接暴露給前端應用，這樣的話，前端應用需要知道每個微服務的vip、端口、請求path，這麼做并不友好。這裡需要引入一個網關層，前端應用發起請求到網關，由網關根據請求url智能轉發到後端不同的微服務應用處理。
調研過程
調研了相關的産品，有幾個備選方案：
1）Nginx：通過配置upstream來實作請求轉發；
2）CSB：雲服務總線
3）Zuul：Springcloud的網關産品，但是不确定是否能适配EDAS環境
調研後發現：
1）Nginx，雖然可以通過配置upstream來實作請求轉發，但是需要人工介入，每當上線或者調整微服務應用接口時，都需要手工修改配置檔案，非常繁瑣。
2）CSB：雲服務總線CSB主要功能有兩點，1是實作跨域的級聯調用。2是協定轉換。CSB并不支援路由轉發。
3）Zuul：基于Springcloud體系的網關産品，非常符合客戶想要的智能路由轉發的功能，但是是否能适配EDAS是不确定的，翻了下官網EDAS的文檔，也隻提到了僅支援Springcloud的eureka服務注冊功能，并沒有涉及到Zuul。
檢驗
為了檢驗Zuul是否可以在EDAS環境正常使用，寫了個Demo做了試驗：
1）pom檔案裡引入Zuul，同時需要把springcloud原生的eureka包換成EDAS提供的vipclient包。
2）application.xml配置檔案裡加入Zuul轉發規則：
3）啟動後可以正常注冊到EDAS輕量注冊中心：
4）通路頁面，能夠實作智能轉發：
結論
至此，經過驗證後，發現Zuul網關是可以在EDAS環境裡正常使用的。