此次要是講不明白Spring Cloud核心組件，那我就白編這故事了

這幾天可真是熱啊，泡個海澡是再好不過了。玩的正起勁，忽然腳底絆上一股暗流，而後我就一直在水裏旋轉旋轉旋轉...終於眼前一黑。

愛的魔力轉圈圈。我穿越了。

鄰國相望，雞犬之聲相聞，民至老死不相往來。這個世界被小諸侯給切的七零八落，一鍋亂麻。

而現實是，個人國家由於常年打仗，剩下的女人不少，須要打通遠嫁他方的通道；而A國盛產長得和豬同樣大的耗子，賣的很好。它們能夠作成皮大氅，用來取暖。因此交流是在所不免的。

現實是這樣的：
1、A國不知道B國身處何方，常常有牧民捧着藏寶圖同樣的破布，葬身在崎嶇的山路上。
2、B國聽不懂C國含糊不清的吐詞，感受他們在求救，等跑近一看，卻發現實際上是在罵娘。
3、C國生產的南瓜就知道賣給D國，剩下的都爛在了地裏，E國都開始吃樹皮了。
4、F國卻是遠近聞名，但四面八方蜂擁而至的難民，讓他們很是苦惱。其中，G國的難民，最是惡劣。
5、曾有其餘大陸板塊的使者，5年不得要領。見神粥大地現狀，做詩一首：《真TM亂》。

做爲一個穿越者，一個憐憫衆生的剩人。我要留給這個世界一張藍圖，好讓後人記住個人名字：xjjdog。同時，我也想起了，我爲何有這種這種強大的自信。

」回憶「的片斷將我帶回到21世紀。

1、我要聊點技術了：單體應用

咱們剛開始的服務，其實並無那麼複雜。我只有一臺配置很是低的機器，個人應用，個人代碼，個人聰明才智，所有在這一個小小的工程裏面。因爲我是搞it的，因此個人項目名字就叫jisuanji。有人說我用中文拼音作項目名，太那個。我不聽，我就是這麼命名。我還把公共模塊叫gg，密碼字段叫mm，誰管得着呢。

對，看下面的圖，就是這麼簡單。項目能活到用nginx來作負載均衡這一步，就算是小成功了。

這個時候，全部的代碼就是一個總體，用戶訪問什麼，我直接給就是。

2、我拆成了兩個服務

多是我和我同樣二的人有點多，個人項目訪問量愈來愈大，這也許就叫臭味相投吧。我本身的開發速度，已經追不上頭腦裏的idea，是時候招我的對服務進行拆分了。

不能拆的太過火，因此剛開始，我把jisuanji拆成了兩個服務。其中的服務B，僅僅部署了一個節點，由於它的壓力還不是太大。即便這樣，我不得不買上3臺服務器來部署服務節點，真是肉痛。我這麼摳門的人，數據庫固然也是共用的。雖然有時候機器壓力有點大，但暫時還死不了人。

這個時候我就面臨了一個選擇問題：服務A要怎麼訪問服務B呢？
因爲我搞過一段時間的webservice，首先就想到了它。但這玩意過重了，我還不如經過Http訪問來的舒爽。經過HttpClient，或者OkHttp，個人服務A，如今能夠直接模擬Http請求訪問服務B了。

當團隊裏有第二我的，就開始吐槽個人項目了。如下是他羅列的，個人項目的罪狀：一、複雜度過高，代碼嚴重耦合；二、技術債務多，拍腦殼需求一籮筐；三、代碼不規範，一坨屎；四、技術創新難，一個類幾千行...

至於麼？從一個服務拆成兩個，就這麼吐槽我。不過爲了之後能拆出成百上千個服務，這口氣我暫時忍了，畢竟我這人仍是比較虛心的。

3、亂成一鍋粥了

等過去半年一看，好傢伙，服務給我拆了了幾十個。當個人同伴把系統結構圖拿給我看，我直接懵逼了。我挑了9個能看的服務，畫了張圖。

首先進行了業務拆分。好比支付業務，訂單業務，用戶中心，商品中心等，都組建了獨立的團隊。每一個業務又進行了細分，拆分紅不一樣的服務。

在這之間，進行了下面的改動：
1、有小夥伴寫了個通用的HttpClient調用組件，本身的負載均衡策略。
2、有另一個小夥伴，習慣protobuf，因此選了gRPC。
3、事實證實SOA仍是有市場的，這不，就有幾個服務的交互引入了webservice。
4、有人想要用RMI，被我及時發現、否決，腹死胎中了。
5、每次建個新服務，都須要更新一下excel，而後將這個excel周知出去。

如今的整個系統，簡直是個四不像。什麼通訊方式都有，什麼交互格式都不缺。拿最要命的D服務來講，光通信模塊，就引入了20幾個jar包。若是應用擴展到上千個...My god...

更要命的是，這麼多服務，每次上線一個模塊都膽戰心驚，由於它不知道到底會有什麼連鎖反應。

是時候叫出超級飛俠了。哦不，叫出微服務了。

4、微服務來襲

目前，最火的微服務框架，就是SpringCloud了。雖然netflix公司對某些組件的維護常常爽約，但有些核心組件仍是很是經典的。

一、註冊中心：Eureka

服務A，怎麼找到服務B，有不少種方式。好比你生活在一個小鎮上，你問xjjdog是誰，老王可能認識他，但小李可能並不知曉；但小李認識老王，因此經過他最終也能找到xjjdog，只不過麻煩一些。

你能夠隨便拉小鎮上的一我的，來問xjjdog是誰。你還會變戲法同樣拿出一個小本本，把你認識的人，都告訴他們。當你腦殘式的問了一個遍，到最後全部人都知道xjjdog了。

上面說的就是gossip協議。最終，大家都可以知道彼此，由於都是大嘴巴。好比小鄭生了個孩子，過不了多少時間，全鎮子的人都把這個孩子記錄在本子上了。

用這種方式，服務都可以知道彼此，完成通訊。

---

惋惜這並不美好，從小鎮的東頭跑到西頭，須要很長時間。在這個時間裏，小鄭剛生的孩子可能由於先天疾病夭折了。咱們須要一種信息集中度和實效性更高的方式。

這就須要一箇中心，那裏的信息就是權威。 在SpringCloud體系中，最經常使用的註冊中心就是Eureka。任何服務啓動之後，都會把本身註冊到Eureka的註冊表中；當服務死亡的時候，也會通知Eureka。

這樣，當服務A想要找服務B的時候，只須要問一下Eureka Server就能夠了，它什麼都知道。

爲了達到這個目的，仍是要有一部分工做量的。且看下圖。這個註冊動做，是由一個叫作Eureka Client的組件來完成的。服務啓動和關閉的時候，會經過這個組件推銷本身；而當服務A想要調用服務B的時候，直接問Eureka Server就能夠了。服務A拿到結果後，會把結果緩存在本地的註冊表裏。

你能夠認爲是一個拷貝。因此Eureka Server死掉後，並不影響服務A找到服務B。

二、負載均衡組件：Ribbon

如今問題來了。服務A拿到服務B的實例列表之後，發現有兩臺。

10.0.0.12
10.0.0.16
複製代碼

接下來麻煩了，該調哪臺機器呢？這就是SpringCloud中組件Ribbon的做用。其實Round Robin是一個通用的計算機術語。它是最經常使用的負載均衡策略，請求會均勻的分配給後面的每臺服務器。

Ribbon工做時，會作下面四件事：
一、優先選擇在一個Zone且負載較少的Eureka Server，進行鏈接。
二、按期從Eureka更新、過濾服務和實例列表。
三、根據負載均衡策略，從註冊表中選擇一個真正的實例地址。
四、經過RestClient對服務發起調用。

能夠看到，Ribbon背後，仍是採用的Http協議進行交互。看如下代碼，就能夠直接實現對遠端服務的調用。

@Bean
@LoadBalanced
RestTemplate restTemplate(){
    return new RestTemplate();
}
...

 @Autowired
RestTemplate restTemplate;
public String test() {
    return restTemplate.getForObject("http://test-service/test", String.class);
}
複製代碼

Ribbon的Filter會查找test-service，並替換成相應的實例地址。

策略 Ribbon不只僅提供了輪詢的策略，還有其餘的，好比：
一、隨機Random
二、根據響應時間加權
三、自定義

拿輪詢來講，最終的選擇邏輯就在RoundRobinRule類中。

private int incrementAndGetModulo(int modulo) {
        for (;;) {
            int current = nextServerCyclicCounter.get();
            int next = (current + 1) % modulo;
            if (nextServerCyclicCounter.compareAndSet(current, next))
                return next;
        }
}
複製代碼

三、爲簡化代碼而生：Feign

能夠看到，Ribbon須要本身構建http請求，模擬http請求而後使用RestTemplate發送給其餘服務，步驟至關繁瑣。並且返回類型不安全，也表達不出什麼語義。

其實，經過Ribbon方式，已經可以完成微服務之間的調用了。但SpringCloud的開發語言是Java，確定要進行更加高級的封裝，才能體現它的逼格。

Feign得益於Java的動態代理機制，最終封裝出一套簡潔的接口調用方式，將須要調用的其餘服務的方法定義成抽象方法便可，不須要本身構建http請求。

首先，Feign會根據@FerignClient註解，經過動態代理，建立一個動態代理類。接下來，你只要經過調用接口的方式，就能夠構造上面提到的Ribbon調用參數，這個過程會自動填充。最後，經過構造的Ribbon請求，發起真正的調用，並經過反射組裝返回值。

因此，Feign只是一層皮，最終仍是要經過Ribbon進行調用。在我看來，把Ribbon和Feign合成一個組件，也是合理的。

它們有一個比較通用的名詞，就叫作RPC（遠程調用）。

四、異常的保護傘：斷路器

下面以一個支付請求爲例，說一下不是風平浪靜的狀況下，服務會有什麼反應。

每個真正的支付請求，都會調用其餘四個服務。首先，使用鑑權服務，獲取用戶的支付權限；而後，風控服務會作一些規則驗證；爲了更好的推銷產品，會調用營銷業務，獲取一些推薦信息；最後，調用聚合支付服務，進行真正的支付。

其中，營銷業務實際上是無關緊要的。讓用戶首先把錢花出去，是咱們的首要任務。

考慮下面一種場景，營銷業務因爲系統故障或者負載問題，發生了大面積的不可用或者超時。而後，全部的請求都卡在了獲取營銷信息的代碼上。

如圖所示，鑑權和風控都已經經過了。由於一個旁路功能：營銷業務，致使真正的支付沒法進行。這個時候，若是有人調用支付請求，會發現支付請求也完蛋了。

由於它們最終都卡在了營銷這一段小代碼上。

因此，對於營銷業務這種不是鏈路上必備的服務提供者，要有一個手段，讓它在發生問題的時候，隔離它一段時間。

負責這個功能的組件，就叫作Hystrix。

以咱們編程的思惟來講，這就是個if條件。

if(服務發生問題){
    return "暫時不要處理";
}
複製代碼

但咱們不能這麼編碼在業務代碼裏。因此Hystrix對每一個服務開了一個線程池，並有比較複雜的規則，來控制這些出問題的服務的行爲。好比，在2分鐘內，直接返回營銷業務的默認結果，而不是一直卡在那裏。

這個過程，就叫熔斷。就像電源同樣，出了問題，先切斷保險絲，別把電器給燒了。

五、此網關非彼網關：zuul

API網關是一個反向的路由，它屏蔽了內部的細節，爲調用者提供了統一的入口。網關，實際上是一堆過濾器的幾何，能夠實現一系列和業務無關的橫切面功能。

熟悉Spring的都知道AOP，路由的一個功能，就是針對於分佈式服務的一個AOP。

仍是先說下網關的職責吧。簡單羅列幾個：
一、安全認證。提供統一的認證方式和鑑權功能，避免重複開發。
二、熔斷，限流。針對問題服務，進行熔斷操做；對流量進行預估，限制訪問。
三、日誌監控。統一流量入口，進行流量分析和監控。
四、屏蔽內部細節，對外提供一致的接口。
五、實現灰度。使用自定義策略實現分流，達到測試的目的。

網關的位置，大致就以下圖。

能夠看到，咱們日常用的nginx，就能夠看成網關。但對於微服務來講，nginx的配置實在是太麻煩了。不是說nginx功能不夠強大，而是由於它們不是一個體系的，就存在整合成本（好比kong）。

zuul就不同了，它和SpringCloud的其餘組件，是一家子的。一家子的，固然會特殊照顧。Zuul自己就是一個Servlet，外部請求通過一系列Filter後，會達到真正的服務。上面說的熔斷器，就是高度集成的。

六、一張聚合圖

有了上面關鍵組件，事情就明瞭的多了。咱們把它放在一張圖中，就是下面的樣子。

咱們將其簡化一下，就能夠獲得一張更簡潔的圖。能夠看到，只須要3個關鍵點：
一、服務註冊中心，統一管理全部服務的信息，默認組件是Eureka。
二、RPC，網絡通訊組件，服務A怎麼調用服務B。在SpringCloud中，就是Ribbon+Feign。
三、網關，拆分的服務怎麼暴露接口，最終見人的樣子。 默認組件是Zuul。

征途

一點道理

處理雜亂無章的事情，最有效的途徑，就是集權和中心化。集權和中心化的核心就是受權或者認同，不然註定失敗。受權是對上，各位當權者應該贊成個人作法，因此我須要用及其易懂的語言，去說服他們接受這個體系；認同，是對下，最好是從人民的抱怨聲中，出具的改善措施，因此要權威專業。

和微服務同樣，須要給一些陳舊的概念，強行賦予看起來比較天然的新意義。好比我把統一語言，叫作文化融合，就顯得高大上一些。

第二個，就是把職責拆的足夠細。夠細纔可以精，每一個位置上的人才能各司其職。

還有一點，整個過程，要可以系統化，可以進行推演。若是一件事有着不可預料的後果，那是冒險家乾的事情。

一些途徑

爲了對世界進行初步的瞭解，我成立了資源統計部，對山川河流進行了初步的勘查，繪製出有章可循的地圖。對社會的現狀和錯綜複雜的關係進行了摸底。我把這些信息出版成圖書，遭到藏寶圖收藏者們的嫉妒和憎惡。他們躲藏在鮮爲人知的角落，齷齪行事。

我還選了一個本身以爲好聽的方言，統一了每一個諸侯國的語言。在推行的過程當中，屢次受到土著們強烈的反對，拒不改正。被我強行斬首了幾個以後，之後的推行，就快的多了。

對於全部的重要商品，進行了集中管控。這個世界貴重的不是黃金，而是食物，因此我還修建了四通八達的道路和無孔不入的交易中心。今後以後，不多餓死過人。因爲這部分是在個人控制範圍內，因此進行的很順暢。

G國的民風比較彪悍，常常發生暴力事件。這也不免，從剛開始，這個國家就難以馴化。好在缺了他們，這個系統也能循環的下去。前不久G國又發生了重大的事件，全部其餘國家聯合抵制，禁止G國國民入境。但時間是化解傷痛的良藥，我估計這樣的限制不會持續好久。

但糟粕仍是有的。有人的地方，就有江湖，就有壓迫。但這樣的糟粕我是不想讓其餘人看到的。來訪的使者，應該只可以看到歌舞昇平、安居樂業，這注定了不能讓他們和底層接觸，不然就發現金玉其外敗絮其中的現狀了。

他們和外交官打的不亦樂乎，我很欣慰。

End

我清楚的知道，爲了創建一個和諧天然的系統，曾經花費了多大的代價。這其中的組成部分，並不能老是天衣無縫的運行。並且，在這個看似平和的總體上，就滋生了其餘無數使人頭痛的問題 ，不過這是另一個話題了。

就是這樣。我所作的一切，我全部的指望，只不過是爲了：當新的機會在我身後，我可以從容的、華麗的轉身。

這就是我爲了有一天可以穿越，所作的準備。

---

還不過癮？關注微信公衆號xjjdog，有更多姊妹篇和乾貨。