一个完整的微服务项目是由很多很多的子项目构成，类似我们前面写的案例，它有两个业务模块，一个订单模块，一个商品模块。
但是，我们在调用的时候会发现，每一个服务的调用地址是各不相同（域名、端口），而 Api 网关就是将这些个调用地址进行保护，对外有一个比较统一的地址（不可能一模一样，不然怎么区分调用的什么模块）。
如上图，用户请求后，第一步就是要过 Gateway 网关，通过网关进行处理，将请求发送到对应的模块中。
二、Api 网关的作用Api 网关除去对这些 Api 服务进行统一管理之外，还有安全验证、限流、过滤等很多种作用，详细我们来看官网的介绍。
三、Api 网关种类常用的 Api 网关有这么几种：Gateway、Zuul 1.0、Zuul2.0 等
四、Gateway 网关由来在 Gateway 没有出来的时候，我们都是使用的 Netflix 提供的一种网关解决方案：Zuul 1.0。
但是 Zuul 1.0 是有着很大的问题的（例如性能不是很好，Zuul 2.0 的开发老是跳票），所以 Spring 团队直接自己去搞一个 Api 网关，也就是我们现在所要学习的 Gateway。
五、Zuul 1.0 与 Gateway 的区别Zuul 1.0：
- 使用的是阻塞式的 API，不支持长连接（websocket 就是不支持长连接）；
- 底层使用的是 Servlet
- 没有一部支持、流控功能。（这些功能均由 Hystrix 支持提供）
Gateway：
- 提供了异步支持
- 提供了抽象负载均衡、流控等功能，并且实现了 RedisRateLimiter。
Gateway & Zuul 1.0 相同点
- 底层都是 Servlet
- 两者均是web网关，处理的是http请求
Gateway & Zuul 1.0 不同点
- 内部实现
Gateway 对比 Zuul 多依赖了 Spring-WebFlux，在 Spring 的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于 Spring Cloud 套件，Zuul则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等。
- 是否支持异步
Zuul 仅支持同步，Gateway 支持异步。理论上 Gateway 则更适合于提高系统吞吐量（但不一定能有更好的性能，最终性能还需要通过严密的压测来决定）。
总的来说，在 Spring Cloud 生态的基础组件中，Gateway 相比 Zuul 而言更加具备优势，光从流式编程 + 异步就足以让开发者选择他们。
多说一句！虽然 Zuul 已经发布了 Zuul 2.0，基于Netty，也是非阻塞的，支持长连接，但 Spring Cloud 暂时还没有整合计划，也就是说，Zuul 也凉凉了~~~
这一讲就讲到这里，有问题可以联系我：QQ 2100363119，欢迎大家访问我的个人网站：https://www.lemon1234.com
最近网站已经做好，并且已经上线，欢迎各位留言~~
