dubbo是分布式還是微服務為什么使用dubbo分布式

大家好，關(guān)于dubbo是分布式還是微服務很多朋友都還不太明白，不過沒關(guān)系，因為今天小編就來為大家分享關(guān)于為什么使用dubbo分布式的知識點，相信應該可以解決大家的一些困惑和問題，如果碰巧可以解決您的問題，還望關(guān)注下本站哦，希望對各位有所幫助！

dubbo性能高嗎

dubbo性能高的。

ApacheDubbo(incubating)|?d?b??|是一款高性能、輕量級的開源JavaRPC框架，它提供了三大核心能力：面向接口的遠程方法調(diào)用，智能容錯和負載均衡，以及服務自動注冊和發(fā)現(xiàn)。

Dubbo是一個分布式服務框架，致力于提供高性能和透明化的RPC遠程服務調(diào)用方案、服務治理方案。

dubbo是用來做什么的

"dubbo是用來進行分布式服務治理的。

"1.Dubbo是阿里巴巴提供的基于Java的高性能RPC分布式服務框架。

它可以良好的支持各種RPC協(xié)議和各種序列化機制，是在大規(guī)模分布式環(huán)境中提供有效的服務治理方案的理想選擇。

2.通過Dubbo，可以進行服務注冊與發(fā)現(xiàn)、服務治理、負載均衡、容錯、并發(fā)控制、服務路由和可視化等服務間通訊和治理方案的實現(xiàn)。

同時，它也具備高可靠、高效能、易于擴展和集成等特點，被廣泛應用于互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、金融等領(lǐng)域，可以方便有效的解決大型分布式應用系統(tǒng)所面臨的復雜性問題。

為什么阿里會放棄dubbo

因為阿里認為dubbo已經(jīng)無法滿足阿里的業(yè)務需求和技術(shù)發(fā)展，同時dubbo的架構(gòu)和實現(xiàn)方式也與阿里現(xiàn)有的技術(shù)體系有很大區(qū)別，無法與阿里現(xiàn)有技術(shù)進行有效整合和升級。阿里的技術(shù)發(fā)展需要一個更先進的、更靈活、更可控的架構(gòu)來支持。此外，阿里也明確表示，雖然不再對dubbo進行維護，但將承諾兼容現(xiàn)有版本，并積極推動社區(qū)化的發(fā)展，以幫助更多的開發(fā)者和企業(yè)在技術(shù)上實現(xiàn)快速發(fā)展。

微服務框架spring cloud和dubbo有什么區(qū)別

首先，從嚴格意義上來說，Dubbo和SpringCloud的定位是不一樣的。Dubbo是一個高性能的、基于java的開源RPC框架，注意它的定位是是高性能和RPC框架。SpringCloud提供了一系列通用工具來幫助開發(fā)者在分布式系統(tǒng)里快速構(gòu)建一些常見模式，比如分布式配置管理、服務發(fā)現(xiàn)、熔斷降級、智能路由、微代理、控制總線、一次性令牌、全局鎖、分布式選主、分布式session等一些列解決方案，它的設計目標是提供一整套服務治理能力，它具有一套完整的微服務解決方案體系。

dubbo只是一個分布式的RPC框架，如果一定要按照分布式系統(tǒng)架構(gòu)里的功能來定義的話，只是解決了服務發(fā)現(xiàn)、服務路由、服務降級和負載均衡方面的能力，新版本里也提供了動態(tài)配置中心和服務治理相關(guān)的能力，但相比SpringCloud而言，還是差了相當一部分的能力。

從功能支持上來說，dubbo的角色定位可能更像是另外一個大名鼎鼎的框架，那就是gRPC，而且兩者在使用的方式以及工作原理上都非常相似，都是基于序列化協(xié)議來解決分布式系統(tǒng)中的遠程調(diào)用問題，在使用上可以通過約定接口或者通過proto文件生成代碼文件來“提升用戶的使用”。

如果你在系統(tǒng)設計之初就已經(jīng)考慮到了后續(xù)可能會涉及到各種服務治理能力，比如分布式配置、全局鎖、分布式session等常見需求，那么使用SpringCloud將會減少你很多的工作，因為這些基本上都是"套件"，相互配合使用會非常順暢。如果你想要的只是解決分布式架構(gòu)后的遠程調(diào)用問題，那么Dubbo是一個不錯的選擇。

SpringCloud和Dubbo的基本差異大概就是如上所述，如果你不知道該如何做選擇，這里再補充幾個比較關(guān)鍵的差異點，希望能幫助你更好的結(jié)合自身業(yè)務做出選擇：

能力支持方面

上文也提到，SpringCloud提供了一整套微服務治理的功能組件，很多組件基本上都是"開箱即用"的，并且相互之間能很好的兼容，舉個例子，如果要在SpringCloud里實現(xiàn)服務發(fā)現(xiàn)、負載均衡和熔斷降級，你只需要引用SpringCloud的依賴組件即可，直接通過注解便可使用，基本上零配置；而dubbo框架，除了上述提到的能力支持之外，如果想要使用熔斷降級，那你可能需要額外引用hystrix或者resilience4j來實現(xiàn)；溫馨提示，hystrix官方目前也已經(jīng)宣布不再更新，并且推薦使用resilience4j。

協(xié)議兼容方面

SpringCloud里并沒有限制服務之間的通信協(xié)議，但是主流的一些客戶端比如restTemple、feign等都是直接支持使用Ribbon來做服務注冊發(fā)現(xiàn)和智能路由的，其底層通信的協(xié)議都是HTTP；而dubbo框架缺省是基于NIO異步傳輸使用TCP長連接并采用Hessian二進制序列化方式通信的；

這會涉及后續(xù)系統(tǒng)在擴展上的兼容性問題，比如需要調(diào)用一個三方系統(tǒng)或者是被第三方系統(tǒng)調(diào)用，相比而言HTTP協(xié)議可能更加通用。

模型定義方面

dubbo在模型設計上將一個接口定義為一個服務，而SpringCloud里則是將一個應用定義為一個服務，這兩者在模型上是存在很大差異的，你也許會奇怪，這個對使用會有影響嗎？從現(xiàn)有使用方面來說是沒有什么影響的，但是你如果有關(guān)注ServiceMesh最新微服務技術(shù)的話，目前對Dubbo協(xié)議這塊可能支持暫時還不完善，其中很大一部分原因就是因為在服務模型上與K8S的服務模型有差異；

調(diào)用性能方面

如果分布式系統(tǒng)中比較關(guān)注遠程調(diào)用的性能，那Dubbo可能是一個較好的選擇，基于NIO和TCP長連接的通信傳輸方式，在性能上相比HTTP協(xié)議是有絕對優(yōu)勢的；當然基于SpringCloud你也可以使用gRPC協(xié)議來解決性能問題，那就是另外一個問題了。