这是我参与8月更文挑战的第18天，活动详情查看：8月更文挑战
Zookeeper导致的链路雪崩回顾
可能有的人对上述提及的点觉得很有道理，但是没有多少实际感受。
然而，对于亲身经历过2015年JD 大促时全链路雪崩的我来说，却感触颇深。
虽然那时候的我，还是个刚参加工作不久的孩子。
历史回顾：
那个风和日丽的上午，因为促销活动早就漫天宣传，我和组里的大佬们，早早的就坐在电脑前监控系统指标。
9、10点钟，突然有一部分系统报警变多，其中的一部分机器频繁报警--连不上注册中心。
正促销呢，快，重启一下，试试能不能解决。
然而没用，更多的服务，以及更多的节点出现问题，异常从固定的机房扩展到了全部节点。
我们知道，注册中心应该是全挂了。
不断的重启希望重连注册中心，然并卵。
后来有平台的同学说先暂时不要重启，等待通知。经过漫长的等待，终于，可以重启了，果然，都连上了，但是，黄花菜。。。
到底发生了什么：
刚开始，一定是注册中心某一节点挂了，是因为秒杀活动等节点大量扩容，还是带宽打满现在不得而知了，总之是挂了。
因为Zookeeper保证的是CP，那此时只有连接Leader的那些节点能提供服务。所以，出现问题的机房，虽然业务服务器都没问题，但是没法提供服务。
可是，用户请求不会少，大量的请求被分流到了正常的机房的服务器上，业务系统扛不住挂了。连带着吧注册中心也冲垮了。
然而，ZK不保证可用性，在选举Leader等情况下是没法正常服务的。
所以，大量的业务系统同一时间想通过重启重连注册中心，要么是连不上，要么，大量写操作一起去注册服务节点，再次把注册中心冲垮。
毕竟，想要保证在高并发情况下节点创建的全局唯一，必然要付出更多的系统资源。
恶性循环出现了，越重启，越起不来。。。
所以，后面当平台要求分批重启，才使得注册中心得以恢复正常。
0.5注册中心的选型
综上所述，注册中心是需要保证AP原则，需要考虑扩容和容灾。
JD的注册中心优化方案：
用mysql+redis 的KV形式，代替了zookeeper的树状形式；用户注册中心寻址来对注册中心分片，以实现水平扩展，并支持容灾。
Eureka2.0的实现
Eureka2.0在方案上支持读写集群的分离，这个思路也被蚂蚁开源的sofa注册中心中采用。
其实，大概浏览一下就会发现，当前比较火的开源注册中心，其实都是按高可用，可扩展，可容灾恢复的方向上进行的。
