BAT面試分享：微服務26道面試題（含答案解析）

一、什麼是微服務Micoreservice?

微服務的核心就是將傳統的一站式應用,根據業務拆分成一個一個的服務,徹底地去耦合,每個微服務提供單個業務功能的服務,一個服務只做一件事; 從技術角度來看就是一種小而獨立的處理過程,類似程序的概念; 每個微服務能夠自行獨立的啟動或銷燬,擁有自己獨立的資料庫。

 

二、微服務的優缺點有哪些？

優點:

1.每個服務足夠內聚,足夠小,程式碼容易理解,這樣能聚焦一個具體的業務功能或業務需求;

2.開發簡單,提高開發效率,一個服務可能專門只做一件事;

3.微服務能夠被小團隊單獨開發,這個小團隊可以有2-5個開發人員組成;

4.微服務是鬆耦合的,是具有功能意義的服務,無論是在開發階段,還是部署階段都是獨立的;

5.微服務可以使用不同的語言開發;

6.易於第三方整合,微服務允許以容易且靈活的方式整合自動部署,通過持續整合工具,如:Jendis, Hudson;

7.微服務易於被一個開發人員理解、修改和維護,這樣小團隊能夠更關注自己的工作成果,無需通過合作來體現價值;

8.微服務只是業務邏輯程式碼,不會與HTML和css等其他介面元件混合;

9.每個微服務都有獨立的儲存能力,可以由自己的資料庫管理,也可以由統一的資料庫管理。

缺點:

1.開發人員要處理分散式系統的複雜性;

2.多運維難度大,隨著服務的增加,運維的壓力也在增大;

3.系統部署依賴;

4.系統整合測試;

5.服務間通訊成本;

6.資料一致性;

7.效能監控;

...等。

三、微服務和微服務架構的區別？

1.微服務強調的是一個一個的個體,每個個體做自己的事情;

2.微服務架構強調的是整體,其把一個個的微服務組裝起來,對外提供服務。

四、微服務技術棧有哪些？

技術棧: 多種技術的集合體;

1.服務開發: SpringBoot, Spring, SpringMVC;

2.服務設定與管理: Netflix公司的Archaius, Alibaba的Diamond等;

3.服務註冊與發現: Eureka, Zookeeper;

4.服務呼叫: Rest, RPC, gRPC;

5.服務熔斷器: Hystrix, Envoy;

6.服務負載均衡: Ribbon, Nginx;

7.服務介面呼叫: Feign;

8.訊息佇列: Kafaka, RabbitMQ, ActiveMQ;

9.訊息設定中心管理: SpringCloudConfig, Chef

10.服務監控: Zabbix, Nagios, Metrics, Spectator;

11.服務路由(API閘道器): Zuul;

12.全鏈路跟蹤: Zipkin, Brave, Dapper

13.服務部署: Docker, OpenStack, Kubernetes;

14.資料流操作開發包: SpringCloud Stream;

15.事件訊息匯流排: SpringCloud Bus;

...等。

五、為什麼要選擇SpringCloud作為微服務架構？

選型依據:

1.整體解決方案(SpringCloud框架有全家桶的一站式整體解決方案,類似宜家家居那樣,從廚房到臥室再到浴室等所有家居都可以在一個地方全套購買,方便快捷),並且框架成熟度高;

2.社群熱度高,使用的人群多;

3.可維護性;

4.學習曲線等;

六、什麼是SpringCloud？

SpringCloud是一個基於SpringBoot的快速構建分散式系統的工具集, 其基於SpringBoot提供了一套微服務一站式解決方案,包括服務註冊與發現, 設定中心, 全鏈路監控, 服務閘道器, 負載均衡, 熔斷器等元件; 除了基於Netflix的開源元件做高度湊向封裝之外,還有一些選型中立的開源元件。

 

七、什麼是微服務"全家桶"？

分散式微服務架構下的一站式解決方案,是各個微服務架構落地技術的集合體俗稱微服務"全家桶"。

八、SpringBoot 與 SpringCloud 的關係？

1.SpringBoot專注於快速方便的開發單個個體微服務;

2.SpringCloud是專注於全域性的微服務協調治理框架,它將SpirngBoot開發的一個個單體微服務整合並統一管理, 為各個微服務之間提供設定管理, 服務發現, 斷路器, 路由,微代理, 事件匯流排, 全域性鎖, 決策競選, 分散式對談等整合服務;

3.SpringBoot可以離開SpringCloud獨立使用開發專案, 但SpringCloud離不開SpringBoot,二者屬於依賴關係。

九、SpringCloud與Dubbo的區別？

1.兩者的最大區別就是SpringCloud拋棄了Dubbo的RPC通訊,採用的是HTTP的REST方式;

2.嚴格來說,這兩種方式各有優劣,雖然從一定程度上講,REST犧牲了服務呼叫的效能,但也避免了原生RPC帶來的問題; 而且,REST相比RPC更為靈活,服務提供方和呼叫方的依賴只依靠一紙契約,不存在程式碼級別的強依賴,這在強調快速演化的微服務環境下,顯得更加適合;

3.Dubbo只實現了服務治理,而SpringCloud的子專案分別覆蓋了微服務架構下的眾多部件,服務治理只是其中的一個方面; 但是Dubbo提供了各種Filter,各種要核心要素可以通過擴充套件Filter來完善。

十、微服務的註冊與發現是怎麼玩的？

微服務的註冊與發現是通過Eureka元件實現的，Eureka包含兩大內容：Eureka Server 和 Eureka Client；

Eureka Server提供服務註冊服務，各個節點啟動後，會在Eureka Server中進行註冊，這樣Eureka Server中的服務登入檔中將會儲存所有可用服務的節點資訊，服務節點的資訊可以在介面中直觀看到；Eureka Client是一個Java使用者端用於簡化Eureka Server的互動，使用者端同時也具備一個內建的、使用輪詢(round-robin)負載演演算法的負載均衡器；在應用啟動後，將會向Eureka Server傳送心跳(預設週期為30s)；如果Eureka Server在多個心跳週期內沒有接受到某個節點的心跳，Eureka Server將會從服務登入檔中把這個服務節點移除(預設90秒)。

注；在EurekaServer7001_App主啟動類中加入 @EnableEurekaServer 註解即可！

十一、作為服務註冊中心Eureka比Zookeeper好在哪裡?

1.Eureka遵守AP原則,Zookeeper遵守CP原則;

2.根據CAP理論,一個分散式系統不可能同時滿足一致性,可用性和分割區容錯性,由於分割區容錯性是分散式系統中必須保證的,因此我們只能在一致性和可用性之間權衡;

3.Zookeeper採用CP,節點採用主從,一旦主機down機,就會在多個從中進行決策選舉一個從作為主,但是選舉時間為30-120s之間,時間太長,在選舉期間會導致叢集不可用,從而導致整個註冊中心癱瘓;

4.Eureka採用AP,所有節點平等,沒有主從,如果有一個節點掛掉,就會自動切換到下一個可用的節點,只要有一個Eureka節點正常執行,就能保證註冊中心可用;只不過查詢到的資訊可能不是最新的(不保證強一致性);

5.除此之外, Eureaka還有自我保護機制; 因此Eureka可以很好地應對因網路故障而導致部分節點失去聯絡的情況,而不會像Zookeeper那樣使整個註冊服務癱瘓。

十二、Eureka保護機制？

1.Eureka自我保護機制是一種應對網路異常的安全保護措施,它的架構哲學是寧可保留所有的微服務(健康的和不健康的微服務都保留),也不盲目登出任何健康的微服務,使用自我保護模式,可以讓Eureka叢集更加健壯,穩定;

2.預設情況下,如果Eureka Server在一定時間內沒有接收到某個微服務範例的心跳，Eureka Server將會登出該範例(預設90秒),但是當網路發生故障時,微服務與Eureka Server之間無法正常通訊,以上行為可能變得非常危險--因為服務本身其實是健康的,此時本不應該登出這個服務;

3.Eureka通過"自我保護模式"來解決這個問題--當Eureka Server在短時間丟失過多使用者端時(可能發生了網路分割區故障),那麼該節點就會進入自我保護模式; 一旦進入該模式,Eureaka Server就會保護登入檔中的資訊,不再刪除服務登入檔中的資料(也不會登出任何微服務),當網路故障恢復後，該Eureka Server節點會自動退出自我保護模式。

十三、傳統的 ACID 分別是什麼？

A (Atomicity) 原子性;

C (Consistency) 一致性;

I (Isolation) 隔離性;

D (Durability) 永續性。

十四、CAP 分別是什麼？

C (Consistency) 強一致性;

同樣資料在分散式系統中所有地方都是被複製成相同的;

A (Availability) 可用性;

所有在分散式系統活躍的節點都能夠處理操作並且能相應查詢;

P (Partition Tolerance) 分割區容錯性;

在兩個複製系統之間,如果發生了計劃之外的網路連線問題,對於這種情況,有一套容錯性設計來保證;

CAP理論的核心是: 一個分散式系統不可能同時很好的滿足一致性,可用性和分割區容錯性, 最多隻能同時實現兩種。

十五、什麼是Ribbon？

SpringCloud Ribbon 是基於Netfix Ribbon 實現的一套使用者端負軟載均衡工具。

十六、什麼是負載均衡 ？

負載均衡(Load Balance) 簡單的說就是將使用者的請求平攤到多個服務上,從而達到系統的HA，即高可用;

分類: 集中式LB, 程序內LB。

十七、什麼是 Feign？

Feign是一個宣告式的WebService使用者端, 其內建了Ribbon的負載均衡,還有它的面向介面程式設計，優雅而簡單的實現了服務的呼叫，讓編寫WebService使用者端更簡單。

 

十八、分散式系統面臨的問題？

複雜分散式系統結構中的應用程式有數十個依賴關係，每個依賴關係在某些時候將面臨不可避免的依賴失敗。

十九、什麼是服務雪崩？

多個微服務之間呼叫的時候,假設微服務A呼叫微服務B和C,微服務B和C又呼叫其他微服務,這就是所謂的"扇出"; 如果扇出鏈路上的某個微服務的呼叫不可用或響應時間過長,對微服務A的呼叫就會佔用越來越多的系統資源,進而引起系統崩潰,所謂的"雪崩效應"(是一種 服務提供者 的不可用導致 服務呼叫者的不可用，並將不可用逐漸放大的過程)。

二十、什麼是 Hystrix？

Hystrix 是一個用於處理分散式系統的延遲和容錯的開源庫(基於Netfix); 在分散式系統裡,許多依賴不可避免的會失敗,比如超時,異常等, Hystrix能夠保證在一個依賴出現問題的情況下,不會導致整體服務失敗,避免級聯故障,以提高分散式系統的彈性;斷路器本事是一種開關裝置,當某個服務單元發生故障後,通過斷路器的故障監控(類似熔斷保險絲),向呼叫方返回一個符合預期的,可處理的備選響應(FallBack),而不是長時間的等待或者丟擲呼叫方無法處理的異常,這樣就保證了服務呼叫方的執行緒不會被長時間,不必要地佔用, 從而避免了故障在分散式系統的蔓延，乃至雪崩。

二十一、Hystrix 能幹什麼？

服務降級、服務熔斷、服務限流、服務監控。

二十二、什麼是服務熔斷？

熔斷機制是應對雪崩效應的一種微服務鏈路保護機制; 當扇出鏈路的某個微服務不可用或響應時間過長時,會進行服務降級,進而熔斷該節點微服務的呼叫,快速返回錯誤的響應資訊; 當檢測到該節點微服務呼叫響應正常後恢復呼叫鏈路; 在SpringCloud框架裡,熔斷機制通過Hystrix實現,Hystrix會監控服務間的呼叫狀況,當失敗的呼叫達到一定閥值,就會啟動熔斷機制,預設是5秒內呼叫20次；(熔斷機制的註解是@HystrixCommand)

二十三、服務降級是什麼？

1.當伺服器壓力劇增的情況下,根據實際業務情況及流量,對一些服務和頁面有策略的不處理或換種簡單的方式處理,從而釋放釋放伺服器資源以保證核心交易正常運作;

2.服務降級一般是從整體負荷考慮,就是當某個服務熔斷之後,伺服器將不再被呼叫,此時使用者端可以自己準備一個原生的fallback回撥,返回一個預設值; 這樣做,雖然服務水平下降了,但好歹還可以用,比服務直接掛掉的要強;

3.服務降級處理是在使用者端完成的，與伺服器端無關。

二十四、什麼是服務監控 (Hystrix Dashboard)？

除了隔了依賴服務的呼叫之外,Hystrix還提供了準實時的呼叫監控(Hystrix Dashboard)，Hystrix會持續的記錄所有通過Hystrix 發起請求的執行資訊, 並以統計報表和圖形的形式展示給使用者,包括每秒執行多少請求、多少成功、多少失敗等資訊，並轉化為視覺化介面。

二十五、Zuul 是什麼？

Zuul(路由閘道器)包含了對請求的路由和過濾兩個重要的功能;

其中路由功能負責將外部請求轉發到具體的微服務範例上,是實現外部存取統一入口的基礎；而過濾功能則負責對請求的處理過程進行干預,是實現請求校驗,服務聚合等功能的基礎。

二十六、SpringCloud Config分散式設定中心是什麼？

SpringCloud Config為服務構架中的微服務提供集中化的外部設定支援,設定伺服器為各個不同微服務應用的所有環境提供了一箇中心化的外部設定, 集中管理組態檔, 將設定資訊已REST介面的形式暴露。

需要Java架構師方面的資料可以「加我小助理VX領取免費架構視訊資料」，記得要點贊轉發噢！！！