一、什么是Spring cloud

構建分布式系統不需要復雜和容易出錯，Spring Cloud 為最常見的分布式系統模式提供了一種簡單且易于接受的編程模型，幫助開發人員構建有彈性的、可靠的、協調的應用程式，Spring Cloud 構建于 Spring Boot 之上，使得開發者很容易入手并快速應用于生產中，

官方果然官方，介紹都這么有板有眼的，

我所理解的 Spring Cloud 就是微服務系統架構的一站式解決方案，在平時我們構建微服務的程序中需要做如 服務發現注冊 、配置中心 、訊息總線 、負載均衡 、斷路器 、資料監控 等操作，而 Spring Cloud 為我們提供了一套簡易的編程模型，使我們能在 Spring Boot 的基礎上輕松地實作微服務專案的構建，

二、Spring Cloud 的版本

當然這個只是個題外話，

Spring Cloud 的版本號并不是我們通常見的數字版本號，而是一些很奇怪的單詞，這些單詞均為英國倫敦地鐵站的站名，同時根據字母表的順序來對應版本時間順序，比如：最早 的 Release 版本Angel ，第二個 Release 版本 Brixton （英國地名），然后是 Camden 、 Dalston 、 Edgware 、 Finchley 、Greenwich 、 Hoxton ，

三、Spring Cloud 的服務發現框架——Eureka

Eureka 是基于 REST （代表性狀態轉移）的服務，主要在 AWS 云中用于定位服務，以實作負載均衡和中間層服務器的故障轉移，我們稱此服務為 Eureka 服務器，Eureka還帶有一個基于 Java 的客戶端組件 Eureka Client ，它使與服務的互動變得更加容易，客戶端還具有一個內置的負載平衡器，可以執行基本的回圈負載平衡，在 Netflix ，更復雜的負載均衡器將 Eureka 包裝起來，以基于流量，資源使用，錯誤條件等多種因素提供加權負載均衡，以提供出色的彈性，

總的來說， Eureka 就是一個服務發現框架，何為服務，何又為發現呢？

舉一個生活中的例子，就比如我們平時租房子找中介的事情，

在沒有中介的時候我們需要一個一個去尋找是否有房屋要出租的房東，這顯然會非常的費力，一你找憑一個人的能力是找不到很多房源供你選擇，再者你也懶得這么找下去(找了這么久，沒有合適的只能將就)，這里的我們就相當于微服務中的 Consumer ，而那些房東就相當于微服務中的 Provider ，消費者 Consumer 需要呼叫提供者 Provider 提供的一些服務，就像我們現在需要租他們的房子一樣，

但是如果只是租客和房東之間進行尋找的話，他們的效率是很低的，房東找不到租客賺不到錢，租客找不到房東住不了房，所以，后來房東肯定就想到了廣播自己的房源資訊(比如在街邊貼貼小廣告)，這樣對于房東來說已經完成他的任務(將房源公布出去)，但是有兩個問題就出現了，第一、其他不是租客的都能收到這種租房訊息，這在現實世界沒什么，但是在計算機的世界中就會出現 資源消耗 的問題了，第二、租客這樣還是很難找到你，試想一下我需要租房，我還需要東一個西一個地去找街邊小廣告，麻不麻煩？

那怎么辦呢？我們當然不會那么傻乎乎的，第一時間就是去找 中介 呀，它為我們提供了統一房源的地方，我們消費者只需要跑到它那里去找就行了，而對于房東來說，他們也只需要把房源在中介那里發布就行了，

那么現在，我們的模式就是這樣的了，

但是，這個時候還會出現一些問題，

1. 房東注冊之后如果不想賣房子了怎么辦？我們是不是需要讓房東 定期續約 ？如果房東不進行續約是不是要將他們從中介那里的注冊串列中 移除 ，
2. 租客是不是也要進行 注冊 呢？不然合同乙方怎么來呢？
3. 中介可不可以做 連鎖店 呢？如果這一個店因為某些不可抗力因素而無法使用，那么我們是否可以換一個連鎖店呢？

針對上面的問題我們來重新構建一下上面的模式圖

好了，舉完這個栗子我們就可以來看關于 Eureka 的一些基礎概念了，你會發現這東西理解起來怎么這么簡單，

服務發現：其實就是一個“中介”，整個程序中有三個角色：服務提供者(出租房子的)、服務消費者(租 客)、服務中介(房屋中介)，

服務提供者： 就是提供一些自己能夠執行的一些服務給外界，

服務消費者： 就是需要使用一些服務的“用戶”，

服務中介： 其實就是服務提供者和服務消費者之間的“橋梁”，服務提供者可以把自己注冊到服務中介那里，而服務消費者如需要消費一些服務(使用一些功能)就可以在服務中介中尋找注冊在服務中介的服務提供者，

服務注冊 Register：

官方解釋：當 Eureka 客戶端向 Eureka Server 注冊時，它提供自身的元資料，比如IP地址、埠，運行狀況指示符URL，主頁等，

結合中介理解：房東 (提供者 Eureka Client Provider )在中介 (服務器 Eureka Server ) 那里登記房屋的資訊，比如面積，價格，地段等等(元資料 metaData )，

服務續約 Renew：

官方解釋： Eureka 客戶會每隔30秒(默認情況下)發送一次心跳來續約， 通過續約來告知 Eureka Server 該 Eureka 客戶仍然存在，沒有出現問題， 正常情況下，如果 Eureka Server 在90秒沒有收到 Eureka 客戶的續約，它會將實體從其注冊表中洗掉，

結合中介理解：房東 (提供者 Eureka Client Provider ) 定期告訴中介 (服務器 Eureka Server ) 我的房子還租(續約) ，中介 (服務器 Eureka Server ) 收到之后繼續保留房屋的資訊，

獲取注冊串列資訊 Fetch Registries：

官方解釋： Eureka 客戶端從服務器獲取注冊表資訊，并將其快取在本地，客戶端會使用該資訊查找其他服務，從而進行遠程呼叫，該注冊串列資訊定期（每30秒鐘）更新一次，每次回傳注冊串列資訊可能與 Eureka 客戶端的快取資訊不同, Eureka 客戶端自動處理，如果由于某種原因導致注冊串列資訊不能及時匹配， Eureka 客戶端則會重新獲取整個注冊表資訊， Eureka 服務器快取注冊串列資訊，整個注冊表以及每個應用程式的資訊進行了壓縮，壓縮內容和沒有壓縮的內容完全相同， Eureka 客戶端和 Eureka 服務器可以使用JSON / XML格式進行通訊，在默認的情況下 Eureka 客戶端使用壓縮 JSON 格式來獲取注冊串列的資訊，

結合中介理解：租客(消費者 Eureka Client Consumer ) 去中介 (服務器 Eureka Server ) 那里獲取所有的房屋資訊串列 (客戶端串列 Eureka Client List ) ，而且租客為了獲取最新的資訊會定期向中介 (服務器 Eureka Server ) 那里獲取并更新本地串列，

服務下線 Cancel：

官方解釋：Eureka客戶端在程式關閉時向Eureka服務器發送取消請求， 發送請求后，該客戶端實體資訊將從服務器的實體注冊表中洗掉，該下線請求不會自動完成，它需要呼叫以下內容：DiscoveryManager.getInstance().shutdownComponent();

結合中介理解：房東 (提供者 Eureka Client Provider ) 告訴中介 (服務器 Eureka Server ) 我的房子不租了，中介之后就將注冊的房屋資訊從串列中剔除，

服務剔除 Eviction：

官方解釋：在默認的情況下，當Eureka客戶端連續90秒(3個續約周期)沒有向Eureka服務器發送服務續約，即心跳，Eureka服務器會將該服務實體從服務注冊串列洗掉，即服務剔除，

結合中介理解：房東(提供者 Eureka Client Provider ) 會定期聯系 中介 (服務器 Eureka Server )告訴他我的房子還租(續約)，如果中介 (服務器 Eureka Server ) 長時間沒收到提供者的資訊，那么中介會將他的房屋資訊給下架(服務剔除)，

下面就是 Netflix 官方給出的 Eureka 架構圖，你會發現和我們前面畫的中介圖別無二致，

當然，可以充當服務發現的組件有很多： Zookeeper ， Consul ， Eureka 等，

四、負載均衡之 Ribbon

1.什么是 RestTemplate ?

不是講 Ribbon 么？怎么扯到了 RestTemplate 了？你先別急，聽我慢慢道來，

我不聽我不聽我不聽，我就說一句！ RestTemplate 是 Spring 提供的一個訪問Http服務的客戶端類，怎么說呢？就是微服務之間的呼叫是使用的 RestTemplate ，比如這個時候我們 消費者B 需要呼叫 提供者A 所提供的服務我們就需要這么寫，如我下面的偽代碼，

@Autowired 
private RestTemplate restTemplate; 
// 這里是提供者A的ip地址，但是如果使用了 Eureka 那么就應該是提供者A的名稱 
private static final String SERVICE_PROVIDER_A = "http://localhost:8081"; 

@PostMapping("/judge") 
public boolean judge(@RequestBody Request request) { 
	String url = SERVICE_PROVIDER_A + "/service1"; 
	return restTemplate.postForObject(url, request, Boolean.class); 
}

如果你對原始碼感興趣的話，你會發現上面我們所講的 Eureka 框架中的 注冊、續約 等，底層都是使用的 RestTemplate ，

2.為什么需要 Ribbon？

Ribbon 是 Netflix 公司的一個開源的負載均衡 專案，是一個客戶端/行程內負載均衡器，運行在消費者端，

我們再舉個栗子，比如我們設計了一個秒殺系統，但是為了整個系統的 高可用 ，我們需要將這個系統做一個集群，而這個時候我們消費者就可以擁有多個秒殺系統的呼叫途徑了，如下圖，

如果這個時候我們沒有進行一些 均衡操作 ，如果我們對 秒殺系統1 進行大量的呼叫，而另外兩個基本不請求，就會導致 秒殺系統1 崩潰，而另外兩個就變成了傀儡，那么我們為什么還要做集群，我們高可用體現的意義又在哪呢？

所以 Ribbon 出現了，注意我們上面加粗的幾個字——運行在消費者端，指的是， Ribbon 是運行在消費者端的負載均衡器，如下圖，

其作業原理就是 Consumer 端獲取到了所有的服務串列之后，在其內部使用負載均衡演算法，進行對多個系統的呼叫，

3.Nginx 和 Ribbon 的對比

提到 負載均衡 就不得不提到大名鼎鼎的 Nignx 了，而和 Ribbon 不同的是，它是一種集中式的負載均衡器，

何為集中式呢？簡單理解就是 將所有請求都集中起來，然后再進行負載均衡，如下圖，

我們可以看到 Nginx 是接收了所有的請求進行負載均衡的，而對于 Ribbon 來說它是在消費者端進行的負載均衡，如下圖，

請注意 Request 的位置，在 Nginx 中請求是先進入負載均衡器，而在 Ribbon 中是先在客戶端進行負載均衡才進行請求的，

4.Ribbon 的幾種負載均衡演算法

負載均衡，不管 Nginx 還是Ribbon都需要其演算法的支持，如果我沒記錯的話 Nginx 使用的是 輪詢和加權輪詢演算法，而在 Ribbon 中有更多的負載均衡調度演算法，其默認是使用的 RoundRobinRule 輪詢策略，

• RoundRobinRule ：輪詢策略， Ribbon 默認采用的策略，若經過一輪輪詢沒有找到可用的provider ，其最多輪詢 10 輪，若最侄訓沒有找到，則回傳 null ，
• RandomRule : 隨機策略，從所有可用的 provider 中隨機選擇一個，
• RetryRule : 重試策略，先按照 RoundRobinRule 策略獲取 provider ，若獲取失敗，則在指定的時限內重試，默認的時限為 500 毫秒，

還有很多，這里不一一舉了栗子，你最需要知道的是默認輪詢演算法，并且可以更換默認的負載均衡演算法，只需要在組態檔中做出修改就行，

providerName: 
	ribbon: 
		NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

當然，在 Ribbon 中你還可以自定義負載均衡演算法，你只需要實作 IRule 介面，然后修改組態檔或者自定義 Java Config 類，

五、什么是 Open Feign

有了 Eureka ， RestTemplate ， Ribbon ， 我們就可以愉快地進行服務間的呼叫了，但是使用 RestTemplate 還是不方便，我們每次都要進行這樣的呼叫，

@Autowired 
private RestTemplate restTemplate; 
// 這里是提供者A的ip地址，但是如果使用了 Eureka 那么就應該是提供者A的名稱 
private static final String SERVICE_PROVIDER_A = "http://localhost:8081"; 

@PostMapping("/judge") 
public boolean judge(@RequestBody Request request) { 
	String url = SERVICE_PROVIDER_A + "/service1"; 
	// 是不是太麻煩了？？？每次都要 url、請求、回傳型別的 
	return restTemplate.postForObject(url, request, Boolean.class); 
}

這樣每次都呼叫 RestRemplate 的 API 是否太麻煩，我能不能像呼叫原來代碼一樣進行各個服務間的呼叫呢？

聰明的小朋友肯定想到了，那就用 映射 呀，就像域名和IP地址的映射，我們可以將被呼叫的服務代碼映射到消費者端，這樣我們就可以 “無縫開發” 啦，

OpenFeign 也是運行在消費者端的，使用 Ribbon 進行負載均衡，所以 OpenFeign 直接內置了 Ribbon ，

在匯入了 Open Feign 之后我們就可以進行愉快撰寫 Consumer 端代碼了，

// 使用 @FeignClient 注解來指定提供者的名字 
@FeignClient(value = "eureka-client-provider") 
public interface TestClient { 
	// 這里一定要注意需要使用的是提供者那端的請求相對路徑，這里就相當于映射了 
	@RequestMapping(value = "/provider/xxx", 
	method = RequestMethod.POST) 
	CommonResponse<List<Plan>> getPlans(@RequestBody planGetRequest request); 
}

然后我們在 Controller 就可以像原來呼叫 Service 層代碼一樣呼叫它了，

@RestController 
public class TestController { 
	// 這里就相當于原來自動注入的 Service 
	@Autowired 
	private TestClient testClient; 
	// controller 呼叫 service 層代碼 
	@RequestMapping(value = "/test", method = RequestMethod.POST) 
	public CommonResponse<List<Plan>> get(@RequestBody planGetRequest request) { 
		return testClient.getPlans(request); 
	} 
}

參考資料：《Java中高級核心知識全面決議》限量100份，有一些人已經通過我之前的文章獲取了哦！
名額有限先到先得！！！還有更多Java Pdf學習資料等你來拿！！！
有想要獲取這份學習資料的同學可以點擊這里免費獲取》》》》》》》