京东API网关实践之路！

京东作为电商平台，近几年用户、业务持续增长，访问量持续上升，随着这些业务的发展，API网关应运而生。

API网关，就是为了解放客户端与服务端而存在的。对于客户端，使开放给客户端的接口标准统一，以降低客户端的接入成本；对于服务端，使服务端无需关注接口暴露在公网面临的问题而着眼于业务的实现，来提升开发效率。

在刚刚过去的全民狂欢购物节，API网关如何做才能高效的处理近千万的并发请求是本文的重点。

API网关，作为客户端与服务端的纽带，核心任务是将客户端请求转发到后端服务。但是，作为所有流量请求的入口 , 面临的很重要的一个问题就是高并发，因为高并发的需要，要求网关处理请求必须高效；其次是安全防护，安全主要是指对网关对后端服务的一个保护；再者就是完善的数据统计及监控报警机制；当然，为了方便我们内部用户接入，多协议适配的支持、灰度发布上线也是必备功能。

API网关特征：

1）高性能：在高吞吐量下保证低延迟。

2）安全稳定：身份认证、精细化流量控制、大数据实时分析等多种手段保障服务质量。

3）平台化：进行各项数据监控，提供数据分析、监控告警、故障定位等服务。

4）灰度：灰度发布，支持按设备、PIN、自定义比例方式在不影响正常用户的情况下，保障后端服务平稳过渡。

5）方便快捷：支持http、jsf服务快捷接入，mock功能加快协同开发。

API网关服务于原生客户端、Web、小程序，不限于具体的业务。其主要架构图如下所示：

主要分3层：

• 第1是VIP层，主要是接收客户端http、https请求，并将请求转发到网关；
• 第2是网关层，对请求进行合法性校验并转发；
• 第3层就是后端业务API，这些业务方，就是我们服务的主要对象。

网关高并发实践主要利用异步化处理技术，将请求由同步变为异步，利用NIO多路复用，达到请求接收最大化。

首先看下图同步处理过程：

采用同步处理，线程的释放就受限于后端服务响应的快慢。当响应过慢时，线程池就容易出现耗尽现象，并且资源利用率上不去，吞吐量很低，或者说此时的大量请求都会被服务器拒绝。

由此可以看出，同步处理使资源利用率得不到充分的利用，大量请求被拒绝同时又影响了用户体验。如果想提高并发只能通过横向加机器，这样造成机器资源大量浪费的现象。如果是网关这么处理，那么这种现象体现的将更明显。

为了解决同步引起的问题，采用异步，如下图所示：

通过实现异步化处理，线程可以在开启异步后直接释放，当前请求的响应会被延后，当后端服务有响应后，再将响应写回给客户端。这样就算是有后端服务响应很慢，因为线程已被释放了，可以继续接收新的请求，达到服务资源使用的最大化。

精细化流控：

作为所有业务方的第一道防线，网关承载着海量流量的访问，以及随时可能爆发的恶意流量攻击的压力。

很典型的，每年双十一或是618都会有刷子恶意刷后端服务接口，如果网关不做处理直接将流量透传到后端服务，后端服务很大可能会被瞬时流量冲垮，至少会增大后端服务响应延时及浪费公司大量资源来处理攻击。

那么，进行流量控制就是必不可少的。网关提供秒级的流量控制，可以对单个接口按地域、风控等级等维度进行流控配置。这样流量只到了网关层面，就不会透传到后端服务了。

流控主要是采用令牌桶算法实现，策略主要有排队或熔断，具体的策略根据不同的端，选择合适的流控动作。

授权及签名认证：

API暴露在公网，肯定会存在被刷的风险，网关要做的就是尽可能降低这种风险。就像通过制定法律来尽可能减少犯罪一样，通过访问权限控制、签名认证、跨域校验等来尽可能的降低API接口被刷的风险。

授权：只有通过API负责人授权的接口，客户端才有权限访问 。如果未授权，在网关处拦截，响应给客户端没有访问权限；

签名认证：按规则将请求参数通过HMAC-SHA256算法运算生成签名值，对客户端计算的签名值与网关计算的签名值进行匹配，匹配的请求继续向下流转，否则直接被拦截。

跨域效验：

对于WEB端应用，调用网关属于跨域请求。这类请求，如果不进行校验，会产生跨域攻击。所以需要获取到客户端请求来源，对客户端请求来源进行认证，只有合法的请求来源才被允许访问后端服务。对于小程序应用，也会校验小程序真实性。

设想这样一个场景：有一个核心业务，做了比较大的改动，又或者是项目重构，开发完成，同时测试完成，要上线了。但是，问题也来了：因为改动很大，业务很重要，测试所拿机型设备有限，担心直接全部上线会影响测试未覆盖的线上用户。那么，能不能先有10%的流量请求到新服务，看下用户使用情况，再决定是否全部上线呢。

为了满足这种需求，网关提供按设备号、用户标识的定点灰度测试，同时支持按比例进行的灰度上线。

用户请求到网关，如果开启灰度模式，就获取到灰度地址，将请求转发到特定的服务。

在高举可持续发展旗帜的时代下，如果一个产品仅仅做到功能齐全是远远不够的。只有做到可持续发展，实现自动化运营的产品才真正是个好产品。API网关平台化意味着N条产品线，一个网关，通过实现自动化运营，解放生产力，打造统一化平台，提供可持续化产品，拥抱API经济，实现API变现。

API网关控制台首页

  API网关统一管理着发布方对外暴露的API服务，各个服务可以独立开发部署。针对后端服务的发布与下线，发布方可通过API网关提供界面化管理控制平台，实现流程化管理，线上审批通过后，实时生效，无需手动控制，实现自动化运营。

同时对于后端服务的各项配置，如API权限管理、流量控制等，API网关进行自动化管理，动态配置，动态加载，保证在无需重启服务的情况下即可进行配置更改操作。

要实现自动化运营，除了对API服务管理做到独立部署、快速扩展外，对于API的调用方也实现自助API开通，授权访问API服务。

由于API网关处在一个内部系统与外部环境的分界点处，所有外部请求都经过API网关进行调度和过滤，每时每刻都有大量请求通过API网关进入内部服务。因此可以在API网关层进行请求接入监控，监控各个接口的访问请求并进行收集，以便相应指标的统计分析。

在API网关界面化管理控制平台中，对收集统计到的监控数据，如API接口调用量、响应时间等信息，提供了可视化的API实时智能数据分析与监控告警功能，订阅API异常报警信息，以便实时监控后端服务运行情况。

后端接口监控数据图

当发生线上故障时，API网关提供一系列的故障现场还原措施进行故障的定位与排查，通过日志实时分析、异常流量实时探测、监控告警等技术，快速拿到故障快照、还原故障现场以及迅速定位问题原因。

作为系统的唯一入口，API网关的地位是至关重要的。API网关位于技术中台的核心要塞，符合技术中台战略发展方向，做到了产品组件化、需求结构化、数据配置化、业务可视化：

对于基于微服务架构实现的后端服务而言，接入一个性能高效、安全稳定的API网关，享受其带来的身份认证、路由请求、协议转换等便利，更加专注于自身业务逻辑的开发，是有必要的。利用API网关对各个服务API进行统一的管理和监控，解决客户端与后端服务交互不便的问题，具有十分重要的意义。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：
长按订阅更多精彩▼
如有收获，点个在看，诚挚感谢