服务注册中心

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

在建立springcloud的项目的时候，一定要注意全局依赖和springboot之间的版本号约束
最新版本号约束信息

<properties>
    <spring.cloud-version>Hoxton.SR8</spring.cloud-version>
</properties>
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring.cloud-version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

服务注册中心
所谓服务注册中心就是在整个的微服务架构中单独提出一个服务，这个服务不完成系统的任何的业务功能，仅仅用来完成对整个微服务系统的服务注册和服务发现，以及对服务健康状态的监控和管理功能。

常用的注册中心：eureka，consul，zookeeper以及阿里巴巴的nacos。

eureka的自我保护机制
当eureka在一定的时间比例没有收到服务心跳时，会将实例移除。但是在网络分区出现故障的时候，实例实际上是健壮的，但是不能及时传递心跳而导致被移除，所以会出现eureka的自我保护机制。

Eurekaserver在运行期间会去统计服务心跳比列在15分钟之内是否低于85%，若低于，eurekaserver会将这些实例保护起来，让这些实例不会过期。

consul
consul是一个可以提供服务发现，健康检查，多数据中心，key/value存储等功能的分布式服务框架，用于实现分布式系统的服务发现与配置，与其他分布式服务注册与发现的方案，使用起来也较为简单。

要使用consul客户端必须引入健康检查依赖，如果没有引入这个依赖，及时服务可用，但是在consul服务注册中获取不到服务状态，consul注册中心始终认为不可用

不同服务注册中心的区别
CAP定理：
指的是在一个分布式系统中，一致性，可用性，分区容错性。CAP原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
可用性：在集群中一部分结点故障后，集群整体是非还能响应客户端的读写请求。
分区容忍性：就是高可用性，一个节点崩了，并不影响其他的结点

Eureka特点：Eureka中没有使用任何的数据强一致性算法保证不同集群间的server的数据一直，仅通过数据拷贝的方式争取注册中心数据的最终一致性，虽然放弃数据强一致性但是换来了server的可用性，降低了注册的代价，提高了集群运行的健壮性。

Consul特点：基于Raft算法（数据强一致性算法），consul提供强一致性的注册中心服务，但是由于Leader结点承担了所有的处理工作，势必加大而来注册和发现的代价，降低了服务的可用性。通过Gossip协议，Consul可以很好地监控consul集群的运行，同时可以方便通知各类事件，如leader选择发生，server地址变更等。

Zookeeper特点：基于zab协议，zookeeper可以用于构建具备数据请一致性的服务注册与发现中心，而与此相对地牺牲了服务的可用性和提高了注册需要的时间。