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


一、概念

       微服務(Microservices)是一種架構風格,一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署,各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下,每個任務代表着一個小的業務能力。

旨在:通過將功能分解到各個離散的服務中以實現對解決方案的解耦。將其看作是在架構層次而非獲取服務的,它的主要作用是將功能分解到離散的各個服務當中,從而降低系統的耦合性,並提供更加靈活的服務支持。

概念:把一個大型的單個應用程序和服務拆分為數個甚至數十個的支持微服務,它可擴展單個組件而不是整個的應用程序堆棧,從而滿足服務等級協議。

定義:圍繞業務領域組件來創建應用,這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用雲架構和平台式部署、管理和服務功能,使產品交付變得更加簡單。

本質:用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題

1、Dubbo 是什么

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

架構圖:

模塊注解:

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

流程詳解:

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

2、Spring Cloud 是什么

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

重點:

  • 基於 Spring Boot
  • 雲服務、分布式框架集合(眾多)

核心功能:

  • 分布式/版本化配置
  • 服務注冊和發現
  • 路由
  • 服務和服務之間的調用
  • 負載均衡
  • 斷路器
  • 分布式消息傳遞

Spring Cloud 組件架構:

流程:

  • 請求統一通過 API 網關(Zuul)來訪問內部服務。
  • 網關接收到請求后,從注冊中心(Eureka)獲取可用服務。
  • 由 Ribbon 進行均衡負載后,分發到后端具體實例。
  • 微服務之間通過 Feign 進行通信處理業務。
  • Hystrix 負責處理服務超時熔斷。
  • Turbine 監控服務間的調用和熔斷相關指標。

Spring Cloud工具框架

  • Spring Cloud Config 配置中心,利用 Git 集中管理程序的配置。
  • Spring Cloud Netflix 集成眾多Netflix的開源軟件。
  • Spring Cloud Netflix Eureka 服務中心(類似於管家的概念,需要什么直接從這里取,就可以了),一個基於 REST 的服務,用於定位服務,以實現雲端中間層服務發現和故障轉移。
  • Spring Cloud Netflix Hystrix 熔斷器,容錯管理工具,旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。
  • Spring Cloud Netflix Zuul 網關,是在雲平台上提供動態路由,監控,彈性,安全等邊緣服務的框架。Web 網站后端所有請求的前門。
  • Spring Cloud Netflix Archaius 配置管理 API,包含一系列配置管理API,提供動態類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。
  • Spring Cloud Netflix Ribbon 負載均衡。
  • Spring Cloud Netflix Fegin REST客戶端。
  • Spring Cloud Bus 消息總線,利用分布式消息將服務和服務實例連接在一起,用於在一個集群中傳播狀態的變化。
  • Spring Cloud for Cloud Foundry 利用 Pivotal Cloudfoundry 集成你的應用程序。
  • Spring Cloud Cloud Foundry Service Broker 為建立管理雲托管服務的服務代理提供了一個起點。
  • Spring Cloud Cluster 集群工具,基於 Zookeeper, Redis, Hazelcast, Consul 實現的領導選舉和平民狀態模式的抽象和實現。
  • Spring Cloud Consul 基於 Hashicorp Consul 實現的服務發現和配置管理。
  • Spring Cloud Security 安全控制,在 Zuul 代理中為 OAuth2 REST 客戶端和認證頭轉發提供負載均衡。
  • Spring Cloud Sleuth 分布式鏈路監控,SpringCloud 應用的分布式追蹤系統,和 Zipkin,HTrace,ELK 兼容。
  • Spring Cloud Data Flow 一個雲本地程序和操作模型,組成數據微服務在一個結構化的平台上。
  • Spring Cloud Stream 消息組件,基於 Redis,Rabbit,Kafka 實現的消息微服務,簡單聲明模型用以在 Spring Cloud 應用中收發消息。
  • Spring Cloud Stream App Starters 基於 Spring Boot 為外部系統提供 Spring 的集成。
  • Spring Cloud Task 短生命周期的微服務,為 Spring Booot 應用簡單聲明添加功能和非功能特性。
  • Spring Cloud Task App Starters。
  • Spring Cloud Zookeeper 服務發現和配置管理基於 Apache Zookeeper。
  • Spring Cloud for Amazon Web Services 快速和亞馬遜網絡服務集成。
  • Spring Cloud Connectors 便於PaaS應用在各種平台上連接到后端像數據庫和消息經紀服務。
  • Spring Cloud Starters (項目已經終止並且在 Angel.SR2 后的版本和其他項目合並)
  • Spring Cloud CLI 命令行工具,插件用 Groovy 快速的創建 Spring Cloud 組件應用。

二、Dubbo和Spring Cloud區別

     Dubbo 的功能只是 Spring Cloud 體系的一部分。Dubbo 是 SOA 時代的產物,它的關注點主要在於服務調用,流量分發、流量監控和熔斷。而 Spring Cloud 誕生於微服務架構時代,考慮的是微服務治理的方方面面,另外由於依托Spring、Spring Boot 的優勢之上,兩個框架在開始目標就不一致,Dubbo 定位服務治理、Spring Cloud 是一個生態。
僅關注於服務治理的這個層面,Dubbo 優於 Spring Cloud:

  • Dubbo 支持更多的協議,如:rmi、hessian、http、webservice、thrift、memcached、redis 等。
  • Dubbo Admin有更強大的后台管理,Dubbo 提供的后台管理 Dubbo Admin 功能強大,提供路由規則、動態配置、訪問控制、權重調節、均衡負載等諸多強大的功能
  • Dobbo Registry 嚴重依賴第三方組件(zookeeper 或者 redis),當這些組件出現問題時,服務調用很快就會中斷
  • Dubbo 使用 RPC 協議效率更高,Dubbo由於是二進制的傳輸,占用帶寬會更少
  • Spring Cloud 是http協議傳輸,帶寬會比較多,同時使用http協議一般會使用JSON報文,消耗會更大,在極端壓力測試下,Dubbo 的效率會高於 Spring Cloud 效率一倍多,但RESTful比RPC更加靈活,不存在代碼級別的強依賴
  • 可以限制某個 IP 流量的訪問權限,設置不同服務器分發不同的流量權重,並且支持多種算法,利用這些功能可以在線上做服務治理、灰度發布、故障轉移、流量分發等,Spring Cloud 到現在還不支持灰度發布、流量權重等功能。
  • 最大的區別就是通信方式不同,Dubbo底層是使用Netty這樣的NIO框架,是基於TCP協議傳輸,配合hession序列化進行RPC調用,springcloud是基於REST調用
  • Spring Cloud提供了 Docker 及 Kubernetes 微服務編排支持

服務調用方式的不同

 

 

Dubbo 和 Spring Cloud 對比

 

 

 

 

三、ZooKeeper 和 Eureka 的區別

      鑒於服務發現對服務化架構的重要性,Dubbo 實踐通常以 ZooKeeper 為注冊中心(Dubbo 原生支持的 Redis 方案需要服務器時間同步,且性能消耗過大)。針對分布式領域著名的 CAP 理論(C——數據一致性,A——服務可用性,P——服務對網絡分區故障的容錯性),Zookeeper 保證的是 CP ,但對於服務發現而言,可用性比數據一致性更加重要,AP 勝過 CP,而 Eureka 設計則遵循 AP 原則
Spring Cloud 支持 Consul(CA)和 Zookeeper,但不推薦使用。

 

參考資料:https://www.cnblogs.com/xishuai/p/dubbo-and-spring-cloud.html


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM