consul介绍 用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案，Consul 的方案更“一站式”，内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具（比如 ZooKeeper 等）。使用起来也较 为简单。Consul 使用 Go 语言编写，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合。 服务发现：consul通过http 方式注册服务，并且服务与服务之间相互感应。 服务健康监测 key/value 存储 多数据中心 CAP理论是分布式架构中重要理论： 一致性(Consistency) (所有节点在同一时间具有相同的数据) 可用性(Availability) (保证每个请求不管成功或者失败都有响应) 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作) consule 核心 agent组件： Agent是一个独立的程序，通过守护进程的方式，运行在consul集群中的每个节点上。每个Consul agent维护它自己的服务集合以及检查注册和健康信息。agent负责执行自己的健康检查和更新本地状态 其中，Agent 根据节点的性质，分为： Agent Server 和 Agent Client Agent Client： client将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。 Agent Server： server 保存client的注册信息，集群的配置信息, 维护集群高可用, 在局域网内与本地客户端通讯, 通过广域网与其它数据中心通讯。 每个数据中心的 server 数量推荐为 3 个或是 5 个,通过 Raft 算法来保证一致性。 Consul提供强大的一致性保证，因为服务器使用Raft协议复制状态 。 最大的区别是Eureka保证AP, Consul为CP。 Consul强一致性(C)带来的是： 服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功 Leader挂掉时，剩余节点则会发起选举，选举期间导致短暂不可用的情况，所以保证了强一致性而无法保证高可用性。 Eureka保证高可用(A)和最终一致性： eureka在设计时的分区容错保证了eureka各个节点都是平等的，只要不是所有节点都挂掉eureka就可以正常注册与使用，不会像zk出现选举而短暂不可用的情况 服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功 当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。 其他方面，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。