一篇文章徹底搞懂Spring Cloud 和 Dubbo！

微服務

SOA: 面向服務的架構，將服務拆分後註冊到企業總線統一對外提供服務

微服務：業務系統徹底組件化，將應用拆分爲多個小的應用，這些應用從web UI到服務api都是獨立的完整的一個整體。

微服務特點：單一職責，自治。

微服務與SOA的區別：微服務不再強調傳統SOA架構裏面比較重的ESB企業服務總線，微服務將業務系統徹底的組件化。

微服務優點：

1、邏輯清晰，每個服務只負責自己的那部分業務
2、擴展方便，只需修改當前的微服務，且部署的時候也不會影響其他模塊
3、高可用，分佈式部署提高了整體應用的吞吐量，對某些訪問量比較高的服務可以單獨擴充節點 4、技術異構，不同的團隊維護不同的服務時，可以根據自己熟悉的技術棧去實現並不會影響其他人。

微服務缺點：

1、相對於單體應用，複雜度相對較高
2、維護成本較高，應用拆分出大量的微服務一定程度上也會增加運維的成本
3、相對單體應用的本地調用，微服務之間相互調用需要使用Rest、RPC等方式，一定程度上影響了性能。

另外也整理了spring cloud和dubbo的資料和其他Java知識點，需要的朋友可以點擊：點這個，點這個，暗號：csdn。

spring cloud

Spring Cloud Netflix Eureka 與服務治理：
服務發現與調用流程圖

三個服務A,B,C都是多實例部署在集羣環境中，都需要到註冊中心註冊，B,C作爲A的服務提供者，A需要通過負載均衡器找到B，C完成服務調用，負載均衡器從註冊中心獲取服務的定義信息。

服務治理涉及的角色主要有三種：

• 註冊中心：提供服務的註冊和發現
• 服務提供者：服務提供者將自身服務註冊到註冊中心，從而使消費者能夠找到
• 服務消費者：從註冊中心獲取註冊服務列表，從而完成消費

服務治理的策略：

輪詢機制：消費者定時去註冊中心拉取最新的服務列表並更新本地緩存
監聽和通知機制：註冊中心註冊服務列表發生變化時，觸發回調通知消費者更新本地緩存。

服務治理實現工具：Zookeeper(Java)、Consul(Go)、Eureka(Java)

搭建一個Eureka服務非常簡單，引入spring-cloud-starter-eureka-server依賴，在啓動類上添加@EnableEurekaServer就完成了。Euraka可以通過相互註冊（eureka.client.serviceUrl.defaultZone:多個eureka-url）的方式形成一個集羣。

Eureka客戶端的搭建也非常簡單，引入依賴spring-cloud-starter-eureka，在啓動類上添加註解@EnableEurekaClient，配置文件中添加配置eureka.client.serviceUrl.defaultZone:eureka-server-url
獲取註冊到Eureka服務器上的具體某一個服務實例的詳細信息可以通過訪問http:eureka-service-url/eureka/apps/appid(servername)

Eureka基本架構

Spring cloud Netflix Ribbon 負載均衡

所有的服務實例註冊到註冊中心後，Ribbon從註冊中心獲取服務列表實現負載均衡。

負載均衡的類型：

1、服務端負載均衡，在客戶端與服務端之間加一個代理，訪問代理，代理將請求轉發到某個微服務節點上

2、客戶端負載均衡，負載均衡器與客戶端爲一個整體，客戶端在發起請求時首先根據負載均衡器定位到本次訪問的目的節點，然後發起請求。

Ribbon是一種客戶端負載均衡方案。

還有最近最新的大廠面試題，需要的朋友可以點擊：點這個，點這個，暗號：csdn。

負載均衡的算法：

1、靜態負載均衡算法：隨機算法，使用JDK自帶的隨機算法或者改進後的加權隨機算法;輪詢算法：輪詢或者加權輪詢

2、動態負載均衡算法：最少連接數算法，統計每個節點的被調用次數，調用次數較少的優先調用；服務調用延時算法，根據各節點響應的平均時間來調整調用優先級；源IP Hash算法，計算源IPde Hash值決定調用哪個節點，可以保證同一個客戶端每次調用的都是同一個服務節點。

使用Ribbon實現負載均衡：

Ribbon作爲一種客戶端負載均衡的實現方案，不需要獨立部署，而是直接嵌入在服務消費者的代碼中。

有兩種使用方式：
1、使用@LoadBalanced和RestTemplate
2、使用@RibbonClient註解

使用：
引入依賴spring-boot-starter-ribbon，通過@LoadBalanced註解創建RestTemplate，然後通過RestTemplate調用http://serverName(服務生產者的服務名稱)/api(調用的接口),實際上是Ribbon跟據serverName從註冊中心獲取對應的Ip和port信息列表，按照負載均衡算法得到當前應該訪問的服務節點，將url替換掉進行訪問。

Spring Cloud Netflix Hystrix 服務容錯

Hystrix提供三種容錯處理：

1、隔離（線程隔離和信號量隔離）線程隔離相當於維護多個線程池
2、熔斷 維護一個請求失敗的計數器，當一個請求異常調用次數到達一個閾值，觸發熔斷器開啓，開後後到達一定時間，進入半開啓狀態，允許部分請求進入，若全部成功，或者成功達到一定比例，關閉熔斷器。
3、回退 服務回退指調用失敗後不是直接拋出異常而是用另外的代碼去處理

Spring Cloud Netflix Zuul Api網關

解耦服務調用：服務消費者只需要關注網關而不需要關注服務本身的提供者
優化Api：爲不同的調用者產生不用的響應，例如用戶查詢pc一次性查詢全部數據而App分頁查詢。
簡化調用過程：可以將一些需要多個微服務結合才能實現的接口整合
服務路由：提供統一的服務路由供客戶端訪問
安全性控制：統一的認證權限處理
訪問控制：控制客戶端訪問次數和訪問頻率 負載均衡：提供前置的負載均衡功能

zuul使用內部的ZuulFilter鏈處理

Spring Cloud Config 配置中心

提供統一的配置信息管理

實現的兩種方式：

• 基於本地文件系統，文件名稱要跟各個服務的名稱一致；
• 基於中央倉庫（GIT）實現

Dubbo

Dubbo+Zookeeper

將接口抽象出來定義好，發佈到倉庫，服務提供者依賴api模塊，實現接口，添加@Service註冊到zk上，服務消費者只需要引用Api模塊，使用@Reference引用就可以了。 服務提供者和服務消費者都需要依賴dubbo的相關依賴和Zookeeper的相關依賴，都需要註冊到Zookeeper上。

Dubbo是阿里巴巴開發的一款Java服務平臺框架以及SOA治理方案，主要功能包括：高性能NIO通信以及多協議集成、服務動態尋址與路由、軟負載均衡與容錯、依賴分析、降級等

注意Dubbo註冊的@Service註解爲Dubbo提供的，消費者使用@Reference

RPC: 遠程過程調用，可以使消費者服務像調用本地方法一樣調用遠程服務提供的方法。
整體流程爲：確定遠程服務地址（ip,port等），建立連接（Tcp）,調用方法以及參數信息序列化通過tcp傳輸給遠程服務，遠程服務接收後本地調用產生結果再返回給消費者。

Dubbo基本原理（個人猜測暫未認證）：識別@Reference註解，生成代理類，從註冊中心或者本地緩存定位遠程訪問得服務列表，根據負載算法確定遠程調用者，使用Netty與遠程服務建立TCP連接，封裝調用信息得消息體，發送給遠程服務，遠程服務解析消息體完成本地調用，返回調用結果，調用可能爲異步得，由客戶端生成唯一得請求id。

SpringCloud和Dubbo的區別

1、SpringCloud使用Rest api通信，Dubbo採用RPC通信，服務之間調用得性能會更好
2、springcloud相關組件多，有自己得註冊中心網關等，集成方便，Dubbo需要自己額外去集成。
3、Dubbo相對更容易上手。

最後

提供免費的Java架構學習資料，學習技術內容包含有：Spring，Dubbo，MyBatis, RPC, 源碼分析，高併發、高性能、分佈式,性能優化，微服務 高級架構開發等等。

需要的朋友可以點擊：點這個！點這個！，暗號：csdn。

還有Java核心知識點+全套架構師學習資料和視頻+一線大廠面試寶典+面試簡歷模板可以領取+阿里美團網易騰訊小米愛奇藝快手嗶哩嗶哩面試題+Spring源碼合集+Java架構實戰電子書+2020年最新大廠面試題。