微服務
在 jsp 時代，應用前後端耦合，前後端 all in 一臺服務器，隨着流量的增大，代碼數量的增加，單體應用不再適合互聯網的發展，微服務順應提出。
微服務是一種用於構建應用的架構方案。區別於更爲傳統的單體式方案，將應用拆分成多個核心功能。每個功能都被稱爲一項服務，可以單獨構建和部署，這意味着各項服務在工作（和出現故障）時不會相互影響。
參考：https://www.redhat.com/zh/topics/microservices/what-are-microservices
Spring Cloud 版本
在微服務大哥的帶領下，各種架構層出不窮，有 Dubbo、gRPC、Thrift、SpringCloud 等等，其中 Spring Cloud 背靠 Spring 生態，脫穎而出。Spring Cloud 框架是在 Springboot 框架基礎上編寫的，因此在技術選型的時候，我們需要注意 Spring Cloud 版本要與 Springboot 版本對應。
Spring Cloud 社區活躍，已經出了好幾個版本，生命力旺盛。值得一提的是他的版本號。SpringCloud 不是使用數字作爲版本號，而是將倫敦地鐵站作爲版本號，這讓我想起被地鐵支配的恐懼。
目前 SprinCloud官網主推薦版本是 Hoxton SR1。Spring Cloud 與 Spring Boot 有明確的版本對應關係。
| 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 是一個身懷絕技的武林高手，能上九天攬月下五洋捉鱉，反正就是牛，他喜歡結交武林各路英雄豪傑，有 MyBatis 、Redis、RabbitMQ、Kafaka、Elasticsearch 等等各路高手，他們喜歡行俠仗義，助人爲樂，慢慢的以 Spring boot 爲大佬的幫派越來越多，有一天 Spring boot 和兄弟們說，要不我們成立一個門派把，就叫 Spring Cloud 。
大家一呼百應。但是成立的門派後，需要管理啊，所以 Spring Cloud 成立了 Eureka 分舵（服務中心），負責對各個分舵同步門派的大事件，有新成員（提供者）加入門派，也需要到 Eureka 分舵報道，其他分舵（消費者）需要協助，也像 Eureka 分舵請求支援。分舵也培養新分舵，出現了幾個職能相同的分舵（服務帶集羣），Eureka 分舵看到分舵越來越多，自己也開始培養新分舵（服務中心集羣）。同時也建立了一個 Ribbon 分舵（客戶端負載均衡），負責對各個分舵進行高效的溝通。 Spring Cloud 門派名聲越來越大，加入的人越來越多，Spring Cloud 開始成立了 Zuul 分舵（網關），負責對新加入的人員進行篩選。
江湖還在，Spring Cloud 門派也越來越強大，到處都是他的傳說
Spring Cloud 與 Dubbo 區別
目前來說，在 Java 領域，微服務主要是 Spring Cloud 和 Dubbo 的天下，因此，人們經常喜歡比較兩種技術，然後選擇其中一種進行搭建。
由於 Dubbo 是國人開發的，有詳細的開發文檔，在 Spring Cloud 的萌芽時， 國人憑着滿腔熱情大力發展 Dubbo，不斷試坑，後來 Dubbo 發展停滯，Spring Cloud 的春風開始席捲神州大地。不過，目前 Dubbo 又開始起色，捐給了 Apache 。
| 技術維度 | Dubbo | Spring Cloud |
|---|---|---|
| 服務註冊中心 | Zookeeper | Spring Cloud Netflix Eurrke |
| 服務調用方式 | RPC | REST API |
| 服務監控 | Dubbo-monitor | spring boot admin |
| 斷路器 | 不完善 | Spirng Cloud Netflix Hystrix |
| 服務網關 | 無 | Spring Cloud Netflix Zuul |
| 分佈式配置 | 無 | Spring Cloud Config |
Eureka 組件
Eureka 音譯尤里卡，是 Spring Cloud 的註冊中心。在分佈式系統中，包含很多個節點，這些節點大體分爲消費者和提供者。
服務端和客戶端就是通過 Eureka 進行管理的。舉一個例子，Eureka 就好比小區的快遞箱，快遞就是服務端，取快遞的人就是客戶端。我們什麼時候可以取快遞呢，等快遞箱向我們發送短信，我們就可以去取快遞了。這就是 Eureka 的作用。這樣看來服務中心 Eureka 是十分重要的，爲了保證高可用，避免註冊中心掛掉，我們兩眼一抹黑的尷尬局面，一般來說， Eureka 會做集羣，保證高可用。同理可得，服務中心我們也需要集羣，保證高可用。
Eureka 作爲 Spring Cloud 框架的註冊中心，與之對應的是 Dubbo 框架的Zookeeper。他倆有什麼區別呢？這裏需要引入一個 CAP 定理。所謂 CAP 定理，分佈式系統的三個指標 C（一致性）、A（可用性）、P（分區容錯性）不可以同時滿足了。
一般來說，分區容錯無法避免，因此可以認爲 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到
參考：https://www.ruanyifeng.com/blog/2018/07/cap.html
而 Eureka 的設計原則是 AP，即可用性和分區容錯性。他保證了註冊中心的可用性，但捨棄了數據一致性，各節點上的數據有可能是不一致的（會最終一致）。ZK 的設計原則是 CP，即強一致性和分區容錯性。他保證數據的強一致性，但捨棄了可用性，如果出現網絡問題可能會影響 ZK 的選舉，導致 ZK 註冊中心的不可用。
參考：https://www.infoq.cn/article/jlDJQ*3wtN2PcqTDyokh
Ribbon
微服務劃分成幾個節點，他們分佈在不同的虛擬機，通訊就成了一個難點，通過我們會想到 HttpClient，如果是 Spring的話，我們可以用 RestTemplate，但是在集羣環境下，他們並不能做到負載均衡。因此，Ribbon 出現了。Ribbon 是一款在客戶端實行負載均衡的工具。Ribbon 其實現原理就是根據在配置文件中列出的機器，自動按照某種規則（輪詢，隨機）去連接這些機器。使用者也可以自定義自己的負載均衡算法。負載均衡目的是達到高可用。
Feign
Feign 是有一款客戶端負載均衡工具。既然有了 Ribbon ，爲什麼還要有 Feign 呢？ 在實際使用 Ribbon 組件中，我們會發現 Ribbon 會讓我們硬編碼，十分不靈活。因此，在 Ribbon 的基礎下，面向接口編程的 Feign 組件 就出現了。Feign 讓我們可以編寫出優雅的代碼，因此，實際中，Feign 得到大力使用。
Hystrix
Hystrix 是一個用於處理分佈式系統的延遲和容錯的開源庫，在分佈式系統裏，許多依賴不可避免的會調用失敗，比如超時、異常等，Hystrix 能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，以提高分佈式系統的彈性。
Hystrix 斷路器是一種開關裝置，當某個服務單元發生故障之後，通過斷路器的故障監控，向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方無法處理的異常，這樣就保證了服務調用方不會長時間、不必要佔用，從而避免了故障在分佈式系統中的蔓延，乃至雪崩。
提到服務雪崩，我們可以通過一張圖來理解。假設我們有三個服務調用 A B C。當其中下游的 C 服務發生故障，就有可能引起 服務雪崩。爲了解決 服務雪崩，我們就需要引入 Hystrix 組件。
Hystrix 主要是通過服務熔斷和服務降級來解決服務雪崩問題。那麼問題來了，服務熔斷和服務降級的區別又是什麼？
簡單來說服務熔斷屬於服務降級的一種，而服務降級有很多種降級方式！如開關降級、限流降級、熔斷降級。
參考：https://www.cnblogs.com/rjzheng/p/10340176.html
Zuul
Zuul中文是神獸的意思。在Spring Cloud 中，Zuul是一項網關服務，可提供動態路由，監視，彈性，安全性等。
簡單的話，Zuul 就是樓下保安亭的大爺，所有進入大樓的人，都需要大爺檢查，得到大爺的許可。 我們可以通過一張圖理解。
Spring Cloud Config
實際工作中，我們可能會有幾十上百的微服務節點，每一個節點有需要有配置信息，比如數據庫的連接，服務中心的地址等等，當中信息變化的時候，我們可能面臨手動一臺一臺修改的囧境。爲了解決上述問題，我們能否借鑑 Git 的思想，有一個標準的配置，當我們配置修改，我們只需要同步刷新一下即可，不用手動搬運呢？答案是有的，我們可以通過 Spring Cloud Config 達到同步更新配置信息。