微服务刚刚诞生的时候，人们将服务进行拆分，实现服务之间的松耦合，并且每个服务有专门的团队维护，然后客户端直接和各个子服务进行交互。比如，订单，商品，会员服务。

那么这种客户端直接和后端服务交互的方式会有什么问题呢？

1、客户端需要知道每个服务的地址

2、每个后端服务都需要实现认证、限流、日志、监控、缓存等功能，重复造轮子大大降低了开发效率，而这些公共业务逻辑完全可以拆分出来

3、假如后端某些服务由之前的http/https调用变成rpc调用，或者某些参数发生改变，则客户端需要做很大调整。

后来人们为了解决这些问题，引入API网关。

当引入API网关后，API网关接管了所有的入口流量，就像nginx，将请求路由到对应的后端服务。这样客户端无需关心后端服务地址，只需调用网关即可。不仅如此，网关还针对这些流量做了功能的扩展，包括鉴权、限流、日志监控、告警、访问控制、协议转换等功能，这样后端服务只需关注自身的业务逻辑。

我们可以将API网关的部分功能做一个简单的梳理。

注册API

API网关要给后端服务赋能，就需要后端服务（API提供者）将API信息注册到网关，并且为每个API配置后端服务的地址。但是，这样遇到的问题是，API之间是独立的，无法将服务于同一功能的API组织起来，统一管理。为了适应真实的服务场景，API网关使用API分组来管理一组API，并配置同一后端，用户（API提供者）不仅可以管理API也可以管理API分组。

下图参考了京东云的API网关

当调用者（API调用者）发起调用时，网关先判断请求来自哪个分组，最后判断请求来自哪个API，如果API提供者对分组添加能力，比如限流，那么这个限流功能只针对分组生效。

身份认证

基本上每个组件都关联了用户信息，需要识别用户身份。因此API网关接管了身份认证的功能，识别调用者信息，并且将其传递给后端服务。常见身份认证的方式有很多，这些方式关注的点是如何携带身份信息，以及如何对信息做加密，选择这些认证方式的考量就是安全性和性能。下面分析几种常见的身份验证的方式：

1、HTTP基本认证(Basic Authentication)

就是将用户名、密码信息进行base64编码，放在Authorization header中发送给网关，网关验证用户名密码是否正确。

好处：调用简单

不足：不够安全，为了防止密码被泄露，一般使用https传输；需要调用远端的用户中心服务，查询用户信息，验证用户名密码的正确性。

2、HMAC Authentication

客户端将请求信息（包含用户名，不包含密码）与密码做HMAC，生成一串散列值（签名信息），传给网关。网关通过用户名获取密码，再和收到的请求信息做HMAC，生成签名信息，并与客户端的签名信息进行比对，一致则验证通过。

好处：安全，客户端无需传密码至网关，同时通过签名的方式防止了请求信息被篡改。

不足：需要调用远端的用户中心服务，查询用户密码等信息；客户端每次调用前还需要生成签名信息，导致调用不太方便。

基于HMAC Authentication的签名认证算法有很多，如AWS、京东云、阿里云API网关的基于AK,SK的签名算法，就是在HMAC Authentication上改进的。

3、JWT Authentication

JSON Web Token（JWT）也是一种常用的身份验证和签名算法，客户端请求登录的时候携带用户名密码请求用户中心服务器，获取token（不包含密码）保存到客户端，客户端携带token调用网关时，网关解析token，通过公钥验证token的正确性，获取用户信息。

好处：安全性高，调用简单，网关无需访问用户中心服务

不足：非对称加密，消耗计算资源

访问控制（授权）

很多情况下，我们并不希望所有的用户都能访问我们的接口，或者只希望某些用户访问到部分内容，那么使用访问授权就能实现。网关在API或API分组级别上对用户的调用做控制，限制用户访问某些分组或者API，常用的访问控制组件有ACL。更为高级的访问控制功能可以参考各大云厂商的访问控制组件，比如AWS的IAM以及阿里云的RAM。

1、访问控制列表(ACL)

ACL是将一组白名单用户或一组黑名单用户关联到具体的API分组或者API，当请求经过网关时，网关会验证调用者是否为白名单或者黑名单用户，以此判断是否允许或拒绝请求。

2、IAM

访问控制（Identity and Access Management， IAM）是针对子用户进行的权限管理，可以提供更精细化的权限控制。IAM的特点是使用一组策略来定义权限，策略包含接口名称，资源（参数），权限类型，这样就将权限控制在资源（参数）层级。

限流

对于经常出现流量突增的系统，比如618，双11大促、微博出现重大新闻事件等，我们很难及时的评估流量，做好应对预案，最终导致服务整个不可用。因此做好限流就十分有必要了，当流量突增超过限流阈值时，通过限流降级策略保护核心业务的正常运转。选择限流方案，主要考虑使用什么样的限流算法，单击限流还是分布式限流。

1、限流算法

简单计数法、令牌桶、漏桶等是常见的限流算法，简单计数法的特点是统计某一段时间内的请求个数，以此判断是否拒绝请求，这种简单粗暴的限流方式无法应对突发流量；令牌桶算法的特点是，以固定速率往桶里添加令牌，通过桶里是否有令牌判断是否拒绝请求，桶的大小决定了突发流量的大小。漏桶的思想和令牌桶相反，以固定的速率分发请求，实现流量的平滑处理。因此，当我们完全不关心流量突发的情况，选择简单计数法即可，当我们无法容忍流量突发，则选择漏桶算法，当我们允许一定程度的流量突发，选择令牌桶算法。

2、单机限流

单击限流，调用数存储在本地，无需频繁的和远端节点交互，性能比较高。

3、分布式限流

分布式限流，调用数存储在远端节点，如redis。每次需要和远端节点交互，性能较低。那为啥还要使用分布式限流呢？因为有些场景下（特别是API网关），限流值是用户配置的，需要保证限流的准确性。我们有个折中的方案，先在本机存储少量的调用数，然后同步到远端节点，这样就成倍的减少了调用远端的次数，虽然准确性有所降低，但是在可接受的范围。

安全

安全是API网关不可或缺的功能，身份验证、访问授权，限流等一定程度上也算是保障后端服务的安全稳定，但是这些远远不够用。API网关的安全防范功能还包括IP限制、waf等。

1、IP限制

主要是通过IP白名单和黑名单列表，允许和拒绝某些IP访问后端服务

2、WAF

网站应用级入侵防御系统（Web Application Firewal， WAF），是通过安全策略，更细粒度的验证请求的合法性，从而为后端服务应用级安全性提供保障。

日志

API网关接管了所有的入口流量，包含丰富的调用日志，所以利用好网关的日志，能够为后端服务做很多事情。API网关的日志通常包括access日志，error日志，审计日志等。access日志通过会记录Trace_id标识一个请求的完整链路、请求总耗时、网关耗时、请求方式、请求体大小、响应体大小、响应状态码、用户标识、API分组标识、API标识、请求是否到后端等。审计日志更完整，除了记录access日志包含的内容，还记录请求参数，响应参数，用户信息等具体内容。下面简单罗列API网关日志可以做什么？

1、简单的日志查询。
2、将指定API分组的日志输入到指定文件、http/https后端、TCP后端、UDP后端、kafka等多个位置，供API提供者做进一步处理。
3、将指定API分组的日志输入到DataDog、Prometheus、ZipKin等服务，提供日志统计、分析、监控的功能。
4、接入计费功能，按调用次数、输入输出流量统一计费。

监控

监控平台是API网关针对API和API分组做统一监控告警，API提供者通过平台配置告警规则，查看实时的监控数据，包括QPS、成功失败次数分布、响应状态分布、响应时间分布、用户调用次数分布、流量分布等。正如日志部分介绍的，如果API提供者需要定制更多的监控功能，可以将日志输入到Prometheus，然后做进一步处理。

API市场

API市场是实现API商业化的有效途径，API网关将API上架到API市场供其他用户购买使用，并根据调用次数或者流量计算费用，最终帮助API提供者获利。

当然，API网关的功能远远不止这些，还包括参数校验、参数转换、协议转换、请求体响应体大小限制、请求跨域访问限制、mock服务、serverless、后端路由、服务发现、缓存、容错降级、金丝雀发布、蓝绿部署等。总之，API网关为后端服务提供更好的体验和保障的同时，也大大缩短了API的上线周期，方便API的运营维护，最终还能实现API的商业化，价值非常之大，意义非常之深远。

点击【阅读】可了解京东云API网关服务

欢迎点击“京东云”了解更多精彩内容