Spring Cloud（1）

Q：
什麼是微服務？
微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分爲一組小的服務，每個服務運行在其獨立的自己的進程中，服務之間相互協調、互相配合，爲用戶提供最終價值。服務之間採用輕量級的通信機制互相溝通（通常是基於HTTP的RESTful API），每個服務都圍繞着具體的業務進行構建，並且能夠被獨立的構建在生產環境、類生產環境等。另外，應避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。

Q：
Spring Cloud由哪些組件組成？
Eureka：服務註冊與發現
Zuul：服務網關
Ribbon：客戶端負載均衡
Feign：聲明性的Web服務客戶端
Hystrix：斷路器
Config：分佈式統一配置管理
等20幾個框架，開源一直在更新

Q：
Spring Cloud和 dubbo區別?
服務調用方式：

dubbo是 RPC
springcloud 是Rest Api
註冊中心：

dubbo是 zookeeper；
springcloud是 eureka，也可以是 zookeeper
服務網關：

dubbo本身沒有實現，只能通過其他第三方技術整合；
springcloud有Zuul路由網關，作爲路由服務器，進行消費者的請求分發；springcloud支持斷路器，與git完美集成配置文件支持版本控制，事物總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素。

Q：
Eureka的工作原理？
Eureka：服務註冊中心（可以是一個集羣），對外暴露自己的地址
提供者：啓動後向Eureka註冊自己信息（地址，提供什麼服務）
消費者：向Eureka訂閱服務，Eureka會將對應服務的所有提供者地址列表發送給消費者，並且定期更新
心跳(續約)：提供者定期通過http方式向Eureka刷新自己的狀態（每30s定時向EurekaServer發起請求）

Q：
說說Eureka的自我保護機制？
當一個服務未按時進行心跳續約時，在生產環境下，因爲網絡延遲等原因，此時就把服務剔除列表並不妥當，因爲服務可能沒有宕機。Eureka就會把當前實例的註冊信息保護起來，不予剔除。生產環境下這很有效，保證了大多數服務依然可用。但是有可能會造成一些掛掉的服務被剔除有延遲。

Q：
Eureka和ZooKeeper的區別？
1、ZooKeeper中的節點服務掛了就要選舉，在選舉期間註冊服務癱瘓，雖然服務最終會恢復，但是選舉期間不可用的， 選舉就是改微服務做了集羣，必須有一臺主其他的都是從。
2、Eureka各個節點是平等關係，服務器掛了沒關係，只要有一臺Eureka就可以保證服務可用，數據都是最新的。如果查詢到的數據並不是最新的，就是因爲Eureka的自我保護模式導致的。
3、Eureka本質上是一個工程，而ZooKeeper只是一個進程。
4、Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像ZooKeeper 一樣使得整個註冊系統癱瘓。
5、ZooKeeper保證的是CP，Eureka保證的是AP

CAP：
C：一致性Consistency （取捨:強一致性、單調一致性、會話一致性、最終一致性、弱一致性）
A：可用性 Availability
P：分區容錯性Partition tolerance

Q：
什麼是zuul?
zuul是對SpringCloud提供的成熟對的路由方案，他會根據請求的路徑不同，網關會定位到指定的微服務，並代理請求到不同的微服務接口，他對外隱蔽了微服務的真正接口地址。
三個重要概念：

動態路由表：Zuul支持Eureka路由，手動配置路由，這倆種都支持自動更新
路由定位：根據請求路徑，Zuul有自己的一套定位服務規則以及路由表達式匹配
反向代理：客戶端請求到路由網關，網關受理之後，在對目標發送請求，拿到響應之後在 給客戶端
Zuul的應用場景：對外暴露，權限校驗，服務聚合，日誌審計等

Q：
zuul的工作流程?
在Spring Cloud Netflix中，Zuul巧妙的整合了Eureka來實現面向服務的路由。
實際上，API網關將自己註冊到Eureka服務註冊中心上，也會從註冊中心獲取所有服務以及它們的實例清單。在Eureka的幫助下，API網關已經維護了系統中所有serviceId與實例地址的映射關係。當有外部請求到達API網關的時候，根據請求的URL找到最匹配的path，API網關就可以知道要將該請求"路由"到哪個具體的serviceId上去。最終通過Ribbon的負載均衡策略實現請求的路由。

Q：
什麼是feign?
1.feign採用的是基於接口的註解
2.feign整合了ribbon，具有負載均衡的能力
3.整合了Hystrix，具有熔斷的能力

Q：
feign的工作流程？
1、通過動態代理生成實現類
2、根據接口類的註解生命規則，解析出底層的methodhandler
3、攔截器負責對請求和返回進行包裝和處理
4、通過均衡負載http去訪問遠程服務

Q：
什麼是Hystrix？
在分佈式系統，我們一定會依賴各種服務，那麼這些個服務一定會出現失敗的情況，就會導致雪崩，Hystrix就是這樣的一個工具，防雪崩利器，它具有服務降級，服務熔斷，服務隔離，監控等一些防止雪崩的技術。
Hystrix有四種防雪崩方式：

服務降級：接口調用失敗就調用本地的方法返回一個空
服務熔斷：接口調用失敗就會進入調用接口提前定義好的一個熔斷的方法，返回錯誤信息
服務隔離：隔離服務之間相互影響
服務監控：在服務發生調用時,會將每秒請求數、成功請求數等運行指標記錄下來。

Q： Hystrix流程? 1、構造一個 HystrixCommand或HystrixObservableCommand對象，用於封裝請求，並在構造方法配置請求被執行需要的參數； 2、執行命令，Hystrix提供了4種執行命令的方法； 3、判斷是否使用緩存響應請求，若啓用了緩存，且緩存可用，直接使用緩存響應請求。Hystrix支持請求緩存，但需要用戶自定義啓動； 4、判斷熔斷器是否打開，如果打開，跳到第8步； 5、判斷線程池/隊列/信號量是否已滿，已滿則跳到第8步； 6、執行HystrixObservableCommand.construct()或HystrixCommand.run()，如果執行失敗或者超時，跳到第8步；否則，跳到第9步； 7、統計熔斷器監控指標； 8、走Fallback備用邏輯 9、返回請求響應