1、配置中心
配置中心一般用作系統的參數配置，它需要滿足如下幾個要求：高效獲取、實時感知、分佈式訪問。
zookeeper 配置中心
實現的架構圖如下所示，採取數據加載到內存方式解決高效獲取的問題，藉助 zookeeper 的節點監聽機制來實現實時感知。
配置中心數據分類
2、事件調度（kafka）
消息服務和事件的統一調度，常用用 kafka ，activemq 等。
3、服務跟蹤（starter-sleuth）
隨着微服務數量不斷增長，需要跟蹤一個請求從一個微服務到下一個微服務的傳播過程， SpringCloud Sleuth 正是解決這個問題，它在日誌中引入唯一 ID，以保證微服務調用之間的一致性，這樣你就能跟蹤某個請求是如何從一個微服務傳遞到下一個。
1. 爲了實現請求跟蹤，當請求發送到分佈式系統的入口端點時，只需要服務跟蹤框架爲該請求創建一個唯一的跟蹤標識，同時在分佈式系統內部流轉的時候，框架始終保持傳遞該唯一標識，直到返回給請求方爲止，這個唯一標識就是前文中提到的 Trace ID。通過 Trace ID 的記錄，我們就能將所有請求過程日誌關聯起來。
2. 爲了統計各處理單元的時間延遲，當請求達到各個服務組件時，或是處理邏輯到達某個狀態時，也通過一個唯一標識來標記它的開始、具體過程以及結束，該標識就是我們前文中提到的 Span ID，對於每個 Span 來說，它必須有開始和結束兩個節點，通過記錄開始 Span 和結束 Span 的時間戳，就能統計出該 Span 的時間延遲，除了時間戳記錄之外，它還可以包含一些其他元數據，比如：事件名稱、請求信息等。
3. 在快速入門示例中，我們輕鬆實現了日誌級別的跟蹤信息接入，這完全歸功於spring-cloud-starter-sleuth 組件的實現。在 Spring Boot 應用中，通過在工程中引入 spring-cloud-starter-sleuth 依賴之後， 它會自動的爲當前應用構建起各通信通道的跟蹤機制，比如：
通過諸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 綁定器實現的消息中間件）傳遞的請求。
通過 Zuul 代理傳遞的請求。
通過 RestTemplate 發起的請求。
4、服務熔斷（Hystrix）
在微服務架構中通常會有多個服務層調用，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以後的多個調用快速失敗，不再訪問遠程服務器，從而防止應用程序不斷地嘗試執行可能會失敗的操作，使得應用程序繼續執行而不用等待修正錯誤，或者浪費 CPU時間去等到長時間的超時產生。熔斷器也可以使應用程序能夠診斷錯誤是否已經修正，如果已經修正，應用程序會再次嘗試調用操作。
Hystrix 斷路器機制
斷路器很好理解, 當 Hystrix Command 請求後端服務失敗數量超過一定比例(默認 50%),，斷路器會切換到開路狀態(Open)，這時所有請求會直接失敗而不會發送到後端服務，斷路器保持在開路狀態一段時間後(默認 5 秒)， 自動切換到半開路狀態(HALF-OPEN).，這時會判斷下一次請求的返回情況,如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN)。 Hystrix 的斷路器就像我們家庭電路中的保險絲, 一旦後端服務不可用, 斷路器會直接切斷請求鏈, 避免發送大量無效請求影響系統吞吐量, 並且斷路器有自我檢測並恢復的能力。
5、API 管理
SwaggerAPI 管理工具。