兩大微服務 框架 Dubbo 和 Spring Cloud 的對比

1、基本介紹html

dubbogit

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

優勢:redis

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

缺點:spring

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

 

spring cloud安全

Spring Cloud 基於 Spring Boot,爲微服務體系開發中的架構問題,提供了一整套的解決方案——服務註冊與發現,服務消費,服務保護與熔斷,網關,分佈式調用追蹤,分佈式配置管理等。網絡

優勢:架構

  • 有強大的 Spring 社區、Netflix 等公司支持,而且開源社區貢獻很是活躍
  • 標準化的將微服務的成熟產品和框架結合一塊兒,Spring Cloud 提供整套的微服務解決方案,開發成本較低,且風險較小
  • 基於 Spring Boot,具備簡單配置、快速開發、輕鬆部署、方便測試的特色。
  • 支持 REST 服務調用,相比於 RPC,更加輕量化和靈活(服務之間只依賴一紙契約,不存在代碼級別的強依賴),有利於跨語言服務的實現,以及服務的發佈部署。另外,結合 Swagger,也使得服務的文檔一體化
  • 提供了 Docker 及 Kubernetes 微服務編排支持。
  • 國內外企業應用很是多,經受了大公司的應用考驗(好比 Netfilx 公司),以及強大的開源社區支持。

缺點:併發

  • 支持 REST 服務調用,可能由於接口定義太輕,致使定義文檔與實際實現不一致致使服務集成時的問題(可使用統一文檔和版本管理解決,好比 Swagger)。
  • 另外,REST 服務調用性能會比 RPC 低一些(但也不是強綁定)
  • Spring Cloud 整合了大量組件,相關文檔比較複雜,須要針對性的進行閱讀。

補充:spring cloud目前支持的服務發現框架

  euerka Consul zookeeper etcd
服務健康檢查 可配支持 服務狀態,內存,硬盤等 (弱)長鏈接,keepalive 鏈接心跳
多數據中心 支持
kv 存儲服務 支持 支持 支持
一致性 raft paxos raft
cap ap ca cp cp
使用接口(多語言能力) http(sidecar) 支持 http 和 dns 客戶端 http/grpc
watch 支持 支持 long polling/大部分增量 全量/支持long polling 支持 支持 long polling
自身監控 metrics metrics metrics
安全 acl /https acl https 支持(弱)
spring cloud 集成 已支持 已支持 已支持 已支持

 

還有Service Mesh

若是用一句話來解釋什麼是 Service Mesh,能夠將它比做是應用程序或者說微服務間的 TCP/IP,負責服務之間的網絡調用、限流、熔斷和監控。
對於編寫應用程序來講通常無須關心 TCP/IP 這一層(好比經過 HTTP 協議的 RESTful 應用),
一樣使用 Service Mesh 也就無須關係服務之間的那些原來是經過應用程序或者其餘框架實現的事情,好比 Spring Cloud、OSS,如今只要交給 Service Mesh 就能夠了。 Service Mesh有一個成熟的產品,微軟內部用了近10年的產品,如今命名爲Service fabric 開源在GitHub上:https:
//github.com/Microsoft/service-fabric

 

 

2、主要區別

(1)服務調用方式

Q:爲何說 Dubbo 比 Spring Cloud 性能要高一些?

A:由於 Dubbo 採用單一長鏈接和 NIO 異步通信(保持鏈接/輪詢處理),使用自定義報文的 TCP 協議,而且序列化使用定製 Hessian2 框架,適合於小數據量大併發的服務調用,以及服務消費者機器數遠大於服務提供者機器數的狀況,但不適用於傳輸大數據的服務調用。而 Spring Cloud 直接使用 HTTP 協議(但也不是強綁定,也可使用 RPC 庫,或者採用 HTTP 2.0 + 長連接方式(Fegin 能夠靈活設置))。

(2)


參考博文:

到底孰優孰劣?Dubbo和Spring Cloud微服務架構終極對決!

Java 微服務框架選型(Dubbo 和 Spring Cloud?)

相關文章
相關標籤/搜索