API网关有点类似于设计模式中的Facade模式

图上有很多Service ,有UserService、ProductService、OrderService，即用户服务、产品服务、订单服务。假如这个网站前端想要访问后端的产品服务，那就有可能要检查是否登录过，顺序就成了先访问UserService中的login，发现已经登录了，就可以查询产品了。这种形式会带来不安全：

• 后台的微服务对外是暴露的
  前端可以知道访问的服务是什么，传递的什么参数，这些是透明的
• 如果要提交订单，要做三步操作：①检查是否登录；②检查是否产品足够；③提交订单。着三步操作要对应不同的微服务，而且还有顺序性。前端就要分别访问，等待时间过长。
  这就好比以前看新闻网站，先看下搜狐网站，再看下新浪网站，最后看下网易新闻，后来出来了hao123一类的门户网站，我们可以通过这种门户，进行转发。这样所有的分别面对的就是hao123，新浪、搜狐、网易这些都是透明的。现在出来的今日头条，更夸张，新闻从哪里来的都不清楚了，只要下载一个app就可以面向所有的新闻。

鉴于这种场景，就诞生了一种叫gateway的东西，即“网关”。是后台服务于前端的一个接口，前端所有人都访问gateway,gateway再去访问UserService、ProductService、OrderService等等。

API网关一般都是微服务系统中的门面

“网关”就相当于一个接口人，前端面向的是它，后端面向的也是它，不论什么时候，都帮前后端转发。

API网关是微服务的重要组成部分

不管用springcloud，还是dubbo，又或者是ZeroC IceGrid，API网关都是必须要做的，不能逃避的。

API网关的常见作用

• 身份的验证和安全
  一般来讲，绝大多数的业务都要验证身份是否安全的，比如是否登录、当前环境是否安全、上传的文件是否安全等等一系列东西。理论上，API网关后的所有东西都是安全的，它就像个防火墙，将所有不安全因素都挡掉了。

• 审查和检测
  API网关有点类似拦截器，请求进来先经过我，然后我去分发，分发完成后响应还要经过我，我再返回。这种情况，可以对一些边缘数据进行统计，比如当前业务执行了多长时间，当前业务是否需要用户登录，当前业务调用了什么服务，这样当同一个用户调用了不同的服务，就可以对这个用户进行一个行为的记录。

• 动态路由
  相当于来一个，网关将请求和服务进行一个映射，这样进过API网关处理下，就可以立马找到对应的服务了。

  如果使用dubbo，动态路由是不用处理的，因为dubbo已经实现的很好了。如果要是用springcloud，那就要去处理了，因为spirngcloud没有这个实现。

• 压力测试
  举个经典的例子，双11电商平台需要压力测试，是需要阶梯性测试的。比如认为12点到1点需要什么压力，11点到12点需要是个什么压力，这种测试有可能在生产环境上（因为测试环境有可能测试不出某些问题）。例如过两天就要双11了，这时候会向API网关阶梯性的灌入一些数据，增量到5%，10%，直到双11的压力值。

• 负载均衡
  比如同一个业务有三个微服务的集群，那给三个钟的哪一个发请求呢？这就牵扯到了负载均衡。使用dubbo是不用关心这个的，因为dubbo已经做好了。

• 静态相应处理
  当一个业务很明显不会出现动态的业务，比如首页，几天都不更新，那就可能需要做动静分离。当访问首页时候，就不需要访问微服务了，直接将首页给返回就行了。