1. 什么是微服務
- 以前的模式是 所有的代碼在同一個工程中 部署在同一個服務器中 同一個項目的不同模塊不同功能互相搶占資源
- 微服務 將工程根據不同的業務規則拆分成微服務 微服務部署在不同的機器上 服務之間進行相互調用
- Java微服務的框架有 dubbo（只能用來做微服務），spring cloud（提供了服務的發現，斷路器等）
- 微服務化的核心就是將傳統的一站式應用,根據業務拆分成一個一個的服務,徹底地去耦合,
- 每一個微服務提供單個業務功能的服務,一個服務做一件事,
- 從技術角度看就是一種小而獨立的處理過程,類似進程概念,能夠自行單獨啟動或銷毀
- 擁有自己獨立的數據庫
2. springcloud如何實現服務的注冊和發現
服務在發布時 指定對應的服務名（服務名包括了IP地址和端口） 將服務注冊到注冊中心（eureka或者zookeeper）
這一過程是springcloud自動實現 只需要在main方法添加@EnableDisscoveryClient 同一個服務修改端口就可以啟動多個實例
調用方法：傳遞服務名稱通過注冊中心獲取所有的可用實例 通過負載均衡策略調用（ribbon和feign）對應的服務
3.Ribbon和Feign的區別
Ribbon和Feign都是用於調用其他服務的，不過方式不同。
1.啟動類使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
2.服務的指定位置不同，Ribbon是在@RibbonClient注解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。
3.調用方式不同，Ribbon需要自己構建http請求，模擬http請求然后使用RestTemplate發送給其他服務，步驟相當繁瑣。
Feign則是在Ribbon的基礎上進行了一次改進，采用接口的方式，將需要調用的其他服務的方法定義成抽象方法即可，
不需要自己構建http請求。不過要注意的是抽象方法的注解、方法簽名要和提供服務的方法完全一致。
4.springcloud斷路器的作用
當一個服務調用另一個服務由於網絡原因或者自身原因出現問題時 調用者就會等待被調用者的響應 當更多的服務請求到這些資源時 導致更多的請求等待 這樣就會發生連鎖效應（雪崩效應） 斷路器就是解決這一問題
斷路器有完全打開狀態
一定時間內 達到一定的次數無法調用 並且多次檢測沒有恢復的跡象 斷路器完全打開，那么下次請求就不會請求到該服務
半開
短時間內 有恢復跡象 斷路器會將部分請求發給該服務 當能正常調用時 斷路器關閉
關閉
當服務一直處於正常狀態 能正常調用 斷路器關閉
5. 微服務之間是如何獨立通訊的spring Cloud和 Dubbo有哪些區別?
本質區別：
dubbo 是 基於 RPC 遠程 過程調用
cloud 是基於 http rest api 調用
最大區別: Spring Cloudi拋棄了 Dubbo的RPC通信,采用的是基於HTP的REST方式。
嚴格來說,這兩種方式各有優劣。雖然從一定程度上來說,后者犧牲了服務調用的性能,但也避兔了上面提到的原生RPC帶來的問題。
而且REST相比RPC更為靈活,服務提供方和調用方的依賴只依靠一紙契約,不存在代碼級別的強依賴,這在強調快速演化的微服務環境下,顯得更加合適
很明顯, Spring Cloud的功能比 DUBBO更加強大,涵蓋面更廣,而且作為 Spring的挙頭項目,它也能夠與 Spring FrameworkSpring Boot.、 Spring Data、 Spring Batch等其他 Springi項目完美融合,這些對於微服務而言是至關重要的。使用 Dubbo構建的微服務架構就像組裝電腦,各環節我們的選擇自由度很高,但是最終結果很有可能因為一條內存質量不行就點不亮了,總是讓人不怎么放心,但是如果你是一名高手,那這些都不是問題;而 Spring Cloud就像品牌機,在 Spring Source的整合下,做了大量的兼容性測試,保證了機器擁有更高的穩定性,但是如果要在使用非原裝組件外的東西,就需要對其基礎有足夠的了解
6.Spring Boot和 Spring Cloud,請你談談對他們的理解 什么是服務熔斷?
spring boot 是一個快速整合第三方框架 關注的是 微觀 具體關注快速方便的開發單個個體的 服務
spring cloud 關注的是 宏觀 具體關注全局的微服務協調整理治理框架 將spring boot 開發的一個個單體服務整合 並管理起來
它為各個微服務之間提供 配置管理 服務發現 斷路器路由 微代理 全局鎖 分布式會話 等 集成服務
舉個例子 ： 一所醫院 boot 是 一個一個科室 cloud 是把一個一個科室 組合起來 對外稱之為 醫院
存在依賴關系 cloud 離不開boot
7.hystrix 斷路器
服務熔斷 是指 由於某些原因使得服務出現了過載現象，為防止造成整個系統故障，從而采用的一種保護措施，所以很多地方把熔斷亦稱為過載保護。
8. 什么是服務降級 微服務的優缺點分別是什么?
用 通俗易懂的來說 ： 整體資源快不夠了，忍痛將某些服務先關掉，待渡過難關，再開啟回來
9. 說下你在項目開發中碰到的坑你所知道的微服務技術棧有哪些?
微服務技術棧 ： 多種技術的結合體
我們在討論分布式的微服務架構的時候 它需要有哪些維度？
1 服務治理 2 服務注冊 3 服務調用 4 負載均衡 5 服務監控
10.請說說eureka和 zookeeper,兩個的區別?
首先 說CAP 是什么 所謂的CAP C強一致性 A可用性 P 分區容錯性
著名的CAP理論指出,
一個分布式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分區容錯性P在是分布式系統中必須要保證的,因此我們只能在A和C之間進行權衡。
zookeeper 遵守 CP
當向注冊中心查詢服務列表時, 我們可以容忍注冊中心返回的是幾分鍾以前的注冊信息, 但不能接受服務直接down掉不可用。
也就是說,服務注冊功能對可用性的要求要高於一致性。
但是zookeeper 會出現這樣一種情況, 當 master節點因為網絡故障與其他節點失去聯系時,剩余節點會重新進行 leader選舉。
問題在於,選舉 leader的時間太長,30~120s,目選舉期間整個zookeeper 集群都是不可用的,這就導致在選舉期間注冊服務癱瘓。
在雲部署的環境下,因網絡問題使得zookeeper 集群失去 master節點是較大概率會發生的事,雖然服務能夠最終恢復,但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。
或許 這個回答太過於抽象 用一種其他說法來說 就是 ：
當有一個zookeeper 掛了 那其他的zookeeper 會進行 一次選舉 （強一致性 ： 我一定要保持數據一致性） 而在此選舉期間 zookeeper 是不可用的 而當前 有用戶正在使用 用戶就不爽了 。
eureka 遵守 AP
Eureka:看明白了這一點,因此在設計時就優先保證可用性。
Eureka各個節點都是平等的,幾個節點掛掉不會影響正常節點的工作,剩余的節點依然可以提供注冊和查詢服務。
而 Eureka的客戶端在向某個 Eureka注冊或時如果發現連接失敗,則會自動切換至其它節點
只要有一台 Eureka還在,就能保證注冊服務可用(保證可用性),只不過查到的信息可能不是最新的不保證強一致性)。
除此之外, Eureka還有一種自我保護機制,如果在15分鍾內超過85%的節點都沒有正常的心跳,那么 Eurekas就認為客戶端與注冊中心出現了網絡故障,此時會出現以下幾種情況:
1. Eureka不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務
2. Ureka仍然能夠接受新服務的注冊和査詢請求,但是不會被同步到其它節點上(即保證當前節點依然可用)
3.當網絡穩定時,當前實例新的注冊信息會被同步到其它節點中
因此, Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況,而不會像 zookeeper那樣使整個注冊服務癱瘓。
11.SpringCloud核心組件
1）Spring Cloud核心組件：Eureka（Eureka是微服務架構中的注冊中心，專門負責服務的注冊與發現）
Eureka Client： 負責將這個服務的信息注冊到Eureka Server中
Eureka Server： 注冊中心，里面有一個注冊表，保存了各個服務所在的機器和端口號
2）Spring Cloud核心組件：Feign（ Feign的一個關鍵機制就是使用了動態代理）
沒有底層的建立連接、構造請求、解析響應的代碼，直接就是用注解定義一個 FeignClient接口，然后調用那個接口就可以了。人家Feign Client會在底層根據你的注解，跟你指定的服務建立連接、構造請求、發起靕求、獲取響應、解析響應，等等。這一系列臟活累活，人家Feign全給你干了。
1.首先，如果你對某個接口定義了@FeignClient注解，Feign就會針對這個接口創建一個動態代理
2.接着你要是調用那個接口，本質就是會調用 Feign創建的動態代理，這是核心中的核心
3.Feign的動態代理會根據你在接口上的@RequestMapping等注解，來動態構造出你要請求的服務的地址
4.最后針對這個地址，發起請求、解析響應
3）Spring Cloud核心組件：Ribbon（它的作用是 負載均衡 ，會幫你在每次請求時選擇一台機器，均勻的把請求分發到各個機器上）
Ribbon的負載均衡默認使用的最經典的 Round Robin輪詢算法,還有隨機算法
此外，Ribbon是和Feign以及Eureka緊密協作，完成工作的，具體如下：
首先Ribbon會從 Eureka Client里獲取到對應的服務注冊表，也就知道了所有的服務都部署在了哪些機器上，在監聽哪些端口號。
然后Ribbon就可以使用默認的Round Robin算法，從中選擇一台機器
Feign就會針對這台機器，構造並發起請求。
4）Spring Cloud核心組件：Hystrix（ Hystrix是隔離、熔斷以及降級的一個框架）
微服務架構中恐怖的服務雪崩問題
這么多服務互相調用，要是不做任何保護的話，某一個服務掛了，就會引起連鎖反應，導致別的服務也掛。比如積分服務掛了，會導致訂單服務的線程全部卡在請求積分服務這里，沒有一個線程可以工作，瞬間導致訂單服務也掛了，別人請求訂單服務全部會卡住，無法響應。
隔離：Hystrix會搞很多個小小的線程池 ，比如訂單服務請求庫存服務是一個線程池，請求倉儲服務是一個線程池，請求積分服務是一個線程池。每個線程池里的線程就僅僅用於請求那個服務。
熔斷：但是如果積分服務都掛了，每次調用都要去卡住幾秒鍾干啥呢？有意義嗎？當然沒有！ 所以我們直接對積分服務熔斷不就得了，比如在5分鍾內請求積分服務直接就返回了，不要去走網絡請求卡住幾秒鍾， 這個過程，就是所謂的熔斷
降級：沒問題，咱們就來個降級：每次調用積分服務，你就在數據庫里記錄一條消息，說給某某用戶增加了多少積分，因為積分服務掛了，導致沒增加成功！這樣等積分服務恢復了，你可以根據這些記錄手工加一下積分。 這個過程，就是所謂的降級
5）Spring Cloud核心組件：Zuul（這個組件是負責網絡路由的）
所以一般微服務架構中都必然會設計一個網關在里面，像android、ios、pc前端、微信小程序、H5等等，不用去關心后端有幾百個服務，就知道有一個網關，所有請求都往網關走，網關會根據請求中的一些特征，將請求轉發給后端的各個服務。
而且有一個網關之后，還有很多好處，比如可以做 統一的降級、限流、認證授權、安全 ，等等。
服務治理為心臟，路由網關、消息中心、斷路器、鏈路追蹤、配置中心等為依托，構造了整個微服務框架的「五臟六腑