服务端发现模式。
客户端模式与服务端模式，两者的本质区别在于，客户端是否保存服务列表信息。
客户端发现模式在客户端模式下，如果要进行微服务调用，首先要进行的是到服务注册中心获取服务列表，然后再根据调用端本地的负载均衡策略，进行服务调用。
在上图中，client端提供了负载均衡的功能，其首先从注册中心获取服务提供者的列表，然后通过自身负载均衡算法，选择一个最合理的服务提供者进行调用:
1、 服务提供者向注册中心进行注册，提交自己的相关信息
2、 服务消费者定期从注册中心获取服务提供者列表
3、 服务消费者通过自身的负载均衡算法，在服务提供者列表里面选择一个合适的服务提供者，进行访问
客户端发现模式的优缺点如下：
优点：
负载均衡作为client中一个功能，用自身的算法，从服务提供者列表中选择一个合适服务提供者进行访问，因此client端可以定制化负载均衡算法。优点是服务客户端可以灵活、智能地制定负载均衡策略，包括轮询、加权轮询、一致性哈希等策略。
可以实现点对点的网状通讯，即去中心化的通讯。可以有效避开单点造成的性能瓶颈和可靠性下降等问题。
服务客户端通常以SDK的方式直接引入到项目，这种方式语言的整合程度最佳，程序执行性能最佳，程序错误排查更加容易。
缺点：
当负载均衡算法需要更新时候，很难做到同一时间全部更新，所以就造成新旧算法同时运行
与注册中心紧密耦合，如果要换注册中心，需要去修改代码，重新上线。微服务的规模越大，服务更新越困难，这在一定程度上违背了微服务架构提倡的技术独立性。
目前来说，大部分服务发现的实现都采取了客户端模式。
服务端发现模式在服务端模式下，调用方直接向服务注册中心进行请求，服务注册中心再通过自身负载均衡策略，对微服务进行调用。这个模式下，调用方不需要在自身节点维护服务发现逻辑以及服务注册信息。
在服务端模式下： 1、 服务提供者向注册中心进行服务注册 2、 注册中心提供负载均衡功能， 3、 服务消费者去请求注册中心，由注册中心根据服务提供列表的健康情况，选择合适的服务提供者供服务消费者调用
现代容器化部署平台（如Docker和Kubernetes）就是服务端服务发现模式的一个例子，这些部署平台都具有内置的服务注册表和服务发现机制。容器化部署平台为每个服务提供路由请求的能力。服务客户端向路由器（或者负载均衡器）发出请求，容器化部署平台自动将请求路由到目标服务一个可用的服务实例。因此，服务注册，服务发现和请求路由完全由容器化部署平台处理。
服务端发现模式的特点如下：
优点：
服务消费者不需要关心服务提供者的列表，以及其采取何种负载均衡策略
负载均衡策略的改变，只需要注册中心修改就行，不会出现新老算法同时存在的现象
服务提供者上下线，对于服务消费者来说无感知
缺点：
rt增加，因为每次请求都要请求注册中心，尤其返回一个服务提供者
注册中心成为瓶颈，所有的请求都要经过注册中心，如果注册服务过多，服务消费者流量过大，可能会导致注册中心不可用
微服务的一个目标是故障隔离，将整个系统切割为多个服务共同运行，如果某服务无法正常运行，只会影响到整个系统的相关部分功能，其它功能能够正常运行，即去中心化。然而，服务端发现模式实际上是集中式的做法，如果路由器或者负载均衡器无法提供服务，那么将导致整个系统瘫痪。
4实现方案 file以文件的形式实现服务发现，这是一个比较简单的方案。其基本原理就是将服务提供者的信息(ip:port)写入文件中，服务消费者加载该文件，获取服务提供者的信息，根据一定的策略，进行访问。
需要注意的是，因为以文件形式提供服务发现，服务消费者要定期的去访问该文件，以获得最新的服务提供者列表，这里有个小优化点，就是可以有个线程定时去做该任务，首先去用该文件的最后一次修改时间跟服务上一次读取文件时候存储的修改时间做对比，如果时间一致，表明文件未做修改，那么就不需要重新做加载了，反之，重新加载文件。
文件方式实现服务发现，其特点显而易见：
优点：实现简单，去中心化
缺点：需要服务消费者去定时操作，如果某一个文件推送失败，那么就会造成异常现象
zookeeperZooKeeper 是一个集中式服务，用于维护配置信息、命名、提供分布式同步和提供组服务。