實現遠程調用的方式
Http接口（web接口、RestTemplate+Okhttp）、Feign、RPC調用（Dubbo、Socket編程）、Webservice。
什么是Feign？
Feign是Spring Cloud提供的一個聲明式的偽Http客戶端，它使得調用遠程服務就像調用本地服務一樣簡單，只需要創建一個接口並添加一個注解即可。
Nacos注冊中心很好的兼容了Feign，Feign默認集成了Ribbon，所以在Nacos下使用Fegin默認就實現了負載均衡的效果。
什么是Dubbo？
Dubbo是阿里巴巴開源的基於Java的高性能RPC分布式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。
Spring-cloud-alibaba-dubbo是基於SpringCloudAlibaba技術棧對dubbo技術的一種封裝，目的在於實現基於RPC的服務調用。
Feign與Dubbo的對比
Feign與Dubbo功能上有很多類似的地方，因為都是專注於遠程調用這個動作。比如注冊中心解耦、負載均衡、失敗重試熔斷、鏈路監控等。
Dubbo除了注冊中心需要進行整合，其它功能都自己實現了，而Feign大部分功能都是依賴全家桶的組件來實現的。Dubbo小而專一，專注於遠程調用。而Spring全家桶而言，遠程調用只是一個重要的功能而已。
協議支持方面：
Feign更加優雅簡單。Feign是通過REST API實現的遠程調用，基於Http傳輸協議，服務提供者需要對外暴露Http接口供消費者調用，服務粒度是http接口級的。通過短連接的方式進行通信，不適合高並發的訪問。Feign追求的是簡潔，少侵入（因為就服務端而言，在SpringCloud環境下，不需要做任何額外的操作，而Dubbo的服務端需要配置開放的Dubbo接口)。
Dubbo方式更靈活。Dubbo是通過RPC調用實現的遠程調用，支持多傳輸協議(Dubbo、Rmi、http、redis等等)，可以根據業務場景選擇最佳的方式，非常靈活。默認的Dubbo協議：利用Netty，TCP傳輸，單一、異步、長連接，適合數據量小、高並發和服務提供者遠遠少於消費者的場景。Dubbo通過TCP長連接的方式進行通信，服務粒度是方法級的。
從協議層選擇看，Dubbo是配置化的，更加靈活。Dubbo協議更適合小數據高並發場景。
通信性能方面：
從通信的性能上來分析，SpringCloud的通信采用Openfeign（feign）組件。
Feign基於Http傳輸協議，底層實現是rest。從OSI 7層模型上來看rest屬於應用層。
在高並發場景下性能不夠理想，成為性能瓶頸（雖然他是基於Ribbon以及帶有熔斷機制可以防止雪崩），需要改造。具體需要改造的內容需要時再研究。
Dubbo框架的通信協議采用RPC協議，屬於傳輸層協議，性能上自然比rest高。提升了交互的性能，保持了長連接，高性能。
Dubbo性能更好，比如支持異步調用、Netty性能更好。Dubbo主要是配置而無需改造。
| RPC | REST | |
| 耦合性 | 強耦合 | 松耦合 |
| 消息協議 | 二進制 thrift/protobuf | 文本 xml、jason |
| 通信協議 | TCP | HTTP |
| 接口契約IDL | thrift/protobuf | swagger |
| 開發調試 | 消息不可讀 | 可讀，可調試 |
| 對外開放 | 一般作為內部各個系統的通信框架 | 對接外部系統 |
使用SpringCloud整合Dubbo，正所謂是強強聯合。
負載均衡方面：
Feign默認使用Ribbon作為負載均衡的組件。
Dubbo和Ribbon（Feign默認集成Ribbon）都支持負載均衡策略，但是Dubbo支持的更靈活。
Dubbo和Ribbon對比：
Ribbon的負載均衡策略：
隨機、規則輪詢、空閑策略、響應時間策略。
Dubbo的負載均衡策略：Dubbo支持4種算法，隨機、權重輪詢、最少活躍調用數、一致性Hash策略。而且算法里面引入權重的概念。
Dubbo可以使用路由策略，然后再進行負載均衡。
Dubbo配置的形式不僅支持代碼配置，還支持Dubbo控制台靈活動態配置。
Dubbo負載均衡的算法可以精准到某個服務接口的某個方法，而Ribbon的算法是Client級別的。Ribbon需要進行全局配置，個性化配置比較麻煩。
容錯機制方面：
Feign默認使用Hystix作為服務熔斷的組件。Hystix提供了服務降級，服務熔斷，依賴隔離，監控（Hystrix Dashboard）等功能。Feign是利用熔斷機制來實現容錯的，與Dubbo處理的方式不一樣。
Dubbo支持多種容錯策略，FailOver、FailFast、Failsafe、FailBack、Aviailable、Broadcast、Forking策略等，以及Mock。也引入了retry次數，timeout等配置參數。Dubbo自帶了失敗重試的功能。
其他方面（以下方便並未進行詳細整理僅做參考）：
Dubbo附帶了白名單功能、結果緩存、同步和異步調用的功能。
Dubbo支持更多更靈活的並發控制：
客戶端配置actives參數，配置單個Cunsumer最大並發請求數，超出則線程阻塞等待，超時報錯。
Provider可以配置executes參數來限制最大的並發線程數，超出報錯。
Provider可以配置accepts參數來限制最大長連接數來限制最大的連接數。
Provider的通過配置任務線程池的類型和最大線程數來控制並發量，超負載直接丟棄。
路由、流量調度、ABtest方面：
Ribbon需自己實現，應用不靈活。
Ribbon主要通過擴展AbstractLoadBalancerRule負載均衡的方法來實現，在負載均衡的部分還要進行改造升級。
Dubbo更加靈活方便。
Dubbo通過界面化、校本化配置路由規則，可以實現灰度發布、動態流量調度、容量計算等，方案成熟。
另外，Dubbo 還支持多版本調用。
Dubbo支持更完善的監控和管理界面，SC也有Actuator等工具進行監控，但是並不是針對遠程調用這一塊的
Dubbo支持客戶端設置調用結果緩存，支持配置3種策略的結果緩存(LRU、LFU、FIO)，但是要自己實現超時管理。
總結
Dubbo支持更多功能、更靈活、支持高並發的RPC框架。
SpringCloud全家桶里面（Feign、Ribbon、Hystrix），特點是非常方便。Ribbon、Hystrix、Feign在服務治理中，配合Spring Cloud做微服務，使用上有很多優勢，社區也比較活躍，看將來更新發展。
業務發展影響着架構的選型，當服務數量不是很大時，使用普通的分布式RPC架構即可，當服務數量增長到一定數據，需要進行服務治理時，就需要考慮使用流式計算架構。Dubbo可以方便的做更精細化的流量調度，服務結構治理的方案成熟，適合生產上使用，雖然Dubbo是塵封后重新開啟，但這並不影響其技術價值。
如果項目對性能要求不是很嚴格，可以選擇使用Feign，它使用起來更方便。
如果需要提高性能，避開基於Http方式的性能瓶頸，可以使用Dubbo。
Dubbo Spring Cloud的出現，使得Dubbo既能夠完全整合到Spring Cloud的技術棧中，享受Spring Cloud生態中的技術支持和標准化輸出，又能夠彌補Spring Cloud中服務治理這方面的短板。