SpringCloud--Eureka搭建高可用注册中心

背景介绍
服务中心又称注册中心，管理各种服务功能包括服务的注册、发现、熔断、负载、降级等。
有了服务中心调用关系会有什么变化，画几个简图来帮忙理解

项目A调用项目B

正常调用项目A请求项目B

有了服务中心之后，任何一个服务都不能直接去掉用，都需要通过服务中心来调用

项目A调用项目B，项目B在调用项目C

这时候调用的步骤就会为两步：第一步，项目A首先从服务中心请求项目B服务器，然后项目B在从服务中心请求项目C服务。

由于各种服务都注册到了服务中心，就有了去做很多高级功能条件。比如几台服务提供相同服务来做均衡负载；监控服务器调用成功率来做熔断，移除服务列表中的故障点；监控服务调用时间来对不同的服务器设置不同的权重等等。

Eureka
Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现。Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用 Eureka 的客户端连接到 Eureka Server，并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。Spring Cloud 的一些其他模块（比如Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。
Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。

上图简要描述了Eureka的基本架构，由3个角色组成：

1、Eureka Server
提供服务注册和发现
2、Service Provider
服务提供方
将自身服务注册到Eureka，从而使服务消费方能够找到
3、Service Consumer
服务消费方
从Eureka获取注册服务列表，从而能够消费服务

Eureka Server 搭建

首先创建一个主Maven工程，在其pom文件引入依赖，spring Boot版本为2.0.3.RELEASE，Spring Cloud版本为Finchley.RELEASE。这个pom文件作为父pom文件，起到依赖版本控制的作用，其他module工程继承该pom。

再创建2个子工程一个model工程作为服务注册中心，即Eureka Server,另一个作为Eureka Client。

Eureka Server pom文件继承了父pom文件，并引入spring-cloud-starter-netflix-eureka-server的依赖

启动一个服务注册中心，只需要一个注解@EnableEurekaServer，这个注解需要在springboot工程的启动application类上加：

配置文件
server.port=8761
#指定主机名称
eureka.instance.hostname=localhost
eureka.client.registerWithEureka=false
eureka.client.fetchRegistry=false
eureka.client.serviceUrl.defaultZone=http://$eureka.instance.hostname:${server.port}/eureka/

eureka.client.register-with-eureka ：表示是否将自己注册到Eureka Server，默认为true。
eureka.client.fetch-registry ：表示是否从Eureka Server获取注册信息，默认为true。
eureka.client.serviceUrl.defaultZone ：设置与Eureka Server交互的地址，查询服务和注册服务都需要依赖这个地址。默认是http://localhost:8761/eureka ；多个地址可使用 , 分隔。

启动服务 查看http://localhost:8761 ,界面如下：
此时服务中心没有发现服务

创建Eureka Clien
当client向server注册时，它会提供一些元数据，例如主机和端口，URL，主页等。Eureka server 从每个client实例接收心跳消息。 如果心跳超时，则通常将该实例从注册server中删除。

新建client工程pom文件如下

通过注解@EnableEurekaClient 表明自己是一个eurekaclient.

@EnableEurekaClient是不够的，还需要在配置文件中注明自己的服务注册中心的地址，application.yml配置文件如下：
#服务提供者 (eureka client)
server.port=8763
#服务名称
spring.application.name=service-hi
#注册中心地址
eureka.client.serviceUrl.defaultZone=http://peer1:8761/eureka/

需要指明spring.application.name,在以后的服务与服务之间相互调用一般都是根据这个name 。
启动工程，打开http://localhost:8761 ，即eureka server 的网址：

一个服务已经注册在服务中了，服务名为SERVICE-HI ,端口为8763
这时打开 http://localhost:8763/hi?name=forezp ，在浏览器上看到 :

eureka集群
注册中心这么关键的服务，如果是单点话，遇到故障就是毁灭性的。在一个分布式系统中，服务注册中心是最重要的基础部分，理应随时处于可以提供服务的状态。为了维持其可用性，使用集群是很好的解决方案。Eureka通过互相注册的方式来实现高可用的部署，所以我们只需要将Eureke Server配置其他可用的serviceUrl就能实现高可用部署。

在生产中我们可能需要三台或者大于三台的注册中心来保证服务的稳定性，配置的原理其实都一样，将注册中心分别指向其它的注册中心。这里只介绍三台集群的配置情况，每台注册中心分别又指向其它两个节点即可，使用application.yml来配置。

1、创建application-peer1.yml，作为peer1服务中心的配置，并将serviceUrl指向peer2，peer3

2、创建application-peer2.yml，作为peer2服务中心的配置，并将serviceUrl指向peer1，peer3

3、创建application-peer3.yml，作为peer3服务中心的配置，并将serviceUrl指向peer1，peer2

4、本机电脑host文件转换

在hosts文件中加入如下配置：
127.0.0.1 peer1
127.0.0.1 peer2
127.0.0.1 peer3

5.IDEA分别以peer1、peer2、peer3的配置参数启动eureka注册中心。

启动后注册中心如下：

可以在peer1中看到了peer2、peer3的相关信息。至此eureka集群也已经完成了。

Eureka与Zookeeper比较
著名的CAP理论支出，一个分布式系统不可能同时满足C（一致性）、A（可用性）和P（分区容错性）。由于分区容错性在分布式系统中必须要保证的，因此我们只能在A和C之间权衡。

Zookeeper保证CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是ZK会出现这样的情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举learder的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现网络故障，此时会出现以下几种情况：
1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
3、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。