--SpringCloud 的組件使用哪些--------
https://www.cnblogs.com/weigy/p/12310337.html
---SpringCloud的Eureka主要注冊什么----
服務提供者，IP
服務實例名和IP
包括服務的主機與端口號、服務版本號、通訊協議等一些附加信息.
---SpringCloud的Eureka的基本原理----
https://www.cnblogs.com/weigy/p/12310362.html
---SpringCloud 服務調用，是如何輪詢的---
--SpringCloud之Eureka注冊過程分析--
https://www.cnblogs.com/weigy/p/12617122.html
---SpringCloud的Eureka注冊中心掛了，正在調用的兩個服務怎么樣----
--SpringCloud服務之間是如何調用的--
--Spring Cloud服務雪崩、降級與熔斷--
https://blog.csdn.net/Mrs_chens/article/details/91831286
--SpringCloud Feign工作原理--
--使用 Spring Cloud 有什么優勢--
使用Spring Boot開發分布式微服務時，我們面臨以下問題
1.與分布式系統相關的復雜性-這種開銷包括網絡問題，延遲開銷，
帶寬問題，安全問題。
2.服務發現-服務發現工具管理群集中的流程和服務如何查找和互
相交談。它涉及一個服務目錄，在該目錄中注冊服務，然后能夠查
找並連接到該目錄中的服務。
3.冗余-分布式系統中的冗余問題。
4.負載平衡 --負載平衡改善跨多個計算資源的工作負荷，諸如計
算機，計算機集群，網絡鏈路，中央處理單元，或磁盤驅動器的分
布。
5.性能-問題 由於各種運營開銷導致的性能問題。
6.部署復雜性-Devops技能的要求。
--服務注冊和發現是什么意思？Spring Cloud 如何實現--
當我們開始一個項目時，我們通常在屬性文件中進行所有的配置。
隨着越來越多的服務開發和部署，添加和修改這些屬性變得更加復
雜。有些服務可能會下降，而某些位置可能會發生變化。手動更改
屬性可能會產生問題。Eureka服務注冊和發現可以在這種情況下
提供幫助。由於所有服務都在Eureka服務器上注冊並通過調用
Eureka服務器完成查找，因此無需處理服務地點的任何更改和處
理。
-------負載平衡的意義什么？-----------
在計算中，負載平衡可以改善跨計算機，計算機集群，網絡鏈接，
中央處理單元或磁盤驅動器等多種計算資源的工作負載分布。負載
平衡旨在優化資源使用，最大化吞吐量，最小化響應時間並避免任
何單一資源的過載。使用多個組件進行負載平衡而不是單個組件可
能會通過冗余來提高可靠性和可用性。負載平衡通常涉及專用軟件
或硬件，例如多層交換機或域名系統服務器進程。
---------什么是 Hystrix 斷路器？我們需要它嗎？---------
由於某些原因，employee-consumer公開服務會引發異常。在這
種情況下使用Hystrix我們定義了一個回退方法。如果在公開服務
中發生異常，則回退方法返回一些默認值。
如果firstPage method() 中的異常繼續發生，則Hystrix電路將
中斷，並且員工使用者將一起跳過firtsPage方法，並直接調用回
退方法。 斷路器的目的是給第一頁方法或第一頁方法可能調用的
其他方法留出時間，並導致異常恢復。可能發生的情況是，在負載
較小的情況下，導致異常的問題有更好的恢復機會 。
-----什么是 Netflix Feign？它的優點是什么？-------
Feign是受到Retrofit，JAXRS-2.0和WebSocket 啟發的java
客戶端聯編程序。Feign的第一個目標是將約束分母的復雜性統一
到httpapis，而不考慮其穩定性。在employee-consumer的例
子中，我們使用了employee-producer使用REST模板公開的
REST服務。但是我們必須編寫大量代碼才能執行以下步驟
1.使用功能區進行負載平衡。
2.獲取服務實例，然后獲取基本URL。
3.利用REST模板來使用服務。
如何使用NetflixFeign使呼叫變得更加輕松和清潔。如果NetflixRibbon依賴
關系也在類路徑中，那么Feign默認也會負責負載平衡。
----------什么是 Spring Cloud Bus？我們需要它嗎？--------
考慮以下情況：我們有多個應用程序使用Spring Cloud Config
讀取屬性，而SpringCloudConfig從GIT讀取這些屬性。 下面
的例子中多個員工生產者模塊從Employee Config Module獲取
Eureka注冊的財產。
如果假設GIT中的Eureka注冊屬性更改為指向另一台Eureka服
務器，會發生什么情況。在這種情況下，我們將不得不重新啟動服
務以獲取更新的屬性。還有另一種使用執行器端點/刷新的方式。
但是我們將不得不為每個模塊單獨調用這個url；
Spring Cloud Bus提供了跨多個實例刷新配置的功能。
如果我們刷新Employee Producer1，則會自動
刷新所有其他必需的模塊。如果我們有多個微服務啟動並運行，這
特別有用。這是通過將所有微服務連接到單個消息代理來實現的。
無論何時刷新實例，此事件都會訂閱到偵聽此代理的所有微服務，
並且它們也會刷新。可以通過使用端點/總線/刷新來實現對任何單
個實例的刷新。
---------spring cloud 和dubbo區別?--------
1.服務調用方式 dubbo是RPC springcloud Rest Api
2.注冊中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper
3.服務網關,dubbo本身沒有實現，只能通過其他第三方技術整合，springcloud有Zuul路由網關，作為路由服務器，進行消費者的請求分發,springcloud支持斷路器，與git完美集成配置文件支持版本控制，事物總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素。
--------REST 和RPC對比---------
1.RPC主要的缺陷是服務提供方和調用方式之間的依賴太強，需要對每一個微服務進行接口的定義，並通過持續繼承發布，嚴格版本控制才不會出現沖突。
2.REST是輕量級的接口，服務的提供和調用不存在代碼之間的耦合，只需要一個約定進行規范。
10.架構
在微服務架構中，需要幾個基礎的服務治理組件，包括服務注冊與發現、服務消費、負載均衡、斷路器、智能路由、配置管理等，由這幾個基礎組件相互協作，共同組建了一個簡單的微服務系統
在Spring Cloud微服務系統中，一種常見的負載均衡方式是，客戶端的請求首先經過負載均衡（zuul、Ngnix），再到達服務網關（zuul集群），然后再到具體的服。，服務統一注冊到高可用的服務注冊中心集群，服務的所有的配置文件由配置服務管理，配置服務的配置文件放在git倉庫，方便開發人員隨時改配置。
----------Eureka和Zookeeper區別--------
https://www.cnblogs.com/weigy/p/12310362.html
1.Eureka取CAP的AP，注重可用性，Zookeeper取CAP的CP注重
一致性。
2.Zookeeper在選舉期間注冊服務癱瘓，雖然服務最終會恢復，但選舉期間不可用。
3.eureka的自我保護機制，會導致一個結果就是不會再從注冊列表移除因長時間沒收到心跳而過期的服務。依然能接受新服務的注冊和查詢請求，但不會被同步到其他節點。不會服務癱瘓。
4.Zookeeper有Leader和Follower角色，Eureka各個節點平等。
5.Zookeeper采用過半數存活原則，Eureka采用自我保護機制解決分區問題。
6.eureka本質是一個工程，Zookeeper只是一個進程。
----------什么是服務熔斷？什么是服務降級?---
服務直接的調用，比如在高並發情況下出現進程阻塞，導致當前線程不可用，慢慢的全部線程阻塞，導致服務器雪崩。
服務熔斷：相當於保險絲，出現某個異常，直接熔斷整個服務，而不是一直等到服務超時。通過維護一個自己的線程池，當線程到達閾值的時候就啟動服務降級，如果其他請求繼續訪問就直接返回fallback的默認值。