Java架構師面試問些什麼？微服務之springcloud面試題（共22題，含詳細解答）

【 Java架構師面試網】收集整理了幾乎整個架構師學習途中會遇到的面試題，但願你們都能早日圓本身的架構師夢~
公衆號： Java架構師面試網，關注回覆「 資料」便可領取精美整理的面試資料一份哦~

一、微服務的優缺點分別是什麼?說下你在項目開發中碰到的坑。

優勢：
1)    每個服務足夠內聚,代碼容易理解
2)    開發效率提升,一個服務只作一件事
3)    微服務可以被小團隊單獨開發
4)    微服務是鬆耦合的,是有功能意義的服務
5)    能夠用不一樣的語言開發,面向接口編程
6)    易於與第三方集成
7)    微服務只是業務邏輯的代碼,不會和HTML,CSS或者其餘界面組合
8)    開發中,兩種開發模式
9)    先後端分離
10)    全棧工程師
11)    能夠靈活搭配,鏈接公共庫/鏈接獨立庫
缺點：
1)    分佈式系統的負責性
2)    多服務運維難度,隨着服務的增長,運維的壓力也在增大
3)    系統部署依賴
4)    服務間通訊成本
5)    數據一致性
6)    系統集成測試
7)    性能監控

二、什麼是Spring Cloud？
Spring cloud流應用程序啓動器是基於Spring Boot的Spring集成應用程序，提供與外部系統的集成。Spring cloud Task，一個生命週期短暫的微服務框架，用於快速構建執行有限數據處理的應用程序。

三、SpringBoot和SpringCloud

1)    SpringBoot專一於快速方便的開發單個個體的微服務
2)    SpringCloud是關注全局的微服務協調整理治理框架,整合並管理各個微服務,爲各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件總線等集成服務
3)    SpringBoot不依賴於SpringCloud,SpringCloud依賴於SpringBoot,屬於依賴關係
4)    SpringBoot專一於快速,方便的開發單個的微服務個體,SpringCloud關注全局的服務治理框架

四、SpringCloud和Dubbo

1)    區別
    a.    服務的調用方式Dubbo使用的是RPC遠程調用,而SpringCloud使用的是 Rest API,其實更符合微服務官方的定義
    b.    服務的註冊中心來看,Dubbo使用了第三方的ZooKeeper做爲其底層的註冊中心,實現服務的註冊和發現,SpringCloud使用Spring Cloud Netflix Eureka實現註冊中心,固然SpringCloud也可使用ZooKeeper實現,但通常咱們不會這樣作
    c.    服務網關,Dubbo並無自己的實現,只能經過其餘第三方技術的整合,而SpringCloud有Zuul路由網關,做爲路由服務器,進行消費者的請求分發,SpringCloud還支持斷路器,與git完美集成分佈式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素
2)    技術選型
    a.    目前國內的分佈式系統選型主要仍是Dubbo畢竟國產,並且國內工程師的技術熟練程度高,而且Dubbo在其餘維度上的缺陷能夠由其餘第三方框架進行集成進行彌補
    b.    而SpringCloud目前是國外比較流行,固然我以爲國內的市場也會慢慢的偏向SpringCloud,就連劉軍做爲Dubbo重啓的負責人也發表過觀點,Dubbo的發展方向是積極適應SpringCloud生態,並非起衝突
3)    Rest和RPC對比
    其實若是仔細閱讀過微服務提出者馬丁福勒的論文的話能夠發現其定義的服務間通訊機制就是Http Rest。
    RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,咱們須要爲每個微服務進行接口的定義,並經過持續繼承發佈,須要嚴格的版本控制纔不會出現服務提供和調用之間由於版本不一樣而產生的衝突
    而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是經過一個約定進行規範,但也有可能出現文檔和接口不一致而致使的服務集成問題,但能夠經過swagger工具整合,是代碼和文檔一體化解決,因此REST在分佈式環境下比RPC更加靈活
    這也是爲何當當網的DubboX在對Dubbo的加強中增長了對REST的支持的緣由

4) 文檔質量和社區活躍度

SpringCloud社區活躍度遠高於Dubbo,畢竟因爲梁飛團隊的緣由致使Dubbo中止更新迭代五年,而中小型公司沒法承擔技術開發的成本致使Dubbo社區嚴重低落,而SpringCloud異軍突起,迅速佔領了微服務的市場,背靠Spring混的風生水起
    Dubbo通過多年的積累文檔至關成熟,對於微服務的架構體系各個公司也有穩定的現狀

五、你所知道的微服務技術棧有哪些?請列舉一二。維度(SpringCloud)

1)    服務開發：SpringBoot、Spring、SpringMVC
2)    服務配置與管理：Netfilx公司的Archaiusm,阿里的Diamond
3)    服務註冊與發現：Eureka,ZooKeeper
4)    服務調用：Rest,RPC,gRPC
5)    服務熔斷器：Hystrix
6)    服務負載均衡：Ribbon,Nginx
7)    服務接口調用：Feign
8)    消息隊列：Kafka,RabbitMq,ActiveMq
9)    服務配置中心管理：SpringCloudConfing
10)    服務路由(API網關)：Zuul
11)    事件消息總線：SpringCloud Bus

六、負載平衡的意義什麼？
在計算中，負載平衡能夠改善跨計算機，計算機集羣，網絡連接，中央處理單元或磁盤驅動器等多種計算資源的工做負載分佈。負載平衡旨在優化資源使用，最大化吞吐量，最小化響應時間並避免任何單一資源的過載。使用多個組件進行負載平衡而不是單個組件可能會經過冗餘來提升可靠性和可用性。負載平衡一般涉及專用軟件或硬件，例如多層交換機或域名系統服務器進程。

七、微服務之間是如何獨立通信的

1)    遠程過程調用（Remote Procedure Invocation）
也就是咱們常說的服務的註冊與發現，直接經過遠程過程調用來訪問別的service。
優勢：
簡單，常見,由於沒有中間件代理，系統更簡單
缺點：
a.    只支持請求/響應的模式，不支持別的，好比通知、請求/異步響應、發佈/訂閱、發佈/異步響應；
b.    下降了可用性，由於客戶端和服務端在請求過程當中必須都是可用的
2)    消息
使用異步消息來作服務間通訊。服務間經過消息管道來交換消息，從而通訊。
優勢:
a.    把客戶端和服務端解耦，更鬆耦合
b.    提升可用性，由於消息中間件緩存了消息，直到消費者能夠消費
c.    支持不少通訊機制好比通知、請求/異步響應、發佈/訂閱、發佈/異步響應
缺點:
消息中間件有額外的複雜性

八、springcloud如何實現服務的註冊和發現
服務在發佈時 指定對應的服務名（服務名包括了IP地址和端口） 將服務註冊到註冊中心（eureka或者zookeeper）
這一過程是springcloud自動實現 只須要在main方法添加@EnableDisscoveryClient 同一個服務修改端口就能夠啓動多個實例
調用方法：傳遞服務名稱經過註冊中心獲取全部的可用實例 經過負載均衡策略調用（ribbon和feign）對應的服務

九、Eureka和ZooKeeper均可以提供服務註冊與發現的功能,請說說兩個的區別。

1)    Eureka取CAP中的AP，注重可用性。Zookepper取CAP理論中的CP強調高的一致性。
            ZooKeeper在選舉期間註冊服務癱瘓,雖然服務最終會恢復,可是選舉期間不可用的
            Eureka各個節點是平等關係,只要有一臺Eureka就能夠保證服務可用,而查詢到的數據並非最新的自我保護機制會致使
            Eureka再也不從註冊列表移除因長時間沒收到心跳而應該過時的服務
            Eureka仍然可以接受新服務的註冊和查詢請求,可是不會被同步到其餘節點(高可用)
            當網絡穩定時,當前實例新的註冊信息會被同步到其餘節點中(最終一致性)
            Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況,而不會像ZooKeeper同樣使得整個註冊系統癱瘓
2)    ZooKeeper有Leader和Follower角色,Eureka各個節點平等
3)    ZooKeeper採用過半數存活原則,Eureka採用自我保護機制解決分區問題
4)    Eureka本質上是一個工程,而ZooKeeper只是一個進程

十、eureka自我保護機制
當 Eureka Server 節點在短期內丟失了過多實例的鏈接時（好比網絡故障或頻繁的啓動關閉客戶端），那麼這個節點就會進入自我保護模式，一旦進入到該模式，Eureka server 就會保護服務註冊表中的信息，再也不刪除服務註冊表中的數據（即不會註銷任何微服務），當網絡故障恢復後，該 Ereaka Server 節點就會自動退出自我保護模式（個人 Eureka Server 已經幾個月了，至今未自動退出該模式）

十一、什麼是服務熔斷?什麼是服務降級
在複雜的分佈式系統中,微服務之間的相互調用,有可能出現各類各樣的緣由致使服務的阻塞,在高併發場景下,服務的阻塞意味着線程的阻塞,致使當前線程不可用,服務器的線程所有阻塞,致使服務器崩潰,因爲服務之間的調用關係是同步的,會對整個微服務系統形成服務雪崩
爲了解決某個微服務的調用響應時間過長或者不可用進而佔用愈來愈多的系統資源引發雪崩效應就須要進行服務熔斷和服務降級處理。
所謂的服務熔斷指的是某個服務故障或異常一塊兒相似顯示世界中的「保險絲"當某個異常條件被觸發就直接熔斷整個服務，而不是一直等到此服務超時。
服務熔斷就是至關於咱們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,經過維護一個本身的線程池,當線程達到閾值的時候就啓動服務降級,若是其餘請求繼續訪問就直接返回fallback的默認值

十二、如何使用Eureka

1)    添加pom依賴
    2)    配置文件添加相關配置
    3)    啓動類添加註解@EnableDiscoveryClient

1三、什麼是Ribbon?

ribbon是一個負載均衡客戶端，能夠很好的控制htt和tcp的一些行爲。Feign默認集成了ribbon。
使用：
1)    添加pom依賴
2)    配置文件添加相關配置
3)    啓動類添加註解@EnableEurekaServer
4)    向程序的ioc注入一個bean: restTemplate;並經過@LoadBalanced註解代表這個restRemplate開啓負載均衡的功能
5)    寫一個測試類HelloService，經過以前注入ioc容器的restTemplate來消費service-hi服務的「/hi」接口

源碼：
Ribbon的負載均衡，主要經過LoadBalancerClient來實現的，而LoadBalancerClient具體交給了ILoadBalancer來處理，ILoadBalancer經過配置IRule、IPing等信息，並向EurekaClient獲取註冊列表的信息，並默認10秒一次向EurekaClient發送「ping」,進而檢查是否更新服務列表，最後，獲得註冊列表後，ILoadBalancer根據IRule的策略進行負載均衡。
而RestTemplate 被@LoadBalance註解後，能過用負載均衡，主要是維護了一個被@LoadBalance註解的RestTemplate列表，並給列表中的RestTemplate添加攔截器，進而交給負載均衡器去處理。

1四、什麼是Feign？它的優勢是什麼？

Feign是一個聲明式的僞Http客戶端，它使得寫Http客戶端變得更簡單。使用Feign，只須要建立一個接口並註解。它具備可插拔的註解特性，可以使用Feign 註解和JAX-RS註解。Feign支持可插拔的編碼器和解碼器。Feign默認集成了Ribbon，並和Eureka結合，默認實現了負載均衡的效果。
簡而言之：
Feign 採用的是基於接口的註解
Feign 整合了ribbon，具備負載均衡的能力
整合了Hystrix，具備熔斷的能力
使用：
1)    添加pom依賴
2)    配置文件添加相關配置
3)    啓動類添加註解@EnableFeignClients
4)    定義一個接口，使用註解@ FeignClient（「服務名」），來指定調用哪一個服務

源碼實現過程：
首先經過@EnableFeignCleints註解開啓FeignCleint
根據Feign的規則實現接口，並加@FeignCleint註解
程序啓動後，會進行包掃描，掃描全部的@ FeignCleint的註解的類，並將這些信息注入到ioc容器中。
當接口的方法被調用，經過jdk的代理，來生成具體的RequesTemplate
RequesTemplate在生成Request
Request交給Client去處理，其中Client能夠是HttpUrlConnection、HttpClient也能夠是Okhttp
最後Client被封裝到LoadBalanceClient類，這個類結合類Ribbon作到了負載均衡。

1五、Ribbon和Feign的區別：

Ribbon和Feign都是用於調用其餘服務的，不過方式不一樣。
1.啓動類使用的註解不一樣，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
2.服務的指定位置不一樣，Ribbon是在@RibbonClient註解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。
3.調用方式不一樣，Ribbon須要本身構建http請求，模擬http請求而後使用RestTemplate發送給其餘服務，步驟至關繁瑣。
Feign則是在Ribbon的基礎上進行了一次改進，採用接口的方式，將須要調用的其餘服務的方法定義成抽象方法便可，
不須要本身構建http請求。不過要注意的是抽象方法的註解、方法簽名要和提供服務的方法徹底一致。

1六、什麼是Spring Cloud Bus？

Spring Cloud Bus 將分佈式的節點用輕量的消息代理鏈接起來。它能夠用於廣播配置文件的更改或者服務之間的通信，也能夠用於監控。
若是修改了配置文件，發送一次請求，全部的客戶端便會從新讀取配置文件
使用：
一、添加依賴
二、配置rabbitmq

1七、什麼是zuul?

Zuul的主要功能是路由轉發和過濾器。路由功能是微服務的一部分，好比／api/user轉發到到user服務，/api/shop轉發到到shop服務。zuul默認和Ribbon結合實現了負載均衡的功能。
使用：
一、添加pom依賴
二、配置文件添加相關配置
三、啓動類添加註解@EnableZuulProxy

在zuul中， 整個請求的過程是這樣的，首先將請求給zuulservlet處理，zuulservlet中有一個zuulRunner對象，該對象中初始化了RequestContext：做爲存儲整個請求的一些數據，並被全部的zuulfilter共享。zuulRunner中還有 FilterProcessor，FilterProcessor做爲執行全部的zuulfilter的管理器。FilterProcessor從filterloader 中獲取zuulfilter，而zuulfilter是被filterFileManager所加載，並支持groovy熱加載，採用了輪詢的方式熱加載。有了這些filter以後，zuulservelet首先執行的Pre類型的過濾器，再執行route類型的過濾器，最後執行的是post 類型的過濾器，若是在執行這些過濾器有錯誤的時候則會執行error類型的過濾器。執行完這些過濾器，最終將請求的結果返回給客戶端。

1八、什麼是Hystrix？它如何實現容錯？

Hystrix是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的故障時，中止級聯故障並在複雜的分佈式系統中實現彈性。
一般對於使用微服務架構開發的系統，涉及到許多微服務。這些微服務彼此協做。
使用：
一、添加pom依賴
二、啓動類使用註解@EnableHystrix
三、在Service方法上加上@HystrixCommand註解。該註解對該方法建立了熔斷器的功能，並指定了fallbackMethod熔斷方法

1九、springcloud斷路器的做用

當一個服務調用另外一個服務因爲網絡緣由或者自身緣由出現問題時 調用者就會等待被調用者的響應 當更多的服務請求到這些資源時，致使更多的請求等待 這樣就會發生連鎖效應（雪崩效應） 斷路器就是解決這一問題。
斷路器有徹底打開狀態：必定時間內 達到必定的次數沒法調用 而且屢次檢測沒有恢復的跡象 斷路器徹底打開，那麼下次請求就不會請求到該服務
半開：短期內 有恢復跡象 斷路器會將部分請求發給該服務 當能正常調用時 斷路器關閉
關閉：當服務一直處於正常狀態 能正常調用 斷路器關閉

20、Spring Cloud Config

在分佈式系統中，因爲服務數量巨多，爲了方便服務配置文件統一管理，實時更新，因此須要分佈式配置中心組件。在Spring Cloud中，有分佈式配置中心組件spring cloud config ，它支持配置服務放在配置服務的內存中（即本地），也支持放在遠程Git倉庫中。在spring cloud config 組件中，分兩個角色，一是config server，二是config client。
使用：
一、添加pom依賴
二、配置文件添加相關配置
三、啓動類添加註解@EnableConfigServer

2一、Spring Cloud Gateway

Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關。網關做爲流量的，在微服務系統中有着很是做用，網關常見的功能有路由轉發、權限校驗、限流控制等做用。
使用了一個RouteLocatorBuilder的bean去建立路由，除了建立路由RouteLocatorBuilder可讓你添加各類predicates和filters，predicates斷言的意思，顧名思義就是根據具體的請求的規則，由具體的route去處理，filters是各類過濾器，用來對請求作各類判斷和修改。

2二、架構：

在微服務架構中，須要幾個基礎的服務治理組件，包括服務註冊與發現、服務消費、負載均衡、斷路器、智能路由、配置管理等，由這幾個基礎組件相互協做，共同組建了一個簡單的微服務系統
在Spring Cloud微服務系統中，一種常見的負載均衡方式是，客戶端的請求首先通過負載均衡（zuul、Ngnix），再到達服務網關（zuul集羣），而後再到具體的服。，服務統一註冊到高可用的服務註冊中心集羣，服務的全部的配置文件由配置服務管理，配置服務的配置文件放在git倉庫，方便開發人員隨時改配置。

嗨，你好呀，將來的架構師，本文由Java架構師面試網 www.javajiagoushi.com收集整理並進行編輯發佈，謝謝你們的支持~