SpringCloud 經典面試問題

一.SpringCloud和Dubbo

SpringCloud和Dubbo都是現在主流的微服務架構
SpringCloud是Apache旗下的Spring體系下的微服務解決方案
Dubbo是阿里系的分佈式服務治理框架
從技術維度上,其實SpringCloud遠遠的超過Dubbo,Dubbo本身只是實現了服務治理,而SpringCloud現在以及有21個子項目以後還會更多
所以其實很多人都會說Dubbo和SpringCloud是不公平的
但是由於RPC以及註冊中心元數據等原因,在技術選型的時候我們只能二者選其一,所以我們常常爲用他倆來對比
服務的調用方式Dubbo使用的是RPC遠程調用,而SpringCloud使用的是 Rest API,其實更符合微服務官方的定義
服務的註冊中心來看,Dubbo使用了第三方的ZooKeeper作爲其底層的註冊中心,實現服務的註冊和發現,SpringCloud使用Spring Cloud Netflix Eureka實現註冊中心,當然SpringCloud也可以使用ZooKeeper實現,但一般我們不會這樣做
服務網關,Dubbo並沒有本身的實現,只能通過其他第三方技術的整合,而SpringCloud有Zuul路由網關,作爲路由服務器,進行消費者的請求分發,SpringCloud還支持斷路器,與git完美集成分佈式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素

二.技術選型

目前國內的分佈式系統選型主要還是Dubbo畢竟國產,而且國內工程師的技術熟練程度高,並且Dubbo在其他維度上的缺陷可以由其他第三方框架進行集成進行彌補
而SpringCloud目前是國外比較流行,當然我覺得國內的市場也會慢慢的偏向SpringCloud,就連劉軍作爲Dubbo重啓的負責人也發表過觀點,Dubbo的發展方向是積極適應SpringCloud生態,並不是起衝突

三.Rest和RPC對比

其實如果仔細閱讀過微服務提出者馬丁福勒的論文的話可以發現其定義的服務間通信機制就是Http Rest
RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,我們需要爲每一個微服務進行接口的定義,並通過持續繼承發佈,需要嚴格的版本控制纔不會出現服務提供和調用之間因爲版本不同而產生的衝突
而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是通過一個約定進行規範,但也有可能出現文檔和接口不一致而導致的服務集成問題,但可以通過swagger工具整合,是代碼和文檔一體化解決,所以REST在分佈式環境下比RPC更加靈活
這也是爲什麼噹噹網的DubboX在對Dubbo的增強中增加了對REST的支持的原因

四.文檔質量和社區活躍度

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

五.SpringBoot和SpringCloud

SpringBoot是Spring推出用於解決傳統框架配置文件冗餘,裝配組件繁雜的基於Maven的解決方案,旨在快速搭建單個微服務
而SpringCloud專注於解決各個微服務之間的協調與配置,服務之間的通信,熔斷,負載均衡等,技術維度並相同,並且SpringCloud是依賴於SpringBoot的,而SpringBoot並不是依賴與SpringCloud,甚至還可以和Dubbo進行優秀的整合開發

總結:

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

六.Eureka和ZooKeeper都可以提供服務註冊與發現的功能,請說說兩個的區別

1.ZooKeeper保證的是CP,Eureka保證的是AP

ZooKeeper在選舉期間註冊服務癱瘓,雖然服務最終會恢復,但是選舉期間不可用的
Eureka各個節點是平等關係,只要有一臺Eureka就可以保證服務可用,而查詢到的數據並不是最新的

自我保護機制會導致：

Eureka不再從註冊列表移除因長時間沒收到心跳而應該過期的服務
Eureka仍然能夠接受新服務的註冊和查詢請求,但是不會被同步到其他節點(高可用)
當網絡穩定時,當前實例新的註冊信息會被同步到其他節點中(最終一致性)

Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況,而不會像ZooKeeper一樣使得整個註冊系統癱瘓

2.ZooKeeper有Leader和Follower角色,Eureka各個節點平等
3.ZooKeeper採用過半數存活原則,Eureka採用自我保護機制解決分區問題
4.Eureka本質上是一個工程,而ZooKeeper只是一個進程

七.微服務之間是如何獨立通訊的

微服務通信機制
系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。
圍繞業務能力組織服務、自動化部署、智能端點、對語言及數據的去集中化控制。

將組件定義爲可被獨立替換和升級的軟件單元。
以業務能力爲出發點組織服務的策略。
倡導誰開發，誰運營的開發運維一體化方法。
RESTful HTTP協議是微服務架構中最常用的通訊機制。
每個微服務可以考慮選用最佳工具完成(如不同的編程語言)。
允許不同微服務採用不同的數據持久化技術。
微服務非常重視建立架構及業務相關指標的實時監控和日誌機制，必須考慮每個服務的失敗容錯機制。
注重快速更新，因此係統會隨時間不斷變化及演進。可替代性模塊化設計。

微服務通信方式：

同步：RPC，REST等

異步：消息隊列。要考慮消息可靠傳輸、高性能，以及編程模型的變化等。

消息隊列中間件如何選型

    1.協議：AMQP、STOMP、MQTT、私有協議等。
    2.消息是否需要持久化。
    3.吞吐量。
    4.高可用支持，是否單點。
    5.分佈式擴展能力。
    6.消息堆積能力和重放能力。
    7.開發便捷，易於維護。
    8.社區成熟度。

RabbitMQ是一個實現了AMQP(高級消息隊列協議)協議的消息隊列中間件。RabbitMQ支持其中的最多一次和最少一次兩種。網易蜂巢平臺的服務架構，服務間通過RabbitMQ實現通信。

八.什麼是服務熔斷?什麼是服務降級

   在複雜的分佈式系統中,微服務之間的相互調用,有可能出現各種各樣的原因導致服務的阻塞,在高併發場景下,服務的
   阻塞意味着線程的阻塞,導致當前線程不可用,服務器的線程全部阻塞,導致服務器崩潰,由於服務之間的調用關係是同
   步的,會對整個微服務系統造成服務雪崩，爲了解決某個微服務的調用響應時間過長或者不可用進而佔用越來越多的
   系統資源引起雪崩效應就需要進行服務熔斷和服務降級處理。
  

  所謂的服務熔斷指的是某個服務故障或異常一起類似顯示世界中的“保險絲"當某個異常條件被觸發就直接
  熔斷整個服務，而不是一直等到此服務超時。

  服務熔斷就是相當於我們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,通過維護一個自己的線程池,
  當線程達到閾值的時候就啓動服務降級,如果其他請求繼續訪問就直接返回fallback的默認值。

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

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

十.你所知道的微服務技術棧有哪些?請列舉一二

多種技術的集合體
我們在討論一個分佈式的微服務架構的話,需要哪些維度

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

十一、Eureka自我保護機制

接着以上篇文章建立的三個工程爲基礎（eureka-server,uerreg,myweb）,默認Eureka是開啓自我保護的。我們來做個測試，我們先啓動三個工程，我們訪問註冊中心http://localhost:8761/,

可以看到，實例是成功註冊到中心的。此時我們將uerreg服務關閉，刷新註冊中心，我們會發現如下界面

我們除了看到了一行紅色的警告信息，還發現了一件神奇的事情，就是我們的服務實例雖然被kill了，但是在服務註冊中心他還是存在的。這就是Eureka自我保護機制，他不會剔除已經掛掉的服務，他會認爲這個服務是在嘗試重新連接的。
我們在開發過程中肯定是不希望這樣的，不利於開發。我們可以關閉Eureka的自我保護機制（實際生產環境不建議關閉）。

eureka-server服務端
配置文件中我們添加如下配置

#關閉保護機制，以確保註冊中心將不可用的實例正確剔除
eureka.server.enable-self-preservation=false
#（代表是5秒，單位是毫秒,清理失效服務的間隔 ）
eureka.server.eviction-interval-timer-in-ms=5000

userreg客戶端
配置文件中我們添加如下配置

# 心跳檢測檢測與續約時間
# 測試時將值設置設置小些，保證服務關閉後註冊中心能及時踢出服務
# 配置說明
#　　lease-renewal-interval-in-seconds 每間隔10s，向服務端發送一次心跳，證明自己依然”存活“
#　　lease-expiration-duration-in-seconds  告訴服務端，如果我20s之內沒有給你發心跳，就代表我“死”了，
將我踢出掉。
eureka.instance.lease-renewal-interval-in-seconds=10
eureka.instance.lease-expiration-duration-in-seconds=20

我們重新啓動服務，然後關閉userreg客戶端進行測試。

此時我們發現，紅色警告變成了自我保護被關閉的警告，且實例被註冊中心剔除，表明此時自我保護機制被關閉。

十二、Eureka健康檢查

健康檢查在實際應用場景中有哪些呢？舉個例子，我們配置userreg工程數據源
在pom文件中引入以下依賴

...
 <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>
...

然後建立一個配置類，配置數據源DataSource

@Configuration
public class Myconfig {
   @Bean
   public DataSource dataSource()
   {
       org.apache.tomcat.jdbc.pool.DataSource dataSource=new org.apache.tomcat.jdbc.pool.DataSource();
       dataSource.setUrl("jdbc:mysql://localhost/test?characterEncoding=UTF-8");
       dataSource.setUsername("root");
       dataSource.setPassword("mysql");
       dataSource.setDriverClassName("com.mysql.jdbc.Driver");
       return dataSource;
   }
}

這個在springboot中已經學習過，後續我會把springboot學習過程以博客的方式記錄下來，配置完成數據源之後，我們啓動服務，訪問http://localhost:9001/admin/health 查看健康情況

我們可以看到db的健康情況。假如此時我們的mysql服務掛掉，會怎樣呢？

我們手動停止mysql服務，然後再看健康情況

原文鏈接：https://blog.csdn.net/jerryDzan/article/details/89137818