-
Spring Boot 有哪些優點？
答：Spring Boot 的優點有：
減少開發，測試時間和努力。
使用 JavaConfig 有助於避免使用 XML。
避免大量的 Maven 導入和各種版本沖突。
提供意見發展方法。
通過提供默認值快速開始開發。
沒有單獨的 Web 服務器需要。這意味着你不再需要啟動 Tomcat，Glassfish 或其
他任何東西。
需要更少的配置 因為沒有web.xml文件。只需添加用@ Configuration注釋的類，
然后添加用@Bean 注釋的方法，Spring 將自動加載對象並像以前一樣對其進行管理。
您甚至可以將@Autowired 添加到 bean 方法中，以使 Spring 自動裝入需要的依賴關系
中。
基於環境的配置 使用這些屬性，您可以將您正在使用的環境傳遞到應用程序：
-Dspring.profiles.active = {enviornment}。在加載主應用程序屬性文件后，Spring 將
在（application{environment} .properties）中加載后續的應用程序屬性文件。 -
如何重新加載 Spring Boot 上的更改，而無需重新啟動服務器？
答：
這可以使用 DEV 工具來實現。通過這種依賴關系，您可以節省任何更改，嵌入式
tomcat 將重新啟動。Spring Boot 有一個開發工具（DevTools）模塊，它有助於提高
開發人員的生產力。Java 開發人員面臨的一個主要挑戰是將文件更改自動部署到服務器
並自動重啟服務器。開發人員可以重新加載 Spring Boot 上的更改，而無需重新啟動服
務器。這將消除每次手動部署更改的需要。Spring Boot 在發布它的第一個版本時沒有
這個功能。這是開發人員最需要的功能。DevTools 模塊完全滿足開發人員的需求。該模
塊將在生產環境中被禁用。它還提供 H2 數據庫控制台以更好地測試應用程序。
org.springframework.boot
spring-boot-devtools
true
-
常見的系統架構風格有哪些？各有什么優缺點？
1、單體架構
單體架構也稱之為單體系統或者是單體應用。就是一種把系統中所有的功能、模塊耦
合在一個應用中的架構方式。
單體架構特點：打包成一個獨立的單元(導成一個唯一的 jar 包或者是 war 包)，會一個進
程的方式來運行。
單體架構的優點、缺點
優點：
項目易於管理
部署簡單
缺點：
測試成本高
可伸縮性差
可靠性差
迭代困難
跨語言程度差
團隊協作難
2、MVC 架構
MVC 架構特點：
MVC 是模型(Model)、視圖(View)、控制器(Controller)3 個單詞的縮寫。 下面我們從
這 3 個方面來講解 MVC 中的三個要素。
Model 是指數據模型，是對客觀事物的抽象。如一篇博客文章，我們可能會以一個 Post
類來表示，那么，這個 Post 類就是數據對象。 同時，博客文章還有一些業務邏輯，如
發布、回收、評論等，這一般表現為類的方法，這也是 model 的內容和范疇。 對於
Model，主要是數據、業務邏輯和業務規則。相對而言，這是 MVC 中比較穩定的部分，
一般成品后不會改變。 開發初期的最重要任務，主要也是實現 Model 的部分。這一部
分寫得好，后面就可以改得少，開發起來就快。
View 是指視圖，也就是呈現給用戶的一個界面，是 model 的具體表現形式，也是收集
用戶輸入的地方。如你在某個博客上看到的某一篇文章，就是某個 Post 類的表現形式。
View 的目的在於提供與用戶交互的界面。換句話說，對於用戶而言，只有 View 是可見
的、可操作的。事實上也是如此，你不會讓用戶看到 Model，更不會讓他直接操作 Model。
你只會讓用戶看到你想讓他看的內容。 這就是 View 要做的事，他往往是 MVC 中變化
頻繁的部分，也是客戶經常要求改來改去的地方。 今天你可能會以一種形式來展示你的
博文，明天可能就變成別的表現形式了。
Contorller 指的是控制器，主要負責與 model 和 view 打交道。 換句話說，model 和
view 之間一般不直接打交道，他們老死不相往來。view 中不會對 model 作任何操作，
model 不會輸出任何用於表現的東西，如 HTML 代碼等。這倆甩手不干了，那總得有人
來干吧，只能 Controller 上了。 Contorller 用於決定使用哪些 Model，對 Model 執
行什么操作，為視圖准備哪些數據，是 MVC 中溝通的橋梁。
MVC 架構優缺點
優點：
各施其職，互不干涉。
在 MVC 模式中，三個層各施其職，所以如果一旦哪一層的需求發生了變化，就只需
要更改相應的層中的代碼而不會影響到其它層中的代碼。
有利於開發中的分工。
在 MVC 模式中，由於按層把系統分開，那么就能更好的實現開發中的分工。網頁設
計人員可以進行開發視圖層中的 JSP，對業務熟悉的開發人員可開發業務層，而其它開
發人員可開發控制層。
有利於組件的重用。
分層后更有利於組件的重用。如控制層可獨立成一個能用的組件，視圖層也可做成通
用的操作界面。
缺點：
增加了系統結構和實現的復雜性。
視圖與控制器間的過於緊密的連接。
視圖對模型數據的低效率訪問。
3、面向服務架構(SOA)
面向服務的架構（SOA）是一個組件模型，它將應用程序拆分成不同功能單元（稱
為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進
行定義的，它應該獨立於實現服務的硬件平台、操作系統和編程語言。這使得構建在各
種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
面向服務架構特點：
系統是由多個服務構成
每個服務可以單獨獨立部署
每個服務之間是松耦合的。服務內部是高內聚的，外部是低耦合的。高內聚就是每個
服務只關注完成一個功能。
服務的優點、缺點
優點：
測試容易
可伸縮性強
可靠性強
跨語言程度會更加靈活
團隊協作容易
系統迭代容易
缺點：
運維成本過高，部署數量較多
接口兼容多版本
分布式系統的復雜性
分布式事務 -
什么是 AKF 拆分原則？
業界對於可擴展的系統架構設計有一個朴素的理念,就是：通過加機器就可以解決容
量和可用性問題。(如果一台不行那就兩台)。
我是個段子：（世界上沒有什么事是一頓燒烤不能解決的。如果有，那就兩頓。）
這一理念在“雲計算”概念瘋狂流行的今天，得到了廣泛的認可！對於一個規模迅速
增長的系統而言，容量和性能問題當然是首當其沖的。但是隨着時間的向前，系統規模
的增長，除了面對性能與容量的問題外，還需要面對功能與模塊數量上的增長帶來的系
統復雜性問題以及業務的變化帶來的提供差異化服務問題。而許多系統，在架構設計時
並未充分考慮到這些問題，導致系統的重構成為常態，從而影響業務交付能力，還浪費
人力財力！對此，《可擴展的藝術》一書提出了一個更加系統的可擴展模型—— AKF 可
擴展立方（Scalability Cube） 。這個立方體中沿着三個坐標軸設置分別為：X、Y、Z。 Y 軸擴展會將龐大的整體應用拆分為多個服務。每個服務實現一組相關的功能，如訂
單管理、客戶管理等。在工程上常見的方案是 服務化架構(SOA) 。比如對於一個電子商
務平台，我們可以拆分成不同的服務
X 軸擴展與我們前面朴素理念是一致的，通過絕對平等地復制服務與數據，以解決容量
和可用性的問題。其實就是將微服務運行多個實例，做集群加負載均衡的模式。
Z 軸擴展通常是指基於請求者或用戶獨特的需求，進行系統划分，並使得划分出來的
子系統是相互隔離但又是完整的。以生產汽車的工廠來舉例：福特公司為了發展在中國
的業務，或者利用中國的廉價勞動力，在中國建立一個完整的子工廠，與美國工廠一樣，
負責完整的汽車生產。這就是一種 Z 軸擴展。 -
什么是 Spring Cloud？
Spring Cloud 是一個微服務框架，相比 Dubbo 等 RPC 框架, Spring Cloud 提供的全套
的分布式系統解決方案。
Spring Cloud 對微服務基礎框架 Netflix 的多個開源組件進行了封裝，同時又實現了和
雲端平台以及和 Spring Boot 開發框架的集成。
Spring Cloud 為微服務架構開發涉及的配置管理，服務治理，熔斷機制，智能路由，微
代理，控制總線，一次性 token，全局一致性鎖，leader 選舉，分布式 session，集群狀態
管理等操作提供了一種簡單的開發方式。
Spring Cloud 為開發者提供了快速構建分布式系統的工具，開發者可以快速的啟動服務
或構建應用、同時能夠快速和雲平台資源進行對接 -
Spring Cloud 與 Dubbo 的區別是什么？
-
什么是 Eureka 注冊中心？
Eureka 是 Netflix 開發的服務發現組件，本身是一個基於 REST 的服務。Spring Cloud
將它集成在其子項目 spring-cloud-netflix 中，以實現 Spring Cloud 的服務注冊於發現，
同時還提供了負載均衡、故障轉移等能力。 -
簡單談一下 Eureka 中的三種角色分別是什么？
1、Eureka Server
通過 Register、Get、Renew 等接口提供服務的注冊和發現。
2、Application Service (Service Provider)
服務提供方
把自身的服務實例注冊到 Eureka Server 中 3、Application Client (Service Consumer)
服務調用方
通過 Eureka Server 獲取服務列表，消費服務。 -
什么是 Ribbon
1.Ribbon 是一個基於 Http 和 TCP 的客服端負載均衡工具，它是基於 Netflix Ribbon
實現的。
2.它不像 spring cloud 服務注冊中心、配置中心、API 網關那樣獨立部署，但是它幾乎
存在於每個 spring cloud 微服務中。包括 feign 提供的聲明式服務調用也是基於該 Ribbon
實現的。
3.ribbon 默認提供很多種負載均衡算法，例如 輪詢、隨機 等等。甚至包含自定義的負
載均衡算法。 -
集中式與進程內負載均衡的區別
目前業界主流的負載均衡方案可分成兩類：
第一類：集中式負載均衡, 即在 consumer 和 provider 之間使用獨立的負載均衡設施(可
以是硬件，如 F5, 也可以是軟件，如 nginx), 由該設施負責把 訪問請求 通過某種策略轉發
至 provider；
第二類：進程內負載均衡，將負載均衡邏輯集成到 consumer，consumer 從服務注冊
中心獲知有哪些地址可用，然后自己再從這些地址中選擇出一個合適的 provider。
Ribbon 就屬於后者，它只是一個類庫，集成於 consumer 進程，consumer 通過它來
獲取到 provider 的地址。 -
Ribbon 的常見負載均衡策略有哪些？
id 策略名稱 策略對應的類名 實現原理
1 輪詢策略（默認） RoundRobinRule
輪詢策略表示每次都順序取下一個
provider，比如一共有 5 個 provider， 第 1 次取第 1 個，第 2 次取第 2 個，第
3 次取第 3 個，以此類推
2 權重輪詢策略
WeightedResponseTime
Rule
1.根據每個 provider 的響應時間分配
一個權重，響應時間越長，權重越小，
被選中的可能性越低。
2.原理：一開始為輪詢策略，並開啟一
個計時器，每 30 秒收集一次每個
provider 的平均響應時間，當信息足夠
時，給每個 provider 附上一個權重，
並按權重隨機選擇 provider，高權越重
的 provider 會被高概率選中。
3 隨機策略 RandomRule
從 provider 列表中隨機選擇一個
provider
4 最少並發數策略 BestAvailableRule
選擇正在請求中的並發數最小的
provider，除非這個 provider 在熔斷
中。
5
在“選定的負載均
衡策略”基礎上進
行重試機制
RetryRule
1.“選定的負載均衡策略”這個策略是
輪詢策略 RoundRobinRule
2.該重試策略先設定一個閾值時間段，
如果在這個閾值時間段內當選擇
provider 不成功，則一直嘗試采用“選
定的負載均衡策略：輪詢策略”最后選
擇一個可用的 provider
過濾性能差的 provider,有 2 種：
第一種：過濾掉在 eureka 中處於一直
6 可用性敏感策略 AvailabilityFilteringRule
連接失敗 provider
第二種：過濾掉高並發的 provider
1.以一個區域為單位考察可用性，對於
不可用的區域整個丟棄，從剩下區域中
選可用的 provider
7 區域敏感性策略 ZoneAvoidanceRule
2.如果這個ip區域內有一個或多個實例
不可達或響應變慢，都會降低該 ip 區域
內其他 ip 被選中的權重。 -
簡單說說什么是 Feign？
Feign 是一種聲明式、模板化的 HTTP 客戶端技術(僅在 consumer 中使用)。 -
什么是聲明式，有什么作用，解決什么問題？
聲明式調用就像調用本地方法一樣調用遠程方法;無感知遠程 http 請求。
1、Spring Cloud 的聲明式調用, 可以做到使用 HTTP 請求遠程服務時能就像調用本地
方法一樣的體驗，開發者完全感知不到這是遠程方法，更感知不到這是個 HTTP 請求。
2、它像 Dubbo 一樣，consumer 直接調用接口方法調用 provider，而不需要通過常規
的 Http Client 構造請求再解析返回數據。
3、它解決了讓開發者調用遠程接口就跟調用本地方法一樣，無需關注與遠程的交互細節，
更無需關注分布式環境開發。 -
什么是服務的災難性的雪崩效應？
在微服務架構中，一個請求需要調用多個服務是非常常見的。如客戶端訪問 A 服務，
而 A 服務需要調用 B 服務，B 服務需要調用 C 服務，由於網絡原因或者自身的原因，如
果 B 服務或者 C 服務不能及時響應，A 服務將處於阻塞狀態，直到 B 服務 C 服務響應。
此時若有大量的請求涌入，容器的線程資源會被消耗完畢，導致服務癱瘓。服務與服務之
間的依賴性，故障會傳播，造成連鎖反應，會對整個微服務系統造成災難性的嚴重后果，
這就是服務故障的“雪崩”效應 -
如何解決災難性雪崩效應？
降級
超時降級、資源不足時(線程或信號量)降級，降級后可以配合降級接口返回托底數據。
實現一個 fallback 方法, 當請求后端服務出現異常的時候, 可以使用 fallback 方法返回的
值.
隔離（線程池隔離和信號量隔離）
限制調用分布式服務的資源使用，某一個調用的服務出現問題不會影響其他服務調用。
熔斷
當失敗率(如因網絡故障/超時造成的失敗率高)達到閥值自動觸發降級，熔斷器觸發
的快速失敗會進行快速恢復。
緩存
提供了請求緩存。
請求合並
提供請求合並。 -
線程池隔離和信號量隔離的區別
-
請回答微服務架構的六種常用設計模式是什么？
答：如下這六種
代理設計模式
聚合設計模式
鏈條設計模式
聚合鏈條設計模式
數據共享設計模式
異步消息設計模式 -
什么是網關服務？
答：網關服務，通常是外部訪問服務的唯一接口，訪問內部的所有服務都必須先經過網
關服務。網關服務的主要功能是消息解析過濾，路由，轉發等。 -
網關服務中，路由器的 4 種路由規則方法是什么？
答：
采用 URL 指定路由方式
采用服務名稱指定路由方式
路由的排除方法
路由的添加前綴方法 -
為什么要使用 spring cloud config 配置中心？它解決了什么問題？
-
什么是 Spring Cloud Bus
-
消息驅動 Stream 解決了什么問題？
-
為什么要使用微服務跟蹤？它解決了什么問題？
-
什么是 ELK（ElasticSearch, Logstash, Kibana）
ELK 是三個工具的集合，Elasticsearch + Logstash + Kibana，這三個工具組合形成了
一套實用、易用的監控架構，很多公司利用它來搭建可視化的海量日志分析平台。 -
ElasticSearch
ElasticSearch 是一個基於 Lucene 的搜索服務器。它提供了一個分布式多用戶能力的全
文搜索引擎，基於 RESTful web 接口。Elasticsearch 是用 Java 開發的，並作為 Apache 許
可條款下的開放源碼發布，是當前流行的企業級搜索引擎。設計用於雲計算中，能夠達到實
時搜索，穩定，可靠，快速，安裝使用方便。 -
Logstash
Logstash 是一個用於管理日志和事件的工具，你可以用它去收集日志、轉換日志、解析
日志並將他們作為數據提供給其它模塊調用，例如搜索、存儲等。 -
Kibana
Kibana 是一個優秀的前端日志展示框架，它可以非常詳細的將日志轉化為各種圖表，為
用戶提供強大的數據可視化支持。 -
為什么要用 ELK，它解決了什么問題？
-
什么是分布式跟蹤 : Zipki？
![](https://img2020.cnblogs.com/blog/1848079/202003/1848079-20200322151656753-536197584.png）
微服務框架面試題
免責聲明！
本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。