1、什麼是Spring Cloud ？ Spring cloud 流應用程式啟動器是基於 Spring Boot 的 Spring 集成應用程式，提供與外部系統的集成。Spring cloud Task，一個生命周期短暫的微服務框架，用於快速構建執行有限數據處理的應用程式。 Spring Cloud ...
1、什麼是Spring Cloud ？
Spring cloud 流應用程式啟動器是基於 Spring Boot 的 Spring 集成應用程式，提供與外部系統的集成。Spring cloud Task，一個生命周期短暫的微服務框架，用於快速構建執行有限數據處理的應用程式。
Spring Cloud各個微服務之間為什麼要用http交互？難道不慢嗎？
Spring Cloud是一個為分散式微服務架構構建應用程式的開發工具箱，是Spring Boot的擴展，通過各種微服務組件的集成，極大地簡化了微服務應用程式的構建和開發。在分散式系統中，各個微服務之間的通信是非常重要的，而HTTP作為通信協議具有普遍性和可擴展性，是Spring Cloud微服務架構中主流的通信方式。
儘管使用HTTP作為微服務之間的通信協議存在一定的網路開銷，但是這種不可避免的網路開銷遠低於我們所能得到的好處。使用HTTP通信可以實現松耦合和非同步通信，微服務之間可以彼此獨立地進行開發和測試，單個微服務的故障不會影響整個系統的運行，也可以支持各種不同的技術棧之間的互操作性。
另外，使用HTTP作為通信協議還具有優秀的可擴展性。HTTP協議定義了不同的請求方法（例如 GET、POST、DELETE 等），不同請求方法的擴展格式也很靈活，可以用來傳遞各種類型的數據和格式，同時HTTP協議支持緩存，減少重覆性的數據傳輸和帶寬開銷。
當然，為了提高微服務之間的通信效率，我們也可以通過一些優化手段來減少HTTP協議的網路開銷。例如，使用數據壓縮和緩存技術來壓縮和緩存請求和響應，減少網路數據傳輸量和響應時間；使用負載均衡技術來合理地分配請求和響應，避免單個微服務出現性能瓶頸；使用高速緩存技術來緩存請求和響應，避免重覆的請求和響應等等。
因此，Spring Cloud各個微服務之間使用HTTP交互是一個比較成熟的選擇。雖然它可能存在一些網路開銷，但是在實際應用中，這種開銷是可以優化和控制的，甚至可以提高系統的可擴展性和可靠性。
本文已經收錄到Github倉庫，該倉庫包含電腦基礎、Java基礎、多線程、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分散式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~
如果訪問不了Github，可以訪問碼雲地址。
2、什麼是微服務？
微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程式劃分為一組小的服務，每個服務運行在其獨立的自己的進程中，服務之間相互協調、互相配合，為用戶提供最終價值。服務之間採用輕量級的通信機制互相溝通（通常是基於HTTP的RESTful API）,每個服務都圍繞著具體的業務進行構建，並且能夠被獨立的構建在生產環境、類生產環境等。另外，應避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。
通俗地來講：
微服務就是一個獨立的職責單一的服務應用程式。在 intellij idea 工具裡面就是用maven開發的一個個獨立的module，具體就是使用springboot 開發的一個小的模塊，處理單一專業的業務邏輯，一個模塊只做一個事情。
微服務強調的是服務大小，關註的是某一個點，具體解決某一個問題/落地對應的一個服務應用，可以看做是idea 裡面一個 module。
3、Spring Cloud有什麼優勢
使用 Spring Boot 開發分散式微服務時，我們面臨以下問題
- 與分散式系統相關的複雜性-這種開銷包括網路問題，延遲開銷，帶寬問題，安全問題。
- 服務發現-服務發現工具管理群集中的流程和服務如何查找和互相交談。它涉及一個服務目錄，在該目錄中註冊服務，然後能夠查找並連接到該目錄中的服務。
- 冗餘-分散式系統中的冗餘問題。
- 負載平衡 --負載平衡改善跨多個計算資源的工作負荷，諸如電腦，電腦集群，網路鏈路，中央處理單元，或磁碟驅動器的分佈。
- 性能-問題 由於各種運營開銷導致的性能問題。
- 部署複雜性-Devops 技能的要求。
4、微服務之間如何獨立通訊的?
同步通信：dobbo通過 RPC 遠程過程調用、springcloud通過 REST 介面json調用等。
非同步：消息隊列，如：RabbitMq、ActiveM、Kafka等消息隊列。
5、 什麼是服務熔斷？什麼是服務降級？
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。當某個微服務不可用或者響應時間太長時，會進行服務降級，進而熔斷該節點微服務的調用，快速返回“錯誤”的響應信息。當檢測到該節點微服務調用響應正常後恢復調用鏈路。在Spring Cloud框架里熔斷機制通過Hystrix實現，Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，預設是5秒內調用20次，如果失敗，就會啟動熔斷機制。
服務降級，一般是從整體負荷考慮。就是當某個服務熔斷之後，伺服器將不再被調用，此時客戶端可以自己準備一個本地的fallback回調，返回一個預設值。這樣做，雖然水平下降，但好歹可用，比直接掛掉強。
Hystrix相關註解@EnableHystrix：開啟熔斷 @HystrixCommand(fallbackMethod=”XXX”)，聲明一個失敗回滾處理函數XXX，當被註解的方法執行超時（預設是1000毫秒），就會執行fallback函數，返回錯誤提示。
6、 請說說Eureka和zookeeper 的區別？
Zookeeper保證了CP，Eureka保證了AP。
A：高可用
C：一致性
P：分區容錯性
1.當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用。也就是說，服務註冊功能對高可用性要求比較高，但zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯繫時，剩餘節點會重新選leader。問題在於，選取leader時間過長，30 ~ 120s，且選取期間zk集群都不可用，這樣就會導致選取期間註冊服務癱瘓。在雲部署的環境下，因網路問題使得zk集群失去master節點是較大概率會發生的事，雖然服務能夠恢復，但是漫長的選取時間導致的註冊長期不可用是不能容忍的。
2.Eureka保證了可用性，Eureka各個節點是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點仍然可以提供註冊和查詢服務。而Eureka的客戶端向某個Eureka註冊或發現時發生連接失敗，則會自動切換到其他節點，只要有一臺Eureka還在，就能保證註冊服務可用，只是查到的信息可能不是最新的。除此之外，Eureka還有自我保護機制，如果在15分鐘內超過85%的節點沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心發生了網路故障，此時會出現以下幾種情況：
①、Eureka不在從註冊列表中移除因為長時間沒有收到心跳而應該過期的服務。
②、Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點仍然可用）
③、當網路穩定時，當前實例新的註冊信息會被同步到其他節點。
因此，Eureka可以很好地應對因網路故障導致部分節點失去聯繫的情況，而不會像Zookeeper那樣使整個微服務癱瘓
另外給大家分享一個Github倉庫，上面有大彬整理的300多本經典的電腦書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、操作系統、電腦網路、數據結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~
7、SpringBoot和SpringCloud的區別？
SpringBoot專註於快速方便得開發單個個體微服務。
SpringCloud是關註全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合併管理起來，
為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全局鎖、決策競選、分散式會話等等集成服務
SpringBoot可以離開SpringCloud獨立使用開發項目， 但是SpringCloud離不開SpringBoot ，屬於依賴的關係.
SpringBoot專註於快速、方便得開發單個微服務個體，SpringCloud關註全局的服務治理框架。
8、負載平衡的意義什麼？
在計算中，負載平衡可以改善跨電腦，電腦集群，網路鏈接，中央處理單元或磁碟驅動器等多種計算資源的工作負載分佈。負載平衡旨在優化資源使用，最大化吞吐量，最小化響應時間並避免任何單一資源 的過載。使用多個組件進行負載平衡而不是單個組件可能會通過冗餘來提高可靠性和可用性。負載平衡通常涉及專用軟體或硬體，例如多層交換機或功能變數名稱系統伺服器進程。
9、什麼是Hystrix？它如何實現容錯？
Hystrix是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的故障時，停止級聯故障併在複雜的分散式系統中實現彈性。
通常對於使用微服務架構開發的系統，涉及到許多微服務。這些微服務彼此協作。
思考一下微服務：
假設如果上圖中的微服務9失敗了，那麼使用傳統方法我們將傳播一個異常。但這仍然會導致整個系統崩潰。
隨著微服務數量的增加，這個問題變得更加複雜。微服務的數量可以高達1000.這是hystrix出現的地方 我們將使用Hystrix在這種情況下的Fallback方法功能。我們有兩個服務employee-consumer使用由employee-consumer公開的服務。
簡化圖如下所示
現在假設由於某種原因，employee-producer公開的服務會拋出異常。我們在這種情況下使用Hystrix定義了一個回退方法。這種後備方法應該具有與公開服務相同的返回類型。如果暴露服務中出現異常，則回退方法將返回一些值。
10、什麼是Hystrix斷路器？我們需要它嗎？
由於某些原因，employee-consumer公開服務會引發異常。在這種情況下使用Hystrix我們定義了一個回退方法。如果在公開服務中發生異常，則回退方法返回一些預設值。
如果firstPage method() 中的異常繼續發生，則Hystrix電路將中斷，並且員工使用者將一起跳過firtsPage方法，並直接調用回退方法。斷路器的目的是給第一頁方法或第一頁方法可能調用的其他方法留出時間，並導致異常恢復。可能發生的情況是，在負載較小的情況下，導致異常的問題有更好的恢復機會 。
11、說說 RPC 的實現原理
首先需要有處理網路連接通訊的模塊，負責連接建立、管理和消息的傳輸。其次需要有編 解碼的模塊，因為網路通訊都是傳輸的位元組碼，需要將我們使用的對象序列化和反序列化。剩下的就是客戶端和伺服器端的部分，伺服器端暴露要開放的服務介面，客戶調用服 務介面的一個代理實現，這個代理實現負責收集數據、編碼並傳輸給伺服器然後等待結果返回。
12，eureka自我保護機制是什麼?
當Eureka Server 節點在短時間內丟失了過多實例的連接時（比如網路故障或頻繁啟動關閉客戶端）節點會進入自我保護模式，保護註冊信息，不再刪除註冊數據，故障恢復時，自動退出自我保護模式。
13，什麼是Ribbon？
ribbon是一個負載均衡客戶端，可以很好地控制htt和tcp的一些行為。feign預設集成了ribbon。
14，什麼是 Netflix Feign？它的優點是什麼？
Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 啟發的 java 客戶端聯編程式。
Feign 的第一個目標是將約束分母的複雜性統一到 http apis，而不考慮其穩定性。
特點：
- Feign 採用的是基於介面的註解
- Feign 整合了ribbon，具有負載均衡的能力
- 整合了Hystrix，具有熔斷的能力
使用方式
- 添加pom依賴。
- 啟動類添加
@EnableFeignClients - 定義一個介面
@FeignClient(name=“xxx”)指定調用哪個服務
15， Ribbon和Feign的區別？
1.啟動類註解不同，Ribbon是@RibbonClient feign的是@EnableFeignClients；2.服務指定的位置不同，Ribbon是在@RibbonClient註解上聲明，Feign則是在定義抽象方法的介面中使用@FeignClient聲明；3.調用方式不同，Ribbon需要自己構建http請求，模擬http請求。
16、Spring Cloud 的核心組件有哪些？
- Eureka：服務註冊於發現。
- Feign：基於動態代理機制，根據註解和選擇的機器，拼接請求 url 地址，發起請求。
- Ribbon：實現負載均衡，從一個服務的多台機器中選擇一臺。
- Hystrix：提供線程池，不同的服務走不同的線程池，實現了不同服務調用的隔離，避免了服務雪崩的問題。
- Zuul：網關管理，由 Zuul 網關轉發請求給對應的服務。
17、說說Spring Boot和Spring Cloud的關係
Spring Boot是Spring推出用於解決傳統框架配置文件冗餘,裝配組件繁雜的基於Maven的解決方案,旨在快速搭建單個微服務而Spring Cloud專註於解決各個微服務之間的協調與配置,服務之間的通信,熔斷,負載均衡等技術維度並相同,並且Spring Cloud是依賴於Spring Boot的,而Spring Boot並不是依賴與Spring Cloud,甚至還可以和Dubbo進行優秀的整合開發
總結
- SpringBoot專註於快速方便的開發單個個體的微服務
- SpringCloud是關註全局的微服務協調整理治理框架,整合併管理各個微服務,為各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件匯流排等集成服務
- Spring Boot不依賴於Spring Cloud，Spring Cloud依賴於Spring Boot,屬於依賴關係
- Spring Boot專註於快速,方便的開發單個的微服務個體,Spring Cloud關註全局的服務治理框架
18、說說微服務之間是如何獨立通訊的？
遠程過程調用（Remote Procedure Invocation）
也就是我們常說的服務的註冊與發現，直接通過遠程過程調用來訪問別的service。
優點：簡單，常見,因為沒有中間件代理，系統更簡單
缺點：只支持請求/響應的模式，不支持別的，比如通知、請求/非同步響應、發佈/訂閱、發佈/非同步響應，降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的。
消息
使用非同步消息來做服務間通信。服務間通過消息管道來交換消息，從而通信。
優點：把客戶端和服務端解耦，更松耦合，提高可用性，因為消息中間件緩存了消息，直到消費者可以消費， 支持很多通信機制比如通知、請求/非同步響應、發佈/訂閱、發佈/非同步響應。
缺點：消息中間件有額外的複雜。
19、Spring Cloud如何實現服務的註冊?
服務發佈時，指定對應的服務名，將服務註冊到 註冊中心(Eureka 、Zookeeper)。
註冊中心加@EnableEurekaServer，服務用@EnableDiscoveryClient，然後用ribbon或feign進行服務直接的調用發現。
20、什麼是服務熔斷？
在複雜的分散式系統中,微服務之間的相互調用,有可能出現各種各樣的原因導致服務的阻塞,在高併發場景下,服務的阻塞意味著線程的阻塞,導致當前線程不可用,伺服器的線程全部阻塞,導致伺服器崩潰,由於服務之間的調用關係是同步的,會對整個微服務系統造成服務雪崩
為瞭解決某個微服務的調用響應時間過長或者不可用進而占用越來越多的系統資源引起雪崩效應就需要進行服務熔斷和服務降級處理。
所謂的服務熔斷指的是某個服務故障或異常一起類似顯示世界中的“保險絲"當某個異常條件被觸發就直接熔斷整個服務，而不是一直等到此服務超時。
服務熔斷就是相當於我們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,通過維護一個自己的線程池,當線程達到閾值的時候就啟動服務降級,如果其他請求繼續訪問就直接返回fallback的預設值
21、瞭解Eureka自我保護機制嗎？
當Eureka Server 節點在短時間內丟失了過多實例的連接時（比如網路故障或頻繁啟動關閉客戶端）節點會進入自我保護模式，保護註冊信息，不再刪除註冊數據，故障恢復時，自動退出自我保護模式。
22、熟悉 Spring Cloud Bus 嗎?
spring cloud bus 將分散式的節點用輕量的消息代理連接起來，它可以用於廣播配置文件的更改或者服務直接的通訊，也可用於監控。如果修改了配置文件，發送一次請求，所有的客戶端便會重新讀取配置文件。
23、Spring Cloud 斷路器有什麼作用?
當一個服務調用另一個服務由於網路原因或自身原因出現問題，調用者就會等待被調用者的響應，當更多的服務請求到這些資源導致更多的請求等待，發生連鎖效應（雪崩效應）。一段時間內 達到一定的次數無法調用 並且多次監測沒有恢復的跡象，這時候斷路器完全打開 那麼下次請求就不會請求到該服務。
半開：短時間內 有恢復跡象 斷路器會將部分請求發給該服務，正常調用時 斷路器關閉。關閉：當服務一直處於正常狀態 能正常調用。
24、瞭解Spring Cloud Config 嗎?
在分散式系統中，由於服務數量巨多，為了方便服務配置文件統一管理，實時更新，所以需要分散式配置中心組件。在Spring Cloud中，有分散式配置中心組件Spring Cloud Config，它支持配置服務放在配置服務的記憶體中（即本地），也支持放在遠程Git倉庫中。
在Spring Cloud Config 組件中，分兩個角色，一是config server，二是config client。
使用方式：
- 添加pom依賴
- 配置文件添加相關配置
- 啟動類添加註解@EnableConfigServer
25、說說你對Spring Cloud Gateway的理解
Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關。網關作為流量的，在微服務系統中有著非常作用，網關常見的功能有路由轉發、許可權校驗、限流控制等作用。
使用了一個RouteLocatorBuilder的bean去創建路由，除了創建路由RouteLocatorBuilder可以讓你添加各種predicates和filters，predicates斷言的意思，顧名思義就是根據具體的請求的規則，由具體的route去處理，filters是各種過濾器，用來對請求做各種判斷和修改。
最後給大家分享一個Github倉庫，上面有大彬整理的300多本經典的電腦書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、操作系統、電腦網路、數據結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~
Github地址：https://github.com/Tyson0314/java-books
