全称：Service Discovery
传统情况下，客户端请求服务器的地址都是固定的。这样就有两个问题，有时候需要更换服务器地址，这样客户端也需要跟着改动，浪费人力和时间。将服务器地址直接暴露给客户端，容易产生安全问题。
在现代化服务器中，地址都是由云端动态分配的实例地址。
这个时候我们就需要服务发现了，相当于是服务端和客户端之间的中介。
两种模式
分为客户端发现和服务端发现。
大部分情况都是使用服务端发现模式。
客户端发现
客户端决定服务器的地址。客户端请求一个API，返回一组服务器实例的地址，通过负载均衡算法选出一个地址，最后发起请求。服务器实例的地址在启动时会被记录到服务发现表中，实例终止时从表中删除，服务器实例的表一般需要用心跳机制来定期刷新，防止服务器实例突然挂掉。
优点：服务端不关心被发现的细节。
缺点：客户端需要额外处理服务发现这一逻辑。
服务端发现
客户端向代理网关发起请求，网关查询服务器实例的地址，通过负载均衡算法选出一个地址，将请求转发到服务器。
优点：客户端不需要关心发现细节，只需要将请求发送给代理网关即可。
缺点：在服务端需要手动配置负载均衡。
一句话总结：
一个发现逻辑在客户端，一个发现逻辑在服务端。
职责
监控服务状态。通常使用心跳机制定时检查服务状态。注册新服务到列表中，从表中移除不可用服务。
服务发现表中一般都是存储的key/value结构。
通常使用分布式数据库zookeeper/etcd/consul做服务发现。Redis是单进程，防止挂掉。
场景
通常服务发现用来提供HTTP服务器的地址，也可以用来提供数据库的地址。任何需要动态提供地址的服务都可以。
