RPC。目的是让远程调用像本地调用一样简单方便。它主要由客户端、服务器和注册中心三部分组成。那么，如何将服务端发布的接口暴露给客户端呢？客户端如何获取服务器的地址并创建连接来执行调用逻辑？本文将带大家通过一个Zookeeper引发的全链路服务雪崩的真实案例分析，来说明注册中心的生产场景诉求和选型原则。0.1注册中心如图所示，Provider主要向注册中心注册服务，并上报服务节点的心跳。消费者需要向注册中心订阅感兴趣的服务，并在本地缓存相应服务的节点信息，并接受来自注册中心的服务变更通知。注册中心的权限也很明确，就是维护服务信息和服务实例节点信息，同时监听服务节点的心跳，确认节点状态，当服务节点失效时从实例列表中移除节点状态不健康；同时，它负责在节点列表发生变化时进行通知。订阅者，为了实现服务更新及时和数据一致性0.2Zookeeperregistry实现方案ZK当时真的很火，当然现在也不错。很多年前，一位同事曾开玩笑说，只要在架构上使用了ZK，就可以称为分布式。ZK是经常提到的注册中心选择。那么ZK是如何实现注册中心的呢？能够持久化节点创建的节点。节点创建后一直存在，直到有删除操作主动清除节点。临时节点。将自己的生命周期与客户端状态绑定。如果客户端会话失败，该节点将被自动清除。注意这里说的是session失效，不是断开连接。监听通知的能力就是Watch机制。可以监控一个zk节点，包括该目录下存放的数据的修改和子节点目录的变化。一旦发生变化，可以通知设置为监视的客户端。这个功能是zookeeper对于应用最重要的特性。通过该特性可以实现的功能包括配置集中管理、集群管理、分布式锁等。ZK的以上两个关键能力，使其成为注册中心成为可能。Zookeeper注册中心如上图所示。ZK创建一个Service的持久化节点，在Service下创建Provider和Consumer两个子节点，也是持久化的；Provider和Consumer下挂着很多临时节点。每个临时节点，代表一个应用实例。这样方便根据实例状态动态增减。然后利用wtach机制监听服务端的心跳，通知客户端服务节点的变化，从而实现注册中心的全部能力。0.3使用Zookeeper真的合适吗？前段时间流传了一篇阿里为什么不用zookeeper做服务发现的文章。这里简单阐述一下涉及的要点：1.注册中心的高可用需求Q：注册中心在CAP中需要保证谁？是分区容差。分布式服务依赖网络进行节点连接。在发生任何网络分区故障时，仍然需要保证系统能够对外提供服务（一致性或可用性服务），除非整个网络环境发生故障。来源：www.w3cschool.cn/zookeeper/我们不允许孤立节点在节点间通信失败时无法提供服务。在最简单的情况下，所有节点都可以拥有所有数据。Q：在分区容错的前提下，注册中心应该保证一致性还是可用性？如果保证了一致性，是否能满足我们对系统的要求？来源：infoq.cn/article/why-doesnot-alibaba-use-zookeeper如图，如果ServiceA和ServiceB部署在3号机房，连接ZK5，由于网络异常，ZK5节点无法工作，而serviceB的实例无法注册，3号机房的serviceA无法正常调用ServiceB的任何实例，这是我们不想看到的。而如果保证可用性的话，因为机房的节点是连着的，所以调用是没有效果的，更符合我们的希望。但是zookeeper其实是执行了CP原则的。在leader选举过程中或者某些极端情况下，整个服务不可用。但是我们对注册表可用性的要求远大于数据一致性。也可以说在生产环境中，我们不能容忍注册中心出现故障来保证可用性。对实际生产的影响是灾难性的。2.注册中心的容灾需求在实践中，注册中心不能以任何理由破坏服务间的连通性。那么，如果整个注册表出现故障怎么办？但是zookeeper无法实现跨机房、跨region的容灾。因为它只能有一个领导者。3、服务规模和能力的增长。互联网的发展具有一定的零星性。当前节点和带宽上限可以满足业务发展。一年后会满意吗？三年后呢？ZK扛不住了还能横向扩展吗？0.4回顾Zookeeper引起的链接雪崩有些人可能认为以上几点是有道理的，但实际经验不多。但是，对于亲身经历过2015年京东大促全链路雪崩的我来说，感触很深。虽然那时候，我还是一个刚开始工作的孩子。历史回顾：在那个阳光明媚的早晨，因为促销活动已经大肆宣传，我和群里的老大们一大早就坐在电脑前监控系统指标。9点和10点，突然有的系统告警多了，有的机器频繁告警——注册中心连不上。打折中，赶快重启，试试看能不能解决。但是没用，更多的服务，更多的节点出现问题，异常从固定机房延伸到所有节点。我们知道注册中心应该是彻底挂了。我一直重启希望能重新连接到注册中心，但是没有用。后来平台上有同学说暂时不要重启，等通知吧。等了好久，终于可以重启了，果然，都连上了，不过黄花菜。..到底是怎么回事：一开始肯定是注册中心某个节点宕机了。是因为秒杀活动等节点的大规模扩张，还是带宽已经满了，现在不得而知。简而言之，它下跌了。因为Zookeeper保证了CP，所以此时只有那些连接到Leader的节点才能提供服务。所以在出现问题的机房，虽然业务服务器没问题，但是无法提供服务。但是用户的请求会很多，大量的请求会分流到正常机房的服务器上，导致业务系统出现故障。就算有了它，注册中心也被刷掉了。但是ZK不保证可用性，在leader选举的情况下无法正常服务。所以大量的业务系统同时想通过重启的方式重新连接到注册中心，或者连接不上，或者大量的写操作一起跑到注册服务节点，注册中心又被冲走了.毕竟想要保证高并发下节点创建的全局唯一性，就必须付出更多的系统资源。恶性循环就出现了，越重启越难翻身。..因此，当稍后平台需要批量重启时，注册中心即可恢复正常。0.5注册中心的选择综上所述，注册中心需要保证AP原则，需要考虑扩容和容灾。京东的注册中心优化方案：使用mysql+redis的KV形式替代zookeeper的树形形式；针对用户注册中心，对注册中心进行分段，实现横向扩展，支持容灾。Eureka2.0的实现Eureka2.0在解决方案上支持读写集群分离。蚂蚁的开源沙发注册中心也采用了这个思路。其实大家浏览一下就会发现，目前流行的开源注册中心其实都是朝着高可用、可扩展、容灾的方向进行的。摘自：blog.csdn.net/fly910905/article/details/100023415
