API怎样管理才算正确？（下）

接《API怎样管理才算正确（上）》

API网关在微服务架构中起到了至关重要的作用，它作为微服务系统的大门，向我们提供了请求转发，服务熔断，限流流控等公共功能，又统一整合了各个微服务，对外屏蔽了系统的复杂性和差异性。

四、API网关和反向代理

在传统部署架构中，反向代理大多是用于多个系统模块间的聚合，实现负载均衡，外网向内网的转发。通过修改配置文件的方式来进行增加或删除节点，并重启服务才可生效。通常来说，反向代理服务器只具备负载均衡、转发基本功能，若要需要其他功能，需要增加扩展或提供脚本来实现。

在API网关部署模式中，API网关可以看作特殊的反向代理，是对反向代理服务器功能的扩充，同时API网关仅局限于服务API层面，对API做进一步的管理和保护。API网关不仅提供了负载均衡，转发功能，还提供了灰度发布，统一认证，熔断，消息转换，访问日志等丰富的功能。

倘若我们实际运用中，不需要服务发现、服务动态扩容、服务熔断、统一认证、消息转换等一系列API网关功能，我们完全可以使用反向代理服务器来部署微服务架构，当然如果这样做如遇到增加或减少服务节点时，需要修改反向代理服务器配置，重启服务才可以生效。而当我们可能不仅仅需要负载均衡，内外网转发，还需要其他功能，又同时想实现一些各服务都需要的通用的功能时，这时候就改考虑API网关了。

五、API网关对API的认证及鉴权

目前在微服务中，我们还需要考虑如何保护我们的API只能被同意授权的客户调用。那么对于API的保护，目前大多数采用的方式有这么几种，分别为AppKeys，OAuth2 和 OAuth2+JWT。

1.AppKeys

目前采用AppKeys Auth认证的公有云API网关和数据开放平台居多，具有代表性的如聚合数据、赛合一数据，这种认证模式是由API网关颁发一个key，或者appkey+appsecret+某种复杂的加密算法生成AppKey，调用方获取到key后直接调用API。这个key可以是无任何意义的一串字符。API网关在收到调用API请求时，首先校验key的合法性，包括key是否失效，当前调用API是否被订阅等等信息，若校验成功，则请求上游服务，返回结果。此处上游服务不再对请求做任何校验，直接返回结果。采用AppKeys认证模式比较适合Open Service的场景。其中并不涉及到用户信息，权限信息。

2.OAuth2

大部分场景中，我们还是需要有知道谁在调用，调用者是否有对应的角色权限等。OAuth2可以帮助我们来完成这个工作。在OAuth2的世界中，分为以下几种角色：Resource Owner，Client，Authorization Server，Resource Sever。

3.OAuth2+JWT

OAuth2 + JWT流程跟OAuth2完全一致。了解OAuth2的都应该知道，OAuth2最后会给调用方颁发一个Access Token，OAuth2+JWT实际上就是将Access Token换成JWT而已。这样做的好处仅仅是减少Token校验时查询DB的次数。

有那么多认证方式，加入了API网关后，该怎么做呢？在微服务的世界中，我们每个服务可能都会需要用户信息，用户权限来判断当前接口或功能是否对当前用户可用。我们可以将统一认证放在API网关来实现，由API网关来做统一的拦截和鉴权，结合上文所描述的认证方式中，OAuth2协议中可以携带用户信息，故采用OAuth2。