微服務(wù)
在 jsp 時代，應(yīng)用前后端耦合，前后端 all in 一臺服務(wù)器筹吐，隨著流量的增大痒芝，代碼數(shù)量的增加，單體應(yīng)用不再適合互聯(lián)網(wǎng)的發(fā)展，微服務(wù)順應(yīng)提出。
微服務(wù)是一種用于構(gòu)建應(yīng)用的架構(gòu)方案。區(qū)別于更為傳統(tǒng)的單體式方案硝枉，將應(yīng)用拆分成多個核心功能。每個功能都被稱為一項服務(wù)倦微，可以單獨構(gòu)建和部署妻味，這意味著各項服務(wù)在工作（和出現(xiàn)故障）時不會相互影響。
參考：https://www.redhat.com/zh/topics/microservices/what-are-microservices
Spring Cloud 版本
在微服務(wù)大哥的帶領(lǐng)下欣福，各種架構(gòu)層出不窮责球，有 Dubbo、gRPC、Thrift棕诵、SpringCloud 等等裁良，其中 Spring Cloud 背靠 Spring 生態(tài)，脫穎而出校套。Spring Cloud 框架是在 Springboot 框架基礎(chǔ)上編寫的价脾，因此在技術(shù)選型的時候，我們需要注意 Spring Cloud 版本要與 Springboot 版本對應(yīng)笛匙。
Spring Cloud 社區(qū)活躍侨把，已經(jīng)出了好幾個版本，生命力旺盛妹孙。值得一提的是他的版本號秋柄。SpringCloud 不是使用數(shù)字作為版本號，而是將倫敦地鐵站作為版本號蠢正，這讓我想起被地鐵支配的恐懼骇笔。
目前 SprinCloud官網(wǎng)主推薦版本是 Hoxton SR1。Spring Cloud 與 Spring Boot 有明確的版本對應(yīng)關(guān)系嚣崭。
| Spring Cloud | Spring Boot |
|---|---|
| Hoxton | 2.2.x |
| Greenwich | 2.1.x |
| Finchley | 2.0.x |
| Edgware | 1.5.x |
| Dalston | 1.5.x |
| Camden | 1.4.x |
| Brixton | 1.3.x |
| Angel | 1.2.x |
從圖表可以看出 Spring Cloud 版本號的首字母是按照字母順序排列的笨触。
本文主要介紹的是基于 Spring Boot 1.5.x 的 Dalston 版本的 Spring Cloud。
Spring Cloud 是什么
Spring boot 是一個身懷絕技的武林高手雹舀，能上九天攬月下五洋捉鱉芦劣，反正就是牛，他喜歡結(jié)交武林各路英雄豪杰说榆，有 MyBatis 虚吟、Redis、RabbitMQ签财、Kafaka串慰、Elasticsearch 等等各路高手，他們喜歡行俠仗義唱蒸，助人為樂邦鲫，慢慢的以 Spring boot 為大佬的幫派越來越多，有一天 Spring boot 和兄弟們說油宜，要不我們成立一個門派把，就叫 Spring Cloud 怜姿。
大家一呼百應(yīng)慎冤。但是成立的門派后，需要管理啊沧卢，所以 Spring Cloud 成立了 Eureka 分舵（服務(wù)中心）蚁堤，負(fù)責(zé)對各個分舵同步門派的大事件，有新成員（提供者）加入門派但狭，也需要到 Eureka 分舵報道披诗，其他分舵（消費者）需要協(xié)助撬即，也像 Eureka 分舵請求支援。分舵也培養(yǎng)新分舵呈队，出現(xiàn)了幾個職能相同的分舵（服務(wù)帶集群）剥槐，Eureka 分舵看到分舵越來越多，自己也開始培養(yǎng)新分舵（服務(wù)中心集群）宪摧。同時也建立了一個 Ribbon 分舵（客戶端負(fù)載均衡）粒竖，負(fù)責(zé)對各個分舵進(jìn)行高效的溝通。 Spring Cloud 門派名聲越來越大几于，加入的人越來越多蕊苗，Spring Cloud 開始成立了 Zuul 分舵（網(wǎng)關(guān)），負(fù)責(zé)對新加入的人員進(jìn)行篩選沿彭。
江湖還在朽砰，Spring Cloud 門派也越來越強大，到處都是他的傳說
Spring Cloud 與 Dubbo 區(qū)別
目前來說喉刘，在 Java 領(lǐng)域瞧柔，微服務(wù)主要是 Spring Cloud 和 Dubbo 的天下，因此饱搏，人們經(jīng)常喜歡比較兩種技術(shù)非剃，然后選擇其中一種進(jìn)行搭建。
由于 Dubbo 是國人開發(fā)的推沸，有詳細(xì)的開發(fā)文檔备绽，在 Spring Cloud 的萌芽時， 國人憑著滿腔熱情大力發(fā)展 Dubbo鬓催，不斷試坑肺素，后來 Dubbo 發(fā)展停滯，Spring Cloud 的春風(fēng)開始席卷神州大地宇驾。不過，目前 Dubbo 又開始起色课舍，捐給了 Apache 。
| 技術(shù)維度 | Dubbo | Spring Cloud |
|---|---|---|
| 服務(wù)注冊中心 | Zookeeper | Spring Cloud Netflix Eurrke |
| 服務(wù)調(diào)用方式 | RPC | REST API |
| 服務(wù)監(jiān)控 | Dubbo-monitor | spring boot admin |
| 斷路器 | 不完善 | Spirng Cloud Netflix Hystrix |
| 服務(wù)網(wǎng)關(guān) | 無 | Spring Cloud Netflix Zuul |
| 分布式配置 | 無 | Spring Cloud Config |
Eureka 組件
Eureka 音譯尤里卡筝尾，是 Spring Cloud 的注冊中心。在分布式系統(tǒng)中筹淫，包含很多個節(jié)點，這些節(jié)點大體分為消費者和提供者。
服務(wù)端和客戶端就是通過 Eureka 進(jìn)行管理的饰剥。舉一個例子，Eureka 就好比小區(qū)的快遞箱汰蓉，快遞就是服務(wù)端，取快遞的人就是客戶端古沥。我們什么時候可以取快遞呢，等快遞箱向我們發(fā)送短信岩齿，我們就可以去取快遞了。這就是 Eureka 的作用盹沈。這樣看來服務(wù)中心 Eureka 是十分重要的龄章，為了保證高可用乞封，避免注冊中心掛掉做裙，我們兩眼一抹黑的尷尬局面，一般來說肃晚， Eureka 會做集群锚贱，保證高可用。同理可得关串，服務(wù)中心我們也需要集群拧廊，保證高可用。
Eureka 作為 Spring Cloud 框架的注冊中心晋修，與之對應(yīng)的是 Dubbo 框架的Zookeeper吧碾。他倆有什么區(qū)別呢？這里需要引入一個 CAP 定理墓卦。所謂 CAP 定理倦春，分布式系統(tǒng)的三個指標(biāo) C（一致性）、A（可用性）落剪、P（分區(qū)容錯性）不可以同時滿足了睁本。
一般來說，分區(qū)容錯無法避免忠怖，因此可以認(rèn)為 CAP 的 P 總是成立呢堰。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到
參考：https://www.ruanyifeng.com/blog/2018/07/cap.html
而 Eureka 的設(shè)計原則是 AP脑又，即可用性和分區(qū)容錯性暮胧。他保證了注冊中心的可用性，但舍棄了數(shù)據(jù)一致性问麸，各節(jié)點上的數(shù)據(jù)有可能是不一致的（會最終一致）往衷。ZK 的設(shè)計原則是 CP，即強一致性和分區(qū)容錯性严卖。他保證數(shù)據(jù)的強一致性席舍，但舍棄了可用性，如果出現(xiàn)網(wǎng)絡(luò)問題可能會影響 ZK 的選舉哮笆，導(dǎo)致 ZK 注冊中心的不可用来颤。
參考：https://www.infoq.cn/article/jlDJQ*3wtN2PcqTDyokh
Ribbon
微服務(wù)劃分成幾個節(jié)點，他們分布在不同的虛擬機(jī)稠肘，通訊就成了一個難點福铅，通過我們會想到 HttpClient，如果是 Spring的話项阴，我們可以用 RestTemplate滑黔，但是在集群環(huán)境下环揽，他們并不能做到負(fù)載均衡。因此歉胶，Ribbon 出現(xiàn)了。Ribbon 是一款在客戶端實行負(fù)載均衡的工具通今。Ribbon 其實現(xiàn)原理就是根據(jù)在配置文件中列出的機(jī)器，自動按照某種規(guī)則（輪詢帝嗡，隨機(jī)）去連接這些機(jī)器璃氢。使用者也可以自定義自己的負(fù)載均衡算法。負(fù)載均衡目的是達(dá)到高可用巢寡。
Feign
Feign 是有一款客戶端負(fù)載均衡工具椰苟。既然有了 Ribbon ，為什么還要有 Feign 呢谦絮？ 在實際使用 Ribbon 組件中，我們會發(fā)現(xiàn) Ribbon 會讓我們硬編碼层皱，十分不靈活。因此草冈，在 Ribbon 的基礎(chǔ)下，面向接口編程的 Feign 組件 就出現(xiàn)了怎棱。Feign 讓我們可以編寫出優(yōu)雅的代碼绷跑，因此，實際中诅岩，F(xiàn)eign 得到大力使用带膜。
Hystrix
Hystrix 是一個用于處理分布式系統(tǒng)的延遲和容錯的開源庫，在分布式系統(tǒng)里式廷，許多依賴不可避免的會調(diào)用失敗芭挽，比如超時、異常等袜爪，Hystrix 能夠保證在一個依賴出問題的情況下辛馆，不會導(dǎo)致整體服務(wù)失敗，避免級聯(lián)故障昙篙，以提高分布式系統(tǒng)的彈性苔可。
Hystrix 斷路器是一種開關(guān)裝置，當(dāng)某個服務(wù)單元發(fā)生故障之后映屋，通過斷路器的故障監(jiān)控，向調(diào)用方返回一個符合預(yù)期的棚点、可處理的備選響應(yīng)（FallBack），而不是長時間的等待或者拋出調(diào)用方無法處理的異常，這樣就保證了服務(wù)調(diào)用方不會長時間卵蛉、不必要占用，從而避免了故障在分布式系統(tǒng)中的蔓延傻丝，乃至雪崩。
提到服務(wù)雪崩亏掀，我們可以通過一張圖來理解泛释。假設(shè)我們有三個服務(wù)調(diào)用 A B C。當(dāng)其中下游的 C 服務(wù)發(fā)生故障怜校，就有可能引起 服務(wù)雪崩。為了解決 服務(wù)雪崩魂贬，我們就需要引入 Hystrix 組件裙顽。
Hystrix 主要是通過服務(wù)熔斷和服務(wù)降級來解決服務(wù)雪崩問題愈犹。那么問題來了，服務(wù)熔斷和服務(wù)降級的區(qū)別又是什么萝嘁？
簡單來說服務(wù)熔斷屬于服務(wù)降級的一種扬卷，而服務(wù)降級有很多種降級方式！如開關(guān)降級咱枉、限流降級、熔斷降級蚕断。
參考：https://www.cnblogs.com/rjzheng/p/10340176.html
Zuul
Zuul中文是神獸的意思亿乳。在Spring Cloud 中，Zuul是一項網(wǎng)關(guān)服務(wù)葛假，可提供動態(tài)路由，監(jiān)視抱究，彈性带斑，安全性等。
簡單的話妈候，Zuul 就是樓下保安亭的大爺挂滓，所有進(jìn)入大樓的人，都需要大爺檢查墓毒，得到大爺?shù)脑S可亲怠。 我們可以通過一張圖理解。
Spring Cloud Config
實際工作中主胧，我們可能會有幾十上百的微服務(wù)節(jié)點习勤，每一個節(jié)點有需要有配置信息，比如數(shù)據(jù)庫的連接夷都，服務(wù)中心的地址等等予颤，當(dāng)中信息變化的時候，我們可能面臨手動一臺一臺修改的囧境党饮。為了解決上述問題，我們能否借鑒 Git 的思想氯窍，有一個標(biāo)準(zhǔn)的配置蹲堂，當(dāng)我們配置修改，我們只需要同步刷新一下即可，不用手動搬運呢霹娄？答案是有的，我們可以通過 Spring Cloud Config 達(dá)到同步更新配置信息踩晶。
