这是一个非常简单的API网关的例子。
这个例子有以下功能： // TODO:
下面会涉及到一些看上去非常高大上的名次，其实对应的使用场景不难理解，我用一个例子来说明API网关的这些高大上的功能。
商城首页需要显示推荐的商品、当前用户看过的商品、畅销的商品等三类信息，这三类信息在后端由三个微服务接口提供。
简单直白的说，就是把返回数据的格式转换下。
后端的畅销商品微服务由于历史原因，提供的是XML格式的返回，但前端需要JSON格式的，而且畅销商品的服务程序修改成本比较高。可以在API网关里做这个转换，前端调用API网关。
网关可通过Feign Client (或RestTemplate等方案) 读取服务，然后转换格式并返回给前端。
简单直白的说，就是把几个接口的数据合并到一起。
例后端服务往往拆分得比较细，这样才能够被更多复用，例子中三个微服务就是这种原因。前端一个页面上通常需要显示更多内容，首页显示了这三部分内容。如果首页分别调用三个服务，并显示数据。但这样做增加了网络请求次数，会减慢页面显示速度。为了加速前端显示，会在API网关里把多个微服务的返回合并成一个，供前端调用。
网关可通过Feign Client (或RestTemplate等方案) 读取几个微服务，然后合并数据并返回给前端。
简单直白的说，就是要合并几个服务的时候，发现一个服务不正常了，那么就不用它了，而且后面访问都直接略过它，这样做就叫“熔断”，这样做后，就是另外一个高大上的名次了“服务降级”。
如果例子中的三个微服务，其中某一个，例如当前用户看过的商品，这个微服务出现为题了，每次连接都响应非常慢，这会拖慢整个用户请求的速度，在用户端是不可接受的。缺少这个信息比拖慢响应速度，用户更容易接受些。因此由API网关判断，这个服务是坏掉了，那么以后就不再使用这个服务了，给用户仅返回其余两个服务的结果。这就是熔断。
熔断机制在spring-cloud里可通过 Hystrix 的 HystrixCommand 来实现。
简单直白的说，就是一个服务，只能供同时x个访问，第x+1个访问，就不往这发了，这个x+1的用户就被服务降级了。等x里面有请求结束了，后续访问再进来。更直白点，就是又个计数器。
限流和熔断有相似之处，如果某个服务，例如还是用户看过的商品服务，只能同时支持1000个访问量，超过1000个并发时，会拖慢所有响应的速度，因此并发超过1000时，不调用这个服务，并发降低时调用并返回数据。
限流和熔断的区别是：熔断后所有用户都不会使用这个微服务；限流还是有部分用户会正常使用的。
某些微服务的数据很少变化，为减少请求次数，缓存结果。例如推荐的商品，一般不需要每次都去这个微服务请求，因为一般时定时重新计算的。可以在API网关处缓存一份，每次从缓存中获取，提高响应速度。
简单直白点，我是api网关，所有前端都访问我，那么我这里还不是想从哪个微服务取数据返回给前端都可以吗。从集群里选择一个就是选择路由，选择了某个服务的某个版本，就是版本控制。
我们会对某个微服务升级，升级后可能新老版本同时使用，例如升级推荐商品算法，可能有1.0版和2.0版两个推荐商品算法服务，这时我们可以不修改前端，而是在API网关里控制具体使用哪个版本，这就是路由选择。通过路由选择来实现版本控制的升级、回滚等操作。
应用通常需要用户登录、认证等，在API网关处实现用户身份获取和权限验证，可减少在后端微服务处的操作。
如果某个服务在其他的域名下提供，AJAX直接调用会有跨域问题，如果域名不支持跨域访问，并且由于各种原因无法使他支持（例如服务不是自己提供的），那么通过一个API网关来中转一下，就成了一个不错的选择。这种情况下，程序也比较简单，因为Spring API Gateway可以通过配置实现这个功能。
增加了API网关后，后端微服务的修改，一般不需要前端跟着修改，减少前端的修改。某些操作，例如认证等统一放到了网关处，也减少了修改时每个服务都修改的工作。
使用API网关后，增加了系统的复杂度，也会降低性能（速度再快，多加一层，都会延缓响应速度）。要在项目中根据具体情况取舍。
Spring Cloud Gateway的文档有详细说明如何配置使用Spring Cloud Gateway，来实现路由和路由过滤器。 官方文档请看这里
Spring Cloud Gateway的项目中不能有spring-boot-starter-data-rest、spring-boot-starter-web等依赖，在 gateway 的项目中写 controller 也是可以用的。