一：事發原因
兩個東家都使用SpringCloud，巴拉巴拉用上了Spring全家桶，從eureka到ribbon，從ribbon到feign，從feign到hystrix，然後在使用feign的時候發現使用方式不同，仔細一看這種調用方式，唉，麻煩，我怎麼要自己定義DTO，自己定義Fallback, 自己定義方法呢？用上之後，其實發現各有各的好處，今天就來一一記錄一下。
二：方式1介紹
我們在開發服務的時候，會把接口和實作分開， 即有一個API子產品和一個Service子產品，消費者依賴API的jar包，直接注入API中的Service，則可以直接通過Feign調用到對應的服務，對應的項目結構如下：
我們在接口API中定義好方法，并加上Feign注解等（MICRO-PROVIDER2是服務名，注冊到Eureka Server上的名稱。 使用Feign還可以自己實作fallback，設定逾時預設放回值。這裡做測試，不寫過多代碼。）。具體的實作如下圖所示。
接下來就是我們如何在consumer中去消費這個服務了，我們會在service服務中，依賴api的jar包，實作Provider2Service即可。具體的實作如下圖。
，
代碼中的實作邏輯：
三：方式2介紹
這中方式介紹起來比較簡單。直接在消費者中定義新的service接口，通過Feign注解，定義方法，調用的url和被調用服務的url相同，實作邏輯如下。
四：調用結果測試
方式2：
， 方式1：
可以看到，兩種方式都是可以消費到服務（本質是一樣）。但是兩種方式各有好處和壞處，我們要來比較下，看看究竟哪一種才是我們需要的呢？
五：兩種方式對比
通過兩種方式的對比，我們可以看到的優優劣勢主要有：
方式一：
優點：
1：服務消費者不用自己寫接口。
2：可提供好Dto，Vo等直接給服務消費者。
缺點：
1：service需要依賴jar包，如果依賴服務過多，jar也會過多。
2：給消費者暴露了過多的接口。部分與消費者無關的接口也暴露給對方。
方式二：
1：無需依賴過多jar包。
2：消費者不要要過多接受消費者提供的方法。
1：需要消費者自己實作接口。
2：嚴重依賴文檔。在實作接口時，對于所有資訊都要有文檔定義。如：請求方式，請求參數，傳回值等。
3：自己完成Dto，Vo的編寫。
六：總結
兩種調用方式，我把知道的優缺點放在這了，歡迎大家提出自己的建議。關于如何選擇，請根據需要自己抉擇，或者有好的方案歡迎交流，謝謝！
你的每一個點贊，我都當做喜歡