前言：
今天一覺起來，發現我們開工的日期又延遲了，雖然已經在家辦公一個多禮拜了，但是由於家裏的環境還是不能有很高的效率。於是乾脆就對Spring Cloud的一些知識點做了一些整理。
整理了一些 Spring Cloud 相關面試題，大家測測自己對 Spring Cloud 掌握情況，看看自己的自測結果。
什麼是Spring Cloud？
spring cloud 是一系列框架的有序集合。它利用 spring boot 的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用 spring boot 的開發風格做到一鍵啓動和部署。
使用Spring Cloud有什麼優勢？
使用Spring Boot開發分佈式微服務時，我們面臨以下問題
-
與分佈式系統相關的複雜性-這種開銷包括網絡問題，延遲開銷，帶寬問題，安全問題。
-
服務發現-服務發現工具管理羣集中的流程和服務如何查找和互相交談。它涉及一個服務目錄，在該目錄中註冊服務，然後能夠查找並連接到該目錄中的服務。
-
冗餘-分佈式系統中的冗餘問題。
-
負載平衡 --負載平衡改善跨多個計算資源的工作負荷，諸如計算機，計算機集羣，網絡鏈路，中央處理單元，或磁盤驅動器的分佈。
-
性能-問題 由於各種運營開銷導致的性能問題。
-
部署複雜性-Devops技能的要求。
Spring Cloud 實現服務註冊和發現的原理是什麼？
-
服務在發佈時指定對應的服務名（服務名包括了 IP 地址和端口）將服務註冊到註冊中心（Eureka 或者 Zookeeper）這一過程是 Spring Cloud 自動實現的，只需要在 main 方法添加 @EnableDisscoveryClient 即可，同一個服務修改端口就可以啓動多個實例。
-
調用方法：傳遞服務名稱通過註冊中心獲取所有的可用實例，通過負載均衡策略調用（Ribbon 和 Feign）對應的服務。
爲什麼要使用 Spring Cloud 熔斷器？
當一個服務調用另一個服務，由於網絡原因或者自身原因出現問題時 ，調用者就會等待被調者的響應，當更多的服務請求到這些資源時，導致更多的請求等待，這樣就會發生連鎖效應，斷路器就是解決這一問題的。
斷路器的狀態有以下幾種：
-
完全打開：一定時間內，達到一定的次數無法調用，並且多次檢測沒有恢復的跡象，斷路器完全打開，那麼下次的請求不會請求到該服務。
-
半開：短時間內有恢復跡象，斷路器會將部分請求發送給服務，當能正常調用時，斷路器關閉。
-
關閉：服務一直處於正常狀態，能正常調用，斷路器關閉。
服務註冊和發現是什麼意思？Spring Cloud如何實現？
當我們開始一個項目時，我們通常在屬性文件中進行所有的配置。隨着越來越多的服務開發和部署，添加和修改這些屬性變得更加複雜。有些服務可能會下降，而某些位置可能會發生變化。手動更改屬性可能會產生問題。Eureka服務註冊和發現可以在這種情況下提供幫助。由於所有服務都在Eureka服務器上註冊並通過調用Eureka服務器完成查找，因此無需處理服務地點的任何更改和處理。
spring cloud 和dubbo區別?
-
服務調用方式 dubbo是RPC springcloud Rest Api
-
註冊中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper
-
服務網關,dubbo本身沒有實現，只能通過其他第三方技術整合，springcloud有Zuul路由網關，作爲路由服務器，進行消費者的請求分發,springcloud支持斷路器，與git完美集成配置文件支持版本控制，事物總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素。
微服務之間是如何獨立通訊的
1.遠程過程調用（Remote Procedure Invocation）：也就是我們常說的服務的註冊與發現，直接通過遠程過程調用來訪問別的service。
優點：
- 簡單，常見,因爲沒有中間件代理，系統更簡單
缺點：
- 只支持請求/響應的模式，不支持別的，比如通知、請求/異步響應、發佈/訂閱、發佈/異步響應
- 降低了可用性，因爲客戶端和服務端在請求過程中必須都是可用的
2.消息：使用異步消息來做服務間通信。服務間通過消息管道來交換消息，從而通信。
優點:
-
把客戶端和服務端解耦，更松耦合
-
提高可用性，因爲消息中間件緩存了消息，直到消費者可以消費
-
支持很多通信機制比如通知、請求/異步響應、發佈/訂閱、發佈/異步響應
缺點:
- 消息中間件有額外的複雜
負載均衡的意義是什麼?
在計算中，負載均衡可以改善跨計算機，計算機集羣，網絡鏈接，中央處理單元或磁盤驅動器等多種計算資源的工作負載分佈。負載均衡旨在優化資源使用，最大吞吐量，最小響應時間並避免任何單一資源的過載。使用多個組件進行負載均衡而不是單個組件可能會通過冗餘來提高可靠性和可用性。負載平衡通常涉及專用軟件或硬件，例如多層交換機或域名系統服務進程。
微服務之間是如何獨立通訊的?
1.遠程調用，比如feign調用，直接通過遠程過程調用來訪問別的service。
2.消息中間件
springcloud如何實現服務的註冊?
1.服務發佈時，指定對應的服務名,將服務註冊到 註冊中心(eureka zookeeper)
2.註冊中心加@EnableEurekaServer,服務用@EnableDiscoveryClient，然後用ribbon或feign進行服務直接的調用發現。
spring cloud 斷路器的作用是什麼？
在分佈式架構中，斷路器模式的作用也是類似的，當某個服務單元發生故障（類似用電器發生短路）之後，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個錯誤響應，而不是長時間的等待。這樣就不會使得線程因調用故障服務被長時間佔用不釋放，避免了故障在分佈式系統中的蔓延。
什麼是Hystrix?
Hystrix 是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的故障時，停止級聯故障並在複雜的分佈式系統中實現彈性。通常對於使用微服務架構開發的系統，涉及到許多微服務，這些微服務彼此協作， 隨着微服務數量的增加，這個問題變得更加複雜。我們將使用 Hystrix 的 Fallback 方法來處理，假設由於某種原因，公開的服務接口拋出異常，我們在這種情況下使用 Hystrix 定義一個回退方法。這種後備方法應該具有與公開服務相同的返回類型，如果暴露服務中出現異常，回退方法將返回對應信息。
Eureka和ZooKeeper都可以提供服務註冊與發現的功能,請說說兩個的區別
-
ZooKeeper保證的是CP,Eureka保證的是AP，ZooKeeper在選舉期間註冊服務癱瘓,雖然服務最終會恢復,但是選舉期間不可用的。Eureka各個節點是平等關係,只要有一臺Eureka就可以保證服務可用,而查詢到的數據並不是最新的自我保護機制會導致Eureka不再從註冊列表移除因長時間沒收到心跳而應該過期的服務。Eureka仍然能夠接受新服務的註冊和查詢請求,但是不會被同步到其他節點(高可用)。當網絡穩定時,當前實例新的註冊信息會被同步到其他節點中(最終一致性)。Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況,而不會像ZooKeeper一樣使得整個註冊系統癱瘓。
-
ZooKeeper有Leader和Follower角色,Eureka各個節點平等
-
ZooKeeper採用過半數存活原則,Eureka採用自我保護機制解決分區問題
-
Eureka本質上是一個工程,而ZooKeeper只是一個進程
什麼是Netflix Feign？它的優點是什麼？
Feign是受到Retrofit，JAXRS-2.0和WebSocket啓發的java客戶端聯編程序。Feign的第一個目標是將約束分母的複雜性統一到http apis，而不考慮其穩定性。在employee-consumer的例子中，我們使用了employee-producer使用REST模板公開的REST服務。
但是我們必須編寫大量代碼才能執行以下步驟
- 使用功能區進行負載平衡。
- 獲取服務實例，然後獲取基本URL。
- 利用REST模板來使用服務。前面的代碼如下
@Controller
public class ConsumerControllerClient {
@Autowired
private LoadBalancerClient loadBalancer;
public void getEmployee() throws RestClientException, IOException {
ServiceInstance serviceInstance=loadBalancer.choose("employee-producer");
System.out.println(serviceInstance.getUri());
String baseUrl=serviceInstance.getUri().toString();
baseUrl=baseUrl+"/employee";
RestTemplate restTemplate = new RestTemplate();
ResponseEntity<String> response=null;
try{
response=restTemplate.exchange(baseUrl,
HttpMethod.GET, getHeaders(),String.class);
}catch (Exception ex)
{
System.out.println(ex);
}
System.out.println(response.getBody());
}
之前的代碼，有像NullPointer這樣的例外的機會，並不是最優的。我們將看到如何使用Netflix Feign使呼叫變得更加輕鬆和清潔。如果Netflix Ribbon依賴關係也在類路徑中，那麼Feign默認也會負責負載平衡。
REST 和RPC對比
1.RPC主要的缺陷是服務提供方和調用方式之間的依賴太強，需要對每一個微服務進行接口的定義，並通過持續繼承發佈，嚴格版本控制纔不會出現衝突。
2.REST是輕量級的接口，服務的提供和調用不存在代碼之間的耦合，只需要一個約定進行規範。
什麼是feigin？它的優點是什麼？
-
feign採用的是基於接口的註解
-
feign整合了ribbon，具有負載均衡的能力
-
整合了Hystrix，具有熔斷的能力
使用:
1.添加pom依賴。
2.啓動類添加@EnableFeignClients
3.定義一個接口@FeignClient(name=“xxx”)指定調用哪個服務
Ribbon和Feign的區別？
-
Ribbon都是調用其他服務的，但方式不同。
-
啓動類註解不同，Ribbon是@RibbonClient feign的是@EnableFeignClients
-
服務指定的位置不同，Ribbon是在@RibbonClient註解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。
-
調用方式不同，Ribbon需要自己構建http請求，模擬http請求然後使用RestTemplate發送給其他服務，步驟相當繁瑣。Feign需要將調用的方法定義成抽象方法即可。
什麼是Spring Cloud Bus?
spring cloud bus 將分佈式的節點用輕量的消息代理連接起來，它可以用於廣播配置文件的更改或者服務直接的通訊，也可用於監控。
如果修改了配置文件，發送一次請求，所有的客戶端便會重新讀取配置文件。
使用:
1.添加依賴
2.配置rabbimq
eureka和zookeeper都可以提供服務註冊與發現的功能，請說說兩個的區別？
zookeeper 是CP原則，強一致性和分區容錯性。
eureka 是AP 原則 可用性和分區容錯性。
zookeeper當主節點故障時，zk會在剩餘節點重新選擇主節點，耗時過長，雖然最終能夠恢復，但是選取主節點期間會導致服務不可用，這是不能容忍的。
eureka各個節點是平等的，一個節點掛掉，其他節點仍會正常保證服務。
你所知道微服務的技術棧有哪些？列舉一二
服務網關的作用
-
簡化客戶端調用複雜度，統一處理外部請求。
-
數據裁剪以及聚合，根據不同的接口需求，對數據加工後對外。
-
多渠道支持，針對不同的客戶端提供不同的網關支持。
-
遺留系統的微服務化改造，可以作爲新老系統的中轉組件。
-
統一處理調用過程中的安全、權限問題。
鏈路跟蹤Sleuth
當我們項目中引入Spring Cloud Sleuth後，每次鏈路請求都會添加一串追蹤信息，格式是[server-name, main-traceId,sub-spanId,boolean]：
-
server-name：服務結點名稱。
-
main-traceId：一條鏈路唯一的ID，爲TraceID。
-
sub-spanId：鏈路中每一環的ID，爲SpanID。
-
boolean：是否將信息輸出到Zipkin等服務收集和展示。
Sleuth的實現是基於HTTP的，爲了在數據的收集過程中不能影響到正常業務，Sleuth會在每個請求的Header上添加跟蹤需求的重要信息。這樣在數據收集時，只需要將Header上的相關信息發送給對應的圖像工具即可，圖像工具根據上傳的數據，按照Span對應的邏輯進行分析、展示。
好了各位， 本文到這裏就結束了！ 如果本文有任何錯誤，請批評指教，不勝感激 ！
寫在最後
還有現在整理好了 1000 道多家公司 java 面試題 400 多頁 pdf 文檔，都已經分專題整理好了。還有幾百頁的Java核心知識點PDF，和海量的學習資料
公衆號：JavaTimo 可以回覆：pdf 領取。
我是提莫！ 一個節操氾濫，一身凜然正氣，剛正不阿的Java程序員
