微服务架构中常用的解决方案，总结了传统服务发现方案

Gossip协议常用于集群组关系管理和故障检测，每个节点都通过一个或多个引导节点加入集群，引导节点有集群中所有节点列表，每个节点都从自己所知节点列表中随机选择一组节点周期性地发送多播消息，最终集群中所有节点都能知道其他节点。这个过程看起来很神奇，实际上Gossip协议能在几秒内将消息传遍有上百节点的集群。Akka、Riak、Cassandra都使用Gossip协议维护集群成员列表和故障探测。

此外Consul和Etcd都非常适合容器环境，因为Docker容器启动、停止都会发送事件(Event)，基于事件通知机制非常便于将服务实例从Consul或Etcd上注册、注销。

总结

本文总结了传统服务发现方案如DNS、mDNS以及微服务架构中常用的解决方案，基于Zookeeper、Etcd、Consul框架方案核心思想是通过一组实例(3个或者5个)提供线性强一致性(Linearizable)分布式高可用Key-Value存储服务，将Key-Value存储作为服务注册中心，当相关Key发生变化时监视器能及时通知客户端，通知机制配合服务健康检查当有服务实例启动或故障时客户端能及时感知服务拓扑变化以实现智能路由，从实现方式上看它们可以看作是中心化的服务发现方案。

其实对于服务发现来说线性强一致性并不是唯一必须的，最终一致性在数据传播足够快的情况下一样能满足需求，实践中Gossip协议即使在大型集群也能快速传播数据并收敛到最终一致，将服务实例作为Gossip集群节点，使用CRDT(conflict-free replicated data type)存储服务注册信息通过Gossip快速传播实现集群中所有节点状态最终一致，每个节点都存储全部服务注册信息，这样就不需要单独的服务注册中心，这种方式实现的方案叫去中心化方案，有关去中心化服务发现方案留作下次分享。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!