netty 是什么？
“netty 是一個基於nio的客戶、服務器端編程框架,netty提供異步的,事件驅動的網絡應用程序框架和工具,可以快速開發高可用的客戶端和服務器。netty是基於nio的,它封裝了jdk的nio,讓我們使用起來更加方法靈活。”
Springcloud和Dubbo的區別？
Spring Cloud拋棄了Dubbo 的RPC通信，采用的是基於HTTP的REST方式。Dubbo 支持多協議（dubbo協議，hessian協 https://blog.csdn.net/lzhcoder/article/details/85631571
RPC即遠程過程調用：它是一個計算機通信協議。它允許像調用本地服務一樣調用遠程服務。一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。
Dubbo缺省協議：采用單一長連接和NIO異步通訊，使用基於於netty+hessian（序列化方式）交互。適合於小數據量大並發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況。Dubbo缺省協議不適合傳送大數據量的服務，比如傳文件，傳視頻等，除非請求量很低。
hessian序列化協議：多個短連接，適用於提供者數量比消費者數量還多，適用於文件的傳輸，一般較少用
eureka和zookeeper都可以提供服務注冊與發現的功能，請說說兩個的區別(優點)？
zookeeper： 當主節點故障時，zk會在剩余節點重新選擇主節點，耗時過長，雖然最終能夠恢復，但 是選取主節點期間會導致服務不可用，這是不能容忍的。 eureka： 各個節點是平等的，一個節點掛掉，其他節點仍會正常保證服務。
總結： 著名的CAP理論指出，一個分布式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分
區容錯性P在是分布式系統中必須要保證的，因此我們只能在A和C之間進行權衡。因此，Zookeeper 保證
的是CP, Eureka 則是AP。
Eureka還有一種自我保護機制？
Eureka Client：負責將這個服務的信息注冊到Eureka Server中
Eureka Server：注冊中心，里面有一個注冊表，保存了各個服務所在的機器和端口號
首先eureka client每隔30往eureka server服務端發送心跳，15分鍾內超過85%的節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：
1、Eureka不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務
2、Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)。
3、當網絡穩定時，當前實例新的注冊信息會被同步到其它節點中因此， Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。
Ribbon 與 Nginx 的區別？
1、nginx 是客戶端所有請求統一交給 nginx，由 nginx 進行實現負載均衡請求轉發，屬於服務器端負載均衡。既請求由 nginx 服務器端進行轉發。
Nginx 適合於服務器端實現負載均衡 比如 Tomcat
2、Ribbon 是從 eureka 注冊中心服務器端上獲取服務注冊信息列表，緩存到本地，然后在本地實現輪詢負載均衡策略。既在客戶端實現負載均衡。
Ribbon 適合與在微服務中 RPC 遠程調用實現本地服務負載均衡，比如 Dubbo、SpringCloud 中都是采用本地負載均衡。
Ribbon 怎么實現客戶端負載均衡？
由於 Spring Cloud Ribbon 的封裝， 我們在微服務架構中使用客戶端負載均衡調用非常簡單， 只需要如下兩步
1、啟動多個服務提供者實例並注冊到一個服務注冊中心或是服務注冊中心集群
2、服務消費者通過被＠LoadBalanced 注解修飾過的 RestTemplate 來調用服務提供者。
這樣，我們就可以實現服務提供者的高可用以及服務消費者的負載均衡調用。
Zuul的四大過濾器？
(1) PRE：這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現身份驗證、在集群中選擇請求的微服務、記錄調試信息等。
(2) ROUTING ：這種過濾器用於構建發送給微服務的請求，並使用Apache HttpClient或Netfilx Ribbon請求微服務。
(3) POST：這種過濾器在路由到微服務以后執行。這種過濾器可用來為響應添加標准的HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。
(4) ERROR：在其他階段發生錯誤時執行該過濾器。
Hystrix的作用？
相關鏈接：https://www.jianshu.com/p/aa79fb6d96f3
如果一個用戶服務調另一個庫存服務，庫存服務掛了。用戶服務可以正常訪問，只不過調庫存服務的時候就會報錯。會卡着幾分鍾。
這時候直接做一個服務熔斷，在幾分鍾內請求庫存服務直接fallback返回一個異常頁面。
服務熔斷和服務降級的區別？
服務熔斷：一般是某個服務異常引起的，相當於“保險絲”，當某個異常條件被觸發，直接熔斷整個服務，返回，不是等到此服務超時。
通過@HystrixCommand(fallbackMethod ="hystrix_GET" ) //去找備選響應，進行服務降級
服務降級：降級一般是從整體負荷考慮，當某個服務熔斷之后，服務器將不再被調用，客戶端可自己准備一個本地的fallback回調，返回一個缺省值，雖然服務水平下降，當能用，比直接掛掉要強。
微服務怎么做高可用？
1、從技術看高可用：
主要使用的技術手段是服務和數據的冗余備份和失效轉移，一組服務或一組數據都能在多節點上，之間相互備份。
當一台機器宕機或出現問題的時候，可以從當前的服務切換到其他可用的服務，不影響系統的可用性，也不會導致數據丟失。
2、從架構看高可用：
保持簡單的架構，目前多數網站采用的是比較經典的分層架構，應用層，服務層，數據層。
應用層是處理一些業務邏輯，服務層提供一些數據和業務緊密相關服務，數據層負責對數據進行讀寫。
簡單的架構可以使應用層，服務層可以保持無狀態化進行水平擴展，這個屬於計算高可用。
3、從硬件看高可用：
首先得確認硬件總是可能壞的，網絡總是不穩定的。解決它的方法也是一個服務器不夠就來多幾個，一個機櫃不夠就來幾個，一個機房不夠就來幾個。
4、從軟件看高可用：
軟件的開發不嚴謹，發布不規范也是導致各種不可用出現，通過控制軟件開發過程質量監控，通過測試，預發布，灰度發布等手段也是減少不可用的措施。
5、從服務管理看：
將服務規范化，事前做好服務分割，做好服務監控，預判不可用的出現，在不可用出現之前發現問題，解決問題。