《SpringCloud 从入门到入土 》 第3章：服务治理：Spring Cloud Eureka
简介：Spring Cloud Eureka 是Spring Cloud Netflix微服务套件中的一部分，他基于 Netflix Eureka做了二次封装，主要负责完成微服务架构中的服务治理功能。Spring Cloud通过为Eureka增加了Spring Boot风格的自动化配置，我们只需通过引入简单的依赖和注解配置就能让Spring Cloud构建的微服务应用轻松的与Eureka 服务治理体系进行整合。
1、服务治理
服务为什么需要治理？
早期的各个微服务之间相互调用，只是简单的A调用B，为了实现B的高可用，不论是服务端负载均衡还是客户端的负载均衡，我们需要手动维护B 的具体实例清单，随着业务的发展，系统功能越来越复杂，相应的微服务也越来越多，我们的静态配置也变得难以维护，所以我们需要一个注册中心，进行统一的微服务管理，这里所说的管理就是 服务的注册与发现。
服务注册：即所有的应用服务想注册中心，提供自己的详细信息，注入ip、端口、服务名称等信息。注册中心还需要以心跳的方式检测清单中的服务是否可用。
服务发现：当A需要调用B时，只需要向注册中心索取服务名叫做B 的所有服务即可，然后通过比如轮训调用策略进行调用。
2、Netflix Eureka
3、搭建服务注册中心
首先，创建一个基础的SpringBoot工程，引入必要的依赖：
并在SpringBoot项目主启动类加上@EnableEurekaServer注解启动一个服务注册中心提供给其他应用进行对话。
在默认配置下，该注册中心也会将自己作为客户端来尝试注册他自己，就是自己往自己本身进行注册，这无疑形成了套娃，大可不必。我们需要禁止它的客户端行为，只需在application.properties
中增加如下配置：
- eureka.client.register-with-eureka :由于该应用为注册中心，设置为false,标识不再想自己注册自己
- eureka.clinet.fetch-registry :表示是否从Eureka Server获取注册的服务信息，注册中心的职责本俩就是维护服务实力，他并不需要去服务端检索获取信息，因为它就是它自己。所以设置为false。
- eureka.clinet.serviceUrl.defaultZone :设置与Eureka Server交互的地址，查询服务和注册服务都需要依赖这个地址。多个地址可使用 " , "分隔 。
4、注册服务提供者
1）修改pom.xml增加Spring Cloud Eureka模块的依赖
2）主启动类上添加@EnableDiscoveryClinet 注解，启用服务注册发现功能。
3) 修改 application.properties 配置文件，设置name 应用名，和注册中心地址：
此时，启动该服务，可在注册中心发现该服务的注册信息。
5、高可用注册中心
单节点的注册中心在生产环境显然不合适，为了达到软件高可用的必要配置，我们需要多个Eureka相互注册，共享服务信息的同时并向其他服务提供发现服务的功能。
我们可以在刚才基础之上搭建一个高可用的注册中心：
通过spring.profile.active属性来分别启动peer1和peer2：
6、服务发现与消费
服务消费者主要有两方面：服务的发现 与 消费 ，其中服务的发现任务有Eureka客户端完成，而服务的消费任务有Ribbon完成 。 Ribbon是一个基于HTTP 和TCP的客户端负载均衡器，他可以通过客户端配置的ribbonServerList服务端列表去轮训访问已达到均衡负载的作用。当Ribbon与Eureka联合使用是，Ribbon的服务实力清单 RibbonServeList会被DicoveryEnableNIWSServerList重写，扩展成从Eureka注册中心获取服务列表。本章不对Ribbon做详细介绍，你只需要清除它在Eureka服务发现的基础之上，实现了一套对服务实力的选择策略，从而实现消费服务。
创建SpringBoot基础工程 构建消费者，取名为ribbon-consumer，
1）pom.xml引入依赖：
2）在主类添加@EnableDicoveryClinet注解 ：让该应用同样注册为Eureka客户端应用，以获得服务发现能力。
3）在主类中穿点RestTemplate的Spring Bean 实例，并通过@LoadBalanced注解开启客户端负载均衡。
4）创建C〇nsumerC〇ntr〇lle：类并实现/ribbon—consumer接口。在该接口中， 通过在上面创建的 RestTemplate来实现对 HELLO- SERVICE服务提供的 /hello接口进行调用。可以看到这里访问的地址是服务名HELLO-SERVICE，而 不是一个具体的地址，在服务治理框架中，这是一个非常重要的特性，也符合在本 章一开始对服务治理的解释。
在application .properties中配置Eureka服务注册中心的位置，需要与之前 的HELLO-SERVICE—样，不然是发现不了该服务的，同时设置该消费者的端口为 9000，不能与之前启动的应用端口冲突。
7、Eureka架构及服务治理机制详解
在上一节中，我们通过一个简单的服务注册于实例发现，构建了Eureka服务治理体系中的三个核心角色：服务注册中心、服务提供者以及服务消费者。通过上述示例，相信读者对于Eureka的服务治理机制已经有了初步认识。至此，我们已经学会了如何构建服务注册中心（包括单节点和高可用部署），也知道了如何使用Eureka的注解和配置将SpringBoot应用纳入Eureka的服务治理体系，成为服务提供者或服务消费者，同时对于客户端负载均衡的服务消费也有了一些简单的接触。但是，在实践中，我们的系统结构往往都要比上述复杂的多，我们还需要根据实际情况做一些配置、调整和扩展。
注册中心 - 服务提供者 - 服务消费者：
服务提供者：
服务注册：“服务提供者”在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上自身服务的一些元数据信息。Eureka Server 接收到这个REST请求之后，讲这些元数据信息存储到一个双层结构的Map中，其中第一层的key是服务名，第二层的key是具体的服务实例名。（我们可以回想一下之前在实现Ribbon负载的例子中，Eureka信息面板中一个服务有多个实例的情况，这些内容就是以这样的双层Map形式存储的。）
在服务注册时需要确认一下eureka.clinet.register-with-eureka=true参数是否正确，该值默认为true。若设置为false将不会启动注册操作，自然不会被其他消费者获得其信息。
服务同步：如架构图中所示，这里的两个服务提供者注册到了两个不同的服务注册中心上，也就是说，他们的信息分别被两个服务注册中心所维护。此时，由于服务注册中心之间银湖想注册为服务，当服务提供者发送注册请求到一个服务注册中心时，他会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心的任意一台获取到。
服务续约：
服务消费者：
获取服务：
服务调用：
服务下线：
注册中心：
失效剔除：
自我保护：