1、什么是 Spring Cloud？
Spring cloud 流應用程式啟動器是 于 Spring Boot 的 Spring 集成應用程式，提供與外部系統的集成，Spring cloud Task，一個生命周期短暫的微服務框架，用于快速構建執行有限資料處理的應用程式，
2、使用 Spring Cloud 有什么優勢？
使用 Spring Boot 開發分布式微服務時，我們面臨以下問題
（1）與分布式系統相關的復雜性-這種開銷包括網路問題，延遲開銷，帶寬問題，安全問題，
（2）服務發現-服務發現工具管理群集中的流程和服務如何查找和互相交談，它涉及一個服務目錄，在該目錄中注冊服務，然后能夠查找并連接到該目錄中的服務，
（3）冗余-分布式系統中的冗余問題，
（4）負載平衡 --負載平衡改善跨多個計算資源的作業負荷，諸如計算機，計算機集群，網路鏈路，中央處理單元，或磁盤驅動器的分布，
（5）性能-問題 于各種運營開銷導致的性能問題，
（6）部署復雜性 evops 技能的要求，
3、服務注冊和發現是什么意思？Spring Cloud 如何實作？
當我們開始一個專案時，我們通常在屬性檔案中進行所有的配置，隨著越來越多的服務開發和部署，添加和修改這些屬性變得更加復雜，有些服務可能會下降，而某些位置可能
會發生變化，手動更改屬性可能會產生問題，Eureka 服務注冊和發現可以在這種情況下提供幫助，由于所有服務都在 Eureka 服務器上注冊并通過呼叫 Eureka 服務器完成查找，因此無需處理服務地點的任何更改和處理，
4、負載平衡的意義什么？
在計算中，負載平衡可以改善跨計算機，計算機集群，網路鏈接，中央處理單元或磁盤驅動器等多種計算資源的作業負載分布，負載平衡旨在優化資源使用，最大化吞吐量，最小化回應時間并避免任何單一資源的過載，使用多個組件進行負載平衡而不是單個組件可能會通過冗余來提高可靠性和可用性，負載平衡通常涉及專用軟體或硬體，例如多層交換機或域名系統服務器行程，
5、什么是 Hystrix？它如何實作容錯？
Hystrix 是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的故障時，停止級聯故障并在復雜的分布式系統中實作彈性，通常對于使用微服 構開發的系統，涉及到許多微服務，這些微服務彼此協作，思考以下微服務
假設如果上圖中的微服務 9 失敗了，那么使用傳統方法我們將傳播一個例外，但這仍然會導致整個系統崩潰，隨著微服務數量的增加，這個問題變得更加復雜，微服務的數量可以高達 1000.這是 hystrix 出現的地方 我們將使 Hystrix 在這種情況下的 Fallback 方法功能，我們有兩個服務 employee-consumer 使用由 employee-consumer 公開的服務，簡化圖如下所示
現在假設由于 原因，employee-producer 公開的服務會拋出例外，我們在這種情況下使用 Hystrix定義了一個回退方法，這種后備方法應該具有與公開服務相同的回傳型別，如果暴露服務中出現例外，則回退方法將回傳一些值，
6、什么是 Hystrix 斷路器？我們需要它嗎？
由于某些原因，employee-consumer 公開服務會引發例外，在這種情況下使用Hystrix 我們定義了一個回退方法，如果在公開服務中發生例外，則回退方法回傳一些默認值，
如果 ?rstPage method() 中的例外繼續發生，則 Hystrix 電 ，并且員工使用者將一起跳過?rtsPage 方法，并直接呼叫回退方法，斷路器的目的是給第一 方法或第一頁方法可能呼叫的其他方法留出時間，并導致例外恢復，可能發生的情況是，在負載較小的情況下，導致例外的問題有更好的恢復機會 ，
7、什么是 Net?ix Feign？它的優點是什么？
Feign 是受到 Retro?t，JAXRS-2.0 和 WebSocket 啟發的 java 客戶端聯編程式，Feign 的第一個目標是將約束分母的復雜性統一到 http apis，而不考慮其穩定性，在 employee-consumer 的例子中，我們使用了 emplo e-producer 使用 REST模板公開的 REST 服務，
但是我們必須撰寫大量代碼才能執行以下步驟
1、使用功能區進行負載平衡，
2、獲取服務實體，然后獲取基本 URL，
3、利用 REST 模板來使用服務，前面的代碼如下
@Controllerpublic 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 這樣的例外的機會，并不是最優 ，我們將看到如何使用 Net?ix Fe n使呼叫變得更加輕松和清潔，如果 Net?ix Ribbon 依賴關系 徑中，那么 Feign 默認也會負載平衡，
8、什么是 Spring Cloud Bus？我們需要它嗎？
考慮以下情況：我們有多個應用程式使用 Spr ng Cloud Con?g 讀取屬性，而S ring Cloud Con?g 從GIT 讀取這些屬性，
下面的例子中多個員工生產者模塊從 Employee Con?g Module 獲取 Eureka 注冊的財產
如果假設 GIT 中的 Eureka 注冊屬性更改為指向另一臺 Eureka 服務器，會發生什么情況，在這種情況下，我們將不得不重新啟動服務以獲取更新的屬性，還有另一種使用執行器端點/重繪的方式，但是我們將不得不為每個模塊單獨呼叫這個 url，例如，如果 Employee Producer1 部署在埠 8080 上，則呼叫 http：// localhost：8080 / refresh，同樣對于 Employee Producer2 http：//localhost：8081 /refresh 等等，這又很麻煩，這就是 Spring Cloud Bus 發揮作用的地方，
Spring Cloud Bus 提供了跨多個實體重繪配置的功能，因此，在上面的 中，如果我們重繪Employee Producer1，則會自動刷 所有其他必需的模塊，如果我們有 個微服務啟動并運行，這特別有用，這是通過將所有微服務連 到單個訊息代理來實作的，無論何時重繪實體，此事件都會訂閱到偵聽此代理的所有微服務，并且它們也會重繪，可以通過使用端點/總線/重繪來實作對任何單個實體的重繪
9、什么是微服務
微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程式劃分為一組小的服務，每個服務運行在其獨立的自己的行程中，服務之間相互協調、互相配合，為用戶提供最終價值，服務之間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTful API）,每個服務都圍繞著具體的業務進行構建，并且能夠被獨立的構建在生產環境、類生產環境等，另外，應避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務背景關系，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來撰寫服務，也可以使用不同的資料存盤，
10、什么是服務熔斷？什么是服務降級
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制，當某個微服務不可用或者回應時間太長時，會進行服務降級，進而熔斷該節點微服務的呼叫，快速回傳“錯誤”的回應資訊，當檢測到該節點微服務呼叫回應正常后恢復呼叫鏈路，在SpringCloud框架里熔斷機制通過Hystrix實作，Hystrix會監控微服務間呼叫的狀況，當失敗的呼叫到一定閾值，預設是5秒內呼叫20次，如果失敗，就會啟動熔斷機制，
服務降級，一般是從整體負荷考慮，就是當某個服務熔斷之后，服務器將不再被呼叫，此時客戶端可以自己準備一個本地的fallback回呼，回傳一個預設值，這樣做，雖然水平下降，但好歹可用，比直接掛掉強，
11、Eureka和zookeeper都可以提供服務注冊與發現的功能，請說說兩個的區別？
Zookeeper保證了CP（C：一致性，P：磁區容錯性），Eureka保證了AP（A：高可用）
（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那樣使整個微服務癱瘓
12、SpringBoot和SpringCloud的區別？
SpringBoot專注于快速方便的開發單個個體微服務，
SpringCloud是關注全域的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合并管理起來，為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全域鎖、決策競選、分布式會話等等集成服務SpringBoot可以離開SpringCloud獨立使用開發專案， 但是SpringCloud離不開SpringBoot ，屬于依賴的關系.
SpringBoot專注于快速、方便的開發單個微服務個體，SpringCloud關注全域的 治理框架
13、什么是Hystrix斷路器？我們需要它嗎
由于某些原因，employee-consumer公開服務會引發例外，情況下使用Hystrix我們定義了回退方法，如果在公開服務中發生例外，則回退方法回傳一些默認值 ，
如果?rstPage method() 中的例外繼續發生，則Hystrix電路將中斷，并且員工使用者將一起跳過?rtsPage方法，并直接呼叫回退方法，斷路器的目的是給第一頁方法或第一頁方法可能呼叫的其他方法留出時間，并導致例外恢復，可能發生的情況是，在負載較小的情況下，導致例外的問題有更好的恢復機會 ，
14、說說 RPC 的實作原理
首先需要有處理網路連接通訊的模塊，負責連接建立、管理和訊息的傳輸，其次需要有編解碼的模塊，因為網路通訊都是傳輸的位元組碼，需要將我們使用的物件序列化和反序列化，剩下的就是客戶端和服務器端的部分，服務器端暴露要開放的服務介面，客戶呼叫服務介面的一個代理實作，這個代理實作負責收集資料、編碼并傳輸給服務器然后等待結果回傳，
15、微服務的優點缺點?說下開發專案中遇到的坑?
優點:
（1）每個服務直接足夠內聚，代碼容易理解
（2）開發效率高，一個服務只做一件事，適合小團隊開發
（3）松耦合，有功能意義的服務，
（4）可以用不同語言開發，面向介面編程，
（5）易于第三方集成
（6）微服務只是業務邏輯的代碼，不會和HTML,CSS或其他界
（7）可以靈活搭配，連接公共庫/連接獨立庫
缺點:
（1）分布式系統的責任性
（2）多服務運維難度加大，
（3）系統部署依賴，服務間通信成本，資料一致 ，系統集成測驗，性能監控，
16、spring cloud 和d bbo區別?
（1）服務呼叫方式 dubbo是RPC spri cloud Rest Api
（2）注冊中心,dubbo 是zookeep r springcloud是eureka，也可以是zookeeper
（3）服務網關,dubbo本身沒有實作，只能通過其他第三方技術整合，springcloud有Zuul路由網關，作為路由服務器，進行消費者的請求分發,springcloud支持斷路器，與git完美集成組態檔支持版本控制，事物總線實作配置文 的更新與服務自動裝配等等一系列的微服務架構要素，
17、REST 和RPC對比
（1）RPC主要的缺陷是服務提供方和呼叫方式之間的依賴太強，需要對每一個微服務進行介面的定義，并通過持續繼承發布，嚴格版本控制才不會出現沖突，
（2）REST是輕量級的介面，服務的提供和呼叫不存在代碼之間的耦合，只需要一個約定進行規范，
18、你所知道的微服務技術堆疊？
維度(springcloud)
服務開發：springboot spring springmvc
服務配置與管理:Net?x公司的Archaiusm ,阿里的Diamond
服務注冊與發現:Eureka,Zookeeper
服務呼叫:Rest RPC gRpc
服務熔斷器:Hystrix
服務負載均衡:Ribbon Nginx
服務介面呼叫:Fegin
訊息佇列:Kafka Rabbitmq activemq
服務配置中心管理:SpringCloudCon?g
服務路由（API網關）Zuul
事件訊息總線:SpringCloud Bus
19、微服務之間是如何獨立通訊的?
（1）遠程呼叫，比如feign呼叫，直接通過遠程程序呼叫來訪問別的service，
（2）訊息中間件
20、springcloud如何實作服務的注冊?
（1）服務發布時，指定對應的服務名,將服務注冊到 注冊中心(eureka zookeeper)
（2）注冊中心加@EnableEurekaServer,服務用@EnableDiscoveryClient，然后用ribbon或feign進行服務直接的呼叫發現，
21、Eureka和Zookeeper區別
（1）Eureka取CAP的AP，注重可用性，Zookeeper取CAP的CP注重一致性，
（2）Zookeeper在選舉期間注冊服務癱瘓，雖然服務最侄訓恢復，但選舉期間不可用，
（3）eureka的自我保護機制，會導致一個結果就是不會再從注冊串列移除因長時間沒收到心跳而過期的服務，依然能接受新服務的注冊和查詢請求，但不會被同步到其他節點，不會服務癱瘓，
（4）Zookeeper有Leader和Follower角色，Eureka各個節點平等，
（5）Zookeeper采用過半數存活原則， reka采用自我保護機制解決磁區 ，
（6）eureka本質是一個工程，Zookeeper只是一個行程，
22、eureka自我保護機制是什么?
當Eureka Server 點在短時間內丟失了過多實體的連接時（比如網路故障或頻繁啟動關閉客戶端）節點會進入自我保護模式，保護注冊資訊，不再洗掉注冊資料，故障恢復時，自動退出自我保護模式，
23、什么是Ribbon？
ribbon是一個負載均衡客戶端，可以很好的控制htt和tcp的一些行為，feign默認集成了ribbon，
24、什么是feigin？它的優點是什么？
（1）feign采用的是基于介面的注解
（2）feign整合了ribbon，具有負載均衡的能力
（3）整合了Hystrix，具有熔斷的能力
使用:
（1）添加pom依賴，
（2）啟動類添加@EnableFeignClients
（3）定義一個介面@FeignClient(name=“xxx”)指定呼叫哪個服務
25、Ribbon和Feign的區別？
（1）Ribbon都是呼叫其他服務的，但方式不同，
（2）啟動類注解不同，Ribbon是@RibbonClient feign的是@EnableFeignClients
（3）服務指定的位置不同，Ribbon是在@RibbonClient注解上宣告，Feign則是在定義抽象方法的介面中使用@FeignClient宣告，
（4）呼叫方式不同，Ribbon需要自己構建http請求，模擬http請求然后使用RestTemplate發送給其他服務，步驟相當繁瑣，Feign需要將呼叫的方法定義成抽象方法即可，
26、什么是Spring Cloud Bus?
spring cloud bus 將分布式的節點用輕量的訊息代理連接起來，它可以用于廣播組態檔的更改或者服務直接的通訊，也可用于監控，
如果修改了組態檔，發送一次請求，所有的客戶端便會重新讀取組態檔，
使用:
（1）添加依賴
（2）配置rabbimq
27、springcloud斷路器作用?
當一個服務呼叫另一個服務由于網路原因或自 原因出現問題，呼叫者就會等 呼叫者的回應 當更多的服務請求到這些資源導致更多的請求等待，發生連鎖效應（雪崩效應）
斷路器有完全打開狀態:一段時間內 到一定的次數無法呼叫 并且多次監 沒有恢復的跡象 斷路器完全打開 那么下次請求就不會請求到該服務
半開:短時間內 有恢復跡象 斷路器會將部分請求發給該服務，正常呼叫時 斷路器關閉
關閉：當服務一直處于正常狀 能正常呼叫
28、Spring Cloud Gateway?
Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關，網關作為流量的，在微服務系統中有著非常作用，網關常見的功能有路由轉發、權限校驗、限流控制等作用，
使用了一個RouteLocatorBuilder的bean去創建路由，除了創建路由RouteLocatorBuilder可以讓你添加各種predicates和?lters，predicates斷言的意思，顧名思義就是根據具體的請求的規則，由具體的route去處理，?lters是各種過濾器，用來對請求做各種判斷和修改，
29、作為 務注冊中心，Eureka比Zookeeper好在哪里?
（1）Eureka保證的是可用性和磁區容錯性，Zookeeper 保證的是一致性和磁區容錯性 ，
（2）Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網路故障，而不會像zookeeper那樣使整個注冊服務癱瘓，
30、什么是 Ribbon負載均衡？
（1）Spring Cloud Ribbon是基于Net?ix Ribbon實作的一套客戶端 負載均衡的工具，
（2）Ribbon客戶端組件提供一系列完善的配置項如連接超時，重試等，簡單的說，就是在組態檔中列出Load Balancer（簡稱LB）后面所有的機器，Ribbon會自動的幫助你基于某種規則（如簡單輪詢，隨機連接等）去連接這些機器，我們也很容易使用Ribbon實作自定義的負載均衡演算法，
31、Ribbon負載均衡能干什么？
（1）將用戶的請求平攤的分配到多個服務上
（2）集中式LB即在服務的消費方和提供方之間使用獨立的LB設施(可以是硬體，如F5, 也可以是軟體，如nginx), 由該設施負責把訪問請求通過某種策略轉發至服務的提供方；
（3）行程內LB將LB邏輯集成到消費方，消費方從服務注冊中心獲知有哪些地址可用，然后自己再從這些地址中選擇出一個合適的服務器，
注意：Ribbon就屬于行程內LB，它只是一個類別庫，集成于消費方行程，消費方 它來獲取到服務提供方的地址，
32、什么是 zuul路由網關
（1）Zuul 包含了對請求的路由和過濾兩個最主要的功能:其中 責將外部請求轉發到具體的微服務實體上，是實作外部訪問統一入口的基礎而過濾器功能則負 請求的處理程序進行干預，是實作請求校驗、服務聚合等功能的基礎、
（2）Zuul和Eureka進行整合，將Zuul自身注冊為Eureka服務治理下的應用，同時從Eureka中獲得其他微服務的訊息，也即以后的訪問微服務都是通過Zuul跳轉后獲得，
注意：Zuul服務最侄訓是會注冊進Eureka 提供=代理+路由+過濾 三大功能
33、分布式配置中心能干嘛？
（1）集中管理組態檔不同環境不同配置，動態化的配置更新，分環境部署比如
dev/test/prod/beta/release
（2）運行期間動態調整 置，不再需要在每個服務部署的機器上撰寫組態檔，服務會向配置中心統一拉取配置自己的資訊
（3）當配置發生變動時，服務不需要重啟即可感知到配置的變化并應用新的配置將配置資訊以REST介面的形式暴露
34、Hystrix相關注解
@EnableHystrix：開啟熔斷
@HystrixCommand(fallbackMethod=”XXX”)：宣告一個失敗回滾處理函式XXX，當被注解的方法執行超時（默認是 0毫秒），就會執行fallback函式，回傳錯誤提示，
35、Eureka和zookeeper都可以提供服務注冊與發現的功能，請說說兩個的區別？
Zookeeper保證了CP（C：一致性，P：磁區容錯性），Eureka保證了AP（A：高可用）
（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那樣使整個微服務癱瘓，
執行緒，多執行緒，執行緒池，執行緒背景關系，鎖一鍵啟動執行緒
紅黑樹其實并不難，只是你還沒看過ta
JVM其實并沒有那么難，你也該啃下TA了
阿里面試官最喜歡問的21個HashMap面試題
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/158873.html
標籤：Java