微服務
Q:為什么要用微服務？微服務有哪些優勢？
單體應用把所有功能都堆放在一起，改動影響大，風險高。
微服務具有以下優勢：
針對特定服務發布，影響小，風險小，成本低。
頻繁發布版本，快速交付需求。
低成本擴容，彈性伸縮，適應雲環境。
Q:怎么解決服務調用閉環(循環依賴)？
服務分層，設定groupId。比如分為上層服務，中間層服務，底層服務。
上層服務可以調用中間層、底層服務，底層服務不允許調用上層服務。
Q:如何拆分微服務？
按功能模塊拆分。按DDD（領域驅動設計）拆分。
Q:你們的服務划分了幾個模塊？分別是哪些模塊？
幾十個模塊。
DDD
Q:DDD的聚合根，實體，值對象的區別和聯系是什么？
參見： https://www.cnblogs.com/netfocus/p/5145345.html
Rpc
Q:RPC和Restful分別有哪些優劣性？
RPC協議性能要高的多，吞吐量比http大。響應也更快。
RPC常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等；
Restful使用http協議。http相對更規范，更標准，更通用，無論哪種語言都支持http協議
Q:為什么Rpc的性能比RestFul好一些？
RESTful是基於HTTP協議進行交互的，HTTP協議包含大量的請求頭、響應頭信息。
而Rpc（比如dubbo)是基於(dubbo)自定義的二進制協議進行傳輸，消息體比較簡單，傳輸數據要小很多。
Q:如果想實現一個Rpc框架，需要考慮哪些東西？
動態代理、反射、序列化、反序列化、網絡通信(netty)、編解碼、服務發現和注冊、心跳與鏈路檢測。
參考資料：https://www.cnblogs.com/flzs/p/12174686.html
Q:服務端如何確定客戶端要調用的函數？
在遠程調用中，客戶端和服務端分別維護一個【ID->函數】的對應表， ID在所有進程中都是唯一確定的。客戶端在做遠程過程調用時，附上這個ID，服務端通過查表，來確定客戶端需要調用的函數，然后執行相應函數的代碼。(如果自己去設計一個RPC，可以使用一個Map去保存這些鍵值對)
Dubbo
Q:講一下Dubbo
服務提供者提供服務，服務消費者可以通過Rpc進行服務消費。
Q:Dubbo支持哪些協議？
Dubbo支持Dubbo、rmi、hessian、http、webservice、thrift、Redis等多種協議
Q:Dubbo默認的協議是什么？
Dubbo協議。
Q:Dubbo的序列化有哪些方式？
默認協議：dubbo協議。序列化：hession二進制。
dubbo協議。連接方式：長連接。
其他協議：
rmi協議。連接方式：短連接。序列化：java自帶的二進制。
hessian。連接方式：短連接。序列化：表單序列化。
Q:Dubbo和SpringCloud有哪些區別？
Dubbo是Soa(面向服務的架構)，SpringCloud是微服務架構，除了服務，還有注冊中心、熔斷、配置中心。
Dubbo基於Rpc(遠程過程調用)，SpringCloud基於restFul，基於http協議。
Q:Soa和微服務架構，有哪些區別？
Q:Dubbo的服務提供者、服務消費者需要配置哪些信息？
服務提供者需要配置ip、端口、Dubbo協議、注冊中心地址等
Q:Dubbo有哪些負載均衡策略？
一致性Hash均衡算法、隨機調用法、輪詢法、最少活動調用法。
Q:講一下Dubbo的SPI機制。
Q:你們用的是哪個版本的Dubbo?
SpringCloud(微服務)
Q:你用過SpringCloud的哪些組件？
服務協調，注冊中心，熔斷，降級，配置中心，網關。
Eureka 注冊中心/服務治理
Q:講一下Eureka.
Eureka分為服務注冊中心，服務提供者 ，服務消費者。服務提供者 、服務消費者都必須指定注冊中心。服務提供者提供服務，而服務消費者可以調用提供者的服務。
Q:Eureka是怎么和服務通信的？
心跳機制。
Q:Eureka有哪些特性？
服務提供者有以下特性：
服務續約：在注冊完服務之后，服務提供者會維護一個心跳機制用來持續告訴Eureka Server: "我還活着 ” 。
EurekaServer有以下特性：
失效剔除：默認每隔一段時間（默認為60秒） 將當前清單中超時（默認為90秒）沒有續約的服務剔除出去。
自我保護：EurekaServer 在運行期間，會統計心跳失敗的比例在15分鍾之內是否低於85%(通常由於網絡不穩定導致)。 Eureka Server會將當前的實例注冊信息保護起來， 讓這些實例不會過期，盡可能保護這些注冊信息。
Q:Eureka怎么保證高可用？
多個注冊中心互相注冊。
Eureka Server的高可用實際上就是將自己作為服務向其他服務注冊中心注冊自己,這樣就可以形成一組互相注冊的服務注冊中心,以實現服務清單的互相同步,達到高可用的效果。
Q:Eureka注冊中心和Zookeeper注冊中心，有什么區別？
Eureka注重高可用，屬於CAP中的AP。
Zookeeper注重一致性，屬於CAP中的CP。
Q:除了Zookeeper，你用過哪些注冊中心?有什么區別？
Zookeeper，Redis，Eureka
Zookeeper，是分布式中的CP，能夠更好地保證分布式一致性。
Redis基於發布/訂閱模式。
Eureka在SpringCloud中應用較多。Eureka是分布式中的AP，也就是注重可用性。
服務消費 Feign
Q:講一下Feign。
Q:為什么要使用Feign？
Feign可以進行服務消費，Feign內置了Hystrix和Eureka。
1.feign采用的是基於接口的注解。
2.feign整合了ribbon，具有負載均衡的能力。
3.整合了Hystrix，具有熔斷的能力。
Q:Feign使用了哪些協議？
Http協議。
Q:Feign底層原理。
動態代理。
服務消費 Ribbon
Q:SpringCloud如何進行負載均衡？
使用Ribbon.
Q:Ribbon有哪些功能？
負載均衡，重試機制。
Q:Ribbon有哪些負載均衡的策略？
常用的有：輪詢，隨機，加權。
隨機策略：隨機選擇server.
輪詢策略：按照順序選擇server（ribbon默認策略）.
重試策略：在一個配置時間段內，當選擇server不成功，則一直嘗試選擇一個可用的server.
最低並發策略：逐個考察server，如果server斷路器打開，則忽略，再選擇其中並發鏈接最低的server.
可用過濾策略：過濾掉一直失敗並被標記為circuit tripped的server，過濾掉那些高並發鏈接的server（active connections超過配置的閾值）.
響應時間加權重策略:根據server的響應時間分配權重，響應時間越長，權重越低，被選擇到的概率也就越低。響應時間越短，權重越高，被選中的概率越高，這個策略很貼切，綜合了各種因素，比如：網絡，磁盤，io等，都直接影響響應時間.
區域權重策略: 綜合判斷server所在區域的性能，和server的可用性，輪詢選擇server並且判斷一個AWS Zone的運行性能是否可用，剔除不可用的Zone中的所有server.
參考： https://www.cnblogs.com/idoljames/p/11698923.html
Hystrix熔斷
Q:講一下Hystrix。為什么要使用熔斷？
當某個服務發生故障（類似用電器發生短路）之后，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個錯誤響應，而不是長時間的等待。這樣就不會使得線程因調用故障服務被長時間占用不釋放，避免了故障在分布式系統中的蔓延。
使用熔斷，可以避免服務雪崩。
Q:Hystrix熔斷的原理是什么？
"艙壁模式"，實現進程線程池的隔離，它會為每一個服務創建一個獨立的線程池，這樣就算某個服務出現延遲過高的情況，也不會拖慢其他的服務。
Q:Hystrix熔斷有哪幾種方隔離方式？
線程池隔離。信號量隔離。
Q:這兩種隔離模式，有什么區別？
在大部分情況下，使用線程池隔離會有非常微小的延遲(9ms)，可以忽略不計。
如果對延遲的要求非常高的話，可以使用信號量隔離。
信號量的開銷遠比線程池的開銷小，但是信號量不能設置超時，也沒法實現異步訪問。
Q:什么時候會觸發熔斷？什么時候斷路器的狀態會發生變化？
當QPS達到20，或者請求失敗率達到50%，斷路器就會變成打開，就會觸發熔斷。
斷路器變成打開狀態后，會進行休眠，默認5秒，在到達休眠時間后，將再次允許請求嘗試訪問，此時為"半開狀態"，若此時請求繼續失敗，那斷路器又會進入"打開狀態"，如此循環。
Q:熔斷如何設置超時時間，重試次數？
如果超時時間設置過短，或者重試次數過多，會頻繁地重試，加大服務的壓力。
如果超時時間設置過長，可能會導致請求響應慢，導致阻塞、卡頓。
超時時間設置：方案一，按照服務提供者線上真實的服務水平，取 P999 或者 P9999 的值，也就是以 99.9% 或者 99.99% 的調用都在多少毫秒內返回為准。
方案二，按照接口重要性來進行設置，並發低的接口設置的超時時間可以多點，比如2s，並發高的接口設置的超時時間可以設置的低點，比如200ms。
重試時間設置：一兩次即可。大部分情況下，調用失敗都是因為偶發的網絡問題或者個別服務提供者節點有問題導致的，如果能換個節點再次訪問說不定就能成功。
如果是讀比較多的服務，重試次數設置多一些也沒關系。如果是寫比較多的服務，最好還是減少重試次數，或者不設置重試，否則容易出錯。
Q:講一下熔斷和降級的區別？
熔斷是直接返回一個錯誤響應。
服務降級是采取備用邏輯。
服務降級：當服務器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心交易正常運作或高效運作。
在服務降級邏輯中，我們需要實現一個通用的響應結果，並且該降級邏輯應該是從緩存或者是一些降級邏輯中獲取，而不是依賴網絡請求獲取，這樣能夠穩定地返回結果的處理邏輯。
Q:Hystrix什么時候會觸發服務降級？
當前Hystrix命令處於"熔斷/短路"狀態，斷路器是打開的時候。
當前Hystrix命令的線程池，請求隊列，或者信號量被占滿的時候。
Zuul網關
Q:Zuul網關，有什么功能？
Zuul能夠進行過濾(Filter)，設置白名單。
Zuul還能進行請求路由/服務路由。
路由功能，負責將外部請求功能轉發到具體的微服務實例上，是實現外部訪問統一入口的基礎。
Q:Zuul網關如何實現路由？
通過服務路由的功能，在對外提供服務的時候，只需要通過暴露Zuul中配置的調用地址就可以讓調用方統一的來訪問我們的服務，而不需要了解具體提供服務的主機信息了。
Q:Zuul有幾種過濾器類型？
4種。
pre : 可以在請求被路由之前調用。
適用於身份認證的場景，認證通過后再繼續執行下面的流程。
route : 在路由請求時被調用。
適用於灰度發布場景，在將要路由的時候可以做一些自定義的邏輯。
post :在 route 和 error 過濾器之后被調用。
這種過濾器將請求路由到達具體的服務之后執行。適用於需要添加響應頭，記錄響應日志等應用場景。
error : 處理請求時發生錯誤時被調用。
在執行過程中發送錯誤時會進入 error 過濾器，可以用來統一記錄錯誤信息。
Q:Gateway和Zuul有什么區別和聯系？
Zuul：
使用的是阻塞式的 API，不支持長連接，比如 websockets。
底層是servlet，Zuul處理的是http請求
沒有提供異步支持，流控等均由hystrix支持。
依賴包spring-cloud-starter-netflix-zuul。
Gateway：
底層依然是servlet，但使用了webflux，多嵌套了一層框架。
依賴spring-boot-starter-webflux和/ spring-cloud-starter-gateway。
提供了異步支持，提供了抽象負載均衡，提供了抽象流控，並默認實現了RedisRateLimiter。
-
相同點：
1、底層都是servlet
2、兩者均是web網關，處理的是http請求 -
不同點：
1、內部實現：
gateway對比zuul多依賴了spring-webflux，在spring的支持下，功能更強大，內部實現了限流、負載均衡等，擴展性也更強，但同時也限制了僅適合於Spring Cloud套件
zuul則可以擴展至其他微服務框架中，其內部沒有實現限流、負載均衡等。
2、是否支持異步：
zuul僅支持同步。
gateway支持異步。理論上gateway則更適合於提高系統吞吐量（但不一定能有更好的性能），最終性能還需要通過嚴密的壓測來決定。
3、框架設計的角度：
gateway具有更好的擴展性，並且其已經發布了2.0.0的RELESE版本，穩定性也是非常好的。
4、性能：
WebFlux 模塊的名稱是 spring-webflux，名稱中的 Flux 來源於 Reactor 中的類 Flux。Spring webflux 有一個全新的非堵塞的函數式 Reactive Web 框架，可以用來構建異步的、非堵塞的、事件驅動的服務，在伸縮性方面表現非常好。使用非阻塞API。 Websockets得到支持，並且由於它與Spring緊密集成，所以將會是一個更好的開發體驗。
參考：https://www.cnblogs.com/lgg20/p/12507845.html
SpringCould Config配置中心
Q:講一下Config。
配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集群配置，目前支持本地存儲、Git以及Subversion。
"一次配置，隨處可用"。