服务发现和注册
我们有了两个服务。服务A的IP地址是192.168.0.1，端口9001,服务B的IP地址192.168.0.2，端口9002。我们的客户端需要调用服务A和服务B，我们只需要在配置文件中写上服务A和服务B的IP地址即可。
此时，服务A的服务器负载有点高，我们需要临时增加服务A的实例，IP192.168.0.3，端口9001。但是我们的客户端要怎么才能调用新的实例？
常规来说，我们可以有以下几种方法：
网络代理方式
如果是http方式通信的服务，可以增加一个nginx做反向代理，转发到两个服务A的实例上。
如果是RPC服务则可以增加一个LVS或HAProxy或者ESB之类的网络代理，客户端配置网络代理地址。
服务B我们再来一套一样的配置，这时候又来了服务C、服务D、服务E...，好吧我们好还要再多维护同样多的网络代理。此外，所有的服务调用服务调用都必须经过网络代理，我们还必须保证代理的高可用。最后，陷入运维灾难。DNS方式
给服务A配置一个域名,然后通过配置两个A记录分别指向两个服务A的实例，客户端只要配置服务A的域名即可。
这种方式也存在问题，首先DNS没有办法管理端口，我们的端口还是只能写在每个客户端的配置文件中。此外DNS轮询负载均衡能力太弱，可能会导致客户端负载的不均衡。
现在有了服务发现和注册机制，我们可以更合理的解决这个问题。
服务发现和注册，参考字面意思很容易理解，其核心部分可以理解为一个服务注册表。服务启动时，将自己的信息注册到注册表中。注册表需要每一定时间访问下已经注册的服务，将没有响应的服务从注册表中删除。最终让客户端拿到正常运行的服务地址。
此时，我们的服务注册表必须具备分布式、高可用、强一致性等特点。
目前，业界开源的服务发现和注册产品有很多，比较流行的主要有：ZooKeeper,Etcd,Consul,Eureka等。
下面介绍下今天的主角，Consul。
Consul
Consul是一个服务发现和注册的工具，其具有分布式、高扩展性能特点。
Consul主要包含如下功能：
服务发现： 支持 http 和 dns 两种协议的服务注册和发现方式。
监控检查： 支持多种方式的健康检查。
Key/Value存储： 支持通过HTTP API实现分布式KV数据存储。
多数据中心支持：支持任意数量数据中心。
上图是官网提供的一个事例系统图，图中的Server是consul服务端高可用集群，Client是consul客户端。consul客户端不保存数据，客户端将接收到的请求转发给响应的Server端。Server之间通过局域网或广域网通信实现数据一致性。每个Server或Client都是一个consul agent。Consul集群间使用了
延伸阅读
学习是年轻人改变自己的最好方式