經典Java-SpringCloud面試題

1、 什么是微服務？

? 微服務(Microservice Architecture) 是近幾年流行的一種架構思想，關于它的概念很難一言以蔽之，
究竟什么是微服務呢？我們在此參考ThoughtWorks 公司的首席科學家 Martin Fowler 于2014年提出的一段話：
原文：https://martinfowler.com/articles/microservices.html
漢化：https://www.cnblogs.com/liuning8023/p/4493156.html

• 就目前而言，對于微服務，業界并沒有一個統一的，標準的定義，
• 但通常而言，微服務架構是一種架構模式，或者說是一種架構風格，它體長將單一的應用程式劃分成一組小的服務，每個服務運行在其獨立的自己的行程內，服務之間互相協調，互相配置，為用戶提供最終價值，服務之間采用輕量級的通信機制(HTTP)互相溝通，每個服務都圍繞著具體的業務進行構建，并且能夠被獨立的部署到生產環境中，另外，應盡量避免統一的，集中式的服務管理機制，對具體的一個服務而言，應該根據業務背景關系，選擇合適的語言，工具(Maven)對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來撰寫服務，也可以使用不同的資料存盤，

再來從技術維度角度理解下：

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

2、微服務之間是如何獨立通訊的？

1. 將組建定義為可被獨立替換和升級的軟體單元，
2. 以業務能力為出發點組織服務的策略，
3. 倡導誰開發誰運營的開發運維一體化方法，
4. RestFul Http協議是微服務架構中最常用的通訊機制，
5. 每個微服務可以考慮采用最佳微服務完成（如不同的編程語言），
6. 允許不同的微服務采用不同的資料持久化技術，
7. 微服務非常注重建立架構和業務相關指標的實時監控和日志機制，必須考慮每個服務的失敗容錯機制，
8. 注重快速更新，因此系統會隨著時間不斷變化和演進，可替代性模塊化設計，

微服務通信方式：

    同步：RPC，REST等
    異步：訊息佇列，要考慮訊息可靠傳輸、高性能，以及編程模型的變化等，

1、客戶端到服務端通信，API Gateway方法，

? API Gateway是解決微服務通信的一個不錯的方法，以客戶端為例，一個客戶端可以向多個微服務中的任意一個微服務發出請求，

? API Gateway負責請求轉發、合成和協議轉換，所有請求都要先經過API Gateway，然后再將請求轉發到對應的微服務中，

2、行程通信IPC

? 這種通信不但可以實作一對一、一對多，還可以實作同步和異步請求，

3、SpringCloud 和 Dubbo有那些區別？

1、dubbo由于是二進制的傳輸，占用帶寬會更少；

2、springCloud是http協議傳輸，帶寬會比較多，同時使用http協議一般會使用JSON報文，消耗會更大；

3、dubbo的開發難度較大，原因是dubbo的jar包依賴問題，很多大型工程無法解決；

4、springcloud的介面協議約定比較自由且松散，需要有強有力的行政措施來限制介面無序升級；

5、dubbo的注冊中心可以選擇zookeeper、redis等多種，springcloud的注冊中心只能用eureka或者自研，

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

1. Spring boot 是 Spring 的一套快速配置腳手架，可以基于spring boot 快速開發單個微服務，Spring Cloud是一個基于Spring Boot實作的云應用開發工具；
2. Spring boot專注于快速、方便集成的單個個體，Spring Cloud是關注全域的服務治理框架；
3. spring boot使用了默認大于配置的理念，很多集成方案已經幫你選擇好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot來實作，
4. Spring boot可以離開Spring Cloud獨立使用開發專案，但是Spring Cloud離不開Spring boot，屬于依賴的關系，

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

來源地址：服務雪崩、降級與熔斷

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

百度百科

優點：

1. 服務的獨立部署

   每個服務都是一個獨立的專案，可以獨立部署，不依賴于其他服務，耦合性低，

2. 服務的快速啟動

   拆分之后服務啟動的速度必然要比拆分之前快很多，因為依賴的庫少了，代碼量也少了，

3. 更加適合敏捷開發

   敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行，服務拆分可以快速發布新版本，修改哪個服務只需要發布對應的服務即可，不用整體重新發布，

4. 職責專一，由專門的團隊負責專門的服務

   業務發展迅速時，研發人員也會越來越多，每個團隊可以負責對應的業務線，服務的拆分有利于團隊之間的分工，

5. 服務可以動態按需擴容

   當某個服務的訪問量較大時，我們只需要將這個服務擴容即可，

6. 代碼的復用

   每個服務都提供 REST API，所有的基礎服務都必須抽出來，很多的底層實作都可以以介面方式提供，

缺點：

1. 分布式部署，呼叫的復雜性高

   單體應用的時候，所有模塊之前的呼叫都是在本地進行的，在微服務中，每個模塊都是獨立部署的，通過 HTTP 來進行通信，這當中會產生很多問題，比如網路問題、容錯問題、呼叫關系等，

2. 獨立的資料庫，分布式事務的挑戰

   每個微服務都有自己的資料庫，這就是所謂的去中心化的資料管理，這種模式的優點在于不同的服務，可以選擇適合自身業務的資料，比如訂單服務可以用 MySQL、評論服務可以用 Mongodb、商品搜索服務可以用 Elasticsearch，

3. 測驗的難度提升

   服務和服務之間通過介面來互動，當介面有改變的時候，對所有的呼叫方都是有影響的，這時自動化測驗就顯得非常重要了，如果要靠人工一個個介面去測驗，那作業量就太大了，這里要強調一點，就是 API 檔案的管理尤為重要，

4. 運維難度的提升

   在采用傳統的單體應用時，我們可能只需要關注一個 Tomcat 的集群、一個 MySQL 的集群就可以了，但這在微服務架構下是行不通的，當業務增加時，服務也將越來越多，服務的部署、監控將變得非常復雜，這個時候對于運維的要求就高了，

7、你所知道的微服務技術堆疊有哪些？列舉一二

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

1. ? ZooKeeper保證的是CP,Eureka保證的是AP
2. ? ZooKeeper在選舉期間注冊服務癱瘓,雖然服務最侄訓恢復,但是選舉期間不可用的
3. ? Eureka各個節點是平等關系,只要有一臺Eureka就可以保證服務可用,而查詢到的資料并不是最新的，自我保護機制會導致Eureka不再從注冊串列移除因長時間沒收到心跳而應該過期的服務，Eureka仍然能夠接受新服務的注冊和查詢請求,但是不會被同步到其他節點(高可用)
4. ? 當網路穩定時,當前實體新的注冊資訊會被同步到其他節點中(最終一致性)，Eureka可以很好的應對因網路故障導致部分節點失去聯系的情況,而不會像ZooKeeper一樣使得整個注冊系統癱瘓
5. ? ZooKeeper有Leader和Follower角色,Eureka各個節點平等
6. ? ZooKeeper采用過半數存活原則,Eureka采用自我保護機制解決磁區問題
7. ? Eureka本質上是一個工程,而ZooKeeper只是一個行程

各微服務框架對比

     | Spring Cloud Bus為我們的應用程式帶來了更多管理端點           | 支持降級                                                     | Netflix內部在開發集成gRPC | IDL定義  | 實踐的公司比較多                    |