前言服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何微服务，原则上都应该存在或支持多个提供者，这是由微服务的分布式特性决定的。此外，为了支持弹性伸缩，微服务提供者的数量和分布往往是动态变化的，无法预先确定。因此，单体应用阶段常用的静态LB机制不再适用，需要额外引入一个组件来管理微服务提供者的注册和发现，这个组件就是服务注册中心。CAP理论CAP理论是分布式体系结构中的一个重要理论。一致性（所有节点同时拥有相同的数据）可用性（Availability）（确保每个请求无论成功或失败都有响应）分区容忍度（Partitiontolerance）（系统中任何信息的丢失或失败将不影响系统的继续运行。）关于P的理解，我认为是整个系统的某个部分挂掉或者死机，不影响整个系统的运行或者故障。说到使用，但是可用性就是某个系统的某个节点挂了，但是不影响系统的接受或者请求。不可能拿所有的CAP，只能拿两个。原因是如果C是第一个需求，那么会影响A的性能，因为需要数据同步，否则请求结果会不一样，但是数据同步会消耗时间，期间可用性会下降。如果A是第一个需求，那么只要有服务，就可以正常接受请求，但不能保证返回结果。原因是在分布式部署中，数据一致性的过程不能像切线那样快。.而同事如果满足一致性和可用性，就很难保证分区容错，也就是单点，这也是分布式的基本核心。那么，如果你了解了这些理论，你就可以在相应的场景中选择服务注册和发现ServiceRegistrySolution要设计或选择服务注册中心，首先要考虑的是服务注册和发现机制。纵观目前主流的服务注册解决方案，大致可以分为三类：In-app：直接集成到应用中，依靠应用本身完成服务的注册和发现，最典型的就是提供的Eureka应用Netflix:把应用当成黑盒，通过应用外的某种机制把服务注册到注册中心，尽量减少对应用的侵入，比如Airbnb的SmartStack，HashiCorp的ConsulDNS：把服务注册成DNSSRV记录，严格说起来，是一种应用外的特殊注册方式，SkyDNS就是代表之一。这在大公司比较常见，但是对于小公司来说显然太划算了。注2：由于DNS固有的缓存缺陷，本文不深入讨论第三种注册方式。除了基本的服务注册和发现机制外，从开发和运维的角度，至少要考虑以下五个方面：测试上线：服务注册后，如何测试上线服务，确保服务的可用性？负载均衡：当有多个服务提供者时，如何平衡每个提供者的负载？集成：如何集成服务商或调用方的注册中心？运行时依赖：引入注册中心后，对应用的运行环境会有什么影响？可用性：如何保证注册中心本身的可用性，尤其是杜绝单点故障？主流注册中心产品的软件产品特性并不是一成不变的。如果您发现功能特性有任何变化，请评论并更正。Consul支持自动注销服务实例。请看文档：https://www.consul.io/api-doc...，在检查DeregisterCriticalServiceAfter参数中——感谢菜鸟博主@超巧的新手博主提供最新信息。新版本的Dubbo也扩展了对Consul的支持。参考：https://github.com/apache/dub...ApacheZookeeper->CP与Eureka不同。ApacheZookeeper在设计上遵循CP原则，即对Zookeeper的访问请求在任何时候都可以保持一致。同时系统对网络分段是容错的，但是Zookeeper不能保证每个服务请求都是可达的。从Zookeeper的实际应用来看，在使用Zookeeper获取服务列表时，如果此时Zookeeper集群中的Leader宕机，则集群将被选举为Leader，或者Zookeeper集群中服务器节点的一半以上不可用（比如有三个节点，如果节点一检测到节点三挂了，节点二也检测到节点三挂了，那么这个节点就真的挂了），那么这个请求就不会被处理。因此，Zookeeper无法保证服务的可用性。当然，在大多数分布式环境中，尤其是涉及到数据存储的环境中，首先要保证数据的一致性，这也是Zookeeper在设计上紧跟CP原则的另一个原因。但是对于服务发现，情况就不同了。对于同一个服务，即使注册中心不同节点存储的服务提供者信息不同，也不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的。虽然消费者在获取到可能不正确的服务实例信息后尝试消费，但总比不消费好，因为获取不到实例信息，导致系统异常。做个好人（淘宝的双十一和京东的618是紧跟AP的最佳参考）。当主节点因网络故障与其他节点失去联系时，其余节点将重新选举领导者。问题是leader选举时间太长，30~120s，选举时整个zk集群不可用，导致选举时注册服务瘫痪。在云部署环境下，zk集群由于网络问题失去主节点是大概率事件。虽然最终可以恢复服务，但是长时间的选举事件导致注册长时间不可用是不能容忍的。SpringCloudEureka->APSpringCloudNetflix在设计Eureka时紧跟AP原则（虽然现在已经发布了2.0，但由于闭源，Ereka1.x还是比较活跃的）。EurekaServer也可以运行多个实例构建集群来解决单点问题，但与ZooKeeper的leader选举过程不同，EurekaServer采用PeertoPeer点对点通信。这是一个去中心化的架构，没有主从之分，每个Peer都是平等的。在这种架构风格中，节点相互注册以增加可用性，每个节点都需要添加一个或多个指向其他节点的有效serviceUrls。每个节点都可以被认为是其他节点的副本。在集群环境下，如果某个EurekaServer宕机，EurekaClient的请求会自动切换到新的EurekaServer节点上。当宕机的服务器恢复后，Eureka会重新将其纳入服务器集群管理。当一个节点开始接受客户端请求时，所有操作将在节点之间复制（replicateToPeer），请求将被复制到EurekaServer当前已知的所有其他节点。当一个新的EurekaServer节点启动时，它会首先尝试从相邻节点获取所有注册列表信息并完成初始化。EurekaServer通过getEurekaServiceUrls()方法获取所有节点，并通过心跳合约周期性更新。默认情况下，如果EurekaServer在一定时间内（默认30秒）没有收到服务实例的心跳，EurekaServer会注销该实例（默认90秒，eureka.instance.lease-expiration-duration-in-seconds用于自定义配置）。当EurekaServer节点短时间内丢失过多心跳时，节点会进入自我保护模式。在Eureka集群中，只要还有一个Eureka，就可以保证注册服务（guaranteedavailability），但是查到的信息不一定是最新的（不保证强一致性）。此外，Eureka还具有自我保护机制。如果超过85%的节点在15分钟内没有正常心跳，则Eureka认为客户端与注册中心之间存在网络故障。此时会出现以下情况：情况：Eureka不再从注册中心移除过期的服务，因为它已经很久没有收到心跳了；Eureka仍然可以接受新的服务注册和查询请求，但不会同步到其他节点（即保证当前节点仍然可用）；当网络稳定时，会将当前实例新注册的信息同步到其他节点；因此，Eureka可以很好地处理部分节点因网络故障而失去联系的情况，不会像zookeeper一样让整个注册服务瘫痪。ConsulConsul是HashiCorp推出的一款开源工具，用于分布式系统的服务发现和配置。Consul是用Go语言编写的，所以它天然具有便携性（支持Linux、windows和MacOSX）。Consul内置了服务注册和发现框架、分布式一致性协议实现、健康检查、Key/Value存储和多数据中心解决方案。不再需要依赖其他工具（如ZooKeeper等），使用起来也比较简单。Consul遵循CAP原则中的CP原则来保证强一致性和分区容错，并使用Raft算法，比zookeeper使用的Paxos算法更简单。虽然保证了强一致性，但是可用性也相应降低了。比如服务注册时间会稍微长一些，因为Consul的raft协议要求必须有一半以上的节点写入成功才算注册成功；leader挂掉后，Consul服务将不可用，直到重新选举leader。Consul本质上是一种应用外的注册方式，但可以通过SDK简化注册流程。另一方面，服务发现默认依赖SDK，但可以通过ConsulTemplate（下文提到）去除SDK依赖。ConsulTemplateConsul，默认的服务调用者需要依赖ConsulSDK发现服务，不能保证对应用零侵入。幸运的是，通过ConsulTemplate，可以定时从Consul集群中获取最新的服务提供者列表，并刷新LB配置（比如nginx的upstream），这样服务调用方只需要配置一个统一的服务调用地址即可。Consul的强一致性（C）带来：服务注册比Eureka略慢。因为Consul的raft协议要求必须有一半以上的节点写入成功才算注册成功。当leader挂掉后，整个consul在改选期间不可用。保证了强一致性，但牺牲了可用性。Eureka保证高可用（A）和最终一致性：服务注册比较快，因为不需要等待注册信息复制到其他节点，不保证注册信息是否复制成功。当数据不一致时，虽然A和B上注册的信息不完全一样，但是每个Eureka节点仍然可以正常对外提供服务。查询服务信息时，如果请求A找不到，但是请求B可以找到。这以牺牲一致性为代价来保证可用性。在其他方面，eureka是一个运行在servlet容器中的servlet程序；Consul是用go写的。NacosNacos由阿里开源。Nacos支持基于DNS和基于RPC的服务发现。在SpringCloud中使用Nacos，只需要先下载Nacos并启动Nacos服务器即可。Nacos只需要简单的配置就可以完成服务的注册和发现。除了服务注册和发现，Nacos还支持动态配置服务。动态配置服务允许您集中化、外部化和动态管理所有环境的应用配置和服务配置。动态配置无需在配置更改时重新部署应用程序和服务，使配置管理更加高效和敏捷。配置集中管理，更容易实现无状态服务，更容易让服务按需弹性扩展。一句话，Nacos=SpringCloud注册中心+SpringCloud配置中心。来源：blog.csdn.net/fly910905/article/details/100023415
