changs 2019-04-13 19:26:20 1175

在前两篇文章:服务网关(基础)、服务网关(路由配置)中,我们了解了Spring Cloud Zuul作为网关所具备的最基本功能:路由。本文我们将具体介绍一下Spring Cloud Zuul的另一项核心功能:过滤器。

changs 2019-04-13 19:26:20 1138

在上一篇《Spring Cloud构建微服务架构:服务网关(基础)》一文中,我们通过使用Spring Cloud Zuul构建了一个基础的API网关服务,同时也演示了Spring Cloud Zuul基于服务的自动路由功能。在本文中,我们将进一步详细地介绍关于Spring Cloud Zuul的路由功能,以帮助读者可以更好的理解和使用它,以完成更复杂的路由配置。

changs 2019-04-13 19:26:20 1194

在上一篇《Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)》中,我们已经体验了如何使用@HystrixCommand来为一个依赖资源定义服务降级逻辑。实现方式非常简单,同时对于降级逻辑还能实现一些更加复杂的级联降级等策略。之前对于使用Hystrix来实现服务容错保护时,除了服务降级之外,我们还提到过线程隔离、断路器等功能。那么在本篇中我们就来具体说说线程隔离。

changs 2019-04-13 19:26:20 1134

接下来的示例将分为三个模块:

changs 2019-04-13 19:26:20 890

读者是否还记得我们之前分析了Spring Cloud Zuul自带的核心过滤器有哪些呢?我们先根据下图回忆一下:

changs 2019-04-13 19:26:20 916

不论是使用传统路由的配置方式还是服务路由的配置方式,我们都需要为每个路由规则定义匹配表达式,也就是上面所说的path参数。在Zuul中,路由匹配的路径表达式采用了Ant风格定义。

changs 2019-04-13 19:26:20 1160

我们在项目中使用Spring cloud zuul的时候,有一种这样的需求,就是当我们的zuul进行路由分发时,如果后端服务没有启动,或者调用超时,这时候我们希望Zuul提供一种降级功能,而不是将异常暴露出来。

changs 2019-04-13 19:26:20 1160

本文章对应spring cloud的版本为(Dalston.SR4),具体内容如下:

changs 2019-04-13 19:26:20 1197

在今年5月中,Netflix终于开源了它的支持异步调用模式的Zuul网关2.0版本,真可谓千呼万唤始出来。从Netflix的官方博文[附录1]中,我们获得的信息也比较令人振奋:

changs 2019-04-13 19:26:20 1095

通常微服务架构中的依赖通过远程调用实现,而远程调用中最常见的问题就是通信消耗与连接数占用。在高并发的情况之下,因通信次数的增加,总的通信时间消耗将会变的不那么理想。同时,因为对依赖服务的线程池资源有限,将出现排队等待与响应延迟的情况。为了优化这两个问题,Hystrix提供了HystrixCollapser来实现请求的合并,以减少通信消耗和线程数的占用。

changs 2019-04-13 19:26:20 1118

在Spring Cloud中我们用Hystrix来实现断路器,Zuul中默认是用信号量(Hystrix默认是线程)来进行隔离的,我们可以通过配置使用线程方式隔离。

changs 2019-04-13 19:26:20 1181

上篇文章《Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失》我们对ThreadLocal数据丢失进行了详细的分析,并通过代码的方式复现了这个问题。

changs 2019-04-13 19:26:20 1165

通过之前Spring Cloud系列教程中的《Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)》一文,我们已经知道如何通过Hystrix来保护自己的服务不被外部依赖方拖垮的情况。但是实际使用过程中经常碰到开发反应“莫名”触发了降级逻辑的情况。为了更精准的定位触发原因,或是在降级逻辑中需要根据不同的异常做不同的处理时,在降级方法中,我们希望可以获取到主逻辑中抛出的异常信息。接下来就来介绍一下Hystrix两种不同实现方式中如何在降级逻辑中获取异常信息的方法。

changs 2019-04-13 19:26:20 1151

该类中该方法为发生异常的回调方法,由此可以看出如果抛出异常如果是 HystrixBadRequestException 是直接处理异常之后进行抛出(这里不会触发熔断机制),而不是进入回调方法。

changs 2019-04-13 19:26:20 1138

Spring Cloud Bus除了支持RabbitMQ的自动化配置之外,还支持现在被广泛应用的Kafka。在本文中,我们将搭建一个Kafka的本地环境,并通过它来尝试使用Spring Cloud Bus对Kafka的支持,实现消息总线的功能。由于本文会以之前Rabbit的实现作为基础来修改,所以先阅读《Spring Cloud构建微服务架构(七)消息总线》有助于理解本文。

changs 2019-04-13 19:26:20 1183

在之前发布的《Spring Cloud实战小贴士:Feign的继承特性(伪RPC模式)》一文中,我们介绍了如果使用Feign的继承特性来完成服务的提供以及服务的消费,实现了类似RPC的编程模式。但是,仔细一些的读者可能已经发现一个问题:当我们将服务消费者运行起来的时候,定义在服务提供方的那些请求映射关系也被加载到了服务消费者中,这就会带来两个问题:

changs 2019-04-13 19:26:20 1113

先来看看症状。比如下面的例子:

changs 2019-04-13 19:26:20 1186

在之前介绍使用Ribbon进行服务消费的时候,我们用到了RestTemplate,但是熟悉Spring的同学们是否产生过这样的疑问:RestTemplate不是Spring自己就有的吗?跟Ribbon的客户端负载均衡又有什么关系呢?下面在本文,我们来看RestTemplate和Ribbon是如何联系起来并实现客户端负载均衡的。

changs 2019-04-13 19:26:20 1163

当我们使用Spring Cloud Ribbon实现客户端负载均衡的时候,通常都会利用@LoadBalanced来让RestTemplate具备客户端负载功能,从而实现面向服务名的接口访问(原理可见《Spring Cloud源码分析(二)Ribbon》一文,如果对Spring Cloud中使用Ribbon进行服务消费还没有概念的话,建议先阅读《Spring Cloud构建微服务架构(二)服务消费者》一文。)。

changs 2019-04-13 19:26:20 1133

造成第一次服务调用出现失败的原因主要是Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的,而是在调用的时候才会去创建相应的Client,所以第一次调用的耗时不仅仅包含发送HTTP请求的时间,还包含了创建RibbonClient的时间,这样一来如果创建时间速度较慢,同时设置的超时时间又比较短的话,很容易就会出现上面所描述的显现。

changs 2019-04-13 19:26:20 1124

在Spring Cloud Zuul中也提供了一个配置参数来实现earger-load,具体如下:

changs 2019-04-13 19:26:20 1141

看过之前文章的朋友们,相信已经对Eureka的运行机制已经有了一定的了解。为了更深入的理解它的运作和配置,下面我们结合源码来分别看看服务端和客户端的通信行为是如何实现的。另外写这篇文章,还有一个目的,还是希望鼓励大家能够学会学习和研究的方法,由于目前Spring Cloud的中文资料并不多,并不是大部分的问题都能找到现成的答案,所以其实很多问题给出一个科学而慎重的解答也都是花费研究者不少精力的。

changs 2019-04-13 19:26:20 1134

我们知道Eureka分为两部分,Eureka Server和Eureka Client。Eureka Server充当注册中心的角色,Eureka Client相对于Eureka Server来说是客户端,需要将自身信息注册到注册中心。本文主要介绍的就是在Eureka Client注册到Eureka Server时RetryableClientQuarantineRefreshPercentage参数的使用技巧。

changs 2019-04-13 19:26:20 1099

最近连续发烧四天,偶尔刷两下朋友圈都能看到好几条来自不同号的关于《Eureka 2.0开源工作宣告停止,继续使用风险自负》的推文。主要内容如下:

changs 2019-04-13 19:26:20 2266

昨晚Nacos社区发布了第一个生产级版本:0.8.0。由于该版本除了Bug修复之外,还提供了几个生产管理非常重要的特性,所以觉得还是有必要写一篇讲讲这次升级,在后续的文章中也都将以0.8.0版本为基础。