微服务的消费模式
基于HTTP的客户端经常被用作微服务的消费者。这类客户端往往有着平台无关性、语言无关性等特征，而被社区广泛支持，各类HTTP客户端框架也是层出不穷。
本节我们将带领大家来了解微服务常见的消费模式。
服务直连模式
服务直连模式是最容易理解的，例如，我们在浏览器里面访问某篇文章，我们知道这篇文章的URL，就能直接通过URL 访问到想要的资源。
又如，在之前章节中实现的天气数据采集微服务，我们通过一个RestTemplate类来访问REST-ful API服务，诸如此类都是属于服务直连模式。以下是一个RestTemplate访问RESTfulAPI服务的例子。
代码语言：javascript复制@Service
public class WeatherDataServicelmpl implements WeatherDataService {
@Autowired
private RestTemplate restTemplate;
private WeatherResponse doGetWeatherData(String uri)[
ResponseEntity<String> response = restTemplate.getForEntity(uri,
String.class);
// ...
}
/l ...
}服务直连模式具有以下特点。
- 简洁明了。
- 平台语言无关性。
当然，这种模式也有一个最大的问题，就是假设给定的URL不可用，怎么办?由于这种模式
无法保证服务的可用性，所以在生产环境中比较少用。
客户端发现模式
客户端发现模式是一种由客户端来决定相应服务实例的网络位置的解决方案。其原理如下。
- 当服务实例启动后，将自己的位置信息提交到服务注册表(Service Registry)中。服务注册表维护着所有可用的服务实例的列表。
- 客户端从服务注册表进行查询，来获取可用的服务实例。
- 在选取可用的服务实例的过程中，客户端自行使用负载均衡算法从多个服务实例中选择一个，然后发出请求。
图9-1显示了客户端发现模式的架构。
服务注册表中的实例也是动态变化的。当有新的实例启动时，实例会将实例信息注册到服务注册表中;当实例下线或不可用时，服务注册表也能及时感知到，并将不可用实例及时从服务注册表中清除。服务注册表可以采取类似于心跳等机制来实现对服务实例的感知。
很多技术框架提供这种客户端发现模式。Spring Cloud提供了完整的服务注册及服务发现的实现方式，比如在之前章节中我们所介绍的Eureka。Eureka提供了服务注册表的功能，为服务实例注册管理和查询可用实例提供了RESTAPI接口。Ribbon主要功能是提供客户端的软件负载均衡算法，将中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项，例如，连接超时、重试等。简单地说，就是在服务注册表所列出的实例，Ribbon 会自动帮助你基于某种规则（如简单轮询、随即连接等）去连接这些实例。Ribbon也提供了非常简便的方式来让我们使用Ribbon实现自定义的负载均衡算法。
ZooKeeper是Apache基金会下一个开源的、高可用的分布式应用协调服务，也被广泛应用于服务发现。
客户端发现模式的优点是，该模式相对直接，除了服务注册外，其他部分基本无须做改动。此外，由于客户端已经知晓所有可用的服务实例，所以能够针对特定应用来实现智能的负载均衡。
客户端发现模式的缺点是，客户端需要与服务注册表进行绑定，要针对服务端用到的每个编程语言和框架，来实现客户端的服务发现逻辑。
服务端发现模式
另外一种服务发现的模式是服务端发现模式。该模式是客户端通过负载均衡器向某个服务提出请求，负载均衡器查询服务注册表，并将请求转发到可用的服务实例。同客户端发现模式类似，服务实例在服务注册表中注册或注销。图9-2展现了这种服务端发现模式的架构。
与客户端发现模式不同的是，服务端发现模式中需要有专门的负载均衡器来分发请求。这样客户端就可以保持相对简单，无须自己实现负载均衡机制。
DNS域名解析可以提供最简单方式的服务端发现功能。它作为域名和地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。人们在通过浏览器访问网站时只需要记住网站的域名即可，而不需要记住那些不太容易理解的IP地址。每个DNS域名可以映射多个服务实例。但DNS 也有限制，例如，它无法及时感知服务实例是否有效，不能够按服务器的处理能力来分配负载等。所以一个常用的解决方法是在DNS服务器与服务实例之间搭建一个负载均衡器。
在商业产品领域，Amazon公司的Elastic Load Balancing ( https:/laws.amazon.com/cn/elasticload-balancing/）提供了服务端发现路由的功能，可以在多个Amazon EC2实例之间自动分配应用程序的传入流量。它可以实现应用程序容错能力，从而无缝提供路由应用程序流量所需的负载均衡容量。
Elastic Load Balancing 提供两种类型的负载均衡器，一种是Classic负载均衡器，可基于应用程序或网络级信息路由流量;另一种是应用程序负载均衡器，可基于包括请求内容的高级应用程序级信息路由流量。Classic负载均衡器适用于在多个EC2实例之间进行简单的流量负载均衡，而应用程序负载均衡器则适用于需要高级路由功能、微服务和基于容器的架构的应用程序。应用程序负载均衡器可将流量路由至多个服务，也可在同一EC2实例的多个端口之间进行负载均衡。这两种类型均具备高可用性、自动扩展功能和可靠的安全性。
在开源领域，Kubernetes ( https:/kubernetes.io）及 NGINX ( http:/nginx.org/）也能用作服务端发现的负载均衡器。NGINX是一个高性能的HTTP和反向代理服务器，在连接高并发的情况下，可以作为Apache服务器不错的替代品，在分布式系统中，经常被作为负载均衡服务器使用。
Kubernetes作为Docker生态圈中的重要一员，是Google多年大规模容器管理技术的开源版本。
其中，Kubernetes的 Proxy(代理）组件实现了负载均衡功能。Proxy 会根据Load Balancer将请求透明地转发到集群中可用的服务实例。
使用服务端发现模式的好处是，它通常会简化客户端的开发工作，因为客户端并不需要关心负载均衡的细节工作，其所要做的工作就是将请求发到负载均衡器即可。市面上也提供了很多商业或开源的负载均衡器的实现，开箱即用，方案也比较成熟。
实施服务端发现模式也有难点，一个比较大的问题是需要考虑如何来配置和管理负载均衡器成为高可用的系统组件。
本篇文章内容给大家讲解的是微服务的消费模式
- 下篇文章给大家讲解常见微服务的消费者；
- 觉得文章不错的朋友可以转发此文关注小编；
- 感谢大家的支持！
本文就是愿天堂没有BUG给大家分享的内容，大家有收获的话可以分享下，想学习更多的话可以到微信公众号里找我，我等你哦。
