老张正准备下班，路过小齐的位置，发现他正在阅读Spring Cloud Gataway的官方文档。
看了看时间，等公交车还有一会儿，顺便就和小齐交流一下，便问道：“你在学习Spring Cloud网关吗？”
小齐听到声音后转过身来，便看到老张拉了一把椅子坐下。正好自己有一些疑惑的地方，也想找人交流学习一下。
“是啊，我最近不是在学习微服务这部分知识吗，现在学到网关这部分了。其实我不是特别明白，为什么我们的微服务需要网关呢？”
什么是网关
老张神秘一笑，说道：“我给你看两张图你就明白了。”然后在小齐的电脑上搜出了这篇文章里面的两张图。
“我们假设你现在要做一个电商应用，前端是移动端的APP，后端是各种微服务。那你可能某个页面需要调用多个服务的数据来展示。如果没有网关，你的系统看起来就是这个样子的：”
没有网关
“而如果加上了网关，你的系统就会变成这个样子：”
有网关
“嗯，这看起来是一个‘高内聚，低耦合’的思想，如果不使用网关，可能有什么坏处呢？”小齐问道。
“这个其实从刚刚的第一张图你就看得出来，如果没有网关，你的客户端就会变得非常麻烦。对每一个微服务，可能都要做权限认证、负载均衡等工作；而且后端的微服务可能还使用了不同的消息通信协议；最重要的是，如果你想对微服务进行重构，比如拆分或者合并为服务器，那也必须得修改客户端，增加了复杂性。”
网关的技术选型
小齐：“那看来网关确实是至关重要，现在市面上有哪些微服务网关呢？”
“我们在实现网关的时候，需要考虑到的是它的性能和可扩展性。对于现成的产品来说，NGINX Plus是一个很不错的选择，NGINX Plus 提供了一个成熟的、可扩展的、高性能 web 服务器和一个易于部署的、可配置可编程的反向代理。NGINX Plus 可以管理身份验证、访问控制、负载均衡请求、缓存响应，并提供应用程序可感知的健康检查和监控。除此之外，你还可以使用Node.js或者Netty根据自己的需求去自己写一个网关。而且Spring Cloud也提供了一些已经写好的微服务网关框架，你知道有哪些吗？”
“我查了一下，好像Spring Cloud Gataway和Netflix的Zuul都挺不错的。但Netflix的套件暂停开发了，所以我现在主要在看Spring Cloud Gateway。”
老张点点头，道：“是的，Netflix很多组件到停止开发了。前两天我们讨论的Hystrix也是，但是Hystrix的替代产品还在孵化中。但网关方面，Spring Cloud Gateway已经孵化完成了，可以用来替代Zuul。那你知道Spring Cloud Gateway的原理吗？”
Spring Cloud Gateway
小齐把刚刚自己正在看的官方文档打开，然后给老张看了官网文档的这个图，一边说道：“Spring Cloud Gateway是基于Spring Boot 2.0, Spring WebFlux, Reactor项目构建的，底层是Netty。它的流程其实和Zuul很相似，使用一系列的过滤器去处理请求，达到我们自己想要的定制化。”
原理图
老张问：“那里刚刚看完了官方文档，可以跟我总结一下它有哪些功能吗？”
“Spring Cloud Gateway几乎可以满足绝大多数网关的需求。它主要有下面一些功能：”
断言 Predicate
断言可以指定「在什么情况下」可以匹配某个路由。断言是基于Java 8提供的Predicate接口。Gateway（以下简称Spring Cloud Gateway为Gateway）提供了一些默认的断言。你可以在官方文档查看具体有哪些断言以及它们的用法。
支持时间、Cookie、Header、Host、HTTP Method、相对路径、URL查询语句、远程IP等来做断言。比如：
spring: cloud: gateway: routes: - id: method_route uri: https://example.org predicates: - Method=GET
网关过滤器 GatewayFilter
Gateway也提供了一些已经写好的过滤器。可以查看官方文档。主要有重写request或者response的header、parameter、body、session、安全、重写路径、重试以及对熔断的一些支持。
全局过滤器 Global Filters
全局过滤器与网关过滤器类似，只是默认会给所有的请求都添加上全局过滤器。当然，也可以自己定义全局过滤器。过滤器的顺序可以通过@Order注解来指定：
@Bean @Order(-1) public GlobalFilter a() { return (exchange, chain) -> { log.info("first pre filter"); return chain.filter(exchange).then(Mono.fromRunnable(() -> { log.info("third post filter"); })); }; } @Bean @Order(0) public GlobalFilter b() { return (exchange, chain) -> { log.info("second pre filter"); return chain.filter(exchange).then(Mono.fromRunnable(() -> { log.info("second post filter"); })); }; } @Bean @Order(1) public GlobalFilter c() { return (exchange, chain) -> { log.info("third pre filter"); return chain.filter(exchange).then(Mono.fromRunnable(() -> { log.info("first post filter"); })); }; }
其它功能
Gateway还提供了其它很多功能，比如说SSL方面的配置、基于netty的access log、跨域、actuator端点等等。具体的用法可以参考官方文档。
尤其是actuator端点，它可以让我们使用HTTP请求去动态地获取、新增、删除路由。具体的使用方法和参数查看官方文档。
定制化
除此以外，Gateway提供了一些接口和抽象类。用户还可以自己定制化断言、Filter、路由等，实现更个性化的要求。参考文档在这里，但是目前文档还不完善，可以自己看看源码。
与注册中心配合
老张：“嗯，上面基本上把Spring Cloud Gateway的功能总结全了。它还可以与Spring Cloud的注册中心无缝集成。”
小齐接着老张的话，说道：“是的，Gateway可以很方便地与注册中心配合起来使用，默认使用Ribbon实现了负载均衡。你只需要加入某个注册中心的依赖，比如consul-discovery，然后把配置打开就行了：”
spring.cloud.gateway.discovery.locator.enabled=true
“这样你就可以请求Gataway的/service-id/path来访问服务名叫service-id的某个微服务的/path路径了。比如：”
❝http://gateway:8080/service-user/hello
->
http://service-user:8080/hello
❞
也可以对某个微服务做个性化的配置，参考文档。
网关本身的负载均衡
说完后，小齐问道：“那所有微服务就只有一个网关，万一并发量上去了，网关承受不住怎么办？”
老张笑道：“正如你上面所说，Spring Cloud Gateway底层是Netty的，它本身就能承受比较大的并发。如果还是承受不了并发量，那可以注册多个Gateway实例，然后在前面弄一个Nginx或者F5等负载均衡器。大概图是这样：”
网关负载均衡
老张看了看时间，差不多该去赶车了。“今天就到这吧，下次再交流~”
