整体的Zuul运行之后你会发现，zuul所实现的就是一个代理功能，那么现在就会出现一个问题，例如：以上一课访问的路径为例：

此时必须要知道应用程序的名称，但是如果不知道这个名称肯定无法访问，可是如果让用户知道这个名称，那么使用这个zuul就没有任何的实际意义，直接调用即可。而zuul的主要功能就是代理，那么代理的功能就是不让用户看见真实的操作，所以在实际的使用之中就需要为zuul设置一些路由规则。

1、【microcloud-zuul-gateway-9501】为指定的应用设置路由路径，修改application.yml配置文件：

zuul:

routes:

microcloud-provider-company: /company-proxy/**

那么此时就可以通过”/company-proxy”来访问”microcloud-provider-company”名称。

但是现在还会存在一个实际的问题，虽然现在开启了路由访问支持，但是依然支持通过应用名称进行访问:

2、【microcloud-zuul-gateway-9501】修改application.yml配置文件忽略掉应用名称访问：

* 忽略掉”microcloud-provider-company”应用名称；

zuul:

ignored-services:

microcloud-provider-company

routes:

microcloud-provider-company: /company-proxy/**

这个时候就可以进行代理的安全使用，但是如果你一个系统之中存在有几百个微服务，如果按照如上的方式进行配置就会非常的麻烦，所以最简单的做法是可以采用一个 通配符 “*”的模式来完成。

zuul:

ignored-services:

“*”

routes:

microcloud-provider- company : /company-proxy/**

现在表示所有的Eureka中的服务名称的信息访问都要忽略掉，所有的访问都需要配置一个映射路径的模式来完成。

3、【microcloud-zuul-gateway-9501】除了以上的模式进行服务定义之外，在zuul之中也可以采用如下的方式进行处理：

zuul:

ignored-services:

“*”

routes:

company.path: /company-proxy/**

company.serviceId: microcloud-provider-company

其中在代码里面出现的”company”是一个逻辑名称，改名称的主要作用是将path与serivceId绑定在一起。

4、【microcloud-zuul-gateway-9501】如果说现在不想通过Eureka进行访问，则也可以直接连接到company微服务的 地址 。

zuul:

ignored-services:

“*”

routes:

company.path: /company-proxy/**

company.url:

但是从实际的开发来讲不建议采用此类模式处理，因为所有的服务如果直接绑定了指定的服务提供者的地址，那么将不方便进行 负载均衡 的配置处理，而且没有Eureka所有微服务的管理也非常不方便。

5、【microcloud-zuul-gateway-9501】设置公共前缀：

zuul:

ignored-services:

“*”

routes:

microcloud-provider-company: /company-proxy/**

prefix: /gwolf-proxy

一旦存在有前缀定义之后所有微服务的访问上就必须追加有前缀名称：

以上的地址：

* “/gwolf-proxy”:整个zuul的前缀；

* “/company-proxy”:是在zuul中定义的映射路径；

* /company/get/hello：是微服务提供者提供的操作路径；