注册中心技术选型分析
本文是对微服务中，注册中心的技术选型的一些思考和分析，部分技术比如etcd，本人没有在生产环境使用过，所以部分结论的得出，是在阅读了大量的资料后得出的结论。如eureka，在实际中，很多小项目，其实就是一个单点的eureka做注册中心，也没发生过什么生产事故，但就技术调研和技术储备而言，我们不能只考虑理想的场景，了解各种技术的优缺点，用的时候，起码知道这个技术的短板和可能带来的一些问题，这样在用户体量起来后，可以清晰的知道面临的瓶颈和优化方向。
文章是站在调研consul时，看其他产品的短板来看的，每个产品都有自己的长短版，如果短板对自己业务无负面影响，或者影响可接受，那选型时就问题不大。
1.eureka
1.单点问题
eureka需要部署服务，服务自身需要做集群，增加了系统部署的复杂性。
2.数据同步
各服务之间数据同步是异步的，定时的，这会导致节点间一定时间内，数据不一致；并且，在数据复制的过程中，如果持有新实例注册信息的注册中心自身挂掉了，这个实例就无法得到注册；
3.自我保护机制
注册中心自身如果监测到某个实例的心跳成功比例一定时间内小于一定的阈值，这个实例注册信息会被保护起来，不会注销掉，等到这个心跳成功比例大于阈值时，退出自我保护机制。在这个保护期内，如果服务挂了，那这个实例信息其实时有问题的，应该被剔除。
4.心跳压力
如果注册中心注册的实例过多，比如500个，每个间隔30s发出一次续约心跳，那30s内，就是15000个心跳连接，这个心跳的请求可能大于实际业务发出的请求。
5.健康检查机制
健康检查比较单一，仅仅检查心跳是不够的，心跳还在，说明服务进程没死，那服务所在的硬件问题如内存满载，关联的db挂了等，这些都无法得到反应，所以服务可能并不能提供服务了，但是服务还在注册中心的列表中。
维护风险
官方宣布2.0的开源工作停止了，继续使用的责任自负。
2.zookeeper
1.重
java开发，引入依赖多，对于服务器而言太重，部署复杂，不支持多数据中心。对服务侵入大。
2.健康检查
检查方式单一，需要消费者自己实现，也是靠心跳连接保活，连接断开，就是服务挂了，服务就会被剔除。
3.更新
非常稳定，更新少，微服务架构下，对于做专业的注册中心而言，功能匮乏，丧失了快速迭代的能力，不够与时俱进，不够灵活。
4.算法
paxos算法，复杂难懂。
3.etcd
未使用过，资料了解，其本质上是一个比zk轻量的分布式键值对存储系统，但是需要搭配其他小工具才能较好较易用的实现注册中心功能。但是，为了实现A功能，又额外引入了B和C工具，不是一个优雅的实现方案，而且不支持多数据中心,无web管理页面。
4.consul
1.数据一致性
raft算法，实现思路从源头上避免了数据不一致性。注册时，超过半数没有拿到信息，那就注册失败。
2.开箱即用
集成简单，不依赖其他工具，使用也简单，支持2种服务注册方式：配置文件，http api。
3.kv存储
支持和zk和etcd一样的kv存储，可做配置中心。
4.健康检查
健康检查支持好，提供多种健康检查功能，比如服务返回的状态码，内存利用率等。
5.心跳
服务状态的检查，不是直接向注册中心发心跳，而是agent向服务发出健康监测。
6.web管理页面
官方提供良好的web管理页面。
7.活跃
社区很活跃，更新频繁。
consul相关资料汇总：Consul相关资料
5.Nacos
这个最近也挺火，待了解。
consul中有个问题，服务异常退出时的服务剔除，这个待研究，还没看到原理讲解。