宝石流云|SpringCloud微服务架构开发实战:微服务的消费模式

微服务的消费模式基于HTTP的客户端经常被用作微服务的消费者 。 这类客户端往往有着平台无关性、语言无关性等特征 , 而被社区广泛支持 , 各类HTTP客户端框架也是层出不穷 。
本节我们将带领大家来了解微服务常见的消费模式 。
【宝石流云|SpringCloud微服务架构开发实战:微服务的消费模式】又如 , 在之前章节中实现的天气数据采集微服务 , 我们通过一个RestTemplate类来访问REST-fulAPI服务 , 诸如此类都是属于服务直连模式 。 以下是一个RestTemplate访问RESTfulAPI服务的例子 。
@ServicepublicclassWeatherDataServicelmplimplementsWeatherDataService{@AutowiredprivateRestTemplaterestTemplate;privateWeatherResponsedoGetWeatherData(Stringuri)[ResponseEntityresponse=restTemplate.getForEntity(uri,String.class);//...}/l...}服务直连模式具有以下特点 。
简洁明了 。 平台语言无关性 。当然 , 这种模式也有一个最大的问题 , 就是假设给定的URL不可用 , 怎么办?由于这种模式
无法保证服务的可用性 , 所以在生产环境中比较少用 。
客户端发现模式客户端发现模式是一种由客户端来决定相应服务实例的网络位置的解决方案 。 其原理如下 。
当服务实例启动后 , 将自己的位置信息提交到服务注册表(ServiceRegistry)中 。 服务注册表维护着所有可用的服务实例的列表 。 客户端从服务注册表进行查询 , 来获取可用的服务实例 。 在选取可用的服务实例的过程中 , 客户端自行使用负载均衡算法从多个服务实例中选择一个 , 然后发出请求 。图9-1显示了客户端发现模式的架构 。
很多技术框架提供这种客户端发现模式 。 SpringCloud提供了完整的服务注册及服务发现的实现方式 , 比如在之前章节中我们所介绍的Eureka 。 Eureka提供了服务注册表的功能 , 为服务实例注册管理和查询可用实例提供了RESTAPI接口 。 Ribbon主要功能是提供客户端的软件负载均衡算法 , 将中间层服务连接在一起 。 Ribbon客户端组件提供一系列完善的配置项 , 例如 , 连接超时、重试等 。 简单地说 , 就是在服务注册表所列出的实例 , Ribbon会自动帮助你基于某种规则(如简单轮询、随即连接等)去连接这些实例 。 Ribbon也提供了非常简便的方式来让我们使用Ribbon实现自定义的负载均衡算法 。
ZooKeeper是Apache基金会下一个开源的、高可用的分布式应用协调服务 , 也被广泛应用于服务发现 。
客户端发现模式的优点是 , 该模式相对直接 , 除了服务注册外 , 其他部分基本无须做改动 。 此外 , 由于客户端已经知晓所有可用的服务实例 , 所以能够针对特定应用来实现智能的负载均衡 。
客户端发现模式的缺点是 , 客户端需要与服务注册表进行绑定 , 要针对服务端用到的每个编程语言和框架 , 来实现客户端的服务发现逻辑 。
服务端发现模式另外一种服务发现的模式是服务端发现模式 。 该模式是客户端通过负载均衡器向某个服务提出请求 , 负载均衡器查询服务注册表 , 并将请求转发到可用的服务实例 。 同客户端发现模式类似 , 服务实例在服务注册表中注册或注销 。 图9-2展现了这种服务端发现模式的架构 。


推荐阅读