如果服务消费者每次使用远程服务都需要先查询服务中介获取实例列表，再请求服务，这样效率太低效?对服务中介的压力也不小?通常，客户端会缓存服务实例列表，这样对同名服务的多次请求，便不用重复查询，既减少了延迟又减轻了对服务中介的访问压力。
第五个问题前述的keepalive有间隔，如果在这个间隔内服务实例不可用，那么服务消费者还是不能感知的，所以还是有可能把请求发送到一个无法提供服务的网络远端机器上去，这样自然是没法work。我们无法从根本上杜绝这种情况，系统需要容忍这种错误，但也可以做一些改进，比如向某实例请求服务失败后便拉黑，避免向同一无效服务实例多次派发请求。
第六个问题服务消费者怎么从多个服务实例里选择一个?如何确保同一服务消费者的多次服务请求被分配到固定的服务实例(有时候需要这样)?这其实就是负载均衡的问题，有多种策略，比如rr、优先级、比如加权随机、一致性哈希。
服务发现模式服务发现主要有两种模式：客户端发现模式(client-side discovery)和服务端发现模式(server-side discovery)。
客户端发现模式
客户端负责查询服务实例列表并决定向哪个实例请求服务，也就是负载均衡策略在客户端实现。该模式包括注册和发现两个部分。
服务实例调用服务中介的注册接口进行实例注册，服务实例通过keepalive做服务续期，服务中介通过健康检查剔除不可用的服务实例。
服务消费者请求服务的时候，先向服务注册表查询服务实例列表，注册表是一个服务数据库，为了提升性能和可靠性，客户端通常会缓存服务列表(缓存用来确保注册表挂了之后还能继续工作)，拿到实例列表后客户端基于负载均衡策略挑选一个实例发送服务请求。
优点直接，客户端可以灵活的执行负载均衡策略。
去中心化，非网关式，有效避开单点瓶颈和可靠性下降。
服务发现直接SDK集成进客户端，这种语言整合程度很好，程序执行性能也很好，排错方便。
缺点客户端与服务注册表耦合，需要为服务客户端使用的每种语言每种框架开发服务发现逻辑。
这种侵入式的集成会导致任何服务发现的变化都需要客户端应用程序重新编译和部署，强绑定违背了独立性原则。
服务上下线会对调用方有影响，导致服务短暂不可用。
服务端发现模式
发现：服务消费者通过负载均衡器发送服务请求，负载均衡器会查询服务注册表，挑选一个服务实例，并将请求转发到服务实例。
注册：服务注册/注销可以跟上述客户端发现模式一致，也可以通过部署平台的内置服务注册和发现机制完成，即容器化部署平台(docker/k8s)能主动发现服务实例并帮助服务实例完成注册注销。
对比客户端发现模式，使用服务端发现模式的客户端本地不保存服务实例列表，客户端不做负载均衡，这个负载均衡器既承担了服务发现的角色，又承担了网关的角色，所以经常叫API网关服务器。
因为负载均衡器是中心式的，所以它也必须是一个集群，单个实例不足以支撑高并发访问，针对负载均衡器本身的服务发现和负载均衡通常借助DNS。
Http服务器，Nginx、Nginx Plus就是此类服务端发现模式的负载均衡器。
优点服务发现对于服务消费者是透明的，服务消费者与注册表解耦，服务发现功能的更新对客户端无感知。
服务消费者只需要向负载均衡器发送请求，不需要为每种服务消费者的编程语言和框架，开发服务发现逻辑SDK。
缺点由于所有请求都要经负载均衡器转发，所以负载均衡器有可能成为新的性能瓶颈。
负载均衡器(服务网关)是中心式的，而中心式的架构会有稳定性的隐忧。
因为负载均衡器转发请求，所以RT会比客户端直连模式高。
微服务和服务发现Service Mesh服务网格是服务于微服务应用程序的可配置基础设施层，旨在处理服务之间的大量基于网络的进程间通信。