互联网开放平台的高可用架构.docx

PAGE 1 互联网开放平台的高可用架构  京麦是京东商家的多端开放式工作平台，是京东十万商家唯一的店铺运营管理平台，为京东商家提供在移动和桌面端的操作业务，京麦本身是一个开放的端体系架构，由京东官方和 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 网关。 TCP 网关采用长连接通道，实现全双工会话。TCP 网关采用 Netty 作为 TCP 容器，在 ChannelPipe中加载自定义 ChannelHandler，构建 Container 容器，将每个 TCP Connection 封装到一个 Session 会话中，保存在 Container 容器中，由 Container 容器构建 Session 会话层提供逻辑层请求调用。 自研构建 Session 会话层是因为 HTTP 属于 OSI 的应用层，而 TCP 属于 OSI 的传输层，面向连接的编程极大的增加程序复杂度，所以将 Connection 封装在每一个 Session 会话里，再以微服务的方式提供服务调用，极大的精简了 TCP 编程。 断线重连 客户端与服务端通过 TCP 长连接进行通信，但在中国复杂的网络环境下，移动客户端可能由于网络抖动、弱网络情况下，遭遇非正常网络闪断，如何处理断开后的断线重连，保证客户端与服务端的通讯稳定