1、什麼是微服務？

微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程式劃分成一組小的服務，每個服務執行在其獨立的自己的程序中，服務之間互相協調、互相配合，為使用者提供最終價值。

服務之間採用輕量級的通訊機制互相溝通（通常是基於 HTTP 的 RESTful API）。

每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。

另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的資料儲存。

從技術維度來說：

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

2、微服務之間是如何建立通訊

● 第一種：遠端過程呼叫（Remote Procedure Invocation）

直接通過遠端過程呼叫來訪問別的service。

示例：REST、gRPC、Apache、Thrift

- 優點：
　　簡單，常見。因為沒有中介軟體代理，系統更簡單
- 缺點：
　　只支援請求/響應的模式，不支援別的，比如通知、請求/非同步響應、釋出/訂閱、釋出/非同步響應降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的

●第二種：訊息

使用非同步訊息來做服務間通訊。服務間通過訊息管道來交換訊息，從而通訊。

示例：Apache Kafka、RabbitMQ

- 優點:
　　把客戶端和服務端解耦，更鬆耦合 提高可用性，因為訊息中介軟體快取了訊息，直到消費者可以消費支援很多通訊機制比如通知、請求/非同步響應、釋出/訂閱、釋出/非同步響應
- 缺點:
　　訊息中介軟體有額外的複雜性

3、SpringCloud 和 Dubbo 有哪些區別？

● 相同點：SpringCloud 和 Dubbo 可以實現 RPC 遠端呼叫框架，可以實現服務治理。

● 不同點：SpringCloud 是一套目前比較網站微服務框架了，整合了分散式常用解決方案遇到了問題註冊中心 Eureka、負載均衡器 Ribbon ，客戶端呼叫工具 Rest 和 Feign，分散式配置中心 Config，服務保護 Hystrix，閘道器 Zuul Gateway，服務鏈路 Zipkin，訊息匯流排 Bus 等。

Dubbo 內部實現功能沒有 SpringCloud 強大（全家桶），只是實現服務治理，缺少分散式配置中心、閘道器、鏈路、匯流排等，如果需要用到這些元件，需要整合其他框架。

表 Spring Cloud與Dubbo功能對比

4、SpringBoot 和 SpringCloud，請你談談對他們的理解

 1）SpringBoot 專注於快速方便的開發單個個體微服務。
 2）SpringCloud 是關注全域性的微服務協調整理治理框架，它將 SpringBoot 開發的一個個單體微服務整合並管理起來，為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全域性鎖、決策競選、分散式會話等等整合服務。
 3）SpringBoot 可以離開 SpringCloud 獨立使用開發專案，但是 SpringCloud 離不開 SpringBoot，屬於依賴的關係。
 4）SpringBoot 專注於快速、方便的開發單個微服務個體，SpringCloud 關注全域性的服務治理框架。

Spring Boot可以離開Spring Cloud獨立使用開發專案，但是Spring Cloud離不開Spring Boot，屬於依賴的關係。

5、什麼是服務熔斷？什麼是服務降級？

● 服務熔斷

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

● Hystrix服務降級

其實就是執行緒池中單個執行緒障處理，防止單個執行緒請求時間太長，導致資源長期被佔有而得不到釋放，從而導致執行緒池被快速佔用完，導致服務崩潰。

Hystrix能解決如下問題：

 1）請求超時降級，執行緒資源不足降級，降級之後可以返回自定義資料
 2）執行緒池隔離降級，分散式服務可以針對不同的服務使用不同的執行緒池，從而互不影響
 3）自動觸發降級與恢復
 4）實現請求快取和請求合併

6、微服務的優缺點是分別是什麼？說一下你在專案開發中遇到的坑

● 優點

 1）每個服務足夠內聚，足夠小，程式碼容易理解這樣能聚焦一個指定的業務功能或業務需求
 2）開發簡單、開發效率提高，一個服務可能就是專一的只幹一件事。
 3）微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
 4）微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
 5）微服務能使用不同的語言開發。
 6）易於和第三方整合，微服務允許容易且靈活的方式整合自動部署，通過持續整合工具，如Jenkins, Hudson, bamboo。
 7）微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值。
 8）微服務允許你利用融合最新技術。
 9）微服務只是業務邏輯的程式碼，不會和HTML,CSS 或其他介面元件混合。
10）每個微服務都有自己的儲存能力，可以有自己的資料庫。也可以有統一資料庫。

● 缺點

 1）開發人員要處理分散式系統的複雜性
 2）多服務運維難度，隨著服務的增加，運維的壓力也在增大
 3）系統部署依賴
 4）服務間通訊成本
 5）資料一致性
 6）系統整合測試
 7）效能監控……

7、你所知道的微服務技術棧有哪些？請舉例一二

8、Eureka 和 Zookeeper 都可以提供服務註冊與發現的功能，請說說這兩者的區別？

著名的CAP理論指出，一個分散式系統不可能同時滿足C(一致性)、A(可用性)和P(分割槽容錯性)。由於分割槽容錯性P在是分散式系統中必須要保證的，因此我們只能在A和C之間進行權衡。

因此，Zookeeper 保證的是CP, Eureka 則是AP。

1）Zookeeper保證CP

　　當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s,且選舉期間整個zk叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網路問題使得zk叢集失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

2）Eureka保證AP

　　Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連線失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的資訊可能不是最新的(不保證強一致性)。

除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：

1）Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
2）Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3）當網路穩定時，當前例項新的註冊資訊會被同步到其它節點中

因此， Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。