京麦是京东商家的多端开放式工作平台，是京东十万商家唯一的店铺运营管理平台，为京东商家提供在移动和桌面端的操作业务，京麦本身是一个开放的端体系架构，由京东官方和 ISV 为商家提供多样的应用服务。

京麦开发平台是京东系统与外部系统通讯的重要平台，技术架构从早期的单一 Nginx+Tomcat 部署，到现在的单一职责，独立部署，去中心化，以及自主研发了 JSF/HTTP 等多种协议下的 API 网关、TCP 消息推送、APNs 推送、降级、限流等技术。

京麦开放平台每天承载海量的 API 调用、消息推送，经历了 4 年京东 618 的流量洗礼。本文将为您揭开京麦开放平台高性能 API 网关、高可靠的消息服务的技术内幕。

高性能 API 网关

京东内部的数据分布在各个独立的业务系统中，包括订单中心、商品中心、商家中心等，各个独立系统间通过 JSF（Jingdong Service Framework）进行数据交换。而 API 网关基于 OAuth2 协议提供，ISV 调用是通过 HTTP 的 JSON 协议。

如何将这些内部数据安全可控地开放给外部 ISV 进行服务调用，以及如何快速地进行 API 接入实现数据报文转化，在这个背景下 API 网关诞生。

API 网关在架构设计上采用了多层接口，到达网关的请求首先由网关接入层拦截处理，在接入层进行两个主要环节的处理：

1. 网关防御校验：这里包含降级和限流，以及多级缓存等，进行数据正确性校验；

2. 网关接入分发：网关分发会根据网关注册中心的数据进行协议解析，之后动态构建调用实例，完成服务泛化调用。

API 网关是为了满足 618 高并发请求下的应用场景，网关在服务调度、身份授权、报文转换、负载与缓存、监控与日志等关键点上进行了针对性的架构优化。

API 元数据统一配置

API 的调用依赖对元数据获取，比如 API 的字段信息、流控信息、APP 密钥、IP 白名单等、权限配置等。在 618 场景下，元数据获取性能是 API 网关的关键点。基于 DB 元数据读取是不可取的，即使对 DB 做分库分表处理也不行，因为 DB 就不是用来抗量的。

其次，要考虑到元数据的更新问题，定时的轮训更新会产生极大延迟性，而且空轮训也是对系统资源的极大浪费，采用 MQ 广播通知不失为一种解决办法，但 MQ 仅仅解决数据同步的问题，数据缓存在集群里服务如何保证数据一致性和数据容灾，又极大的增加了系统复杂度。

所以综合考虑服务器性能和网络 IO 等因素，在 API 元数据读取采用基于 ZooKeeper 的统一配置，并自研实现多级缓存容灾架构方案，从 ZooKeeper、内存和本地文件等进行多级缓存，同时支持数据变更时即时同步，以及系统宕机网络异常等情况下的数据自动容灾等策略。

以读为例，网关首先从内存中读取配置，如无数据，从 ZooKeeper 读取，读取后同步到内存，并异步保存本次快照。如果 ZooKeeper 数据变更，通过监听 ZooKeeper 的 DataChangeWatcher 变更同步数据。如果 ZooKeeper 宕机，重启服务器，系统还可以通过本地快照恢复最近一次的元数据配置。

TCP 全双工的长链接会话通道

API HTTP 网关通过接口提供服务调用获取请求数据的，而搭建客户端与服务平台的 TCP 网关的双向通道，以保持客户端与服务平台的会话状态，则可以在 HTTP 网关基础上提供更多、更灵活的技术实现和业务实现。

在业务服务调用上通过 HTTP 网关，在平台服务调用上则通过 TCP 网关，实现平台与业务解耦，并且平台采用 TCP 通道还可以增加对平台的控制力，在此背景下诞生了 TCP 网关。