摘要：集群系統(tǒng)中的單個計算機通常稱為節(jié)點，通常通過局域網(wǎng)連接，但也有其它的可能連接方式。這樣就高興了，可以專心寫自己的，前端就專門交由小周負責了。于是，小周和就變成了協(xié)作開發(fā)。都是為了項目正常運行以及迭代。

只有光頭才能變強

認識我的朋友可能都知道我這陣子去實習啦，去的公司說是用SpringCloud(但我覺得使用的力度并不大啊~~)...

所以，這篇主要來講講SpringCloud的一些基礎的知識。(我就是現(xiàn)學現(xiàn)賣了，主要當做我學習SpringCloud的筆記吧！)當然了，我的水平是有限的，可能會有一些理解錯的的概念/知識點，還請大家不吝在評論區(qū)指正啊~~

SpringCloud GitHub Demo(看完文章的同學可以自己練手玩玩)：

https://github.com/ZhongFuCheng3y/msc-Demo

項目結構圖：

像我這種技術小白，看到這些詞(集群/分布式/微服務/SOA)的時候，感覺就是遙不可及的(高大尚的技術?。?。就好像剛學Java面向對象的時候，在論壇上翻閱資料的時候，無意看到"面向切面編程"，也認為這是遙不可及的(高大尚的技術??！)。

但真正接觸到"面向切面編程"的時候，發(fā)現(xiàn)原來就是如此啊，也沒什么大不了的。只不過當時被它的名字給唬住了...

不知道各位在剛接觸這些名字集群/分布式/微服務/SOA的時候，有沒有被唬住了呢？？

下面我就簡單說說這些名詞的意思

以下內(nèi)容來源維基百科：

計算機集群簡稱集群是一種計算機系統(tǒng)，它通過一組松散集成的計算機軟件和/或硬件連接起來高度緊密地協(xié)作完成計算工作。在某種意義上，他們可以被看作是一臺計算機。集群系統(tǒng)中的單個計算機通常稱為節(jié)點，通常通過局域網(wǎng)連接，但也有其它的可能連接方式。集群計算機通常用來改進單個計算機的計算速度和/或可靠性。一般情況下集群計算機比單個計算機，比如工作站或超級計算機性能價格比要高得多

集群技術特點：

通過多臺計算機完成同一個工作，達到更高的效率。

兩機或多機內(nèi)容、工作過程等完全一樣。如果一臺死機，另一臺可以起作用。

在維基百科上說得也挺明白的了，我來舉個例子吧。

小周在公司寫Java程序，但公司業(yè)務在發(fā)展，一個Java開發(fā)者可能忙不過來，小周有的時候也得請個假呀。于是請了3y過去一起做Java開發(fā)。平時小周和3y就寫Java程序，但3y可能有事要回學校一趟。沒事，公司還有小周做Java開發(fā)呢，公司開發(fā)還能繼續(xù)運作。

3y跟小周都是做Java開發(fā)。

3y來了，小周的工作可以分擔一些。

3y請假了，還有小周在呢。

我寫了一個910便利網(wǎng)發(fā)布到服務器去了，現(xiàn)在越來越多的人訪問了，訪問有點慢，怎么辦？？？很簡單，(只有充錢才能變強)，加配置吧(加cpu，加內(nèi)存)。升級完配置之后，訪問人數(shù)越來越多，于是發(fā)現(xiàn)又不禁用啦，在這臺機器上加配置已經(jīng)解決不了了，怎么辦？？？很簡單，(只有充錢才能變強)，我再買一臺服務器，將910便利網(wǎng)也發(fā)布到新買的這臺服務器上去。

特點：

這兩臺服務器都是運行同一個系統(tǒng)--->910便利網(wǎng)

好處：

本來只有一臺機器處理訪問，現(xiàn)在有兩臺機器處理訪問了，分擔了壓力。

如果其中一臺忘記繳費了，暫時用不了了。沒關系，還有另一臺可以用呢。

集群：同一個業(yè)務，部署在多個服務器上(不同的服務器運行同樣的代碼，干同一件事)

以下內(nèi)容來源維基百科：

分布式系統(tǒng)是一組計算機，通過網(wǎng)絡相互連接傳遞消息與通信后并協(xié)調(diào)它們的行為而形成的系統(tǒng)。組件之間彼此進行交互以實現(xiàn)一個共同的目標。

我也來舉個例子來說明一下吧：

現(xiàn)在公司有小周和3y一起做Java開發(fā)，做Java開發(fā)一般jQuery，AJAX都能寫一點，所以這些活都由我們來干?？墒悄?，3y對前端不是很熟，有的時候調(diào)試半天都調(diào)不出來。老板認為3y是真的菜！于是讓小周專門來處理前端的事情。這樣3y就高興了，可以專心寫自己的Java，前端就專門交由小周負責了。于是，小周和3y就變成了協(xié)作開發(fā)。

3y對前端不熟(能寫出來)，但在調(diào)試的時候可能會花費很多時間

小周來專門做前端的事，3y可以專心寫自己的Java程序了。

都是為了項目正常運行以及迭代。

我的910便利網(wǎng)已經(jīng)部署到兩臺服務器去了，但是越來越多的人去訪問。現(xiàn)在也逐漸承受不住啦。那現(xiàn)在怎么辦??？？那繼續(xù)充錢變強？？作為一個理智的我，肯定得想想是哪里有問題。現(xiàn)在910便利網(wǎng)的模塊有好幾個，全都丟在同一個Tomcat里邊。

其實有些模塊的訪問是很低的(比如后臺管理)，那我可不可以這樣做：將每個模塊抽取獨立出來，訪問量大的模塊用好的服務器裝著，沒啥人訪問的模塊用差的服務器裝著。這樣的好處是：一、資源合理利用了(沒人訪問的模塊用性能差的服務器，訪問量大的模塊多帶帶提升性能就好了)。二、耦合度降低了：每個模塊獨立出來，各干各的事(專業(yè)的人做專業(yè)的事)，便于擴展

特點：

將910便利網(wǎng)的功能拆分，模塊之間獨立，在使用的時候再將這些獨立的模塊組合起來就是一個系統(tǒng)了。

好處：

模塊之間獨立，各做各的事，便于擴展，復用性高

高吞吐量。某個任務需要一個機器運行10個小時，將該任務用10臺機器的分布式跑(將這個任務拆分成10個小任務)，可能2個小時就跑完了

分布式：一個業(yè)務分拆多個子業(yè)務，部署在不同的服務器上(不同的服務器，運行不同的代碼，為了同一個目的)

集群和分布式并不沖突，可以有分布式集群

現(xiàn)在3y的公司規(guī)模變大了，有5個小伙子寫Java，4個小伙子寫前端，2個小伙子做測試，1個小伙子做DBA。

Java，前端，測試，DBA的關系看作是分布式的

5個Java看作是集群的(前端，測試同理)...

其實我認為分布式/微服務/SOA這三個概念是差不多的，了解了其中的一個，然后將自己的理解往上面套就好了。沒必要細分每個的具體概念~~(當然了，我很期待有大佬可以在評論區(qū)留言說下自己的看法哈)

參考資料：

分布式與集群的區(qū)別是什么？https://www.zhihu.com/question/20004877

分布式、集群、微服務、SOA 之間的區(qū)別https://blog.csdn.net/heatdeath/article/details/79038795

從上面所講的分布式概念我們已經(jīng)知道，分布式簡單理解就是：一個業(yè)務分拆多個子業(yè)務，部署在不同的服務器上

一般來說，一個子業(yè)務我們稱為節(jié)點。

如果你接觸過一些分布式的基礎概念，那肯定會聽過CAP這個理論。就比如說：你學了MySQL的InnoDB存儲引擎相關知識，你肯定聽過ACID！

首先，我們來看一下CAP分別代表的是什么意思：

C：數(shù)據(jù)一致性(consistency)

所有節(jié)點擁有數(shù)據(jù)的最新版本

A：可用性(availability)

數(shù)據(jù)具備高可用性

P：分區(qū)容錯性(partition-tolerance)

容忍網(wǎng)絡出現(xiàn)分區(qū)，分區(qū)之間網(wǎng)絡不可達。

下面有三個節(jié)點(它們是集群的)，此時三個節(jié)點都能夠相互通信：

由于我們的系統(tǒng)是分布式的，節(jié)點之間的通信是通過網(wǎng)絡來進行的。只要是分布式系統(tǒng)，那很有可能會出現(xiàn)一種情況：因為一些故障，使得有些節(jié)點之間不連通了，整個網(wǎng)絡就分成了幾塊區(qū)域。

數(shù)據(jù)就散布在了這些不連通的區(qū)域中，這就叫分區(qū)

現(xiàn)在出現(xiàn)了網(wǎng)絡分區(qū)后，此時有一個請求過來了，想要注冊一個賬戶。

此時我們節(jié)點一和節(jié)點三是不可通信的，這就有了抉擇：

如果允許當前用戶注冊一個賬戶，此時注冊的記錄數(shù)據(jù)只會在節(jié)點一和節(jié)點二或者節(jié)點二和節(jié)點三同步，因為節(jié)點一和節(jié)點三的記錄不能同步的。

這種情況其實就是選擇了可用性(availability)，拋棄了數(shù)據(jù)一致性(consistency)

如果不允許當前用戶注冊一個賬戶(就是要等到節(jié)點一和節(jié)點三恢復通信)。節(jié)點一和節(jié)點三一旦恢復通信，我們就可以保證節(jié)點擁有的數(shù)據(jù)是最新版本。

這種情況其實就是拋棄了可用性(availability)，選擇了數(shù)據(jù)一致性(consistency)

一般我們說的分布式系統(tǒng)，P：分區(qū)容錯性(partition-tolerance)這個是必需的，這是客觀存在的。

CAP是無法完全兼顧的，從上面的例子也可以看出，我們可以選AP，也可以選CP。但是，要注意的是：不是說選了AP，C就完全拋棄了。不是說選了CP，A就完全拋棄了！

在CAP理論中，C所表示的一致性是強一致性(每個節(jié)點的數(shù)據(jù)都是最新版本)，其實一致性還有其他級別的：

弱一致性：弱一致性是相對于強一致性而言，它不保證總能得到最新的值；

最終一致性(eventual consistency)：放寬對時間的要求，在被調(diào)完成操作響應后的某個時間點，被調(diào)多個節(jié)點的數(shù)據(jù)最終達成一致

可用性的值域可以定義成0到100%的連續(xù)區(qū)間。

所以，CAP理論定義的其實是在容忍網(wǎng)絡分區(qū)的條件下，“強一致性”和“極致可用性”無法同時達到。

參考資料：

CAP理論中的P到底是個什么意思？https://www.zhihu.com/question/54105974

淺談分布式系統(tǒng)的基本問題：可用性與一致性：https://m.aliyun.com/yunqi/articles/2709

分布式系統(tǒng)的CAP理論：http://www.hollischuang.com/archives/666

為什么CAP理論在舍棄P的情況下，可以有完美的CA？https://www.zhihu.com/question/285878189

不懂點CAP理論，你好意思說你是做分布式的嗎？http://www.yunweipai.com/archives/8432.html

擴展閱讀：

淺談分布式事務：https://m.aliyun.com/yunqi/articles/230242

相信大家讀到這里，對分布式/微服務已經(jīng)有一定的了解了，其實單從概念來說，是非常容易理解的。只是很可能被它的名字給唬住了。

下面我就來講講SpringCloud最基礎的知識~

前面也講了，從分布式/微服務的角度而言：就是把我們一大的項目，分解成多個小的模塊。這些小的模塊組合起來，完成功能。

舉個可能不太恰當?shù)睦?現(xiàn)實可能不會這么拆分，但意思到位就好了)：

拆分出多個模塊以后，就會出現(xiàn)各種各樣的問題，而SpringCloud提供了一整套的解決方案！

注：這些模塊是獨立成一個子系統(tǒng)的(不同主機)。

SpringCloud的基礎功能：

服務治理： Spring Cloud Eureka

客戶端負載均衡： Spring Cloud Ribbon

服務容錯保護： Spring Cloud Hystrix

聲明式服務調(diào)用： Spring Cloud Feign

API網(wǎng)關服務：Spring Cloud Zuul

分布式配置中心： Spring Cloud Config

SpringCloud的高級功能(本文不講)：

消息總線： Spring Cloud Bus

消息驅動的微服務： Spring Cloud Stream

分布式服務跟蹤： Spring Cloud Sleuth

那會出現(xiàn)什么問題呢？？首當其沖的就是子系統(tǒng)之間的通訊問題。子系統(tǒng)與子系統(tǒng)之間不是在同一個環(huán)境下，那就需要遠程調(diào)用。遠程調(diào)用可能就會想到httpClient，WebService等等這些技術來實現(xiàn)。

既然是遠程調(diào)用，就必須知道ip地址，我們可能有以下的場景。

功能實現(xiàn)一：A服務需要調(diào)用B服務

在A服務的代碼里面調(diào)用B服務，顯式通過IP地址調(diào)用：http://123.123.123.123:8888/java3y/3

功能實現(xiàn)二：A服務調(diào)用B服務，B服務調(diào)用C服務，C服務調(diào)用D服務

在A服務的代碼里面調(diào)用B服務，顯式通過IP地址調(diào)用：http://123.123.123.123:8888/java3y/3，(同樣地)B->C，C->D

功能實現(xiàn)三：D服務調(diào)用B服務，B服務調(diào)用C服務

在D服務的代碼里面調(diào)用B服務，顯式通過IP地址調(diào)用：http://123.123.123.123:8888/java3y/3，(同樣地)B->C

.....等等等等

萬一，我們B服務的IP地址變了，想想會出現(xiàn)什么問題：A服務,D服務(等等)需要手動更新B服務的地址

在服務多的情況下，手動來維護這些靜態(tài)配置就是噩夢！

為了解決微服務架構中的服務實例維護問題(ip地址)， 產(chǎn)生了大量的服務治理框架和產(chǎn)品。 這些框架和產(chǎn)品的實現(xiàn)都圍繞著服務注冊與服務發(fā)現(xiàn)機制來完成對微服務應用實例的自動化管理。

在SpringCloud中我們的服務治理框架一般使用的就是Eureka。

我們的問題：

現(xiàn)在有A、B、C、D四個服務，它們之間會互相調(diào)用(而且IP地址很可能會發(fā)生變化)，一旦某個服務的IP地址變了，那服務中的代碼要跟著變，手動維護這些靜態(tài)配置(IP)非常麻煩！

Eureka是這樣解決上面所說的情況的：

創(chuàng)建一個E服務，將A、B、C、D四個服務的信息都注冊到E服務上，E服務維護這些已經(jīng)注冊進來的信息

A、B、C、D四個服務都可以拿到Eureka(服務E)那份注冊清單。A、B、C、D四個服務互相調(diào)用不再通過具體的IP地址，而是通過服務名來調(diào)用！

拿到注冊清單--->注冊清單上有服務名--->自然就能夠拿到服務具體的位置了(IP)。

其實簡單來說就是：代碼中通過服務名找到對應的IP地址(IP地址會變，但服務名一般不會變)

Eureka專門用于給其他服務注冊的稱為Eureka Server(服務注冊中心)，其余注冊到Eureka Server的服務稱為Eureka Client。

在Eureka Server一般我們會這樣配置：

    register-with-eureka: false     #false表示不向注冊中心注冊自己。
    fetch-registry: false     #false表示自己端就是注冊中心，我的職責就是維護服務實例，并不需要去檢索服務

Eureka Client分為服務提供者和服務消費者。

但很可能，某服務既是服務提供者又是服務消費者。

如果在網(wǎng)上看到SpringCloud的某個服務配置沒有"注冊"到Eureka-Server也不用過于驚訝(但是它是可以獲取Eureka服務清單的)

很可能只是作者把該服務認作為單純的服務消費者，單純的服務消費者無需對外提供服務，也就無須注冊到Eureka中了

eureka:
  client:
    register-with-eureka: false  # 當前微服務不注冊到eureka中(消費端)
    service-url: 
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/  

下面是Eureka的治理機制：

服務提供者

服務注冊：啟動的時候會通過發(fā)送REST請求的方式將自己注冊到Eureka Server上，同時帶上了自身服務的一些元數(shù)據(jù)信息。

服務續(xù)約：在注冊完服務之后，服務提供者會維護一個心跳用來持續(xù)告訴Eureka Server: "我還活著 ” 、

服務下線：當服務實例進行正常的關閉操作時，它會觸發(fā)一個服務下線的REST請求給Eureka Server, 告訴服務注冊中心：“我要下線了 ”。

服務消費者

獲取服務：當我們啟動服務消費者的時候，它會發(fā)送一個REST請求給服務注冊中心，來獲取上面注冊的服務清單

服務調(diào)用：服務消費者在獲取服務清單后，通過服務名可以獲得具體提供服務的實例名和該實例的元數(shù)據(jù)信息。在進行服務調(diào)用的時候，優(yōu)先訪問同處一個Zone中的服務提供方。

Eureka Server(服務注冊中心)：

失效剔除：默認每隔一段時間（默認為60秒） 將當前清單中超時（默認為90秒）沒有續(xù)約的服務剔除出去。

自我保護：。EurekaServer 在運行期間，會統(tǒng)計心跳失敗的比例在15分鐘之內(nèi)是否低于85%(通常由于網(wǎng)絡不穩(wěn)定導致)。 Eureka Server會將當前的實例注冊信息保護起來， 讓這些實例不會過期，盡可能保護這些注冊信息。

最后，我們就有了這張圖：

舉個例子：

3y跟女朋友去東站的東方寶泰逛街，但不知道東方寶泰有什么好玩的。于是就去物業(yè)搜了一下東方寶泰商戶清單，發(fā)現(xiàn)一樓有優(yōu)衣庫，二樓有星巴克，三樓有麥當勞。

在優(yōu)衣庫旁邊，有新開張的KFC，在墻壁打上了很大的標識“歡迎KFC入駐東方寶泰”。

商家們需要定時交物業(yè)費給物業(yè)。

物業(yè)維持東方寶泰的穩(wěn)定性。如果某個商家不想在東方寶泰運營了，告訴了物業(yè)。物業(yè)自然就會將其在東方寶泰商戶清單去除。

優(yōu)秀博文：

Spring Cloud Eureka詳解：https://blog.csdn.net/sunhuiliang85/article/details/76222517

《Spring Cloud Netflix》 -- 服務注冊和服務發(fā)現(xiàn)-Eureka 的使用：https://zhuanlan.zhihu.com/p/26472547

微服務架構：Eureka參數(shù)配置項詳解：https://www.cnblogs.com/fangfuhai/p/7070325.html

通過Eureka服務治理框架，我們可以通過服務名來獲取具體的服務實例的位置了(IP)。一般在使用SpringCloud的時候不需要自己手動創(chuàng)建HttpClient來進行遠程調(diào)用。

可以使用Spring封裝好的RestTemplate工具類，使用起來很簡單：

    // 傳統(tǒng)的方式，直接顯示寫死IP是不好的！
    //private static final String REST_URL_PREFIX = "http://localhost:8001";
    
    // 服務實例名
    private static final String REST_URL_PREFIX = "http://MICROSERVICECLOUD-DEPT";

    /**
     * 使用 使用restTemplate訪問restful接口非常的簡單粗暴無腦。 (url, requestMap,
     * ResponseBean.class)這三個參數(shù)分別代表 REST請求地址、請求參數(shù)、HTTP響應轉換被轉換成的對象類型。
     */
    @Autowired
    private RestTemplate restTemplate;

    @RequestMapping(value = "/consumer/dept/add")
    public boolean add(Dept dept) {
        return restTemplate.postForObject(REST_URL_PREFIX + "/dept/add", dept, Boolean.class);
    }

為了實現(xiàn)服務的高可用，我們可以將服務提供者集群。比如說，現(xiàn)在一個秒殺系統(tǒng)設計出來了，準備上線了。在11月11號時為了能夠支持高并發(fā)，我們開多臺機器來支持并發(fā)量。

現(xiàn)在想要這三個秒殺系統(tǒng)合理攤分用戶的請求(專業(yè)來說就是負載均衡)，可能你會想到nginx。

其實SpringCloud也支持的負載均衡功能，只不過它是客戶端的負載均衡，這個功能實現(xiàn)就是Ribbon！

負載均衡又區(qū)分了兩種類型：

客戶端負載均衡(Ribbon)

服務實例的清單在客戶端，客戶端進行負載均衡算法分配。

(從上面的知識我們已經(jīng)知道了：客戶端可以從Eureka Server中得到一份服務清單，在發(fā)送請求時通過負載均衡算法，在多個服務器之間選擇一個進行訪問)

服務端負載均衡(Nginx)

服務實例的清單在服務端，服務器進行負載均衡算法分配

所以，我們的圖可以畫成這樣：

Ribbon是支持負載均衡，默認的負載均衡策略是輪詢，我們也是可以根據(jù)自己實際的需求自定義負載均衡策略的。

@Configuration
public class MySelfRule
{
    @Bean
    public IRule myRule()
    {
        //return new RandomRule();// Ribbon默認是輪詢，我自定義為隨機
        //return new RoundRobinRule();// Ribbon默認是輪詢，我自定義為隨機
        
        return new RandomRule_ZY();// 我自定義為每臺機器5次
    }
}

實現(xiàn)起來也很簡單：繼承AbstractLoadBalancerRule類，重寫public Server choose(ILoadBalancer lb, Object key)即可。

SpringCloud 在CAP理論是選擇了AP的，在Ribbon中還可以配置重試機制的(有興趣的同學可以去搜搜)~

舉個例子：

3y跟女朋友過了幾個月，又去東方寶泰了。由于記性不好，又去物業(yè)那弄了一份東方寶泰商戶清單。

這次看到東方寶泰又開了一間麥當勞，一間在二樓，一間在三樓。原來生意太好了，為了能提高用戶體驗，在二樓多開了一間麥當勞。

這時，3y問女朋友：“去哪間麥當勞比較好？要不我們拋硬幣決定？”3y女朋友說：”你是不是傻，肯定哪間近去哪間啊“

優(yōu)秀博文：

擼一擼Spring Cloud Ribbon的原理-負載均衡策略：https://www.cnblogs.com/kongxianghai/p/8477781.html

到目前為止，我們的服務看起來好像挺好的了：能夠根據(jù)服務名來遠程調(diào)用其他的服務，可以實現(xiàn)客戶端的負載均衡。

但是，如果我們在調(diào)用多個遠程服務時，某個服務出現(xiàn)延遲，會怎么樣？？

在高并發(fā)的情況下，由于單個服務的延遲，可能導致所有的請求都處于延遲狀態(tài)，甚至在幾秒鐘就使服務處于負載飽和的狀態(tài)，資源耗盡，直到不可用，最終導致這個分布式系統(tǒng)都不可用，這就是“雪崩”。

針對上述問題， Spring Cloud Hystrix實現(xiàn)了斷路器、線程隔離等一系列服務保護功能。

Fallback(失敗快速返回)：當某個服務單元發(fā)生故障（類似用電器發(fā)生短路）之后，通過斷路器的故障監(jiān)控（類似熔斷保險絲）， 向調(diào)用方返回一個錯誤響應， 而不是長時間的等待。這樣就不會使得線程因調(diào)用故障服務被長時間占用不釋放，避免了故障在分布式系統(tǒng)中的蔓延。

資源/依賴隔離(線程池隔離)：它會為每一個依賴服務創(chuàng)建一個獨立的線程池，這樣就算某個依賴服務出現(xiàn)延遲過高的情況，也只是對該依賴服務的調(diào)用產(chǎn)生影響， 而不會拖慢其他的依賴服務。

Hystrix提供幾個熔斷關鍵參數(shù)：滑動窗口大?。?0）、 熔斷器開關間隔（5s）、錯誤率（50%）

每當20個請求中，有50%失敗時，熔斷器就會打開，此時再調(diào)用此服務，將會直接返回失敗，不再調(diào)遠程服務。

直到5s鐘之后，重新檢測該觸發(fā)條件，判斷是否把熔斷器關閉，或者繼續(xù)打開。

Hystrix還有請求合并、請求緩存這樣強大的功能，在此我就不具體說明了，有興趣的同學可繼續(xù)深入學習~

Hystrix儀表盤：它主要用來實時監(jiān)控Hystrix的各項指標信息。通過Hystrix Dashboard反饋的實時信息，可以幫助我們快速發(fā)現(xiàn)系統(tǒng)中存在的問題，從而及時地采取應對措施。

啟動時的頁面：

監(jiān)控單服務的頁面：

我們現(xiàn)在的服務是這樣的：

除了可以開啟單個實例的監(jiān)控頁面之外，還有一個監(jiān)控端點 /turbine.stream 是對集群使用的。 從端點的命名中，可以引入Turbine, 通過它來匯集監(jiān)控信息，并將聚合后的信息提供給 HystrixDashboard 來集中展示和監(jiān)控。

舉個例子：

3y和女朋友決定去萬達玩，去到萬達的停車場發(fā)現(xiàn)在負一層已經(jīng)大大寫上“負一層已停滿，請下負二層，負二層空余停車位還有100個！”

這時，3y就跟女朋友說：“萬達停車場是做得挺好的，如果它沒有直接告知我負一層已滿，可能我就去負一層找位置了，要是一堆人跑去負一層但都找不到車位的話，恐怕就塞死了”。3y接著說：“看停車位的狀態(tài)也做得不錯，在停車位上頭有一個感應(監(jiān)控)，如果是紅色就代表已被停了，如果是綠色就說明停車位是空的”。

3y女朋友不屑的說：“你話是真的多”

參考資料：

Hystrix ，為什么說它是每個系統(tǒng)不可或缺的開源框架？https://zhuanlan.zhihu.com/p/34304136

深入理解Hystrix之文檔翻譯：https://zhuanlan.zhihu.com/p/28523060

談談我對服務熔斷、服務降級的理解：https://blog.csdn.net/guwei9111986/article/details/51649240

Hystrix幾篇文章《青芒》：https://segmentfault.com/u/yedge/articles

上面已經(jīng)介紹了Ribbon和Hystrix了，可以發(fā)現(xiàn)的是：他倆作為基礎工具類框架廣泛地應用在各個微服務的實現(xiàn)中。我們會發(fā)現(xiàn)對這兩個框架的使用幾乎是同時出現(xiàn)的。

為了簡化我們的開發(fā)，Spring Cloud Feign出現(xiàn)了！它基于 Netflix Feign 實現(xiàn)，整合了 Spring Cloud Ribbon 與 Spring Cloud Hystrix, 除了整合這兩者的強大功能之外，它還提
供了聲明式的服務調(diào)用(不再通過RestTemplate)。

Feign是一種聲明式、模板化的HTTP客戶端。在Spring Cloud中使用Feign, 我們可以做到使用HTTP請求遠程服務時能與調(diào)用本地方法一樣的編碼體驗，開發(fā)者完全感知不到這是遠程方法，更感知不到這是個HTTP請求。

下面就簡單看看Feign是怎么優(yōu)雅地實現(xiàn)遠程調(diào)用的：

服務綁定：

// value --->指定調(diào)用哪個服務
// fallbackFactory--->熔斷器的降級提示
@FeignClient(value = "MICROSERVICECLOUD-DEPT", fallbackFactory = DeptClientServiceFallbackFactory.class)
public interface DeptClientService {


    // 采用Feign我們可以使用SpringMVC的注解來對服務進行綁定！
    @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
    public Dept get(@PathVariable("id") long id);

    @RequestMapping(value = "/dept/list", method = RequestMethod.GET)
    public List list();

    @RequestMapping(value = "/dept/add", method = RequestMethod.POST)
    public boolean add(Dept dept);
}

Feign中使用熔斷器：

/**
 * Feign中使用斷路器
 * 這里主要是處理異常出錯的情況(降級/熔斷時服務不可用，fallback就會找到這里來)
 */
@Component // 不要忘記添加，不要忘記添加
public class DeptClientServiceFallbackFactory implements FallbackFactory {
    @Override
    public DeptClientService create(Throwable throwable) {
        return new DeptClientService() {
            @Override
            public Dept get(long id) {
                return new Dept().setDeptno(id).setDname("該ID：" + id + "沒有沒有對應的信息,Consumer客戶端提供的降級信息,此刻服務Provider已經(jīng)關閉")
                        .setDb_source("no this database in MySQL");
            }

            @Override
            public List list() {
                return null;
            }

            @Override
            public boolean add(Dept dept) {
                return false;
            }
        };
    }
}

調(diào)用：

基于上面的學習，我們現(xiàn)在的架構很可能會設計成這樣：

這樣的架構會有兩個比較麻煩的問題：

路由規(guī)則與服務實例的維護間題：外層的負載均衡(nginx)需要維護所有的服務實例清單(圖上的OpenService)

簽名校驗、 登錄校驗冗余問題：為了保證對外服務的安全性， 我們在服務端實現(xiàn)的微服務接口，往往都會有一定的權限校驗機制，但我們的服務是獨立的，我們不得不在這些應用中都實現(xiàn)這樣一套校驗邏輯，這就會造成校驗邏輯的冗余。

還是畫個圖來理解一下吧：

每個服務都有自己的IP地址，Nginx想要正確請求轉發(fā)到服務上，就必須維護著每個服務實例的地址！

更是災難的是：這些服務實例的IP地址還有可能會變，服務之間的劃分也很可能會變。

http://123.123.123.123

http://123.123.123.124

http://123.123.123.125

http://123.123.123.126

http://123.123.123.127

購物車和訂單模塊都需要用戶登錄了才可以正常訪問，基于現(xiàn)在的架構，只能在購物車和訂單模塊都編寫校驗邏輯，這無疑是冗余的代碼。

為了解決上面這些常見的架構問題，API網(wǎng)關的概念應運而生。在SpringCloud中了提供了基于Netfl ix Zuul實現(xiàn)的API網(wǎng)關組件Spring Cloud Zuul。

Spring Cloud Zuul是這樣解決上述兩個問題的：

SpringCloud Zuul通過與SpringCloud Eureka進行整合，將自身注冊為Eureka服務治理下的應用，同時從Eureka中獲得了所有其他微服務的實例信息。外層調(diào)用都必須通過API網(wǎng)關，使得將維護服務實例的工作交給了服務治理框架自動完成。

在API網(wǎng)關服務上進行統(tǒng)一調(diào)用來對微服務接口做前置過濾，以實現(xiàn)對微服務接口的攔截和校驗。

Zuul天生就擁有線程隔離和斷路器的自我保護功能，以及對服務調(diào)用的客戶端負載均衡功能。也就是說：Zuul也是支持Hystrix和Ribbon。

關于Zuul還有很多知識點(由于篇幅問題，這里我就不細說了)：

路由匹配(動態(tài)路由)

過濾器實現(xiàn)(動態(tài)過濾器)

默認會過濾掉Cookie與敏感的HTTP頭信息(額外配置)

Zuul支持Ribbon和Hystrix，也能夠實現(xiàn)客戶端的負載均衡。我們的Feign不也是實現(xiàn)客戶端的負載均衡和Hystrix的嗎？既然Zuul已經(jīng)能夠實現(xiàn)了，那我們的Feign還有必要嗎？

或者可以這樣理解：

zuul是對外暴露的唯一接口相當于路由的是controller的請求，而Ribbonhe和Fegin路由了service的請求

zuul做最外層請求的負載均衡 ，而Ribbon和Fegin做的是系統(tǒng)內(nèi)部各個微服務的service的調(diào)用的負載均衡

有了Zuul，還需要Nginx嗎？他倆可以一起使用嗎？

我的理解：Zuul和Nginx是可以一起使用的(畢竟我們的Zuul也是可以搭成集群來實現(xiàn)高可用的)，要不要一起使用得看架構的復雜度了(業(yè)務)~~~

參考資料：

微服務與API網(wǎng)關（上）: 為什么需要API網(wǎng)關？：http://blog.didispace.com/hzf-ms-apigateway-1/

談談 API 網(wǎng)關：https://www.jianshu.com/p/b52a2773e75f

談談微服務中的 API 網(wǎng)關（API Gateway）：https://www.cnblogs.com/savorboard/p/api-gateway.html

API網(wǎng)關性能比較：NGINX vs. ZUUL vs. Spring Cloud Gateway ：http://www.360doc.com/content/18/0208/05/46368139_728502763.shtml

談API網(wǎng)關的背景、架構以及落地方案：http://www.infoq.com/cn/news/2016/07/API-background-architecture-floo

zuul和nginx：https://zhuanlan.zhihu.com/p/37385481

隨著業(yè)務的擴展，我們的服務會越來越多，越來越多。每個服務都有自己的配置文件。

既然是配置文件，給我們配置的東西，那難免會有些改動的。

比如我們的Demo中，每個服務都寫上相同的配置文件。萬一我們有一天，配置文件中的密碼需要更換了，那就得三個都要重新更改。

在分布式系統(tǒng)中，某一個基礎服務信息變更，都很可能會引起一系列的更新和重啟

Spring Cloud Config項目是一個解決分布式系統(tǒng)的配置管理方案。它包含了Client和Server兩個部分，server提供配置文件的存儲、以接口的形式將配置文件的內(nèi)容提供出去，client通過接口獲取數(shù)據(jù)、并依據(jù)此數(shù)據(jù)初始化自己的應用。

簡單來說，使用Spring Cloud Config就是將配置文件放到統(tǒng)一的位置管理(比如GitHub)，客戶端通過接口去獲取這些配置文件。

在GitHub上修改了某個配置文件，應用加載的就是修改后的配置文件。

SpringCloud Config其他的知識：

在SpringCloud Config的服務端， 對于配置倉庫的默認實現(xiàn)采用了Git，我們也可以配置SVN。

配置文件內(nèi)的信息加密和解密

修改了配置文件，希望不用重啟來動態(tài)刷新配置，配合Spring Cloud Bus 使用~

使用SpringCloud Config可能的疑問：application.yml和 bootstrap.yml區(qū)別

https://www.cnblogs.com/BlogNetSpace/p/8469033.html

本文主要寫了SpringCloud的基礎知識，希望大家看完能有所幫助~

SpringCloud的資料也很多，我整理一些我認為比較好，想要深入的同學不妨看看下邊的資源~~~

SpringCloud系列文章參考資料：

史上最簡單的 SpringCloud 教程 | 終章https://blog.csdn.net/forezp/article/details/70148833

Spring Cloud基礎教程《程序員DD》http://blog.didispace.com/Spring-Cloud%E5%9F%BA%E7%A1%80%E6%95%99%E7%A8%8B/

Spring Cloud 系列文章《純潔的微笑》：http://www.ityouknow.com/spring-cloud.html

SpringCloud系列文章：https://www.cnblogs.com/woshimrf/tag/SpringCloud/

SpringCloud系列文章《狂小白》：https://www.cnblogs.com/huangjuncong/tag/SpringCloud/

SpringCloud官方文檔：http://projects.spring.io/spring-cloud/

Spring Cloud 中文文檔：https://springcloud.cc/spring-cloud-dalston.html#_appendix_compendium_of_configuration_properties

參考書籍：

《SpringCloud 微服務實戰(zhàn)》

SpringCloud GitHub Demo(看完文章的同學可以自己練手玩玩，寫好了ReadMe了)：

https://github.com/ZhongFuCheng3y/msc-Demo

如果想看更多的原創(chuàng)技術文章，歡迎大家關注我的微信公眾號:Java3y。Java技術群討論：742919422。公眾號還有海量的視頻資源哦，關注即可免費領取。

可能感興趣的鏈接：

文章的目錄導航(微信公眾號端)：https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang

文章的目錄導航(PC端)：http://www.zhongfucheng.bitcron.com/post/shou-ji/pcduan-wen-zhang-dao-hang

海量精美腦圖：http://www.zhongfucheng.bitcron.com/post/shou-ji/nao-tu-da-quan