最近手头的一个项目由于业务增长，原本一个应用的大杂烩系统，无论功能迭代开发、发布还是回归测试上，项目上线质量越发难以控制。 于是想逐渐往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=*
