springCloud是一套微服務組件， 常用的Eureka，Ribbon，Hystrix，Feign，Gateway，Config，Bus（消息總線）等等。
一、Eureka
1、Eureka：提供服務注冊和發現功能
1、服務注冊：在服務治理框架中，通常都會構建一個注冊中心，每個服務單元向注冊中心登記自己提供的服務注冊中心按照服務名分類組織服務清單，同時還需要以心跳檢測的方式去監測清單中的服務是否可用，若不可用需要從服務清單中剔除，以達到排除故障服務的效果。
2、失效剔除：服務注冊中心在啟動時會創建一個定時任務，默認每隔一段時間 （默認為60秒）將當前清單中超時（默認為90秒）沒有續約的服務剔除
3、自我保護：當一個服務未按時進行心跳續約時，Eureka會統計最近15分鍾心跳失敗的服 務實例的比例是否超過了85%，當EurekaServer節點在短時間內丟失過多客戶端（可能發生了網絡分區故障）。在 生產環境下，因為網絡延遲等原因，心跳失敗實例的比例很有可能超標，但是此時就把服務剔除列表並不妥當，因為服務可能沒有宕機。Eureka就會把當前實例的注冊信息保護起來，不予剔除，在實際中，保證了大多 數服務依然可用。
2、服務提供者：也稱為Eureka客戶端，提供服務的應用，可以是Spring Boot應用，也可以是其它任意技術實現，只要對外提供的是REST風格服務即 可。
搭建步驟，參考我的隨筆：https://www.cnblogs.com/kunmin/p/15097408.html，其中有比較重要的配置就是，
1、服務地址是否使用ip地址
2、續約時間的配置
3.服務消費者：也稱為Eureka客戶端，消費應用從注冊中心獲取服務列表，從而得知每個服務方的信息，知道去哪里調用服務方
搭建步驟參考隨筆：https://www.cnblogs.com/kunmin/p/15097408.html，服務消費端比較重要的就是：
1、服務拉取時間的配置
二：Ribbon
Spring Cloud Ribbon 是一個基於Http和TCP的客服端負載均衡工具，它是基於Netflix Ribbon實現的。它不像服務注冊中心、配置中心、API網關那樣獨立部署，但是它幾乎存在於每個微服務的基礎設施中，
就比如配置網關路由時，就指定了負載均衡，feign依賴里面也有對Ribbon的支持。負載均衡是對系統的高可用、網絡壓力的緩解和處理能力擴容的重要手段之一。常用的負載均衡策略：
1、輪詢Round Robin：對注冊的服務，輪流進行訪問
2、隨機Random：從服務列表里面隨機進行訪問
三，Hystrix：（服務容錯保護）
在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。
解決措施：
1、線程隔離：Hystrix為每個依賴服務調用分配一個小的線程池，如果線程池已滿調用將被立即拒絕，默認不采用排隊，加 速失敗判定時間。 用戶的請求將不再直接訪問服務，而是通過線程池中的空閑線程來訪問服務，如果線程池已滿，或者請求超 時，則會進行降級處理
2、服務降級：用戶的請求故障時，不會被阻塞，更不會無休止的等待或者看到系統崩潰，至少可以看到一個執行結果（例如返回友好的提示信息），有兩種情況會觸發服務降級，1、線程池已滿 ，2、請求超時
服務降級的案例，參考隨筆：https://www.cnblogs.com/kunmin/p/15097408.html，
Hystrix中，還有一個斷路器Circuit Breaker，當Hystrix Command請求后端服務失敗數量超過一定比例(默認50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會發送到后端服務. 斷路器保持在開路狀態一段時間后(默認5秒), 自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回情況, 如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN).下圖是斷路器模型。
Closed：關閉狀態（斷路器關閉），所有請求都正常訪問。
Open：打開狀態（斷路器打開），所有請求都會被降級。Hystrix會對請求情況計數，當一定時間內失敗請求 百分比達到閾值，則觸發熔斷，斷路器會完全打開。默認失敗比例的閾值是50%，請求次數最少不低於20 次。
Half Open：半開狀態，不是永久的，斷路器打開后會進入休眠時間（默認是5S）。隨后斷路器會自動進入半 開狀態。此時會釋放部分請求通過，若這些請求都是健康的，則會關閉斷路器，否則繼續保持打開，再次進 行休眠計時
四、Feign：
是一種聲明式、模板化的HTTP客戶端。我們在隨筆：https://www.cnblogs.com/kunmin/p/15097408.html中，最開始搭建微服務時，就是去訪問對應的url地址（如下圖），這種方式是十分機械的，而且拓展性不高。feign組件，就是解決這一問題的，他可以讓我們使用HTTP請求遠程服務時能與調用本地方法一樣的編碼體驗。使用feign優化服務消費者，參考博文:https://www.cnblogs.com/kunmin/p/15097408.html。
總之，feign就是更加優雅的調用遠程服務。
五、Gateway：（API網關服務）：作用：安全，路由，限流，監控
微服務一般，簡單的分為內部與邊緣之分，內部服務顧名思義是為對內暴露服務的結點，供架構內部來調用；邊緣服務是對外部網絡暴露的服務結點，也就是對外API接口。Gateway就是我們統一的入口。
GateWay，最要就是在於配置文件的編寫。常用的配置就是路由的id，一個提供服務的uri，一組斷言工廠，一組過濾器，如圖的配置就是如果路徑之中包含user，就會請求到名為User-service這個服務中。當然我們也可以配置一些過濾器（局部過濾器，全局過濾器，自定義過濾器），配置步驟參考隨筆：https://www.cnblogs.com/kunmin/p/15097408.html
六： Config分布式配置中心
分布式系統中，每一個功能模塊都能拆分成一個獨立的服務，一次請求的完成，可能會調用很多個服務協調來完成，為了方便服務配置文件統一管理，更易於部署、維護，所以就需要分布式配置中心組件了，在spring cloud中，有分布式配置中心組件spring cloud config，它支持配置文件放在在配置服務的內存中，也支持放在遠程Git倉庫里。我們的外部配置文件就可以集中放置在一個git倉庫里，再新建一個config server，用來管理所有的配置文件，維護的時候需要更改配置時，只需要在本地更改后，推送到遠程倉庫，所有的服務實例都可以通過config server來獲取配置文件，這時每個服務實例就相當於配置服務的客戶端config client。具體的搭建步驟，參考博文：https://www.cnblogs.com/kunmin/p/15097408.html。
七：spring cloud bus 消息總線
Spring Cloud Bus 將分布式的節點用輕量的消息代理連接起來。它可以用於廣播配置文件的更改或者服務之間的通訊，也可以用於監控。Spring cloud bus 通過輕量消息代理連接各個分布的節點。管理和傳播所有分布式項目中的消息，本質是利用了MQ的廣播機制在分布式的系統中傳播消息，目前常用的有Kafka和RabbitMQ。
配置文件更新的過程：搭建步驟看隨筆：https://www.cnblogs.com/kunmin/p/15097408.html
- 1、提交代碼觸發post請求給bus/refresh（需要提前安裝\otp_win64_23.0.exe和rabbitmq-server-3.8.5.exe）
- 2、server端接收到請求並發送給Spring Cloud Bus
- 3、Spring Cloud bus接到消息並通知給其它客戶端
- 4、其它客戶端接收到通知，請求Server端獲取最新配置
- 5、全部客戶端均獲取到最新的配置
以上就是自己目前所學習的微服務組件，如有不足請指出，至於如何搭建微服務框架，參考另一篇隨筆：https://www.cnblogs.com/kunmin/p/15097408.html