spring-cloud 使用初谈(二)--网关

这里说的是zuul

spring-cloud 使用初谈(二)--网关_第1张图片

spring-cloud 使用初谈(二)--网关_第2张图片

spring-cloud 使用初谈(二)--网关_第3张图片

file

服务过滤

spring-cloud 使用初谈(二)--网关_第4张图片

自定义过滤器的实现,需要继承ZuulFilter,需要重写实现下面四个方法:

    四个具有4个基本特征:过滤类型、执行顺序、执行条件、具体操作

filterType:返回一个字符串代表过滤器的类型,在zuul中定义了四种不同生命周期的过滤器类型,具体如下:
pre:可以在请求被路由之前调用
routing:在路由请求时候被调用
post:在routing和error过滤器之后被调用
error:处理请求时发生错误时被调用
filterOrder:通过int值来定义过滤器的执行顺序
shouldFilter:返回一个boolean类型来判断该过滤器是否要执行,所以通过此函数可实现过滤器的开关。在上例中,我们直接返回true,所以该过滤器总是生效。
run:过滤器的具体逻辑。需要注意,这里我们通过ctx.setSendZuulResponse(false)令zuul过滤该请求,不对其进行路由,然后通过ctx.setResponseStatusCode(401)设置了其返回的错误码,当然我们也可以进一步优化我们的返回,比如,通过ctx.setResponseBody(body)对返回body内容进行编辑等。
spring-cloud 使用初谈(二)--网关_第5张图片

最后,总结一下为什么服务网关是微服务架构的重要部分,是我们必须要去做的原因:
不仅仅实现了路由功能来屏蔽诸多服务细节,更实现了服务级别、均衡负载的路由。
实现了接口权限校验与微服务业务逻辑的解耦。通过服务网关中的过滤器,在各生命周期中去校验请求的内容,将原本在对外服务层做的校验前移,保证了微服务的无状态性,同时降低了微服务的测试难度,让服务本身更集中关注业务逻辑的处理。
实现了断路器,不会因为具体微服务的故障而导致服务网关的阻塞,依然可以对外服务。

Zuul 和 nginx的性能对比

结论:
Zuul的原始性能非常接近于Nginx。事实上,在启动预热之后,我的测试结果甚至略好一些(重申免责声明-这并非一个严肃的基准性能测试)。Nginx显示出更多的可预测性能(变化较小),可悲的是在Zuul预热期间,我们经历了一些小故障(150000个请求中的2个,但是您的微服务应该是容错机制的,对吧?)。

Zuul处理Cookie和重定向

spring-cloud 使用初谈(二)--网关_第6张图片

spring-cloud 使用初谈(二)--网关_第7张图片

本文来源于:程序员ken,专属平台有csdn、思否(SegmentFault)、 简书、 开源中国(oschina)、掘金,转载请注明出处。

你可能感兴趣的:(c#)