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功能對比
| 功能名稱 | Dubbo | Spring Cloud |
|---|---|---|
| 服務註冊中心 | ZooKeeper | Spring Cloud Netflix Eureka |
| 服務調用方式 | RPC | REST API |
| 服務網關 | 無 | Spring Cloud Netflix Zuul |
| 斷路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 分佈式配置 | 無 | Spring Cloud Config |
| 服務跟蹤 | 無 | Spring Cloud Sleuth |
| 消息總線 | 無 | Spring Cloud Bus |
| 數據流 | 無 | Spring Cloud Stream |
| 批量任務 | 無 | Spring Cloud Task |
4、請談談對SpringBoot 和SpringCloud的理解
SpringBoot專注於快速方便的開發單個個體微服務。
SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務
SpringBoot可以離開SpringCloud獨立使用開發項目，但是SpringCloud離不開SpringBoot，屬於依賴的關係.
SpringBoot專注於快速、方便的開發單個微服務個體，SpringCloud關注全局的服務治理框架。
Spring Boot可以離開Spring Cloud獨立使用開發項目，但是Spring Cloud離不開Spring Boot，屬於依賴的關係。
5、分佈式系統面臨的問題
複雜分佈式體系結構中的應用程序有數十個依賴關係，每個依賴關係在某些時候將不可避免地失敗。
服務雪崩
多個微服務之間調用的時候，假設微服務A調用微服務B和微服務C，微服務B和微服務C又調用其它的微服務，這就是所謂的“扇出”。
如果扇出的鏈路上某個微服務的調用響應時間過長或者不可用，對微服務A的調用就會佔用越來越多的系統資源，進而引起系統崩潰，所謂的“雪崩效應”.
對於高流量的應用來說，單一的後端依賴可能會導致所有服務器上的所有資源都在幾秒鐘內飽和。
比失敗更糟糕的是，這些應用程序還可能導致服務之間的延遲增加，備份隊列，線程和其他系統資源緊張，導致整個系統發生更多的級聯故障。
這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關係的失敗，不能取消整個應用程序或系統。
一般情況對於服務依賴的保護主要有以下三種解決方案：
熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。
放到我們的系統中，如果某個目標服務調用慢或者有大量超時，此時，熔斷該服務的調用，對於後續調用請求，不在繼續調用目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復調用。
隔離模式：這種模式就像對系統請求按類型劃分成一個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。
例如可以對不同類型的請求使用線程池來資源隔離，每種類型的請求互不影響，如果一種類型的請求線程資源耗盡，則對後續的該類型請求直接返回，不再調用後續資源。
這種模式使用場景非常多，例如將一個服務拆開，對於重要的服務使用單獨服務器來部署，再或者公司最近推廣的多中心。
限流模式：上述的熔斷模式和隔離模式都屬於出錯後的容錯處理機制，而限流模式則可以稱爲預防模式。
限流模式主要是提前對各個類型的請求設置最高的QPS閾值，若高於設置的閾值則對該請求直接返回，不再調用後續資源。
這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因爲沒有被限流的請求依然有可能造成雪崩效應。
6、什麼是服務熔斷，什麼是服務降級
服務熔斷：熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。
當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的調用，快速返回”錯誤”的響應信息。
當檢測到該節點微服務調用響應正常後恢復調用鏈路。在SpringCloud框架裏熔斷機制通過Hystrix實現。
Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內20次調用失敗就會啓動熔斷機制。
熔斷機制的註解是@HystrixCommand。
Hystrix服務降級
其實就是線程池中單個線程障處理，防止單個線程請求時間太長，導致資源長期被佔有而得不到釋放，從而導致線程池被快速佔用完，導致服務崩潰。
Hystrix能解決如下問題：
請求超時降級，線程資源不足降級，降級之後可以返回自定義數據
線程池隔離降級，分佈式服務可以針對不同的服務使用不同的線程池，從而互不影響
自動觸發降級與恢復
實現請求緩存和請求合併
7、微服務的優缺點分別是什麼？說下你在項目開發中碰到的坑？
優點
每個服務足夠內聚，足夠小，代碼容易理解這樣能聚焦一個指定的業務功能或業務需求
開發簡單、開發效率提高，一個服務可能就是專一的只幹一件事。
微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
微服務能使用不同的語言開發。
易於和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins, Hudson, bamboo 。
微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值。
微服務允許你利用融合最新技術。
微服務只是業務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。
每個微服務都有自己的存儲能力，可以有自己的數據庫。也可以有統一數據庫。
缺點
開發人員要處理分佈式系統的複雜性
多服務運維難度，隨着服務的增加，運維的壓力也在增大
系統部署依賴
服務間通信成本
數據一致性
系統集成測試
性能監控……
8、你所知道的微服務技術棧有哪些？請列舉一二
服務開發：Springboot、Spring、SpringMVC
服務配置與管理：Netflix公司的Archaius、阿里的Diamond等
服務註冊與發現：Eureka、Consul、Zookeeper等
服務調用：Rest、RPC、gRPC
服務熔斷器：Hystrix、Envoy等
負載均衡：Ribbon、Nginx等
服務接口調用(客戶端調用服務的簡化工具)：Feign等
消息隊列：Kafka、RabbitMQ、ActiveMQ等
服務配置中心管理：SpringCloudConfig、Chef等
服務路由（API網關）
Zuul等
服務監控：Zabbix、Nagios、Metrics、Spectator等
全鏈路追蹤：Zipkin，Brave、Dapper等
服務部署：Docker、OpenStack、Kubernetes等
數據流操作開發包：SpringCloud Stream（封裝與Redis,Rabbit、Kafka等發送接收消息）
事件消息總線：Spring Cloud Bus
9、什麼是 Eureka服務註冊與發現
Eureka是Netflix的一個子模塊，也是核心模塊之一。
Eureka是一個基於REST的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。
服務註冊與發現對於微服務架構來說是非常重要的，有了服務發現與註冊，只需要使用服務的標識符，就可以訪問到服務，而不需要修改服務調用的配置文件了。功能類似於dubbo的註冊中心，比如Zookeeper。
10、Eureka的基本架構是什麼？
Spring Cloud 封裝了 Netflix 公司開發的 Eureka 模塊來實現服務註冊和發現(請對比Zookeeper)。
Eureka 採用了 C-S 的設計架構。Eureka Server 作爲服務註冊功能的服務器，它是服務註冊中心。
而系統中的其他微服務，使用 Eureka 的客戶端連接到 Eureka Server並維持心跳連接。這樣系統的維護人員就可以通過 Eureka Server 來監控系統中各個微服務是否正常運行。
SpringCloud 的一些其他模塊（比如Zuul）就可以通過 Eureka Server 來發現系統中的其他微服務，並執行相關的邏輯。
Eureka包含兩個組件：Eureka Server 和 Eureka Client
Eureka Server提供服務註冊服務
各個節點啓動後，會在EurekaServer中進行註冊，這樣EurekaServer中的服務註冊表中將會存儲所有可用服務節點的信息，服務節點的信息可以在界面中直觀的看到
EurekaClient是一個Java客戶端
用於簡化Eureka Server的交互，客戶端同時也具備一個內置的、使用輪詢(round-robin)負載算法的負載均衡器。在應用啓動後，將會向Eureka Server發送心跳(默認週期爲30秒)。
如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，EurekaServer將會從服務註冊表中把這個服務節點移除（默認90秒）
11、作爲服務註冊中心，Eureka比Zookeeper好在哪裏?
著名的CAP理論指出，一個分佈式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分區容錯性P在是分佈式系統中必須要保證的，因此我們只能在A和C之間進行權衡。
因此，Zookeeper 保證的是CP, Eureka 則是AP。
Zookeeper保證CP
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務直接down掉不可用。
也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉。
問題在於，選舉leader的時間太長，30~120s,且選舉期間整個zk集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。
在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。
Eureka保證AP
Eureka看明白了這一點，因此在設計時就優先保證可用性。
Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。
而Eureka的客戶端在向某個Eureka註冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。
除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現以下幾種情況：
Eureka不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務
Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中
因此， Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。
12、什麼是 Ribbon負載均衡
Spring Cloud Ribbon是基於Netflix Ribbon實現的一套客戶端 負載均衡的工具。
簡單的說，Ribbon是Netflix發佈的開源項目，主要功能是提供客戶端的軟件負載均衡算法，將Netflix的中間層服務連接在一起。
Ribbon客戶端組件提供一系列完善的配置項如連接超時，重試等。簡單的說，就是在配置文件中列出Load Balancer（簡稱LB）後面所有的機器，Ribbon會自動的幫助你基於某種規則（如簡單輪詢，隨機連接等）去連接這些機器。我們也很容易使用Ribbon實現自定義的負載均衡算法。
13、Ribbon負載均衡能幹嘛？
LB（負載均衡）
LB，即負載均衡(Load Balance)，在微服務或分佈式集羣中經常用的一種應用。
負載均衡簡單的說就是將用戶的請求平攤的分配到多個服務上，從而達到系統的HA。
常見的負載均衡有軟件Nginx，LVS，硬件 F5等。
相應的在中間件，例如：dubbo和SpringCloud中均給我們提供了負載均衡，SpringCloud的負載均衡算法可以自定義。
集中式LB
即在服務的消費方和提供方之間使用獨立的LB設施(可以是硬件，如F5, 也可以是軟件，如nginx), 由該設施負責把訪問請求通過某種策略轉發至服務的提供方；
進程內LB
將LB邏輯集成到消費方，消費方從服務註冊中心獲知有哪些地址可用，然後自己再從這些地址中選擇出一個合適的服務器。
注意：Ribbon就屬於進程內LB，它只是一個類庫，集成於消費方進程，消費方通過它來獲取到服務提供方的地址。
14、什麼是 Feign 負載均衡
Feign是一個聲明式WebService客戶端。使用Feign能讓編寫Web Service客戶端更加簡單, 它的使用方法是定義一個接口，然後在上面添加註解，同時也支持JAX-RS標準的註解。
Feign也支持可拔插式的編碼器和解碼器。Spring Cloud對Feign進行了封裝，使其支持了Spring MVC標準註解和HttpMessageConverters。Feign可以與Eureka和Ribbon組合使用以支持負載均衡。
Feign是一個聲明式的Web服務客戶端，使得編寫Web服務客戶端變得非常容易，只需要創建一個接口，然後在上面添加註解即可。
15、Feign 能幹什麼
Feign旨在使編寫Java Http客戶端變得更容易。
前面在使用Ribbon+RestTemplate時，利用RestTemplate對http請求的封裝處理，形成了一套模版化的調用方法。
但是在實際開發中，由於對服務依賴的調用可能不止一處，往往一個接口會被多處調用，所以通常都會針對每個微服務自行封裝一些客戶端類來包裝這些依賴服務的調用。
所以，Feign在此基礎上做了進一步封裝，由他來幫助我們定義和實現依賴服務接口的定義。在Feign的實現下，我們只需創建一個接口並使用註解的方式來配置它(以前是Dao接口上面標註Mapper註解,現在是一個微服務接口上面標註一個Feign註解即可)，即可完成對服務提供方的接口綁定，簡化了使用Spring cloud Ribbon時，自動封裝服務調用客戶端的開發量。
Feign集成了Ribbon
利用Ribbon維護了MicroServiceCloud-Dept的服務列表信息，並且通過輪詢實現了客戶端的負載均衡。
而與Ribbon不同的是，通過feign只需要定義服務綁定接口且以聲明式的方法，優雅而簡單的實現了服務調用
Feign通過接口的方法調用Rest服務（之前是Ribbon+RestTemplate），該請求發送給Eureka服務器（http://MICROSERVICECLOUD-DEPT/dept/list）,
通過Feign直接找到服務接口，由於在進行服務調用的時候融合了Ribbon技術，所以也支持負載均衡作用。
16、什麼是 Hystrix斷路器
Hystrix是一個用於處理分佈式系統的延遲和容錯的開源庫，在分佈式系統裏，許多依賴不可避免的會調用失敗，比如超時、異常等， Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，以提高分佈式系統的彈性。
“斷路器”本身是一種開關裝置，當某個服務單元發生故障之後，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時間、不必要地佔用，從而避免了故障在分佈式系統中的蔓延，乃至雪崩。
17、Hystrix斷路器能幹嘛？
服務降級：整體資源快不夠了，忍痛將某些服務先關掉，待渡過難關，再開啓回來
服務熔斷：熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的調用，快速返回”錯誤”的響應信息。當檢測到該節點微服務調用響應正常後恢復調用鏈路。在SpringCloud框架裏熔斷機制通過Hystrix實現。Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內20次調用失敗就會啓動熔斷機制。熔斷機制的註解是@HystrixCommand。
服務限流
接近實時的監控：除了隔離依賴服務的調用以外，Hystrix還提供了準實時的調用監控（Hystrix Dashboard），Hystrix會持續地記錄所有通過Hystrix發起的請求的執行信息，並以統計報表和圖形的形式展示給用戶，包括每秒執行多少請求多少成功，多少失敗等。Netflix通過hystrix-metrics-event-stream項目實現了對以上指標的監控。Spring Cloud也提供了Hystrix Dashboard的整合，對監控內容轉化成可視化界面。
18、什麼是 zuul路由網關
Zuul 包含了對請求的路由和過濾兩個最主要的功能：
其中路由功能負責將外部請求轉發到具體的微服務實例上，是實現外部訪問統一入口的基礎而過濾器功能則負責對請求的處理過程進行干預，
是實現請求校驗、服務聚合等功能的基礎.Zuul和Eureka進行整合，將Zuul自身註冊爲Eureka服務治理下的應用，同時從Eureka中獲得其他微服務的消息，也即以後的訪問微服務都是通過Zuul跳轉後獲得。
注意：Zuul服務最終還是會註冊進Eureka
提供=代理+路由+過濾 三大功能
19、什麼是SpringCloud Config分佈式配置中心
SpringCloud Config爲微服務架構中的微服務提供集中化的外部配置支持，配置服務器爲各個不同微服務應用的所有環境提供了一箇中心化的外部配置。
20、分佈式配置中心能幹嘛？
集中管理配置文件
不同環境不同配置，動態化的配置更新，分環境部署比如dev/test/prod/beta/release
運行期間動態調整配置，不再需要在每個服務部署的機器上編寫配置文件，服務會向配置中心統一拉取配置自己的信息
當配置發生變動時，服務不需要重啓即可感知到配置的變化並應用新的配置將配置信息以REST接口的形式暴露