Dubbo是微服務架構嗎？

謝看山腰，作為Apache Dubbo的PMC，說兩句。

要想搞清楚題主的問題，我們需要分三個子問題來看：

什麼是微服務架構
什麼是Dubbo
最後來看，Dubbo是不是微服務架構

1、什麼是微服務架構

什麼是微服務架構，可以參考我這篇文章：

kimmking：00.什麼是微服務架構?

zhuanlan.zhihu.com

微服務架構（MicroServices Architecture，MSA）：微服務架構可以看做是面向服務架構和分散式服務架構的拓展，使用更細粒度的服務（所以叫微服務）和一組設計準則來考慮大規模的複雜系統架構設計。也可以把它看做是SOA的一種衍生，所以總體來說，微服務架構是一種架構設計思想，也是一種做系統的方法論。

通過Martin Flowler的在【這篇文章】中對微服務描述，可以抽象出以下幾個關鍵點：

由一些獨立的服務共同組成應用系統
每個服務單獨布署、獨立跑在自己的進程中
每個服務都是獨立的業務
分散式管理

更多的學習微服務的知識，可以參考：

kimmking：有沒有講微服務架構比較不錯的書？?

zhuanlan.zhihu.comkimmking：微服務架構設計中如何把握「微」度，需要考慮哪幾方面因素？?

zhuanlan.zhihu.comkimmking：梁桂釗《顛覆微服務認知：深入思考微服務的七個主流觀點》?

zhuanlan.zhihu.com

如果想要在實際項目中更好的實踐微服務架構，可以參考Gitchat上的萬字長文《微服務架構深度解析與最佳實踐》：

微服務架構深度解析與最佳實踐?

gitbook.cn

微服務架構的概念，現在對於大家應該都不陌生，無論使用 Apache Dubbo、還是 Spring Cloud，都可以去嘗試微服務，把複雜而龐大的業務系統拆分成一些更小粒度且獨立部署的 Rest 服務。但是這個過程，具體應該怎麼做？現有的條件下到底要不要做微服務？服務拆分成什麼粒度才是合適的？遺留的老系統需要如何考慮重構改造？有哪些坑需要我們注意？系統怎麼在分散式服務下實現數據的一致性和服務的高可用可伸縮？拆分的過程中系統數量增多，測試、部署、運維、監控，又應該如何處理？
本文將從這些問題的深度分析出發，闡述微服務架構落地的一些設計原則和利弊取捨，結合微服務架構過程的很多最佳實踐經驗，希望給讀者帶來一定的啟發和思考，避免在實際應用過程中走彎路，能夠多快好省的落地實現微服務架構。內容涉及：微服務架構的發展過程簡介微服務架構的特點與常見特性使用微服務架構的常見技術與簡單示例微服務架構存在的一些問題

如何合理拆分微服務
遺留系統應該如何改造怎麼考慮拆分後的數據一致性系統和服務的高可用可伸縮如何實現拆分過程的測試和部署如何處理拆分後的運維和監控如何處理

2、什麼是Dubbo

Dubbo是一個分散式服務框架，用於多個系統間的相互調用的。基於這個功能，然後衍生出服務的註冊、發現，監控、路由、治理，多協議支持等等。官網首頁介紹：

Apache Dubbo |?d?b??| 是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向介面的遠程方法調用，智能容錯和負載均衡，以及服務自動註冊和發現。

簡單的說，就是基於dubbo可以非常簡單的、透明地在不同的系統間實現服務之間的調用，並且通過相關的工具，我們能很好的把這些東西管理起來。同時，Dubbo的中文文檔，以及網上的介紹文章和分析材料，也是開源技術里最多的。

分散式服務化領域，Dubbo是國內開源技術在世界範圍的一面旗幟。

Dubbo的歷史可以參考下面回答的前半部分：

現在有什麼好的方案替換zookeeper+ dubbo嗎？?

www.zhihu.com

Dubbo的更多信息參考dubbo重新維護以後我的一個回復：

dubbo在Github上為什麼不更新了？?

www.zhihu.com

3、Dubbo是不是微服務架構

通過第一部分的分析，我們知道，微服務架構，不是一個具體的框架或者類庫。但是我們可以用分散式服務化的框架，結合我們的業務，用微服務架構的指導思想去實現我們的具體系統。

從這個角度來說，以下的框架都是可以選的：

Java平台的：

Apache Dubbo
Spring Cloud
Vert.x
Apache ServiceComb
Quarkus
Helidon
Lagom(Scala)

有些大家應該聽說過，不多說。Quarkus和Helidon比較新，也很有意思，介紹參見：

如何看待RedHat開源的Quarkus微服務框架？ - kimmking的回答 - 知乎

如何看待RedHat開源的Quarkus微服務框架？?

www.zhihu.com

Golang的：

go-micro

NodeJS的：

seneca

等等。

框架的選擇，可以參考：

為何說spring cloud適合中小型項目，而不適合大型項目？?

www.zhihu.com

以上。

：）

Dubbo是一個RPC框架，可以用於微服務架構實踐之中。但絕不是用了Dubbo就是在做微服務了，同樣的這對於Spring Cloud而言也一眼的，因為微服務架構不僅包含技術上的選擇，也包含了文化、組織等多方面的變革。

具體可以看看Martin Fowler關於微服務的文章微服務（Microservices）中文版，附上我的筆記《微服務》九大特性重讀筆記，僅供參考～

謝邀。

什麼是Dubbo？

Dubbo 是一個分散式服務框架，致力於提供高性能和透明化的 RPC 遠程服務調用方案，以及 SOA 服務治理方案。簡單的說，Dubbo 就是個服務框架，說白了就是個遠程服務調用的分散式框架。

Dubbo 框架

模塊註解：

Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。

流程詳解：

0 服務容器負責啟動，載入，運行服務提供者（Standalone 容器）。
1 服務提供者在啟動時，向註冊中心註冊自己提供的服務（Zookeeper/Redis）。
2 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
4 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。
5 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心（根據數據可以動態調整權重）。

Dubbo 集群容錯

面對服務消費方，當業務邏輯中需要調用一個服務時，真正調用的其實是 Dubbo 創建的一個 Proxy，該 Proxy 會把調用轉化成調用指定的 Invoker（Cluster 將 Directory 中的多個 Invoker 偽裝成一個 Invoker，對上層透明，偽裝過程包含了容錯邏輯，調用失敗後，重試另一個（通過 LoadBalance），Invoker 封裝了 Provider 地址及 Service 介面信息）。而在這一系列的委託調用的過程里就完成了服務治理的邏輯，最終完成調用。

Dubbo 特點

遠程通訊: 提供對多種基於長連接的 NIO 框架抽象封裝（非阻塞 I/O 的通信方式，Mina/Netty/Grizzly），包括多種線程模型，序列化（Hessian2/ProtoBuf），以及「請求-響應」模式的信息交換方式。
集群容錯: 提供基於介面方法的透明遠程過程調用（RPC），包括多協議支持（自定義 RPC 協議），以及軟負載均衡（Random/RoundRobin），失敗容錯（Failover/Failback），地址路由，動態配置等集群支持。
自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo 發展歷程

2008 年，阿里巴巴開始內部使用 Dubbo。
2009 年初，發布 1.0 版本。
2010 年初，發布 2.0 版本。
2011 年 10 月，阿里巴巴宣布開源，版本為 2.0.7。
2012 年 3 月，發布 2.1.0 版本。
2013 年 3 月，發布 2.4.10 版本。
2014 年 10 月，發布 2.3.11 版本，之後版本停滯。
2017 年 9 月，阿里巴巴重啟維護，重點升級所依賴 JDK 及組件版本，發布 2.5.4/5 版本。
2017 年 10 月，發布 2.5.6 版本。
2017 年 11 月，發布 2.5.7 版本，後期集成 Spring Boot。
2014 年 10 月，噹噹網 Fork 了 Dubbo 版本，命名為 Dubbox-2.8.0，並支持 HTTP REST 協議。

Dubbo 負責人說明（重啟維護是接受的採訪）：

阿里內部使用 HSF，原因業務屬性和規模有關。
這裡就不得不提到目前的一些文章在談到微服務的時候總是拿 Spring Cloud 和 Dubbo 來對比，需要強調的是 Dubbo 未來的定位並不是要成為一個微服務的全面解決方案，而是專註在 RPC 領域，成為微服務生態體系中的一個重要組件。至於大家關注的微服務化衍生出的服務治理需求，我們會在 Dubbo 積極適配開源解決方案，甚至啟動獨立的開源項目予以支持。受眾主要來自國內各友商以及個人開發者，希望將來能夠將用戶拓展到全球，代表國人在 RPC 領域與 gRPC（基於 HTTP 2.0）、Finagle 等競爭。

Dubbo 一些優點

Dubbo 支持 RPC 調用，服務之間的調用性能會很好。
支持多種序列化協議，如 Hessian、HTTP、WebService。
Dobbo Admin後台管理功能強大，提供了路由規則、動態配置、訪問控制、權重調節、均衡負載等功能。
在國內影響力比較大，中文社區文檔較為全面。
阿里最近重啟維護。

Dubbo 一些問題

Registry 嚴重依賴第三方組件（zookeeper 或者 redis），當這些組件出現問題時，服務調用很快就會中斷。
Dubbo 只支持 RPC 調用。使得服務提供方（抽象介面）與調用方在代碼上產生了強依賴，服務提供者需要不斷將包含抽象介面的 jar 包打包出來供消費者使用。一旦打包出現問題，就會導致服務調用出錯，並且以後發布部署會成很大問題（太強的依賴關係）。
另外，以後要兼容 .NET Core 服務，Dubbo RPC 本身不支持跨語言（可以用跨語言 RPC 框架解決，比如 Thrift、gRPC（重複封裝了），或者自己再包一層 REST 服務，提供跨平台的服務調用實現，但相對麻煩很多）
Dubbo 只是實現了服務治理，其他微服務框架並未包含，如果需要使用，需要結合第三方框架實現（比如分散式配置用淘寶的 Diamond、服務跟蹤用京東的 Hydra，但使用相對麻煩些），開發成本較高，且風險較大。
社區更新不及時（雖然最近在瘋狂更新），但也難免阿里以後又不更新了，就尷尬了。
主要是國內公司使用，但阿里內部使用 HSF，相對於 Spring Cloud，企業應用會差一些。

所以dubbo也算是微服務架構。

來源：博客園

作者：田園裡的蟋蟀

原文：Java 微服務框架選型（Dubbo 和 Spring Cloud？）

發佈於 2020-02-24繼續瀏覽內容知乎發現更大的世界打開Chrome繼續王者程序猿

這麼說吧，dubbo可以是微服務的一部分，但不能以偏概全說dubbo就是微服務，微服務涉及的面比較廣，比如服務發現，服務治理，服務網關，服務監控，鏈路追蹤等等，可以用到的組件也比較多，而dubbo最多只能說是專註於服務治理的組件，所以從這一點上來看，可替代它的技術也是相當之多的，比如一系列rpc框架都可以

不是微服務架構的範圍有點廣 dubbo只不過是個RPC框架提供了一種微服務中的通信及服務發現的功能

不是，他是RPC框架，要想構建微服務框架需要在dubbo基礎上進行擴展。