微服务化遇坑之(一)- ZuulRoute, stripPrefix

最近手头的一个项目由于业务增长,原本一个应用的大杂烩系统,无论功能迭代开发、发布还是回归测试上,项目上线质量越发难以控制。 于是想逐渐往Spring Cloud微服务架构上转型。

前后在Spring cloud技术栈上断断续续研究了1个多月,最终选择了Netflix的一堆脚手架组件。选择Netflix主要还是发现它够简单、容易上手。大概花了一周左右的时间研究了Eureka, Zuul的实现以及和Spring Cloud融合点(AutoConfiguration),但是,理论归理论,实际实践过程中还是踩了不少坑,于是就想到写一些文章记录下来,以便于自己以后翻阅和供大家参考。

由于是旧系统的架构改造,服务拆分,不可避免的会涉及到服务从老应用中迁移到新建应用中,当然你在迁移过程中不能让服务停止或不兼容,尤其是APP端的应用,用户已经在用的版本你总不能让他不能用吧?这是个硬杠杠!这种场景zuul也想到了,它的「绞杀模式」就是为这种场景准备的。

所谓「绞杀模式」我的理解是:将老系统中的服务,根据一定的基于uri的路由规则,逐渐分流到新系统中,从而将老服务逐渐替换掉。

ZUUL中有两种方式可以构建route(也就是转发规则)

1. 手动配置,就是在properties文件中静态配置转发规则,详细字段可以参考类 ZuulProperties

2. 依赖Eureka注册中心中的ServiceId动态生成转发规则

第二个方式中就有一个坑,个人觉得也是Zuul设计中的一个缺陷,通常老系统中,我们服务的访问路径是这么设计的:

https://myapp.goodcompany.com/appcontext/user/query_user

老系统的所有服务都以appcontext上下文起头,后面根据不同的path来区分各个业务模块,在新系统中我们会把会员相关(user)相关的服务拆分到新系统中,通常新会员系统的服务是这么访问的:

https://user.googcompany.com/user/query_user

所以,从route角度来说,你需要把路径 /appcontext/user/query_user 映射到/user/query_user中。但是如果你采用上面第二种方式来自动构建route的话,这个路径会映射到/query_user中,路径中缺少了/user。原因是路径遭遇了strip!! 而且这种通过DiscoveryClient构建的Route, 你没法通过设置zuul相关配置把这个开关关掉!咱们看下代码!

图一中,route.isStripPrefix()被设置为true,直接把/user/**给干掉了!!

图一

所以,尽量使用手动配置的route,同时可以控制每个route的stripPrefix属性

还有一点是,只要是注册到Eureka中的服务,通过DiscoveryClient都可以注册到ZUUL的转发路径中,尽管有些服务是你不想要转发的。虽然,ZuulProperties中有ignoredService属性可以配置用来过滤掉一些serviceId,但是由于Eureka中可以动态加入服务实例,你也不可能每次有新服务加入的时候你修改代码再发布你的ZUUL吧!

修正一下,刚刚在stackoverflow上查到,通过如下配置可以屏蔽掉来自DiscoveryClient的route,

zuul.ignored-services=*

你可能感兴趣的:(微服务化遇坑之(一)- ZuulRoute, stripPrefix)