Spring Cloud微服務

微服務架構4個核心問題？

1. 服務很多，客戶端該怎麼訪問？
2. 這麼多服務？服務之間如何通訊？
3. 這麼多服務？如何治理？
4. 服務掛了怎麼辦？

解決方案：

Spring Cloud 生態！

1. Spring Cloud NetFlix （一站式解決方案）

   api閘道器，zuul元件

   Feign ----HttpClient---- Http通訊方式，阻塞

   服務註冊與發現：Eureka

   熔斷機制：Hystrix

2. Apache Dubbo zookeeper （半自動，需要整合別人的）

   API：沒有，找第三方元件，或者自己實現

   Dubbo

   zookeeper

   熔斷機制沒有，藉助Hystria

3. Spring Cloud Alibaba （一站式解決方案）

   與第一種很類似

4. API 解決路由問題

5. HTTP，RPC解決通訊問題

6. 註冊和發現，解決高可用問題

7. 熔斷機制，解決降級問題

常見面試題

1. 什麼是微服務？
2. 微服務之間是如何獨立通訊的？
3. Spring Cloud 和Dubbo有哪些區別？
4. Spring Boot和Spring Cloud，請你談談對他們的理解
5. 什麼是服務熔斷，什麼是服務降級
6. 微服務的優缺點分別是什麼？說下你在專案中遇到的坑
7. 你所知道的微服務技術棧有哪些？請列舉一二
8. eureka和zookeeper都可以提供服務註冊與發現的功能，請說說兩個的區別

1、什麼是Spring Cloud

1.1、什麼是Spring Cloud

​ SpringCloud,基於SprihgBoot提供了一套微服務解決方案，包括服務註冊與發現，配置中心，全鏈路監控，服務閘道器，負載均衡，熔斷器等元件，除了基於NetFlix的開源元件做高度抽象封裝之外，還有一些選型中立的開源元件。

​ SpringCloud利用SpringBoot的開發便利性，巧妙地簡化了分散式系統基礎設施的開發，SpringCloud為開發人員提供了快速構建分散式系統的一些工具，包括配置管理，服務發現，斷路器，路由，微代理，事件匯流排，全域性鎖，決策競選，分散式會話等等，他們都可以用SpringBoot的開發風格做到一鍵啟動和部署。

​ SpringBoot並沒有重複造輪子，它只是將目前各家公司開發的比較成熟，經得起實際考研的服務框架組合起來，通過SpringBoot風格進行再封裝，遮蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂，易部署和易維護的分散式系統開發工具包

​ SpringCloud是分散式微服務架構下的一站式解決方案，是各個微服務架構落地技術的集合體，俗稱微服務全家桶。

1.2、SpringCloud和SpringBoot關係

• SpringBoot專注於快速方便的開發單個個體微服務。
• SpringCloud是關注全域性的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，為各個微服務之間提供∶配置管理，服務發現，斷路器，路由，微代理，事件匯流排，全域性鎖，決策競選，分散式會話等等整合服務。
• SpringBoot可以離開SpringClooud獨立使用，開發專案，但是SpringCloud離不開SpringBoot，屬於依賴關係
• SpringBoot專注於快速、方便的開發單個個體微服務，SpringCloud關注全域性的服務治理框架

2、Eureka服務註冊與發現

2.1、什麼是Eureka

• Netflix在設計Eureka時，遵循的就是AP原則
• Eureka是Netflix的一個子模組，也是核心模組之一。Eureka是一個基於REST的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移，服務註冊於發現對於微服務來說是非常重要的，有了服務發現與註冊，只需要使用服務的識別符號，就可以訪問到服務，而不需要修改服務呼叫的配置檔案了，功能類似於Dubbo的註冊中心，比如zookeeper

2.2、原理講解

• Eureka的基本架構
  • SpringCloud封裝了NetFlix公司開發的Eureka模組來實現服務註冊和發現(對比Zookeeper)
  • Eureka採用了C-S的架構設計，EurekaServer作為服務註冊功能的伺服器，他是服務註冊中心
  • 而系統中的其他微服務。使用Eureka的客戶端連線到EurekaServer並維持心跳連線。這樣系統的維護人員就可以通過EurekaServer來監控系統中各個微服務是否正常執行，SpringCloud的一些其他模組（比如Zuul）就可以通過EurekaServer來發現系統中的其他微服務，並執行相關的邏輯;
  • 和Dubbo架構對比
  • Eureka包含兩個元件: Eureka Server和Eureka Client 。
  • Eureka Server提供服務註冊服務，各個節點啟動後，會在EurekaServer中進行註冊，這樣Eureka Server中的服務登錄檔中將會村粗所有可用服務節點的資訊，服務節點的資訊可以在介面中直觀的看到。
  • Eureka Client是一個Java客戶端，用於簡化EurekaServer的互動，客戶端同時也具備一個內建的，使用輪詢負載演算法的負載均衡器。在應用啟動後，將會向EurekaServer傳送心跳（預設週期為30秒)。如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，EurekaServer將會從服務登錄檔中把這個服務節點移除掉（預設週期為90秒)
• 三大角色
  • Eureka Server：提供服務的註冊與發現
  • Service Provider：將自身服務註冊到Eureka中，從而使消費方能夠找到
  • Service Consumer：服務消費方從Eureka中獲取註冊服務列表，從而找到消費服務

3、CAP原則

回顧CAP原則

RDBMS（MySql，Oracle，SqlServer）===> ACID

NoSQL（Redis，mongdb）===> CAP

ACID是什麼？

• A（Atomicity）原子性
• C（Consistency）一致性
• I（Isolation）隔離性
• D（Durability）永續性

CAP是什麼?

• C（Consistency）強一致性
• A（Availablity）可用性
• P（Partition tolerance）分割槽容錯性
• CAP的三進二：CA、AP、CP

CAP的核心

• 一個分散式系統不可能同時很好的滿足一致性，可用性和分割槽容錯性這三個需求
• 根據CAP原理，將NoSQL資料庫分成了滿足CA原則，滿足CP原則和滿足AP原則三大類：
  • CA：單點叢集，滿足一致性，可用性系統，通常可擴充套件性較差
  • CP：滿足一直性，分割槽容錯性的系統，通常效能不是特別高
  • AP：滿足可用性，分割槽容錯性的系統，通常性可能對一致性要求低一些

作為服務註冊中心，Eureka比Zookeeper好在哪裡？

著名的CAP理論指出，一個分散式系統不可能同時滿足C（一致性），A（可用性），P（容錯性）

由於分割槽容錯性P在分散式系統中是必須要保證的，因此我們只能在A和C之間進行權衡

• Zookeeper保證的是CP
• Eureka保證的是AP

zookeeper保證的是CP

​ 當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s，且選舉期間整個zk叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因為網路問題使得z水k叢集失去master節點是較大概率會發生的事件，雖然服務最終能夠恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

Eureka保證的是AP

​ Eureka看明白了這一-點， 因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作,剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊時，如果
發現連線失敗，則會自動切換至其他節點，只要有一臺Eureka還在， 就能保住註冊服務的可用性,只不過查到的資訊可能不是最新的，除此之外，Eureka還有一 種自我保護機制， 如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況:

1. Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其他節點上(即保證當前節點依然可用)
3. 當網路穩定時，當前例項新的的註冊資訊會被同步到其他節點上

因此，Eureka可以很好的應對網路故障導致部分節點失去聯絡的情況，而不會像Zookeeper那樣使整個服務癱瘓

4、負載均衡及Ribbon

4.1、ribbon是什麼?

• Spring Cloud Ribbon是基於Netflix Ribbon實現的一套客戶端負載均衡的工具。
• 簡單的說，Ribbon是Netflix釋出的開源專案，主要功能是提供客戶端的軟體負載均衡演算法,將NetFlix的中間層服務連線在一起。Ribbon的客戶端元件提供-系列完整的配置項如: 連線超時、重試等等。簡單的說，就是在配置檔案中列出LoadBalancer (簡稱LB:負載均衡)後面所有的機器，Ribbon會自動的幫助你基於某種規則(如簡單輪詢，隨機連線等等)去連線這些機器。我們也很容易使用Ribbon實現自定義的負載均衡演算法!

4.2、ribbon能幹嘛?

• LB,即負載均衡(Load Balance) ，在微服務或分散式叢集中經常用的一種應用。
• 負載均衡簡單的說就是將使用者的請求平攤的分配到多個服務上,從而達到系統的HA (高可用)。
• 常見的負載均衡軟體有Nginx，Lvs 等等
• dubbo、 SpringCloud中均給我們提供 了負載均衡，SpringCloud的負載均衡演算法可以自定義
• 負載均衡簡單分類:
  • 集中式LB
    • 即在服務的消費方和提供方之間使用獨立的LB設施，如Nginx:反向代理伺服器!，由該設施負責把
      訪問請求通過某種策略轉發至服務的提供方!
  • 程式式LB
    • 將LB邏輯整合到消費方，消費方從服務註冊中心獲知有哪些地址可用，然後自己再從這些地址中選出
      一個合適的伺服器。
    • Ribbon就屬於程式內LB，它只是-個類庫,整合於消費方程式,消費方通過它來獲取到服務提供方
      的地址!

5、Feign使用介面方式呼叫服務

5.1、簡介

feign,主要是社群，大家都習慣面向介面程式設計。這個是很多開發人員的規範。呼叫微服務訪問兩種方法

1. 微服務名字 【ribbon】
2. 介面和註解 【feign 】

Feign能幹什麼?

• Feign旨在使編寫Java Http客戶端變得更容易
• 前面在使用Ribbon + RestTemplate時,利用RestTemplate對Http請求的封裝處理，形成了-套模板化的呼叫
  方法。但是在實際開發中，由於對服務依賴的呼叫可能不止一-處， 往往一個介面會被多處呼叫， 所以通常都會針對每個微服務自行封裝一些客戶端類來包裝這些依賴服務的呼叫。 所以，Feign在此基礎 上做了進一步封
  裝，由他來幫助我們定義和實現依賴服務介面的定義,在Feign的實現下，我們只需要建立一個介面並使用注
  解的方式來配置它(類似於以前Dao介面上標註Mapper註解，現在是一一個微服務介面， 上面標註一個Feign註解即可。)即可完成對服務提供方的介面繫結，簡化了使用Spring Cloud Ribbon時，自動封裝服務呼叫客戶端的開發量。

Feign整合了Ribbon

• 利用Ribbon維護了MicroServiceCloud-Dept的服務列表資訊，井且通過輪詢實現了客戶端的負載均衡，而與
  Ribbon不同的是，通過Feign只需要定義服務繫結介面且以宣告式的方法，優雅而且簡單的實現了服務呼叫。

6、Hystrix服務熔斷

6.1、分散式系統面臨的問題

複雜分散式體系結構中的應用程式有數十個依賴關係，每個依賴關係在某些時候將不可避免的失敗!

6.2、服務雪崩

​ 多個微服務之間呼叫的時候，假設微服務A呼叫微服務B和微服務C,微服務B和微服務C又呼叫其他的微服務,這就是所謂的“扇出”"、如果扇出的鏈路上某個微服務的呼叫響應時間過長或者不可用對微服務A的呼叫就會佔用越來越多的系統資源，進而引起系統崩潰，所謂的“雪崩效應”。

​ 對於高流量的應用來說，單- -的後端依賴可能會導致所有伺服器上的所有資源都在幾秒中內飽和。比失敗更糟糕的是，這些應用程式還可能導致服務之間的延遲增加，備份佇列，執行緒和其他系統資源緊張，導致整個系統發生更多的級聯故障，這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關係的失敗，不能取消整個應用程式或系統。

​ 我們需要，棄車保帥.

6.3、什麼是Hystrix

​ Hystrix是一個用於處理分散式系統的延遲和容錯的開源庫， 在分散式系統裡，許多依賴不可避免的會呼叫失敗，比如超時，異常等，Hystrix能夠保證在一 個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障,
以提高分散式系統的彈性。

​ “斷路器”本身是一種開關裝置， 當某個服務單元發生故障之後，通過斷路器的故障監控(類似熔斷保險絲) , 向呼叫方返回-個服務預期的，可處理的備選響應(FallBack) ，而不是長時間的等待或者丟擲呼叫方法無法處理的異常，這樣就可以保證了服務呼叫方的執行緒不會被長時間，不必要的佔用，從而避免了故障在分散式系統中的蔓延，乃至雪崩。

6.4、服務熔斷

是什麼
熔斷機制是對應雪崩效應的一種微服務鏈路保護機制。
當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的呼叫，快速返回錯誤的響應資訊。當檢測到該節點微服務呼叫響應正常後恢復呼叫鏈路。在SpringCloud框架裡熔斷機制通過Hystrix實現。Hystrix會監 控微服務間呼叫的狀況，當失敗的呼叫到一定閾值，預設是5秒內20次呼叫失敗就會啟動熔斷機制。熔斷機制的註解是@HystrixCommand.

7、Zuul路由閘道器

概述
什麼是Zuul?

Zuul包含了對請求的路由和過濾兩個最主要的功能:

​ 其中路由功能負責將外部請求轉發到具體的微服務例項上，是實現外部訪問統一入口的基礎，而過濾器功能則負責對請求的處理過程進行干預，是實現請求校驗，服務聚合等功能的基礎。Zuul和Eureka進行整合，將Zuul自身註冊為Eureka服務治理下的應用，同時從Eureka中獲得其他微服務的訊息，也即以後的訪問微服務都是通過Zuul跳轉後獲得。

**注意：**Zuul服務最終還是會註冊進Eureka

**提供：**代理＋路由＋過濾t三大功能!

Zuul能幹嘛?

• 路由
• 過濾