20道你必须要背会的微服务面试题，面试一定会被问到
寫在前面： 我是「揚帆向海」，這個昵稱來源于我的名字以及女朋友的名字。我熱愛技術(shù)、熱愛開源、熱愛編程。技術(shù)是開源的、知識是共享的。
這博客是對自己學習的一點點總結(jié)及記錄，如果您對 Java、算法 感興趣，可以關(guān)注我的動態(tài)，我們一起學習。
用知識改變命運，讓我們的家人過上更好的生活。
在學習springcloud之前大家一定要先了解下，常見的面試題有那塊，然后我們帶著問題去學習這個微服務技術(shù)，那么就會更加理解springcloud技術(shù)。如果你已經(jīng)學了springcloud，那么在準備面試的時候，一定要看看看這些面試題。
相關(guān)文章：
Springboot 系列文章
【Java基礎】易錯面試題，初級程序員面試必看
文章目錄
- 1、什么是微服務？
- 2、微服務之間是如何通訊的？
- 3、springcloud 與dubbo有哪些區(qū)別？
- 4、請談談對SpringBoot 和SpringCloud的理解
- 5、分布式系統(tǒng)面臨的問題
- 6、什么是服務熔斷，什么是服務降級
- 7、微服務的優(yōu)缺點分別是什么？說下你在項目開發(fā)中碰到的坑？
- 8、你所知道的微服務技術(shù)棧有哪些？請列舉一二
- 9、什么是 Eureka服務注冊與發(fā)現(xiàn)
- 10、Eureka的基本架構(gòu)是什么？
- 11、作為服務注冊中心，Eureka比Zookeeper好在哪里?
- 12、什么是 Ribbon負載均衡
- 13、Ribbon負載均衡能干嘛？
- 14、什么是 Feign 負載均衡
- 15、Feign 能干什么
- 16、什么是 Hystrix斷路器
- 17、Hystrix斷路器能干嘛？
- 18、什么是 zuul路由網(wǎng)關(guān)
- 19、什么是SpringCloud Config分布式配置中心
- 20、分布式配置中心能干嘛？
1、什么是微服務？
微服務架構(gòu)是一種架構(gòu)模式或者說是一種架構(gòu)風格，它提倡將單一應用程序劃分成一組小的服務，每個服務運行在其獨立的自己的進程中，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。 服務之間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTful API）。每個服務都圍繞著具體業(yè)務進行構(gòu)建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應盡量避免統(tǒng)一的、集中式的服務管理機制，對具體的一個服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構(gòu)建，可以有一個非常輕量級的集中式管理來協(xié)調(diào)這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數(shù)據(jù)存儲。
從技術(shù)維度來說：
微服務化的核心就是將傳統(tǒng)的一站式應用，根據(jù)業(yè)務拆分成一個一個的服務，徹底地去耦合,每一個微服務提供單個業(yè)務功能的服務，一個服務做一件事，從技術(shù)角度看就是一種小而獨立的處理過程，類似進程概念，能夠自行單獨啟動或銷毀，擁有自己獨立的數(shù)據(jù)庫。
2、微服務之間是如何通訊的？
① 遠程過程調(diào)用（Remote Procedure Invocation）
直接通過遠程過程調(diào)用來訪問別的service。
示例：REST、gRPC、Apache、Thrift
優(yōu)點：
簡單，常見。因為沒有中間件代理，系統(tǒng)更簡單
缺點：
只支持請求/響應的模式，不支持別的，比如通知、請求/異步響應、發(fā)布/訂閱、發(fā)布/異步響應
降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的
② 消息
使用異步消息來做服務間通信。服務間通過消息管道來交換消息，從而通信。
示例：Apache Kafka、RabbitMQ
優(yōu)點:
- 把客戶端和服務端解耦，更松耦合 提高可用性，因為消息中間件緩存了消息，直到消費者可以消費
- 支持很多通信機制比如通知、請求/異步響應、發(fā)布/訂閱、發(fā)布/異步響應
缺點:
消息中間件有額外的復雜性
3、springcloud 與dubbo有哪些區(qū)別？
相同點：
SpringCloud 和Dubbo可以實現(xiàn)RPC遠程調(diào)用框架，可以實現(xiàn)服務治理。
不同點:
SpringCloud是一套目前比較網(wǎng)站微服務框架了，整合了分布式常用解決方案遇到了問題注冊中心Eureka、負載均衡器Ribbon ，客戶端調(diào)用工具Rest和Feign，分布式配置中心Config，服務保護Hystrix，網(wǎng)關(guān)Zuul Gateway ，服務鏈路Zipkin，消息總線Bus等。
Dubbo內(nèi)部實現(xiàn)功能沒有SpringCloud強大（全家桶），只是實現(xiàn)服務治理，缺少分布式配置中心、網(wǎng)關(guān)、鏈路、總線等，如果需要用到這些組件，需要整合其他框架。
| 服務注冊中心 | ZooKeeper | Spring Cloud Netflix Eureka、ZooKeeper |
| 服務調(diào)用方式 | RPC | REST API |
| 服務網(wǎng)關(guān) | 無 | Spring Cloud Netflix Zuul |
| 斷路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 分布式配置 | 無 | Spring Cloud Config |
| 服務跟蹤 | 無 | Spring Cloud Sleuth |
| 消息總線 | 無 | Spring Cloud Bus |
| 數(shù)據(jù)流 | 無 | Spring Cloud Stream |
| 批量任務 | 無 | Spring Cloud Task |
4、請談談對SpringBoot 和SpringCloud的理解
① SpringBoot專注于快速方便的開發(fā)單個個體微服務。
② SpringCloud是關(guān)注全局的微服務協(xié)調(diào)整理治理框架，它將SpringBoot開發(fā)的一個個單體微服務整合并管理起來，
為各個微服務之間提供，配置管理、服務發(fā)現(xiàn)、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等集成服務
③ SpringBoot可以離開SpringCloud獨立使用開發(fā)項目，但是SpringCloud離不開SpringBoot，屬于依賴的關(guān)系.
④ SpringBoot專注于快速、方便的開發(fā)單個微服務個體，SpringCloud關(guān)注全局的服務治理框架。
Spring Boot可以離開Spring Cloud獨立使用開發(fā)項目，但是Spring Cloud離不開Spring Boot，屬于依賴的關(guān)系。
5、分布式系統(tǒng)面臨的問題
復雜分布式體系結(jié)構(gòu)中的應用程序有數(shù)十個依賴關(guān)系，每個依賴關(guān)系在某些時候?qū)⒉豢杀苊獾厥 ?/p>
-
服務雪崩
多個微服務之間調(diào)用的時候，假設微服務A調(diào)用微服務B和微服務C，微服務B和微服務C又調(diào)用其它的微服務，這就是所謂的“扇出”。如果扇出的鏈路上某個微服務的調(diào)用響應時間過長或者不可用，對微服務A的調(diào)用就會占用越來越多的系統(tǒng)資源，進而引起系統(tǒng)崩潰，所謂的“雪崩效應”. -
對于高流量的應用來說，單一的后端依賴可能會導致所有服務器上的所有資源都在幾秒鐘內(nèi)飽和。比失敗更糟糕的是，這些應用程序還可能導致服務之間的延遲增加，備份隊列，線程和其他系統(tǒng)資源緊張，導致整個系統(tǒng)發(fā)生更多的級聯(lián)故障。這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關(guān)系的失敗，不能取消整個應用程序或系統(tǒng)。
一般情況對于服務依賴的保護主要有以下三種解決方案：
① 熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統(tǒng)中，如果某個目標服務調(diào)用慢或者有大量超時，此時，熔斷該服務的調(diào)用，對于后續(xù)調(diào)用請求，不在繼續(xù)調(diào)用目標服務，直接返回，快速釋放資源。如果目標服務情況好轉(zhuǎn)則恢復調(diào)用。
② 隔離模式：這種模式就像對系統(tǒng)請求按類型劃分成一個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同類型的請求使用線程池來資源隔離，每種類型的請求互不影響，如果一種類型的請求線程資源耗盡，則對后續(xù)的該類型請求直接返回，不再調(diào)用后續(xù)資源。這種模式使用場景非常多，例如將一個服務拆開，對于重要的服務使用單獨服務器來部署，再或者公司最近推廣的多中心。
③ 限流模式：上述的熔斷模式和隔離模式都屬于出錯后的容錯處理機制，而限流模式則可以稱為預防模式。限流模式主要是提前對各個類型的請求設置最高的QPS閾值，若高于設置的閾值則對該請求直接返回，不再調(diào)用后續(xù)資源。這種模式不能解決服務依賴的問題，只能解決系統(tǒng)整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應。
6、什么是服務熔斷，什么是服務降級
服務熔斷
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。
當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節(jié)點微服務的調(diào)用，快速返回"錯誤"的響應信息。當檢測到該節(jié)點微服務調(diào)用響應正常后恢復調(diào)用鏈路。在SpringCloud框架里熔斷機制通過Hystrix實現(xiàn)。Hystrix會監(jiān)控微服務間調(diào)用的狀況，當失敗的調(diào)用到一定閾值，缺省是5秒內(nèi)20次調(diào)用失敗就會啟動熔斷機制。熔斷機制的注解是@HystrixCommand。
Hystrix服務降級
其實就是線程池中單個線程障處理，防止單個線程請求時間太長，導致資源長期被占有而得不到釋放，從而導致線程池被快速占用完，導致服務崩潰。
Hystrix能解決如下問題：
① 請求超時降級，線程資源不足降級，降級之后可以返回自定義數(shù)據(jù)
② 線程池隔離降級，分布式服務可以針對不同的服務使用不同的線程池，從而互不影響
③ 自動觸發(fā)降級與恢復
④ 實現(xiàn)請求緩存和請求合并
7、微服務的優(yōu)缺點分別是什么？說下你在項目開發(fā)中碰到的坑？
優(yōu)點
- 每個服務足夠內(nèi)聚，足夠小，代碼容易理解這樣能聚焦一個指定的業(yè)務功能或業(yè)務需求
- 開發(fā)簡單、開發(fā)效率提高，一個服務可能就是專一的只干一件事。
- 微服務能夠被小團隊單獨開發(fā)，這個小團隊是2到5人的開發(fā)人員組成。
- 微服務是松耦合的，是有功能意義的服務，無論是在開發(fā)階段或部署階段都是獨立的。
- 微服務能使用不同的語言開發(fā)。
- 易于和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續(xù)集成工具，如Jenkins, Hudson, bamboo 。
- 微服務易于被一個開發(fā)人員理解，修改和維護，這樣小團隊能夠更關(guān)注自己的工作成果。無需通過合作才能體現(xiàn)價值。
- 微服務允許你利用融合最新技術(shù)。
- 微服務只是業(yè)務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。
- 每個微服務都有自己的存儲能力，可以有自己的數(shù)據(jù)庫。也可以有統(tǒng)一數(shù)據(jù)庫。
缺點
- 開發(fā)人員要處理分布式系統(tǒng)的復雜性
- 多服務運維難度，隨著服務的增加，運維的壓力也在增大
- 系統(tǒng)部署依賴
- 服務間通信成本
- 數(shù)據(jù)一致性
- 系統(tǒng)集成測試
- 性能監(jiān)控……
8、你所知道的微服務技術(shù)棧有哪些？請列舉一二
- 服務開發(fā)
Springboot、Spring、SpringMVC - 服務配置與管理
Netflix公司的Archaius、阿里的Diamond等 - 服務注冊與發(fā)現(xiàn)
Eureka、Consul、Zookeeper等 - 服務調(diào)用
Rest、RPC、gRPC - 服務熔斷器
Hystrix、Envoy等 - 負載均衡
Ribbon、Nginx等 - 服務接口調(diào)用(客戶端調(diào)用服務的簡化工具)
Feign等 - 消息隊列
Kafka、RabbitMQ、ActiveMQ等 - 服務配置中心管理
SpringCloudConfig、Chef等 - 服務路由（API網(wǎng)關(guān)）
Zuul等 - 服務監(jiān)控
Zabbix、Nagios、Metrics、Spectator等 - 全鏈路追蹤
Zipkin，Brave、Dapper等 - 服務部署
Docker、OpenStack、Kubernetes等 - 數(shù)據(jù)流操作開發(fā)包
SpringCloud Stream（封裝與Redis,Rabbit、Kafka等發(fā)送接收消息） - 事件消息總線
Spring Cloud Bus
9、什么是 Eureka服務注冊與發(fā)現(xiàn)
Eureka是Netflix的一個子模塊，也是核心模塊之一。Eureka是一個基于REST的服務，用于定位服務，以實現(xiàn)云端中間層服務發(fā)現(xiàn)和故障轉(zhuǎn)移。服務注冊與發(fā)現(xiàn)對于微服務架構(gòu)來說是非常重要的，有了服務發(fā)現(xiàn)與注冊，只需要使用服務的標識符，就可以訪問到服務，而不需要修改服務調(diào)用的配置文件了。功能類似于dubbo的注冊中心，比如Zookeeper。
10、Eureka的基本架構(gòu)是什么？
Spring Cloud 封裝了 Netflix 公司開發(fā)的 Eureka 模塊來實現(xiàn)服務注冊和發(fā)現(xiàn)(請對比Zookeeper)。
Eureka 采用了 C-S 的設計架構(gòu)。Eureka Server 作為服務注冊功能的服務器，它是服務注冊中心。
而系統(tǒng)中的其他微服務，使用 Eureka 的客戶端連接到 Eureka Server并維持心跳連接。這樣系統(tǒng)的維護人員就可以通過 Eureka Server 來監(jiān)控系統(tǒng)中各個微服務是否正常運行。SpringCloud 的一些其他模塊（比如Zuul）就可以通過 Eureka Server 來發(fā)現(xiàn)系統(tǒng)中的其他微服務，并執(zhí)行相關(guān)的邏輯。
Eureka包含兩個組件： Eureka Server 和 Eureka Client
Eureka Server提供服務注冊服務
各個節(jié)點啟動后，會在EurekaServer中進行注冊，這樣EurekaServer中的服務注冊表中將會存儲所有可用服務節(jié)點的信息，服務節(jié)點的信息可以在界面中直觀的看到
EurekaClient是一個Java客戶端
用于簡化Eureka Server的交互，客戶端同時也具備一個內(nèi)置的、使用輪詢(round-robin)負載算法的負載均衡器。在應用啟動后，將會向Eureka Server發(fā)送心跳(默認周期為30秒)。如果Eureka Server在多個心跳周期內(nèi)沒有接收到某個節(jié)點的心跳，EurekaServer將會從服務注冊表中把這個服務節(jié)點移除（默認90秒）
11、作為服務注冊中心，Eureka比Zookeeper好在哪里?
著名的CAP理論指出，一個分布式系統(tǒng)不可能同時滿足C(一致性)、A(可用性)和P(分區(qū)容錯性)。由于分區(qū)容錯性P在是分布式系統(tǒng)中必須要保證的，因此我們只能在A和C之間進行權(quán)衡。
因此，Zookeeper 保證的是CP, Eureka 則是AP。
Zookeeper保證CP
當向注冊中心查詢服務列表時，我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高于一致性。但是zk會出現(xiàn)這樣一種情況，當master節(jié)點因為網(wǎng)絡故障與其他節(jié)點失去聯(lián)系時，剩余節(jié)點會重新進行l(wèi)eader選舉。問題在于，選舉leader的時間太長，30~120s,且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。在云部署的環(huán)境下，因網(wǎng)絡問題使得zk集群失去master節(jié)點是較大概率會發(fā)生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。
Eureka保證AP
Eureka看明白了這一點，因此在設計時就優(yōu)先保證可用性。Eureka各個節(jié)點都是平等的，幾個節(jié)點掛掉不會影響正常節(jié)點的工作，剩余的節(jié)點依然可以提供注冊和查詢服務。而Eureka的客戶端在向某個Eureka注冊或時如果發(fā)現(xiàn)連接失敗，則會自動切換至其它節(jié)點，只要有一臺Eureka還在，就能保證注冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。
除此之外，Eureka還有一種自我保護機制，如果在15分鐘內(nèi)超過85%的節(jié)點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現(xiàn)了網(wǎng)絡故障，此時會出現(xiàn)以下幾種情況：
因此， Eureka可以很好的應對因網(wǎng)絡故障導致部分節(jié)點失去聯(lián)系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。
12、什么是 Ribbon負載均衡
Spring Cloud Ribbon是基于Netflix Ribbon實現(xiàn)的一套客戶端 負載均衡的工具。
簡單的說，Ribbon是Netflix發(fā)布的開源項目，主要功能是提供客戶端的軟件負載均衡算法，將Netflix的中間層服務連接在一起。Ribbon客戶端組件提供一系列完善的配置項如連接超時，重試等。簡單的說，就是在配置文件中列出Load Balancer（簡稱LB）后面所有的機器，Ribbon會自動的幫助你基于某種規(guī)則（如簡單輪詢，隨機連接等）去連接這些機器。我們也很容易使用Ribbon實現(xiàn)自定義的負載均衡算法。
13、Ribbon負載均衡能干嘛？
-
LB（負載均衡)
LB，即負載均衡(Load Balance)，在微服務或分布式集群中經(jīng)常用的一種應用。
負載均衡簡單的說就是將用戶的請求平攤的分配到多個服務上，從而達到系統(tǒng)的HA。
常見的負載均衡有軟件Nginx，LVS，硬件 F5等。
相應的在中間件，例如：dubbo和SpringCloud中均給我們提供了負載均衡，SpringCloud的負載均衡算法可以自定義。 -
集中式LB
即在服務的消費方和提供方之間使用獨立的LB設施(可以是硬件，如F5, 也可以是軟件，如nginx), 由該設施負責把訪問請求通過某種策略轉(zhuǎn)發(fā)至服務的提供方； -
進程內(nèi)LB
將LB邏輯集成到消費方，消費方從服務注冊中心獲知有哪些地址可用，然后自己再從這些地址中選擇出一個合適的服務器。
注意： Ribbon就屬于進程內(nèi)LB，它只是一個類庫，集成于消費方進程，消費方通過它來獲取到服務提供方的地址。
14、什么是 Feign 負載均衡
Feign是一個聲明式WebService客戶端。使用Feign能讓編寫Web Service客戶端更加簡單, 它的使用方法是定義一個接口，然后在上面添加注解，同時也支持JAX-RS標準的注解。Feign也支持可拔插式的編碼器和解碼器。Spring Cloud對Feign進行了封裝，使其支持了Spring MVC標準注解和HttpMessageConverters。 Feign可以與Eureka和Ribbon組合使用以支持負載均衡。
Feign是一個聲明式的Web服務客戶端，使得編寫Web服務客戶端變得非常容易，只需要創(chuàng)建一個接口，然后在上面添加注解即可。
15、Feign 能干什么
Feign旨在使編寫Java Http客戶端變得更容易。
前面在使用Ribbon+RestTemplate時，利用RestTemplate對http請求的封裝處理，形成了一套模版化的調(diào)用方法。但是在實際開發(fā)中，由于對服務依賴的調(diào)用可能不止一處，往往一個接口會被多處調(diào)用，所以通常都會針對每個微服務自行封裝一些客戶端類來包裝這些依賴服務的調(diào)用。所以，Feign在此基礎上做了進一步封裝，由他來幫助我們定義和實現(xiàn)依賴服務接口的定義。在Feign的實現(xiàn)下，我們只需創(chuàng)建一個接口并使用注解的方式來配置它(以前是Dao接口上面標注Mapper注解,現(xiàn)在是一個微服務接口上面標注一個Feign注解即可)，即可完成對服務提供方的接口綁定，簡化了使用Spring cloud Ribbon時，自動封裝服務調(diào)用客戶端的開發(fā)量。
Feign集成了Ribbon
利用Ribbon維護了MicroServiceCloud-Dept的服務列表信息，并且通過輪詢實現(xiàn)了客戶端的負載均衡。而與Ribbon不同的是，通過feign只需要定義服務綁定接口且以聲明式的方法，優(yōu)雅而簡單的實現(xiàn)了服務調(diào)用
Feign通過接口的方法調(diào)用Rest服務（之前是Ribbon+RestTemplate），該請求發(fā)送給Eureka服務器（http://MICROSERVICECLOUD-DEPT/dept/list）,
通過Feign直接找到服務接口，由于在進行服務調(diào)用的時候融合了Ribbon技術(shù)，所以也支持負載均衡作用。
16、什么是 Hystrix斷路器
Hystrix是一個用于處理分布式系統(tǒng)的延遲和容錯的開源庫，在分布式系統(tǒng)里，許多依賴不可避免的會調(diào)用失敗，比如超時、異常等， Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯(lián)故障，以提高分布式系統(tǒng)的彈性。
“斷路器”本身是一種開關(guān)裝置，當某個服務單元發(fā)生故障之后，通過斷路器的故障監(jiān)控（類似熔斷保險絲），向調(diào)用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調(diào)用方無法處理的異常，這樣就保證了服務調(diào)用方的線程不會被長時間、不必要地占用，從而避免了故障在分布式系統(tǒng)中的蔓延，乃至雪崩。
17、Hystrix斷路器能干嘛？
① 服務降級
整體資源快不夠了，忍痛將某些服務先關(guān)掉，待渡過難關(guān)，再開啟回來
② 服務熔斷
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。
當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節(jié)點微服務的調(diào)用，快速返回"錯誤"的響應信息。當檢測到該節(jié)點微服務調(diào)用響應正常后恢復調(diào)用鏈路。在SpringCloud框架里熔斷機制通過Hystrix實現(xiàn)。Hystrix會監(jiān)控微服務間調(diào)用的狀況，當失敗的調(diào)用到一定閾值，缺省是5秒內(nèi)20次調(diào)用失敗就會啟動熔斷機制。熔斷機制的注解是@HystrixCommand。
③ 服務限流
④ 接近實時的監(jiān)控
除了隔離依賴服務的調(diào)用以外，Hystrix還提供了準實時的調(diào)用監(jiān)控（Hystrix
Dashboard），Hystrix會持續(xù)地記錄所有通過Hystrix發(fā)起的請求的執(zhí)行信息，并以統(tǒng)計報表和圖形的形式展示給用戶，包括每秒執(zhí)行多少請求多少成功，多少失敗等。Netflix通過hystrix-metrics-event-stream項目實現(xiàn)了對以上指標的監(jiān)控。Spring
Cloud也提供了Hystrix Dashboard的整合，對監(jiān)控內(nèi)容轉(zhuǎn)化成可視化界面。
18、什么是 zuul路由網(wǎng)關(guān)
Zuul 包含了對請求的路由和過濾兩個最主要的功能：
其中路由功能負責將外部請求轉(zhuǎn)發(fā)到具體的微服務實例上，是實現(xiàn)外部訪問統(tǒng)一入口的基礎而過濾器功能則負責對請求的處理過程進行干預，是實現(xiàn)請求校驗、服務聚合等功能的基礎.Zuul和Eureka進行整合，將Zuul自身注冊為Eureka服務治理下的應用，同時從Eureka中獲得其他微服務的消息，也即以后的訪問微服務都是通過Zuul跳轉(zhuǎn)后獲得。
注意： Zuul服務最終還是會注冊進Eureka
提供=代理+路由+過濾 三大功能
19、什么是SpringCloud Config分布式配置中心
SpringCloud Config為微服務架構(gòu)中的微服務提供集中化的外部配置支持，配置服務器為各個不同微服務應用的所有環(huán)境提供了一個中心化的外部配置。
20、分布式配置中心能干嘛？
① 集中管理配置文件，不同環(huán)境不同配置，動態(tài)化的配置更新，分環(huán)境部署比如dev/test/prod/beta/release
② 運行期間動態(tài)調(diào)整配置，不再需要在每個服務部署的機器上編寫配置文件，服務會向配置中心統(tǒng)一拉取配置自己的信息
③ 當配置發(fā)生變動時，服務不需要重啟==即可感知到配置的變化并應用新的配置將配置信息以REST接口的形式暴露
由于水平有限，本博客難免有不足，懇請各位大佬不吝賜教！
總結(jié)
以上是生活随笔為你收集整理的20道你必须要背会的微服务面试题，面试一定会被问到的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： k2p华硕系统怎么设置_双频路由器怎么设
- 下一篇： 分层架构