目錄
一、什麼是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 提供的一些服務，就像我們現在需要租他們的房子一樣。
但是如果只是租客和房東之間進行尋找的話，他們的效率是很低的，房東找不到租客賺不到錢，租客找不到房東住不了房。所以，後來房東肯定就想到了廣播自己的房源信息(比如在街邊貼貼小廣告)，這樣對於房東來說已經完成他的任務(將房源公佈出去)，但是有兩個問題就出現了。第一、其他不是租客的都能收到這種租房消息，這在現實世界沒什麼，但是在計算機的世界中就會出現 資源消耗 的問題了。第二、租客這樣還是很難找到你，試想一下我需要租房，我還需要東一個西一個地去找街邊小廣告，麻不麻煩？
那怎麼辦呢？我們當然不會那麼傻乎乎的，第一時間就是去找 中介 呀，它爲我們提供了統一房源的地方，我們消費者只需要跑到它那裏去找就行了。而對於房東來說，他們也只需要把房源在中介那裏發佈就行了。
那麼現在，我們的模式就是這樣的了。
但是，這個時候還會出現一些問題。
- 房東註冊之後如果不想賣房子了怎麼辦？我們是不是需要讓房東 定期續約 ？如果房東不進行續約是不是要將他們從中介那裏的註冊列表中 移除 。
- 租客是不是也要進行 註冊 呢？不然合同乙方怎麼來呢？
- 中介可不可以做 連鎖店 呢？如果這一個店因爲某些不可抗力因素而無法使用，那麼我們是否可以換一個連鎖店呢？
針對上面的問題我們來重新構建一下上面的模式圖
好了，舉完這個栗子我們就可以來看關於 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學習資料等你來拿！！！
有想要獲取這份學習資料的同學可以點擊這裏免費獲取》》》》》》》