微处事场景下，每一个微处事对外袒露了一组细粒度的处事。客户真个请求可能会涉及到一串的处事挪用，如果将这些微处事都袒露给客户端，那么客户端需要多次请求差此外微处事才华完成一次业务措置惩罚惩罚，增加客户真个代码庞大度。此外，对付微处事我们可能还需要处事挪用进行统一的认证和校验等等。微处事架构虽然可以将我们的开发单元拆分的更细，降低了开举事度，但是如果不能够有效的措置惩罚惩罚上面提到的问题，可能会造成微处事架构实施的掉败。
Zuul参考GOF设计模式中的Facade模式，将细粒度的处事组合起来供给一个粗粒度的处事，所有请求都导入一个统一的入口，那么整个处事只需要袒露一个api，对外屏蔽了处事真个实现细节，也减少了客户端与处事器的网络挪用次数。这就是API处事网关(API Gateway)处事。我们可以把API处事网关理解为介于客户端和处事器真其中间层，所有的外部请求城市先颠末API处事网关。因此，API处事网关几乎成为实施微处事架构时必需选择的一环。
Spring Cloud Netflix的Zuul组件可以做反向代办代理的成果，通过路由寻址将请求转发到后真个粗粒度处事上，并做一些通用的逻辑措置惩罚惩罚。
通过Zuul我们可以完成以下成果：
动态路由
监控与审查
身份认证与安适
压力测试: 逐渐增加某一个处事集群的流量，以了解处事性能;
金丝雀测试
处事迁移
负载剪裁: 为每一个负载类型分配对应的容量，对赶过限定值的请求弃用;
静态应答措置惩罚惩罚
1. 构建网关 1.1 构建Zuul-Server 编写pom.xml文件Zuul-Server是一个标准的Spring Boot应用，所以还是担任自我们之前的parent：
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 "> <modelVersion>4.0.0</modelVersion> <parent> <groupId>twostepsfromjava.cloud</groupId> <artifactId>twostepsfromjava-cloud-parent</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../parent</relativePath> </parent> <artifactId>zuul-server</artifactId> <name>Spring Cloud Sample Projects: Zuul Proxy Server</name> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>
这里我们增加了spring-cloud-starter-zuul的依赖。
编写启动类