Spring Cloud有好幾個常用的相關框架組件如下：
Spring Cloud Eureka（服務治理）:
服務治理： 服務治理是微服務架構中最爲核心和基礎的模塊，它主要用來實現各個微服務實例的自動化註冊和發現。
服務註冊： 在服務治理框架中，通常都會構建一個註冊中心，每個服務單元向註冊中心登記自己提供的服務，包括服務的主機與端口號、服務版本號、通訊協議等一些附加信息。註冊中心按照服務名分類組織服務清單，同時還需要以心跳檢測的方式去監測清單中的服務是否可用，若不可用需要從服務清單中剔除，以達到排除故障服務的效果。
服務發現： 在服務治理框架下，服務間的調用不再通過指定具體的實例地址來實現，而是通過服務名發起請求調用實現。服務調用方通過服務名從服務註冊中心的服務清單中獲取服務實例的列表清單，通過指定的負載均衡策略取出一個服務實例位置來進行服務調用。
Spring Cloud Ribbon（客戶端負載均衡）:
Spring Cloud Ribbon 是一個基於Http和TCP的客服端負載均衡工具，它是基於Netflix Ribbon實現的。它不像服務註冊中心、配置中心、API網關那樣獨立部署，但是它幾乎存在於每個微服務的基礎設施中。包括前面的提供的聲明式服務調用也是基於該Ribbon實現的。理解Ribbon對於我們使用Spring Cloud來講非常的重要，因爲負載均衡是對系統的高可用、網絡壓力的緩解和處理能力擴容的重要手段之一。
Spring Cloud Hystrix（服務容錯保護）:
在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。
熔斷器模式就像是那些容易導致錯誤的操作的一種代理。這種代理能夠記錄最近調用發生錯誤的次數，然後決定使用允許操作繼續，或者立即返回錯誤。
Spring Cloud Feign（聲明式服務調用）:
Feign是一種聲明式、模板化的HTTP客戶端。在Spring Cloud中使用Feign, 我們可以做到使用HTTP請求遠程服務時能與調用本地方法一樣的編碼體驗，開發者完全感知不到這 是遠程方法，更感知不到這是個HTTP請求
Spring Cloud Zuul（API網關服務）:
過濾:安全、監控、限流、路由
基於Spring的微服務結點在能力上沒有高低貴賤之分，但是在角色上會分爲邊緣服務和內部服務兩部分。內部服務顧名思義是爲對內暴露服務的結點，供架構內部來調用；邊緣服務是對外部網絡暴露的服務結點，也就是對外API接口。
Spring Cloud Config（分佈式配置中心）:
在分佈式系統中，每一個功能模塊都能拆分成一個獨立的服務，一次請求的完成，可能會調用很多個服務協調來完成，爲了方便服務配置文件統一管理，更易於部署、維護，所以就需要分佈式配置中心組件了，在spring cloud中，有分佈式配置中心組件spring cloud config，它支持配置文件放在在配置服務的內存中，也支持放在遠程Git倉庫裏。引入spring cloud config後，我們的外部配置文件就可以集中放置在一個git倉庫裏，再新建一個config server，用來管理所有的配置文件，維護的時候需要更改配置時，只需要在本地更改後，推送到遠程倉庫，所有的服務實例都可以通過config server來獲取配置文件，這時每個服務實例就相當於配置服務的客戶端config client,爲了保證系統的穩定，配置服務端config server可以進行集羣部署，即使某一個實例，因爲某種原因不能提供服務，也還有其他的實例保證服務的繼續進行。
Spring Cloud Bus（消息總線）:
Spring Cloud Bus 將分佈式的節點用輕量的消息代理連接起來。它可以用於廣播配置文件的更改或者服務之間的通訊，也可以用於監控。
消息總線是一種通信工具，可以在機器之間互相傳輸消息、文件等。消息總線扮演着一種消息路由的角色，擁有一套完備的路由機制來決定消息傳輸方向。發送段只需要向消息總線發出消息而不用管消息被如何轉發。Spring cloud bus 通過輕量消息代理連接各個分佈的節點。管理和傳播所有分佈式項目中的消息，本質是利用了MQ的廣播機制在分佈式的系統中傳播消息，目前常用的有Kafka和RabbitMQ。
Spring Cloud Stream（消息驅動微服務）:
消息驅動理解： Windows消息是，當一個窗體或者控件需要讓另外一個窗體或者消息執行某個動作，就向那個窗體發一個消息，放到對方的消息隊列中，然後對方有一個消息循環不停的讀取消息隊列，並執行相應的動作。簡單的講就是一種生產者，消費者模式。發佈者是生產，將輸出發佈到數據中心，訂閱者是消費者，訂閱自己感興趣的數據。當有數據到達數據中心時，就把數據發送給對應的訂閱者。
Spring Cloud Sleuth（分佈式服務跟蹤）:
在微服務框架中，一個由客戶端發起的請求在後端系統中會經過多個不同的的服務節點調用來協同產生最後的請求結果，每一個前段請求都會形成一條複雜的分佈式服務調用鏈路，鏈路中的任何一環出現高延時或錯誤都會引起整個請求最後的失敗。
Spring Cloud Shiro（安全權限控制）:
1.外部請求統一從網關zuul進入，並且服務內部互相調用接口要校驗權限
2.cloud和shiro結合，達到單點登錄，和集中一個服務完成權限管理，其他業務服務不需要關注權限如何實現
3.其他服務依然可以控制權限細粒度到接口，如在接口上使用@RequirePermisson等註解，方便開發