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，最大的不同点在于上面提到的服务清单所在的位置，在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这个清单来自于服务注册中心。
同服务端负载均衡的架构类似，在客户端负载均衡中也需要心跳去维护服务端清单的健康性。在发送请求前通过负载均衡算法选择一个服务器，然后进行访问，这是客户端负载均衡；