實現遠端呼叫的方式
http介面（web介面、resttemplate+okhttp）、feign、rpc呼叫（dubbo、socket程式設計）、webservice。
什麼是feign？
feign是spring cloud提供的乙個宣告式的偽http客戶端，它使得呼叫遠端服務就像呼叫本地服務一樣簡單，只需要建立乙個介面並新增乙個註解即可。
nacos註冊中心很好的相容了feign，feign預設整合了ribbon，所以在nacos下使用fegin預設就實現了負載均衡的效果。
什麼是dubbo？
dubbo是阿里巴巴開源的基於j**a的高效能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主要是配置而無需改造。
rpcrest
耦合性強耦合
松耦合訊息協議
二進位制 thrift/protobuf
文字 xml、jason
通訊協議
介面契約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、**iailable、broadcast、forking策略等，以及mock。也引入了retry次數，timeout等配置引數。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中服務治理這方面的短板。
使用dubbo遠端呼叫微服務上傳檔案介面報錯
原因 服務間使用dubbo的rpc遠端呼叫，因為dubbo並不能跨系統傳遞multipartfile物件 解決辦法 將multipartfile物件轉化為byte陣列傳遞 例如 控制層介面 apioperation 上傳 imgupload public responseresult imguplo...
dubbo微服務日誌呼叫鏈
dubbo實現日誌呼叫鏈 threadcontext threadlocal 配置修改 1.dubbo 配置預設的客戶端過濾器和服務端過濾器 servicefilter com.logfilter client com.logfilter 修改dubbo的provider配置檔案，在dubbo pr...
dubbo服務的 遠端呼叫
首先dubbo 和spring 是無縫整合的，先看下配置檔案 提供端的，id testservice class com.dubbo.provider.impl.tetsserviceimpl dubbo name xixi provider dubbo registry address zooke...