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编写而成。
