图片来自Pexels更进一步，为了支持弹性伸缩，微服务提供者的数量和分布往往是动态变化的，无法预先确定。因此，单体应用阶段常用的静态LB机制不再适用，需要额外引入一个组件来管理微服务提供者的注册和发现，这个组件就是服务注册中心。CAP理论CAP理论是分布式架构中的一个重要理论：一致性（Consistency），所有节点同时拥有相同的数据。可用性（Availability），保证每个请求无论成功或失败都有响应。分区容忍度（Partitiontolerance），系统中任何信息的丢失或故障都不会影响系统的继续运行。关于P的理解，我觉得是因为整个系统的某个部分挂了或者宕机了，不影响整个系统的运行或者使用，但是可用性是某个系统的某个节点是down，但不影响系统接受或请求。不可能拿走所有的CAP，只能拿走其中的两个。原因是如果C是第一个需求，会影响A的性能，因为需要数据同步，否则请求结果会不一样，但是数据同步会消耗时间，这段时间可用性会下降。如果A是第一个需求，那么只要有服务，就可以正常接受请求，但不能保证返回结果。原因是在分布式部署中，数据一致性的过程不能像切线那样快。.如果同时满足一致性和可用性，就很难保证分区的容错性，即单点性，这也是分布式的基本核心。那么，如果你了解了这些理论，你就可以在相应的场景中选择服务注册和发现。服务注册中心解决方案设计或选择服务注册中心，首先要考虑的是服务注册和发现机制。纵观目前主流的服务注册方案，大致可以分为三类：In-app：直接集成到应用中，依靠应用本身完成服务的注册和发现，最典型的是Eureka提供的Netflix。应用外：把应用看成一个黑盒子，通过应用外的某种机制把服务注册到注册中心，尽量减少对应用的侵入，比如Airbnb的SmartStack和HashiCorp的Consul。DNS：将服务注册为DNS的一条SRV记录，严格来说是一种特殊的应用外注册方式，SkyDNS就是其中的代表。注1：对于第一种注册方式，除了Eureka等一站式解决方案外，还可以基于ZooKeeper或etcd实现一套服务注册机制。这在大公司比较常见，但是对于小公司来说显然太划算了。低的。注2：由于DNS固有的缓存缺陷，本文不深入讨论第三种注册方式。除了基本的服务注册和发现机制，从开发和运维的角度至少要考虑以下五个方面：服务？负载均衡：当有多个服务提供者只有一个时，如何平衡每个提供者的负载？集成：如何在服务提供者或调用者处集成注册表？运行时依赖：引入注册中心后，对应用的运行环境会有什么影响？可用性：如何保证注册中心自身的可用性，尤其是杜绝单点故障？主流注册中心产品软件的产品特性并不是一成不变的，如果您发现功能特性有什么变化，欢迎评论指正：Consul支持自动注销服务实例，在勾选的DeregisterCriticalServiceAfter参数中。新版本的Dubbo也扩展了对Consul的支持。①ApacheZookeeper→CP不同于Eureka。ApacheZooKeeper在设计时紧跟CP原则，即任何时候对ZooKeeper的访问请求都能得到一致的数据结果，系统对网络分段具有容错性，但ZooKeeper不能保证每个服务请求都是可达的。从ZooKeeper的实际应用情况来看，在使用ZooKeeper获取服务列表时，如果此时ZooKeeper集群中的Leader宕机，集群将进行Leader选举。或者ZooKeeper集群中超过半数的服务器节点不可用（比如有3个节点，如果节点1检测到节点3宕机，节点2也检测到节点3宕机，那么这个节点就真的挂了下），然后是无法处理请求。因此，ZooKeeper无法保证服务的可用性。当然，在大多数分布式环境中，尤其是涉及到数据存储的环境中，首先要保证数据的一致性，这也是ZooKeeper在设计上紧跟CP原则的另一个原因。但是对于服务发现，情况就不同了。对于同一个服务，即使注册中心不同节点存储的服务提供者信息不同，也不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的。虽然消费者在获取到可能不正确的服务实例信息后尝试消费，但总比不消费好，因为获取不到实例信息，导致系统异常。好（淘宝的双十一和京东的618是紧跟AP的最佳参考）。当Master节点因网络故障与其他节点失去联系时，其余节点将重新选举Leader。问题是选举Leader的时间太长，30-120s，选举时整个ZooKeeper集群不可用，导致选举时注册服务瘫痪。在云部署环境下，ZooKeeper集群由于网络问题失去Master节点是大概率事件。虽然最终可以恢复服务，但是长时间的选举事件导致注册长时间不可用是不能容忍的。②SpringCloudEureka→APSpringCloudNetflix在设计Eureka时紧跟AP原则（虽然现在已经发布了2.0，但由于闭源，Ereka1.x还是比较活跃的）。EurekaServer也可以运行多个实例构建集群来解决单点问题，但是与ZooKeeper选举Leader的过程不同，EurekaServer采用PeertoPeer点对点通信。这是一个去中心化的架构，没有Master/Slave之分，每个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。默认依赖SDKConsul，本质上是一种应用外注册方式，但可以通过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配置中心。作者：祁岩编辑：陶家龙来源：http://45dwz.com/ax2HY
