微服务中的 API 网关（API Gateway）

以下是个人于搭建脚手架过程中的一些理念。

SpringCloud微服务架构中，会使用到网关服务。那么可想而知，网关作为边缘服务，其承受的压力是最大的，当然是要考虑网关的高可用，那么就需要多个网关服务集群部署，从而达到高可用目的。层看到过“双重网关”的概念，不过目前不讨论这个，有兴趣的可以看双重网关。

需求设求
众所周知，一切架构都必须按需求来设计，万能构架基本上是不存在的，即使是像Spring Security安全架构也只是实现了一个能用方式，并不是放之四海而皆准的，但是一个构架的良好扩展性是必须的，可以让使用者按照自己的需要进行扩展使用。所以为了说明本示例的实现，先假定这样一个需求
1，需要有一个Web网关服务进行权限统一认证
2，网关后面有其他的微服务，负责用户、商品、支付等等，但是这些服务需要认证成功之后才能访问
3，需要支持同一个请求可以被多个角色访问

问题
由于我们使用的服务系统架构，所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果，那么如何才能访问各个服务呢？

按照微服务设计的指导原则，我们的微服务可能存在下面的问题：

1·服务使用了多种协议，因为不同的协议有不同的应场景用，比如可能同时使用 HTTP, AMQP, gRPC 等。
2·服务的划分可能随着时间而变化。
3·服务的实例或者Host+端口可能会动态的变化。
那么，对于前端的UI需求也可能会有以下几种：

1·粗粒度的API，而微服务通常提供的细粒度的API，对于UI来说如果要调用细粒度的api可能需要调用很多次，这是个不小的问题。
2·不同的客户端设备可能需要不同的数据。Web,H5,APP
3·不同设备的网络性能，对于多个api来说，这个访问需要转移的服务端会快得多
以上，就是我们构建微服务的过程中可能会遇到的问题。那么如何解决呢？

这种情况下，我们就需要一个东西， API 网关（API Gataway）。

下面是百度上针对于 API 网关的介绍：

API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

Chris Richardson 在他的博客中把 API 网关划分为以下两种：

1·单节点 API 网关
2·Backends for frontends 网关

单节点网关

单节点的 API网关为每个客户端提供不同的API，而不是提供一种万能风格的API。

这个网关和微软在 eShop 项目中推荐的网关是一致的。

Backends for frontends 网关

这种模式是针对不同的客户端来实现一个不同的API网关。

通常情况下， API 网关要做很多工作，它作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作，除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做，那么可以试想在高并发的情况下，这里可能会出现一个性能瓶颈。

另外，如果没有开源项目的支撑前提下，自己来做这样一套东西，是非常大的一个工作量，而且还要做 API 网关本身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其他服务，而就是这个API网关。

至于以上我提到的双重网关，暂不做讨论，主要是没那个能力呀。