锐客网

  1. 首页 > 睿知 > it技术 > >

go语言服务注册与发现 golang consul服务发现和注册( 四 )

IT技术服务


;utm_campaign=client_sharewxshare_count=1timestamp=1546144777app=news_articleutm_source=weixiniid=55667270026utm_medium=toutiao_androidgroup_id=6639493728086000142
【知识总结】6.服务注册发现框架比较(Consul/Zookeeper/etcd/Eureka) 服务发现就是服务提供者将自己提供的地址post或者update到服务中介，服务消费者从服务中介那里get自己想要的服务的地址 。
但是有两个问题：
第一个问题：如果有一个服务提供者宕机，那么中介的key/value中会有一个不能访问的地址 ， 该怎么办？
心跳机制： 服务提供者需要每隔5秒左右向服务中介汇报存活，服务中介将服务地址和汇报时间记录在zset数据结构的value和score中 。服务中介需要每隔10秒左右检查zset数据结构，踢掉汇报时间严重落后的地址 。这样就可以保证服务列表中地址的有效性 。
第二个问题是服务地址变动时如何通知消费者 。有两种解决方案 。
第一种是轮询，消费者每隔几秒查询服务列表是否有改变 。如果服务地址很多，查询会很慢 。这时候可以引入服务版本号机制，给每个服务提供一个版本号，在服务变动时，递增这个版本号 。消费者只需要轮询这个版本号的变动即可知道服务列表是否发生了变化 。
第二种是采用pubsub 。这种方式及时性要明显好于轮询 。缺点是每个pubsub都会占用消费者一个线程和一个额外的连接 。为了减少对线程和连接的浪费 ， 我们使用单个pubsub广播全局版本号的变动 。所谓全局版本号就是任意服务列表发生了变动 ， 这个版本号都会递增 。接收到版本变动的消费者再去检查各自的依赖服务列表的版本号是否发生了变动 。这种全局版本号也可以用于第一种轮询方案 。
CAP理论
CAP理论是分布式架构中重要理论
关于P的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求，CAP 不可能都?。荒苋∑渲?个 。原因是
（1）如果C是第一需求的话 ， 那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低 。
（2）如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证 ， 原因是，在分布式部署的时候 ， 数据一致的过程不可能想切线路那么快 。
（3）再如果 ， 同事满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心，好了，明白这些理论，就可以在相应的场景选取服务注册与发现了 。
平时经常用到的服务发现的产品进行下特性的对比 ， 首先看下结论：
补充：
（1）运维和开发如果是 Java 更熟，也更多 Java 的应用，那毫无疑问应该用 ZK；如果是搞 Go 的，那么还是 etcd 吧，毕竟有时候遇到问题还是要看源码的 。
（2）在创建一百万个或更多键时，etcd可以比Zookeeper或Consul稳定地提供更好的吞吐量和延迟 。此外，它实现了这一目标，只有一半的内存，显示出更高的效率 。但是，还有一些改进的余地，Zookeeper设法通过etcd提供更好的最小延迟，代价是不可预测的平均延迟 。
（3）
一致性协议： etcd 使用 Raft 协议，Zookeeper 使用 ZAB（类PAXOS协议），前者容易理解 ， 方便工程实现；
运维方面：etcd 方便运维 ， Zookeeper 难以运维；
数据存储：etcd 多版本并发控制（MVCC）数据模型，支持查询先前版本的键值对

推荐阅读


上一篇：postgresql查询导出csv，plsql查询结果导出

下一篇：直播带货有什么税收，直播带货 收税