微服务-API网关-整体架构思考

API网关介绍

API网关这个东西的提出其实已经有些年头了，以前主要是运用在开放平台这样的对外提供接口服务的部门，随着微服务概念越来越深入人心，API网关也越发的流行了。

现在各个部门都可以把自己的服务通过API网关暴露给其他部门或者公司外部使用，和Service Mesh一起作为微服务管理的标准解决方案。

API网关就是进入各个服务的统一入口，API网关里面管理着一堆微服务，外面的客户端想要访问里面的微服务就需要先通过API网关，然后API网关对请求处理之后再发送到各个微服务中去，微服务处理完请求后回应也要先经过API网关，然后再返回给客户端。

API网关的几种使用场景

• 面向Web App

这类场景，在物理形态上类似前后端分离，此时的Web App已经不是全功能的Web App，而是根据场景定制、场景化的App。

• 面向Mobile App

这类场景，移动App是后端Service的使用者，此时的API GW还需要承担一部分MDM（此处是指移动设备管理，不是主数据管理）的职能。

• 面向Partner OpenAPI

这类场景，主要为了满足业务形态对外开放，与企业外部合作伙伴建立生态圈，此时的API GW需要增加配额、流控、令牌等一系列安全管控功能。

• 面向Partner ExternalAPI

这类场景，业界提的比较少，很多时候系统的建设，都是为了满足企业自身业务的需要，实现对企业自有业务的映射。当互联网形态逐渐影响传统企业时，很多系统都会为了导入流量或者内容，依赖外部合作伙伴的能力，一些典型的例子就是使用「合作方账号登录」、「使用第三方支付平台支付」等等，这些对于企业内部来说，都是一些外部能力。此时的API GW就需要在边界上，为企业内部Service 统一调用外部的API做统一的认证、（多租户形式的）授权、以及访问控制。

• 面向IoT SmartDevice

这类场景，业界就提的更少了，但在传统企业，尤其是工业企业，传感器、物理设备从工业控制协议向IP转换，导致具备信息处理能力的「智能产品」在被客户激活使用直至报废过程中，信息的传输不能再基于VPN或者企业内部专线，导致物理链路上会存在一部分公网链路。此时的API GW所需要满足的，就是不是前三种单向的由外而内的数据流，也不是第四种由内而外的数据流，「内外兼修」的双向数据流，对于企业的系统来说终端设备很多情况下都不是直连网关，而是进过一个「客户侧」的集中网关在和企业的接入网关进行通信。

我要讲解的是第一种场景：Web App。

为什么需要API网关

从安全角度考虑

身份认证

在API网关把请求发送给后端微服务之前需要先认证发起请求的用户是谁，这个用户是否在黑名单里面。

身份认证包含前端登录认证和API调用认证两个方面。

权限控制

在认证完身份后，如果通过了就需要再查看这个用户有没有相应的操作权限。

我们把身份认证和权限控制抽象出来统一放在API网关里面来做&