概念：服务发现就是程序如何通过一个标志来获取服务列表，并且这个服务列表是能够随着服务的状态而动态变更的。
服务发现的两种模式
客户端模式
在客户端模式下，如果要进行微服务调用，首先要进行的是到服务注册中心获取服务列表，然后再根据调用端本地的负载均衡策略，进行服务调用。
服务端模式
在服务端模式下，调用方直接向服务注册中心进行请求，服务注册中心再通过自身负载均衡策略，对微服务进行调用。
客户端模式 PK 服务端模式
客户端模式通过周期性获取列表放在本地缓存，需要服务时，可以不必去访问服务注册中心，所以即使服务注册中心挂了，客户端一样可以访问到服务，只不过当某个服务突然下线会造成短暂的不可用状态。
服务端模式就是的可用性由路由器中间件决定，路由中间件故障则所有服务不可用，同时，由于所有调度以及存储都由中间件服务器完成，中间件服务器可能会面临过高的负载，路由器中间件对客户端不可见。
目前来说，大部分服务发现的实现都采取了客户端模式。
服务发现的两种常用框架
Eureka
在这个框架中，分为server和client两种角色。server负责保存服务的注册信息，同时server之间也可以彼此相互注册，client则需要向特定的server进行注册。
具体操作是：Service Provider和Service Consumer通过RESTful Api向Eureka Server进行服务注册，Service Provider定期调用Renew接口来更新服务的注册状态，若Eureka Server在60s内没有收到服务的Renew信息，则该服务就会被标志为下线；而如果服务需要主动下线的话，向server调用cancel就可以了。然后Service Consumer需要调用服务时，就可以向Eureka Server获取当前的服务列表，再根据服务列表中的ip地址以及端口号进行调用了。
值得一提的是Eureka同时支持多个注册中心，以保证注册中心的高可用性。
Consul
首先了解一下Raft协议：Raft协议图解
详细了解Raft协议：Raft协议详解
Raft原理：
在Raft中，每个结点会处于下面三种状态中的一种：
- follower：所有结点都以follower的状态开始。如果没收到leader消息则会变成candidate状态
- candidate：会向其他结点“拉选票”，如果得到大部分的票则成为leader。这个过程就叫做Leader选举(Leader
Election) - leader：所有对系统的修改都会先经过leader。每个修改都会写一条日志(log
entry)。leader收到修改请求后的过程如下，这个过程叫做日志复制(Log Replication)：
- leader收到修改请求，先写日志而不提交。
- 复制日志到所有follower结点(replicate entry)
- 大部分结点响应时才提交日志
- 通知所有follower结点日志已提交
- 所有follower也提交日志
- 现在整个系统处于一致的状态
基于Consul的微服务一般都是集群，集群由一个个的Consul Agent组成，在这些Consul Agent里面，分为两种角色，Server 以及 Client。Consul是基于Raft协议实现的，这些Server里包含了Raft中的Leader以及Follower。而Client则只是向这些Server进行键值对的读/写。
当我们在本地启动Consul Agent之后，我们可以通过Consul的Restful Api向Consul Agent注册服务信息，提交服务的端口号，ip地址，以及健康检查的方式。随后，这个Client就按照配置中的周期以及方式执行健康检查，当健康检查失败的时候，就会向Server发送服务不可用的消息，这个服务就会被Consul标记为不可用了。于是我们就能从Server中的任意节点获取服务列表。
由上可以看出,Consul通过Consul Agent去管理服务列表，而对客户端不可见，一种基于服务器的服务发现。