2012 年,在开放云融推动各产业全面发展的大背景下,苏宁 API 对外开放。基于苏宁各内部业务系统的资源,开放丰富的 API 服务,提供给苏宁商家、供应商、售后服务商、物流公司、软件服务商等合作伙伴所需的数据和信息。实现外部系统与苏宁的完美对接,使业务的处理更加高效、便捷。 通过阅读该文章你会了解到如下信息:
到现在为止,苏宁已开放了平台业务、自营业务、自采业务、O2O 业务、政企业务、特卖业务、4PS 业务等几百个 API 接口,每天承载海量的 API 接口调用。 俗话说“无标准不平台”,苏宁 API 设计之初,没认识到标准的重要性,遇到过很多问题,走过很多弯路,接下来细说下苏宁 API 的标准化设计的过程。 谈起 API 接口,首先会想到接口名(接口英文名)。 先来看一组接口名: suning.order.getsuning.selfmarket.order1.querysuning.custom.book.item.querysuning.retuenBadArticleHandleResults.addsuning.shoppingmallsalesdata.saveandupdate 以上接口名有如下问题:
而一个标准的接口名应该有如下特征:
举例:suning.custom.order.get 格式:suning. 业务分类. 模块简称. 操作符 用户通过阅读 API 文档来使用 API 接口。一个规范的 API 文档有助于用户理解 API 的用途,掌握 API 的使用。 苏宁 API 主要是基于 Http(s)+OAuth2.0 协议实现的。可以使用 xml 或者 json 格式进行报文传输。并提供主流 (Java、.Net、PHP、Python) 四种语言 SDK 方便用户使用。 API 接口为一个全局统一的入口: https://open.suning.com/api/http/sopRequest 这里服务契约是指苏宁 API 系统与苏宁内部系统之间的服务契约。苏宁 API 承接着苏宁内部多方系统。如果不固定服务契约,苏宁 API 就无法做到标准化,这是一个 API 标准化的一个前提。 有了服务契约的固定,才能实现动态发布 API,缩短 API 的研发周期。 即调用 API 接口异常场景下返回的错误码。苏宁的 API 接口返回异常码的同时也会返回中文详细描述,以增强异常码的可读性。异常码通常表示某种异常场景,具有唯一指向性。 异常码常见的问题包括:无统一风格、无分类、无唯一性、难以理解等。基于以上问题,苏宁的 API 网关在异常码方面进行一些标准化设计,使异常码变得有如下特征。
在以上标准化的基础上,为了缩短 API 接口上线周期,我们实现了 API 接口配置化,能支持自动发布 API 接口、动态修改配置项。具体界面如下图:
当 API 接口发布上线后,会自动生成(Java、.Net、PHP、Python)四种语言的 SDK,并执行自动化测试,测试通过后上传官网,供外部用户使用。 随着 API 接口数量越来越多,一些问题逐渐暴露出来,下面详细介绍几个关键问题的重构详解。 系统上线之初,选用 IBM 的 IHS 和 Websphere、DB2 来部署 API 系统,系统架构如下: 这套架构的 优点 是简单,整个 API 运行在 Servlet 容器中,API 全局入口是一个 Spring MVC 的 Controller。缺点 是 API 系统不是通过服务调用业务系统,而是自己要连接业务数据库,并处理业务逻辑。一个 API 接口对应一个 API Service,实现了简单的流控、校验、权限认证、本地配置功能。随着时间变迁,API 接口数量越来越多,API 接口开发周期变长、响应时间逐渐变慢了。 为了解决 API 接口响应时间慢的问题,对系统进行如下重构: 此时 API 系统架构变成 Nginx+Wildfly(JBoss),整个 API 运行在 Servlet 容器中,API 全局入口是一个 Servlet;同时新增了流控、监控、调用器组件;API 业务逻辑处理修改为通过 Hessian 方式调用业务系统;监控组件同步发送日志到 kafka,Elasticsearch 从 kafka 消费日志,建立索引。 经过上面系统重构后,系统运行一段时间,发现接口响应返回越来越慢,很多无效调用和攻击影响正常的请求,同时核心链路并发支持低,也是影响接口响应慢的原因。 为了解决无效调用、安全攻击、核心并发支持低导致 API 接口响应时间慢的问题,对系统进行如下重构: 此次系统重构主要是 强化接入层的功能,在接入层实现了防攻击、基础校验、日志、降级、流控等功能,同时将核心服务权限认证进行平台化,增加核心链路的并发度和增强系统扩展性,将监控组件异步化。 运行一段时间后,又出现了一个现象,运行快的 API 接口会被运行慢的接口影响,也变得运行慢。 为了解决接口之间互相影响的问题,对系统进行如下重构: 在接入层进行接口分流,不同的接口请求到不同的后端服务,这样接口进行应用层的资源隔离;并对应用层进行重构,重写核心组件;整个应用层基于 Netty 提供 API 服务;IO 线程负责连接的接收与建立;Work 线程负责 IO 的读写;同时支持多组 work 线程池,用来隔离不同接口和业务直接的互相影响;服务调用组件修改为苏宁自研分布式服务框架 (RSF),使用异步回调方式,提高系统的吞吐量,核心权限认证服务,也修改 RSF 调用方式,提高服务的性能,新增 Zookeeper 来提供配置管理,来实现分流的动态配置修改。 在系统重构过程中,除了提高系统的性能,系统的高可用设计也尤其重要。下面将详细介绍苏宁 API 的高可用设计包括哪些内容。 一次 API 接口请求链路如下,每个链接职责分离。
API 系统流量管控,主要分为接入层和应用层流控。接入层主要是基于 Nginx+Lua 来实现的,应用层基于计数器和信号量等实现。具体信息如下: 接口分流基于 Nginx+Lua 实现,预先对每一个 API 接口进行逻辑执行区域的分类,不同的分类对应不同的后端服务,通过 Zookeeper 动态管理配置项,一个接口请求会找到对应 upstream Server。 接口降级同样基于 Nginx+Lua 实现,Nginx 共享内存中存放接口的降级信息,通过 Zookeeper 动态管理配置项,如果接口被降级就会直接返回异常码,否则接口就会执行接口分流逻辑,请求会找到对应 upstream Server。 同时服务降级也支持多个层级,具体如下图: 当 API 接口数量和调用量达到一定程度后,面临了如下问题:
第一版日志明细实现系统设计如下图: 上线后,由于 Flume 采集任务和 Hadoop 任务导致日志明细不能实时查看,整个日志延迟 20 分钟。基于上述原因对系统进行重构,结果如下: 去掉 Flume 采集任务和 Hadoop,直接采用 Elasticsearch 消费 kafka 数据,实时建索引。 日志源和 kafka、Elasticsearch 都具备扩展性,满足性能要求。 依赖于苏宁数据大数据平台来完成接口的统计。
Libra 实时计算平台 是苏宁在 Storm 的基础上二次开发封装的,通过编写 EPL 计算语句(EPL 是 esper 中一种类似 SQL 的语言), 转换为一个个计算规则,提供实时计算功能的平台,主要特点为配置简单能够实时计算需求的快速上线、支持分布式计算、支持动态扩容,以满足大数据量的计算需求。 在没有监控之前,存在如下问题:
而有了监控之后:
苏宁有如下告警平台和告警机制,能够准确地通知开发及运维人员系统的异常状况,有助于快速定位问题和解决问题。
以上都是苏宁系统提供的通用告警机制,接下来介绍苏宁 API 系统实现的告警机制:
从 2012 年开始,每年双十一苏宁都带给消费者一次次购物享受之旅。今年苏宁易购双十一的主题是“不止所见嗨购 11 天”,换句话说,这场狂欢盛宴将始于购物,但不止于购物,为消费者提供其他电商没法实现的“任性”。 O2O 购物节是一次狂欢盛宴,对每一个苏宁人来说是一场必胜的战役,为了保证 O2O 购物节系统正常,需提前做好系统保障工作,正所谓不打无准备的战役。 O2O 购物节中苏宁 API 网关提供哪些应用场景辅助商家、供应商、服务商进行商品交易?下面列举了主要的应用场景:
何翔,2010 年加入苏宁,主要从事 JAVA 领域开发与设计工作,现担任苏宁云商 IT 总部多终端开发技术负责人,全面负责苏宁 API 网关管理与设计工作。从零开始搭建苏宁 API 网关,通过一次次系统重构与性能优化,经历了多次 818 促销和双十一 O2O 购物节的考验,支撑了亿级流量调用,保证系统稳定高性能。在 NIO、性能优化、高可用、扩展性、高稳定性等方面有一定的思考和领悟,目标是用技术打造一个高性能高可用的服务平台。 人工智能已不再停留在大家的想象之中,各路大牛也都纷纷抓住这波风口,投入 AI 创业大潮。那么,2017 年,到底都有哪些 AI 落地案例呢?机器学习、深度学习、NLP、图像识别等技术又该如何用来解决业务问题? |
|