Eureka服務治理
在Eureka服務治理的框架中，有三種角色，服務注冊中心、服務提供者、服務消費者。
1. 服務注冊中心
Eureka服務端，支持高可用配置，能夠集群部署，在Eureka服務治理設計中，所有節點既是服務提供方，也是服務消費方，服務注冊中心也不例外。不同注冊中心相互注冊，以實現服務清單的互相同步。
每個服務單元向注冊中心登記自己提供的服務，將主機與端口號信息告訴注冊中心，注冊中心按服務名分類組織服務清單。注冊中心會通過心跳的方式去監測清單中的服務是否可用。
Eureka客戶端既可以作為服務提供者也可以作為服務消費者，當是服務提供者的時候，進行服務的注冊，當時服務消費者的時候進行服務的發現。
2. 服務提供者
作為一個微服務應用向服務注冊中心發布自己，也就是進行服務的注冊。在配置文件中指定服務命名和服務注冊中心的地址，如果注冊中心是集群部署，那么就在此指定多個注冊中心的地址。
3. 服務消費者
完成發現服務和消費服務
發現服務：服務的發現任務是由Eureka的客戶端完成，在服務治理的框架下，服務間的調用不再通過具體的實例地址來實現，而是通過向服務名發起請求調用實現。服務調用方在調用服務提供方接口的時候，並不知道具體的服務實例位置。因此，調用方需要向服務注冊中心咨詢服務，並獲取這個服務所有的實例清單。
消費服務：服務消費人物由Ribbon完成，它是一個客戶端負載均衡器，當發起服務調用的的時候，就會從服務清單中以某種輪詢的策略取出一個位置來進行服務調用。
Eureka主要適用於通過java實現的分布式系統，但是由於Eureka服務端的服務治理機制提供了完備的RESTful API，所有它也支持將非java語言構建的微服務應用納入Eureka的服務治理體系中來。
Ribbon
Ribbon可以讓我們輕松的將面向服務的REST模板請求自動轉換成客戶端負載均衡的服務調用，它不需要像注冊中心、網關那樣獨立部署，它幾乎存在每一springcloud構建的微服務和基礎設施當中，微服務之間的調用，API網關的請求轉發實際上都是Ribbon實現，包括Feign。
通過Ribbon的封裝，使用客戶端負載均衡調用非常簡單：
1） 服務提供者啟動多個服務實例並注冊到一個注冊中心或是多個相關聯的服務注冊中心
2） 服務消費者直接通過調用@LoadBalance注解修飾過的RestTemplate來實現面向服務的接口調用。
注：客戶端負載均衡和服務端負載均衡的區別？
服務器端負載均衡：例如Nginx，通過Nginx進行負載均衡，通過維護一個可用的服務端清單，通過心跳檢測來剔除故障的服務端節點以保證清單中都是可以正常訪問的服務端節點。當客戶發送請求到負載均衡設備的時候，
該設備按某種算法（比如線性輪詢、按權重負載、按流量負載等）從維護的可用服務清單中取出一台服務端的地址，然后進行轉發。
客戶端負載均衡：例如spring cloud中的ribbon，最大的不同點在於上面提到的服務清單所在的位置，在客戶端負載均衡中，所有客戶端節點都維護着自己要訪問的服務端清單，而這個清單來自於服務注冊中心。
同服務端負載均衡的架構類似，在客戶端負載均衡中也需要心跳去維護服務端清單的健康性。在發送請求前通過負載均衡算法選擇一個服務器，然后進行訪問，這是客戶端負載均衡；