SpringCloud 有哪些核心組件?(必會)

? Eureka: 注冊中心, 服務注冊和發現

? Ribbon: 負載均衡, 實現服務調用的負載均衡

? Hystrix: 熔斷器 ? Feign: 遠程調用

? Zuul: 網關

? Spring Cloud Config: 配置中心

(1)Eureka 提供服務注冊和發現, 是注冊中心. 有兩個組件: Eureka 服務端和 Eureka 客戶端 ? Eureka 服務端: 作為服務的注冊中心, 用來提供服務注冊, 支持集群部署.

? Eureka 客戶端: 是一個 java 客戶端, 將服務注冊到服務端, 同事將服務端的信息緩存 到本地, 客戶端和服務端定時交互.

1. 原理

? Eureka-Server：就是服務注冊中心（可以是一個集群），對外暴露自己的地址。

? 提供者：啟動后向 Eureka 注冊自己信息（地址，服務名稱等），并且定期進行服務續 約 ? 消費者：服務調用方，會定期去 Eureka 拉取服務列表，然后使用負載均衡算法選出一 個服務進行調用。

? 心跳(續約)：提供者定期通過 http 方式向 Eureka 刷新自己的狀態

2. 服務下線、失效剔除和自我保護

? 服務的注冊和發現都是可控制的，可以關閉也可以開啟。默認都是開啟

? 注冊后需要心跳，心跳周期默認 30 秒一次，超過 90 秒沒發心跳認為宕機

? 服務拉取默認 30 秒拉取一次.

? Eureka 每個 60 秒會剔除標記為宕機的服務

? Eureka 會有自我保護，當心跳失敗比例超過閾值(默認 85%)，那么開啟自我保護，不 再剔除服務。 ? Eureka 高可用就是多臺 Eureka 互相注冊在對方上.

(2)Ribbon

? Ribbon 是 Netflix 發布的云中服務開源項目. 給客戶端提供負載均衡, 也就是說 Ribbon 是作用在消費者方的.

? 簡單來說, 它是一個客戶端負責均衡器, 它會自動通過某種算法去分配你要連接的機 器. ? SpringCloud 認為 Ribbon 這種功能很好, 就對它進行了封裝, 從而完成負載均衡. ? Ribbon 默認負責均衡策略是輪詢策略.

(3)Hystrix 熔斷器

? 有時候可能是網絡問題, 一些其它問題, 導致代碼無法正常運行, 這是服務就掛了, 崩 潰了. 熔斷器就是為了解決無法正常訪問服務的時, 提供的一種解決方案.

? 解決因為一個服務崩潰而引起的一系列問題, 使問題只局限于這個服務中,不會影響其 他服務.

? Hystrix 提供了兩種功能, 一種是服務降級, 一種是服務熔斷.

1. 服務降級原理

? Hystrix 為每個服務分配了小的線程池, 當用戶發請求過來, 會通過線程池創建線 程來執行任務, 當創建的線程池已滿或者請求超時(這里和多線程線程池不一樣,不 存在任務隊列), 則啟動服務降級功能. ? 降級指的請求故障時, 不會阻塞, 會返回一個友好提示(可以自定義, 例如網站維 護中請稍后重試), 也就是說不會影響其他服務的運行.

2. 服務熔斷原理 狀態機有 3 個狀態：

? Closed：關閉狀態（斷路器關閉），所有請求都正常訪問。

? Open：打開狀態（斷路器打開），所有請求都會被降級。Hystix 會對請求情況計數， 當一定時間內失敗請求百分比達到閾值，則觸發熔斷，斷路器會完全關閉。默認失敗比 例的閾值是 50%，請求次數最少不低于 20 次。

? Half Open：半開狀態，open 狀態不是永久的，打開后會進入休眠時間（默認是 5S）。 隨后斷路器會自動進入半開狀態。此時會釋放 1 次請求通過，若這個請求是健康的， 則會關閉斷路器，否則繼續保持打開，再次進行 5 秒休眠計時。

(4)Feign: 遠程調用組件

? 后臺系統中, 微服務和微服務之間的調用可以通過 Feign 組件來完成.

? Feign 組件集成了 Ribbon 負載均衡策略(默認開啟的, 使用輪詢機制), Hystrix 熔斷器 (默認關閉的, 需要通過配置文件進行設置開啟)

? 被調用的微服務需要提供一個接口, 加上@@FeignClient("url")注解 ? 調用方需要在啟動類上加上@EnableFeignClients, 開啟 Feign 組件功能.

(5)Zuul: 路由/網關

?? 對于項目后臺的微服務系統, 每一個微服務都不會直接暴露給用戶來調用的, 但是如果 用戶知道了某一個服務的 ip:端口號:url:訪問參數, 就能直接訪問你. 如果再是惡意訪問, 惡意攻擊, 就會擊垮后臺微服務系統.因此, 需要一個看大門的大 boss, 來保護我們的 后臺系統.

? Zuul 類似 Nginx, 反向代理功能. 用戶訪問服務, 首先會到 Zuul 中心, Zuul 去 Eureka 中拉取服務, 獲取服務列表, 獲取具體的地址, 再通過具體的地址去訪問目標微服務.

? Zuul 提供了過濾和路由兩個功能, 過濾可以分配權限, 允許誰可以訪問誰不可以訪問, 路由則是去 Eureka 拉取服務提訪問地址.

? Zuul 網關也繼承了 Ribbon 負載均衡和 Hystix 熔斷機制.

(6)Spring Cloud Config

? 在分布式系統中，由于服務數量巨多，為了方便服務配置文件統一管理，實時更新，所 以需要分布式配置中心組件。在 Spring Cloud 中，有分布式配置中心組件 spring Cloud Config ，它支持配置服務放在配置服務的內存中（即本地），也支持放在遠程 Git 倉庫中.

? 那我們如果想在不重啟微服務的情況下更新配置如何來實現呢? 我們使用 SpringCloudBus 來實現配置的自動更新. ? 創建 Config Server 微服務, 用于存放配置文件, 默認使用 git 存儲此項目.

? 創建 Config Client 微服務, 用于拉取 git 上的配置文件, 項目中集成 SpringCloudBus 對應的消息中間件 jar 包.

? 更新配置文件的流程

? 手動向 Mq 隊列中發送消息,http://127.0.0.1:12000/actuator/bus-refresh(固定 地址)

? Config Client 中的 MQ 監聽到消息, 去 git 服務器上加載新的配置文件, 并向 mq 中生產一條配置文件變更的消息.

? 其他被集中管理的微服務也集成了 mq,監聽到消息, 向 Config Client 中重新獲取 最新的配置文件. 、

SpringBoot 和 SpringCloud 的關系(必會)

? SpringBoot 是為了解決 Spring 配置文件冗余問題, 簡化開發的框架.

? SpringCloud 是為了解決微服務之間的協調和配置問題, 還有服務之間的通信, 熔斷, 負載均衡遠程調度任務框架.

? SpringCloud 需要依賴 SpringBoot 搭建微服務, SpringBoot 使用了默認大于配 置的理念，很多集成方案已經幫你選擇好了，能不配置就不配置，SpringCloud 很大的一部分是基于 SpringBoot 來實現。

? SpringBoot 不需要依賴 SpringCloud 就可以獨立開發. SpringBoot 也可以集成 Dubbo 進行開發.

SpringCloud 和 Dubbo 的區別(高薪常問)

? SpringCloud 和 Dubbo 都是主流的微服務架構.

? SpringCloud 是 Apache 下的 Spring 體系下的微服務解決方案.

? Dubbo 是阿里系統中分布式微服務治理框架.

? 技術方面對比 ? SpringCloud 功能遠遠超過 Dubbo, Dubbo 只實現了服務治理(注冊和發現). 但 是 SpringCloud 提供了很多功能, 有 21 個子項目

? Dubbo 可 以 使 用 Zookeeper 作 為 注 冊 中 心 , 實 現 服 務 的 注 冊 和 發 現 , SpringCloud 不僅可以使用 Eureka 作為注冊中心, 也可以使用 Zookeeper 作為 注冊中心.

? Dubbo 沒有實現網關功能, 只能通過第三方技術去整合. 但是 SpringCloud 有 zuul 路由網關, 對請求進行負載均衡和分發. 提供熔斷器, 而且和 git 能完美集成.

? 性能方面對比

? 由于 Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基于 TCP 協議傳輸的，配合 以 Hession 序列化完成 RPC。

? 而 SpringCloud 是基于 Http 協議+Rest 接口調用遠程過程的，相對來說，Http 請求會有更大的報文，占的帶寬也會更多。

? 使用 Dubbo 時, 需要給每個實體類實現序列化接口, 將實體類轉化為二進制進行 RPC 通信調用.而使用 SpringCloud 時, 實體類就不需要進行序列化. 剛才有提到注冊中心不一樣,那么 Eureka 和 Zookeeper 有什么區別? 我們繼續往 下說~

Eureka 和 Zookeeper 的區別(高薪常問)

在談這個問題前我們先看下 CAP 原則: C(Consistency)-數據一致性; A(Availability)- 服務可用性; P(Partition tolerance)-服務對網絡分區故障的容錯性, 這三個特性在任何分 布式系統中不能同時滿足, 最多同時滿足兩個, 而且 P(分區容錯性)是一定要滿足的.

? Eureka 滿足 AP(服務可用性和容錯性), Zookeeper 滿足 CP(數據一致性和容錯性)

? Zookeeper 滿足 CP, 數據一致性, 服務的容錯性. 數據在各個服務間同步完成后才返 回用戶結果, 而且如果服務出現網絡波動導致監聽不到服務心跳, 會立即從服務列表中 剔除, 服務不可用.

? Eureka 滿足 AP, 可用性, 容錯性. 當因網絡故障時, Eureka 的自我保護機制不會立即 剔除服務, 雖然用戶獲取到的服務不一定是可用的, 但至少能夠獲取到服務列表. 用戶 訪問服務列表時還可以利用重試機制, 找到正確的服務. 更服務分布式服務的高可用需 求.

? Eureka 集群各節點平等, Zookeeper 集群有主從之分.

1. 如果 Zk 集群中有服務宕機,會重新進行選舉機制,選擇出主節點, 因此可 能會導致整個集群因為選主而阻塞, 服務不可用.

2. Eureka 集群中有服務宕機,因為是平等的各個服務器,所以其他服務器不 受影響.

? Eureka 的服務發現者會主動拉取服務, ZK 服務發現者是監聽機制

1. Eureka 中獲取服務列表后會緩存起來, 每隔 30 秒重新拉取服務列表.

2. Zk 則是監聽節點信息變化, 當服務節點信息變化時, 客戶端立即就得到 通知.