大家好！我是【程式員寫榮】，希望接下來可以通過書寫博客，使自己的程式員生涯欣欣向榮，這博客通過面試題的形式將各個知識點進行匯總，是對自己學習的一點點總結及記錄，
什么是單體應用架構？
?一個應用中包含了應用程式的所有功能（比如：頁面、代碼、配置等），把應用打成一個war或jar包部署到Tomcat中，通常稱為單體應用架構，
單體應用架構的優點和缺點？
- 優點
- 易于開發和測驗：單個應用包含所有功能，不涉及多個應用的互聯互調，便于在團隊之間開發與測驗，只更新這個大的應用程式，其他的都不用考慮，
- 易于部署：只需將單個應用打成war或jar包，進行部署到Tomcat即可，運維起來比較方便
- 易于整體擴展：當應用負載壓力大時，將這個應用復制幾份，分別部署在不同的服務器上，在通過負載均衡即可提高應用的并發能力，
- 缺點
- 復雜性高：由于是單個應用，所以整個專案檔案包含的模塊非常多，導致模塊的邊界非常模糊、依賴關系不清晰、代碼的質量參差不齊，混亂的堆在一起，使得整個專案非常復雜，以致每次修改代碼，都非常小心，可能添加一個簡單的功能，或者修改一個bug都會帶來隱藏的缺陷，
- 技術債務：隨著時間的推移、需求的變更和技術人員的更替，會逐漸形成應用程式的技術債務，并且越積越多，
- 阻礙技術創新：對于單體應用來說，技術是在開發之前經過慎重評估后選定的，每個團隊成員必須使用相同的開發語言、持久化存盤及訊息系統，
什么是微服務架構？
?微服務是一種架構風格，是以開發一組小型服務的方式來作為一個獨立的應用系統，每個服務都運行在自己的行程中，服務之間采用輕量級的HTTP通信機制（通常采用HTTP的RESTful API）進行通信，這些服務都是圍繞具體業務進行構建的，并且可以獨立部署到生產環境上，這些服務可以用不同的編程語言撰寫，并且可以使用不同的資料存盤技術，對這些微服務我們只需要使用一個非常輕量級的集中式管理來進行協調，
微服務架構的優點和缺點？
- 優點
- 易于開發和維護：一個微服務只會關注一個特定的業務功能，所以業務清晰、代碼量較少，開發和維護單個微服務相對簡單，
- 單個微服務啟動較快
- 區域修改容易部署：單個應用只要有修改，就得重新部署整個應用，微服務解決了這樣的問題，一般來說，對某個微服務進行修改，只需要重新部署這個服務即可，
- 技術堆疊不受限制：在微服務架構中，可以結合專案業務及團隊的特點，合理的選擇技術堆疊，
- 按需伸縮：可根據需求，實作細粒度的擴展，
- 缺點
- 運維要求高：更多的服務意味著要投入更多的運維
- 分布式固有的復雜性：使用微服務構建的是分布式系統，對于一個分布式系統，系統容錯、網路延遲、分布式事務等都會帶來巨大的問題，
- 介面的調整成本高：微服務之間通過介面進行通信，如果修改某一個微服務的API，可能所有用到這個介面的微服務都需要進行調整，
微服務架構總結
- 微服務的核心就是將傳統的單一應用，根據業務拆分成一個一個的服務，徹底地去耦合，每一個微服務提供單個業務功能的服務，一個服務做一件事，
- 在 IDEA 工具中使用 Maven 構建的一個個獨立的 Model，也就是使用 Spring Boot 開發的一個個小模塊就是一個個微服務，將專業的事交給專業的模塊來做，比如一個大型專案可能有上百個微服務，講這些微服務集中起來構成一個大的系統，對外暴露服務進行呼叫與使用，
- 從技術角度看就是一種小而獨立的處理程序，類似行程概念，能夠自行單獨啟動或銷毀，擁有自己獨立的資料庫，
Spring Cloud 是什么？
Spring Cloud 是一組技術的集合，基于 Spring Boot 提供了一套微服務解決方案，包括服務注冊與發現、配置中心、全鏈路監控、服務網關、負載均衡、熔斷器等組件，除了基于 NetFlix 的開源組件做高度抽象封裝之外，還有一些選型中立的開源組件，
官方：構建分布式系統不用特別的復雜且避免容易出現的錯誤，Spring Cloud為最常見的分布式系統模式提供了一個簡單和可訪問的編程模式，幫助開發人員構建彈性、可靠和協調的應用程式，Spring Cloud 構建在 Spring Boot 之上，使開發人員很容易開始作業并迅速提高生產力，
Spring Boot 快速構建一個個微服務，多個微服務之間如何互通互調呢？
- 使用 Spring Cloud 進行管理協調服務間正常互聯互調，從而實作分布式微服務架構，
- 說明：
- Spring Cloud 使用 RESTful API 實作服務之間通信
- Dubbo 使用 RPC（遠程程序呼叫）實作服務之間通信
- Spring Cloud 包含21項技術
Spring Boot 和 Spring Cloud 的關系？
- Spring Boot 可以離開 Spring Cloud 單獨使用開發專案，但是 Spring Cloud 離不開 Spring Boot，屬于依賴的關系，
- Spring Boot 專注于快速方便的開發單個個體微服務，Spring Cloud 關注全域的服務治理框架，
- Spring Cloud 是關注全域的微服務協調治理框架，它將 Spring Boot 開發的一個個單體服務整合并管理起來，為各個微服務之間提供、配置管理、服務發現、斷路器、路由、微代理、事件總線、全域鎖、決策競選、分布式會話等等集成服務，
Spring Cloud 和 Spring Boot 的版本依賴關系？
| Could代號 | Boot版本 |
|---|---|
| Greenwich | 2.1.x |
| Finchley | 2.0.x |
| Edgware | 1.5.x |
| Dalston | 1.5.x |
最穩定版本：Finchley SR2，搭配 Spring Boot 2.0.7
GA：General Availability，正式發布的版本，官方推薦使用本版本，在國外都是用GA來說明 RELEASE 版本的，
PRE：預覽版，內部測驗版，主要是給開發人員和測驗人員找bug用的，不建議使用，
SNAPSHOT：快照版，可以穩定使用，且仍在繼續改進版本，
RestTemplate 組件是什么？
RestTemplate 是 Spring 提供的用于訪問 Rest 服務的客戶端模板工具集，提供了多種便捷訪問遠程 HTTP 服務的方法，簡化了與 HTTP 服務的通信，并滿足 RestFul 原則，程式代碼可以給它提供 URL，并提取結果，能夠大大提高客戶端的撰寫效率，
RestTemplate 和 HttpClient 的比較？
RestTemplate 和 HttpClient 都是處理 HTTP 客戶端工具，其中RestTemolate內部內置訊息轉化器，在一定程度上減少代碼開發，例如 MappingJackson2HttpMessageConverter 將 json 格式資料轉換為具體物件，如果使用 HttpClient，還需要手動將 json 資料轉換為具體物件，
系統會根據業務被拆分成很多的微服務，微服務的資訊如何管理？
Spring Cloud 中提供服務注冊中心來管理服務資訊，
輪詢演算法：向 Eureka Server 發送心跳（默認周期是30秒），服務端在多個心跳周期內沒有接受到某個節點的心跳，服務端就會從服務注冊中心吧這個服務節點洗掉（默認周期90秒），
為什么要用注冊中心？
微服務數量眾多，要進行遠程呼叫就需要知道服務端的 ip 地址和埠號，注冊中心幫助我們管理這些服務的 ip 和埠，
微服務會實時上報自己的狀態，注冊中心統一管理這些微服務的狀態，將存在問題的服務踢出服務串列，客戶端獲取到可用的服務進行調度，
Spring Cloud Eureka 是什么？
Spring Cloud Eureka 是對 Netflix 公司的 Eureka 的二次封裝，它實作了服務治理的功能，Spring Cloud Eureka 提供 Eureka Server 服務端與 Eureka Client 客戶端，服務端即是 Eureka 服務注冊中心，客戶端完成微服務向 Eureka 服務的注冊與發現，
客戶端同時具備一個內置的使用輪詢負載演算法的負載均衡器，在微服務啟動后，將會向 Eureka Server 發送心跳（默認周期是30秒），如果 Eureka Server 在多個心跳周期內沒有接受到某個節點的心跳，Eureka Server 將會從服務注冊表中吧這個服務節點移除（默認周期90秒），
Eureka Server 自我保護機制是什么？
當 Eureka Server 在一定時間內（默認90秒）沒有接受到某個微服務的心跳，Eureka Server 會從服務串列將此服務實體注銷，但是如果出現網路例外情況（微服務本身是正常的），微服務與 Eureka Server 之間無法正常通信，以上行為可能變的非常危險了，因為微服務本身其實是正常的，此時本不應該注銷這個微服務，
Eureka Server 有一種自我保護模式來解決這個問題，當 Eureka Server 在短時間內丟失過多客戶端是（可能發生了網路故障），此時 Eureka Server 會進入自我保護模式，一旦進入該模式，Eureka Server 就會保護服務注冊表的資訊，不在洗掉服務注冊表中的資料（也就是不會注銷任何微服務），當網路故障恢復后，該 Eureka Server 會自動退出自我保護模式，
所以，自我保護模式是一種應對網路例外的安全保護措施，它的架構哲學是寧可同時保留所有的微服務（健康的微服務和不健康的微服務都會保留），也不盲目注銷任何健康的微服務，使用自我保護模式，可以讓 Eureka 集群更加的健壯、穩定，
為什么搭建集群版 Eureka Server 服務注冊中心？
為了避免 Eureka Server 的失效， Eureka Server 高可用環境需要部署兩個及以上 Eureka Server，它們互相向對方注冊，微服務需要連接兩臺 Eureka Server 服務注冊中心，其中一臺 Eureka 死掉也不會影響服務的注冊與發現，
什么是服務端負載均衡？
服務端負載均衡是我們處理高并發、緩解網路壓力和進行服務端擴容的重要手段之一，簡單地說就是將用戶的請求平攤的分配到多個服務商，從而實作系統的高可用性集群，服務端負載均衡服務器為為兩種，一種是通過硬體實作的負載均衡服務器，簡稱硬負載例如：F5，一種是通過軟體來實作的負載均衡，簡稱軟負載例如：Apache 和 Nginx，應付在和軟負載相比前者作用的網路層次比較多可以作用到 Socket 介面的資料鏈路層對發出的請求進行分組轉發但是價格成本比較貴，而軟負載作用的層次在 HTTP 協議層之上可以對 HTTP 請求進行分組轉發并且因為是開源的所以幾乎是0成本，
無論是硬體負載均衡還是軟體負載均衡都會維護一份可用的服務端清單，然后通過心跳機制來洗掉故障的服務端節點以保證清單中都是可以正常訪問的服務端節點，此時當客戶端的請求到達負載均衡服務器時，負載均衡服務器按照某種配置好的規則（負載均衡演算法有：輪詢、隨機、加權輪詢、加權隨機、地址哈希等方法）從可用服務端清單中選出一臺服務器去處理客戶端的請求，所以負載均衡可以為微服務集群分擔請求，降低系統的壓力，
什么是客戶端負載均衡（Ribbon）？
Spring Cloud Ribbon 是基于 Netflix 公司發布的開源專案 Ribbon 進行封裝的一套客戶端負載均衡器，
Ribbon是一個基于HTTP和TCP的客戶端負載均衡器，當我們將Ribbon和Eureka一起使用時，Ribbon會從Eureka注冊中心去獲取服務端串列，然后進行輪詢訪問以到達負載均衡的作用，客戶端負載均衡中也需要心跳機制去維護服務端清單的有效性，當然這個程序需要配合服務注冊中心一起完成，
客戶端負載均衡和服務端負載均衡的區別？
客戶端負載均衡和服務端負載均衡最大的區別是服務清單所存盤的位置，在客戶端負載均衡中，每個客戶端服務都有一份自己要訪問的服務端清單，這些清單統統都是從 Eureka 服務注冊中心獲取的，而在服務端負載均衡中，只要負載均衡器維護一份服務端串列，
什么是 Feign？
Feign 是 Netflix 公司開源的輕量級 Rest 客戶端，使用 Feign 可以非常方便、簡單的實作 HTTP 客戶端，Spring Cloud 對 Feign 進行了封裝， Feign 默認繼承了 Ribbon 實作了客戶端負載均衡呼叫，
微服務間有哪些呼叫方式？
- 通過微服務名稱，獲得服務的呼叫地址，
- 通過介面+注解，獲得服務的呼叫
Feign 作業原理是什么？
Feign 通過介面的方法呼叫Rest服務，請求發送給 Eureka 服務器，通過 Feign 直接找到服務介面，因為繼承了 Ribbon 技術，Feign 自帶負載均衡配置功能，
- 啟動類添加@EnableFeignClients注解，Spring會掃描標記了@FeignClient注解的介面，并生成此介面的代理物件，
- @FeignClient("服務名稱 ") 即指定了 product 服務名稱，Feign會從Eureka注冊中心獲取 product 服務串列， 并通過負載均衡演算法進行服務呼叫，
- 在介面方法中使用注解 @RequestMapping(value = “/product/list”,method = RequestMethod.GET)，指定呼叫的url，Feign 會根據url進行遠程呼叫，
Feign 注意事項？
SpringCloud對Feign進行了增強兼容了SpringMVC的注解 ，我們在使用SpringMVC的注解時需要注意：
- @FeignClient介面方法有基本型別引數在引數必須加@PathVariable(“XXX”) 或 @RequestParam(“XXX”)，
- @FeignClient介面方法回傳值為復雜物件時，此型別必須有無參構造方法，
什么是 Hystrix？
Hystrix 是 Netflix 公司開源專案，實作了熔斷器模型，Spring Cloud 對這一組件進行了整合，
為什么使用 Hystrix？
在微服務架構中，根據業務來拆分成一個個的服務，而服務于服務之間存在著依賴關系（比如用戶調商品、商品調庫存、庫存調訂單等等），在 Spring Cloud 中多個微服務之間可以用 RestTemplate + Ribbon 和 Fegin 來呼叫，
在服務之間呼叫的鏈路上由于網路原因、資源繁忙或者自身的原因，服務并不能保證100%可用，如果單個服務出現問題，呼叫這個服務就會出現執行緒阻塞，導致回應時間過長或不可用，此時若有大量的請求涌入，容器的執行緒資源會被消耗完畢，導致服務癱瘓，服務與服務之間的依賴性，故障會傳播，會對整個微服務系統造成災難性的后果，這就是服務故障的“雪崩”效應，為了解決這個問題，業界踢出了熔斷器模型，
什么是服務熔斷？
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制，在微服務中，衣蛾請求需要呼叫多個服務是非常常見的，
當服務之間呼叫的鏈路上某個微服務不可用或者回應時間太長時，會導致連鎖故障，當失敗的呼叫帶一定閾值（預設是5秒內20次呼叫失敗）就會啟動熔斷機制，在 Spring Cloud 框架里熔斷機制通過 Hystrix 實作，Hystrix 會監控微服務間呼叫的狀況，熔斷器打開后，可用避免連鎖故障 fallback 方法可以直接回傳一個固定值，
什么是服務監控？
除了隔離依賴服務的呼叫以外，Hystrix 還提供了準實時的呼叫監控（Hystrix Dashboard），Hystrix 會持續地記錄所有通過 Hystrix 發起的請求的執行資訊，并以統計報表和圖形的形式展示給用戶，包括美妙執行多少請求多少成功，多少失敗等，
Netflflix 通過 hystrix-metrics-event-stream 專案實作了對以上指標的監控，Spring Cloud也提供了 Hystrix Dashboard 的整合，對監控內容轉化成可視化界面，
什么是 Zuul？
Zuul 是 Netflix 公司開源專案，Zuul 包含了對請求路由和校檢過濾兩個最主要的功能：
- 其中路由功能負責將外部請求轉發到具體的微服務實力上，是實作外部訪問統一入口的基礎，
- 而過濾功能則負責對請求的處理程序進行干預，是實作請求校驗等功能的基礎，
Zuul 和 Eureka 進行整合，將 Zuul 自身注冊為 Eureka 服務治理中的服務，同時從 Eureka中獲得其他微服務的訊息，也即以后的訪問微服務都是通過 Zuul 跳轉后獲得，注意：Zuul 服務最侄訓是會注冊進 Eureka，
如何自定義 Zuul 過濾器？
自定義過濾器需要繼承 ZuulFilter，ZuulFilter是一個抽象類，需要覆寫它的4個方法：
- filterType：回傳字串代表過濾器的型別，回傳值有：
- pre：在請求路由之前執行 route：在請求路由時呼叫
- post：請求路由之后呼叫，也就是在 route 和 error 過濾器之后呼叫
- error：處理請求發生錯誤時呼叫
- filterOrder：此方法回傳整形數值，通過此數值來定義過濾器的執行順序，數字越小優先級越高，
- shouldFilter：回傳 Boolean 值，判斷該過濾器是否執行，回傳 true 表示要執行此過濾器，false 不執行，
- run：過濾器的業務邏輯，
分布式架構的問題有哪些？
在分布式微服務架構中，由于服務數量很多，使得有很多組態檔，在更新組態檔時很麻煩，我們每個微服務自己帶著一個 application.yml，上百個組態檔的管理起來就很麻煩，所以一套集中地、動態的配置管理功能是必不可少的，在 Spring Cloud 中，有分布式配置中心組件 Spring Cloud Config 來解決這個問題，
什么是 Spring Cloud Config ？
Spring Cloud Config 為微服務架構中的微服務提供集中式的外部配置支持，配置服務器為各個不同微服務應用的所有環境提供了一個中心化的外部配置，
Spring Cloud Config 分為服務端與客戶端兩個部分：
服務端 config server：也稱為分布式配置中心，它是一個獨立的微服務應用，用來連接配置服務器并為客戶端提供獲取配置資訊，加密、解密資訊等訪問介面，配置服務器官方推薦采用 Git 來存盤配置資訊，這樣就有助于對環境配置進行版本管理，并且可通過 Git 客戶端工具來方便的管理與訪問配置資訊，
客戶端 config client：通過制定的服務端來管理服務的資源，以及與業務相關的配置內容，并在啟動的時候從服務器端獲取和加載配置資訊，
使用 Spring Cloud Config 的作用？
- 集中管理組態檔，
- 不同環境不同配置，動態化的配置更新，根據不同環境部署，如 dev/test/prod，
- 運行期間動態調整配置，不需要再每個服務部署的機器上撰寫配置，服務輝會向配置中心統一拉取自己的配置資訊，
- 當配置發生變動時，服務不需要重啟即可感知到配置的變化并使用修改后的配置資訊將配置資訊以REST介面的方式暴露，
bootstrap.yml 是什么？
application.yml 是用戶級別的配置項，bootstrap.xml 是系統級別的配置項，優先級更高
Spring Cloud 會創建一個 Bootstrap Context，Bootstrap Context 會負責從外部資源加載配置屬性并決議配置；Bootstrap 屬性有高優先級，默認情況下，它們不會被本地配置覆寫，
Spring Cloud Bus解決的問題？
當我們更新 Github 中的組態檔內容后，Config客戶端服務是否會及時更新的配置內容呢？
如果希望在不重啟微服務的情況下更新配置如何來實作呢？我們是用 Spring Cloud Bus 來實作配置的自動更新，
Spring Cloud Bus 的使用機制？
Spring Cloud Bus 被國內很多都翻譯為訊息總線，大家可以把它理解為管理和傳播所有分布式專案中的訊息即可，其實本質是利用了 MQ 的廣播機制在分布式的系統中傳播訊息，目前常用的有 Kafka 和 RabbitMQ，利用 Bus 的機制可以做很多的事情，其中配置中心客戶端重繪就是典型的應用場景之一，Spring Cloud Bus 做配置跟新的步驟：
- 提交配置后發送 POST 方式的 /bus-refresh 請求給 Config 客戶端，
- Config 客戶端接收到請求從 Server 端更新配置并且發送訊息給訊息總線，
- 訊息總線街道訊息并通知給其他客戶端，
- 其他客戶端接收到通知，請求 Server 端獲取最新配置，
- 全部客戶端均獲取到最新的配置，
什么是 Postman？
Postman 是款強大網頁除錯的 windows 客戶端工具，提供功能強大的 Web API & HTTP 請求除錯，軟體功能非常強大，界面簡潔明晰、操作方便快捷，設計得很人性化，Postman 中文版能夠發送任何型別的 HTTP 請求（GET、DELETE、POST、PUT…），附帶任何數量的請求引數，
非常感謝您的閱讀！如果文章有書寫錯誤或不清楚的地方，希望您評論指出，我將第一時間改正，如果您喜歡這篇文章的話，請你點贊和評論，如果您還能點擊收藏，那就是對我最大的鼓勵！
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/243985.html
標籤：其他