一、微服务的消费模式
基于HTTP的客户端经常被用作微服务的消费者。这类客户端往往有着与平台无关性、语言无关性等特征，而被社区广泛支持，各类HTTP客户端框架也是层出不穷。常见的微服务消费模式如下：
1、服务直连模式
服务直连模式是最容易理解的，例如，在浏览器里面访问某篇文章，我们知道URL，直接通过URL访问想要的资源。
服务直连模式具有以下特点：
- 简单明了
- 平台语言无关
假如给定的URL不可用，则访问不了。由于简单直连模式如法保证服务的可用性，所以在生产环境中比较少用。
2、客户端发现模式
客户端发现模式是一种由客户端来决定相应服务实例的网络位置的解决方案。原理如下：
- 当服务实例启动后，将自己的位置信息提交给服务注册表（Serivice Registry）中。服务注册表是维护着所有可用服务实例的列表。
- 客户端从服务注册表中进行查询，来获取可用的服务实例。
- 在选取可用的服务实例的过程中，客户端自身使用负载均衡算法从多个服务实例中选择一个，然后发出请求。
很多技术框架提供了客户端发现模式。Spring Cloud 提供了完整的服务注册与服务发现的实现方式，例如 Eureka ，其提供了服务注册表的功能，为服务注册实例注册管理和查询可用实例提供了 REST API 接口。Ribbon 主要功能是提供客户端的软件负载均衡算法，将中间层服务连接在一起；Ribbon 客户端组建提供一系列完善的配置项，例如，连接超时、重试等。
Zooker 是 Apache 基金会下一个开源的、高可用的分布式应用协调服务，也被广泛应用于服务发现。
客户端发现模式的特点：
优点：
该模式相对直接，除服务注册外，其他部分基本无需做改动。此外，由于客户端已经知道所有可用的服务实例，所以能够针对特定应用来实现智能的负载均衡。
缺点：
客户端需要与服务注册表进行绑定，要针对服务端用到的每个编程语言和框架，来实现客户端的服务发现逻辑。
3、服务端发现模式
该模式就是客户端通过负载均衡器向某个服务提出请求，负载均衡器查询服务注册表，并将请求转发到可用的服务实例。同客户端发现模式类似，服务实例在注册表中注册或注销。
与客户端发现模式不同的是，服务端发现模式中需要有专门的负载均衡器来分发请求。这样客户端就可以保持相对简单，无须自己实现负载均衡机制。
开源领域中，kubernates（https://kubernetes.io/）及 nginx （http://nginx.org/）可以用作服务端发现的负载据衡器。
服务端发现模式的特点：
优点：
会简化客户端的开发工作。客户端之需要将请求发送到负载均衡器即可。
难点：
需要考虑如何来配置和管理负载均衡器成为高可用的系统组件。