基于分布式系统的基本特质，P 是必须要满足，接下来需要考虑满足 C 还是 A。在类似银行之类对金额数据要求强一致性的系统中，要优先考虑满足数据一致性；而类似大众网页之类的系统，用户对网页版本的新旧不会有特别的要求，在这种场景下服务可用性高于数据一致性。
如何选择服务注册与发现框架？随着近几年微服务框架高速发展，目前业界已经开源出了大量优秀的服务注册与发现组件，包括不仅限于 Consul、Etcd、Zookeeper、Eureka。它们之间各有千秋，在组件选型时可以根据自身业务的需要进行选择和改造，接下来我们主要对 Consul、Etcd、Zookeeper 作一些简单的介绍和比较。
基于 Raft 算法、开箱即用的服务发现系统 ConsulConsul 由 HashiCorp 开源，是支持多个平台的分布式高可用系统。Consul 使用 Golang 语言实现，主要用于实现分布式系统的服务发现与配置，满足 AP 特性。Consul 是分布式、高可用和可横向扩展的，提供以下主要特性：
服务发现：可以使用 HTTP 或者 DNS 的方式将服务实例的元数据注册到 Consul，和通过 Consul 发现所依赖服务的元数据列表。
检查检查：Consul 提供定时的健康检查机制，定时请求注册到 Consul 中的服务实例提供的健康检查接口，将异常返回的服务实例标记为不健康。
Key/Value：Consul 提供了 Key/Value 存储功能，可以通过简单的 HTTP 接口进行使用。
多数据中心：Consul 使用 Raft算法来保证数据一致性，提供了开箱即用的多数据中心功能。
服务实例与 Consul 的交互如下图所示：
Consul 与服务实例的交互过程
通过 Consul 实现服务注册与发现中心的调用过程如下：
Producer在启动之初会通过 /register 接口将自己的服务实例元数据注册到 Consul 中；
Consul 通过 Producer 提供的健康检查接口 /health 定时检查 Producer 的服务实例状态；
Consumer 请求 Consul 的接口获取 Producer 服务的元数据；
Consumer 从 Consul 中返回的 Producer 服务实例元数据列表中选择合适的服务实例，使用其配置的 IP 和端口信息发起服务调用，如图 7-1 中 Consumer 调用 Producer 的 /service 接口。
Consul 是一个高可用的分布式系统，支持多数据中心部署。一个 Consul 集群由多个部署和运行了 Consul Agent 的节点组成。Consul 集群中存在两种角色，Server 和 Client。每个 Consul Agent 负责对本地的服务进行监控检查，并将查询请求转发到 Server 中进行处理。Consul 简单的架构图如下图所示：
Consul 架构图
从上图可知，Consul 主要由 Consul Client 和 Consul Server 组成，且 Consul 使用 Gossip 协议来管理成员和广播消息到集群。
Consul 作为一个开箱即用、高可用分布式服务发现和配置系统，可以很方便地为微服务的服务治理提供强有力的支持。在后面的课时中，我们将实现一个 Consul 的客户端，将我们自身的 Web 服务注册到 Consul 中，以供其他服务或者网关调用。
基于 HTTP 协议的分布式 key/Value 存储系统 EtcdEtcd 是由 CoreOS 开源，采用 Golang 语言编写的分布式、高可用的 Key/Value 存储系统，主要用于服务发现和配置共享。Ectd 的经典应用场景有：
Key/Value 存储：Etcd 支持 HTTP RESTful API，提供强一致性、高可用的数据存储能力。
服务发现：通过在 Etcd 中注册某个服务的目录，服务实例连接 Etcd 并在目录下发布对应 IP 和 Port 以供调用方使用，可以有效实现服务注册与发现的功能；