WebAPI 开放平台架构实践

导读

• 背景
• 需求
• 场景
• 架构设计
• 总结

背景

       随着业务的发展,越来越多不同系统之间需要数据往来,我们和外部系统之间产生了数据接口的对接。当然,有我们提供给外部系统(工具)的,也有我们调用第三方的。而这里重点讲一下我们对外的接口。

       我们运营和维护着诸多的对外接口,很多现有的接口服务寄宿在各个不同的项目,哪些应用在使用api也没有管理起来。并且以前的调用模式也是比较复杂,排错困难。

       目前已经对外提供服务的有短信平台,审核中心,ETCP,官网系列(充值,登陆,注册),服务中心,AuterCenter,HomeAPI(即将上线)。同时内部还有工单系统,安全中心,基础服务,GEMC等。其他的还有一些内部工具服务。

       从目前的需求上看,我们对外提供接口的需求很大。当然,能够持续对外提供服务是好事。但是,对接标准不统一,服务寄宿不合理, 无文档,无测试报告,无demo,无接口变更记录都将导致api的可持续和可维护变得越来越难。

       我们将更多的考虑对外服务的安全性,高可靠性,可维护性,尤其是离产品和用户最近的那些API。 同时,尽量做到所有api及其调用关系都有数据可查。因此,对于新接入的API,提供专业、规范的设计标准和文档规范势在必行。

       让所有支撑服务化,所有服务标准化。

       OPenAPI将作为支撑的中间件,与其他系统服务一起为运维、安全、产品和运营的各种需求提供强有力支撑。

需求

• 对服务提供方(如官网服务)及其API进行管理
• 对接入的应用进行管理
  • 用户先申请appkey,appsecrect
  • 下载sdk
  • 通过appkey,appsecrect生成token
  • _aop_timestamp 请求时间戳
  • _aop_signature 请求签名
  • access_token 用户授权令
  • 调用API
• API规范
  • 命名规范 入参,返回值 参考: https://developer.github.com/v3/ http://cizixs.com/2016/12/12/restful-api-design-guide
  • API文档规范
• 日志记录
  • API调用记录
  • API调用异常记录
  • ...
• 安全
  • 参数加密
  • IP白名单限制
  • 接口限制
• 性能
  • 客户端缓存
  • 服务端缓存
  • 限流,对于高频访问进行限制,如每个appkley1min调用次数

使用场景

架构设计

• 基础架构
• UML设计
• 认证机制
  • 验证(Authentication)是为了确定用户是其申明的身份,比如提供账户的密码。不然的话,任何人伪造成其他身份(比如其他用户或者管理员)是非常危险的
• 主要原理:
  • 做一个认证服务，提供一个认证的webapi，用户先访问它获取对应的token
  • 用户拿着相应的token以及请求的参数和服务器端提供的签名算法计算出签名后再去访问指定的api
  • 服务器端每次接收到请求就获取对应用户的token和请求参数,服务器端再次计算签名和客户端签名做对比,如果验证通过则正常访问相应的api,验证失败则返回具体的失败信息

• 核心实现

  • 1.用户请求认证服务GetToken,将TOKEN保存在服务器端缓存中,并返回对应的TOKEN到客户端(该请求不需要进行签名认证）
  • 2.客户端调用服务器端API,需要对请求进行签名认证,签名方式如下
  • get请求:按照请求参数名称将所有请求参数按照字母先后顺序排序得到:keyvaluekeyvalue...keyvalue,字符串如:将arong=1,mrong=2,crong=3,排序为:arong=1,crong=3,mrong=2,然后将参数名和参数值进行拼接得到参数字符串：arong1crong3mrong2。post请求:将请求的参数对象序列化为json格式字符串
  • 在请求头中添加timespan(时间戳),nonce(随机数),appkey,appsecrect,signature(签名参数)
  • 计算本次请求的签名,用timespan+nonc+appkey+appsecrect+token+data(请求参数字符串)得到signStr签名字符串,然后再进行排序和MD5加密得到最终的signature签名字符串,添加到请求头中
  • webapi接收到相应的请求,取出请求头中的timespan,nonc,appkey,appsecrect,signature数据,根据timespan判断此次请求是否失效,根据appkey+appsecrect取出相应token判断token是否失效，根据请求类型取出对应的请求参数,然后服务器端按照同样的规则重新计算请求签名,判断和请求头中的signature数据是否相同,如果相同的话则是合法请求,正常返回数据,如果不相同的话,该请求可能被恶意篡改,禁止访问相应的数据,返回相应的错误信息,参与签名的TOKEN,整个过程中TOKEN是不参与通信的,所以只要保证TOKEN不泄露,请求就不会被伪造。然后我们通过timestamp时间戳用来验证请求是否过期,这样就算被人拿走完整的请求链接也是无效的。
  • Sign签名的方式能够在一定程度上防止信息被篡改和伪造,保障通信的安全。

• 授权

  (Authorization)是为了保证用户有对请求资源特定操作的权限。比如用户的私人信息只能自己能访问,其他人无法看到;有些特殊的操作只能管理员可以操作,其他用户有只读的权限等等

  • 1.IP白名单限制,平台服务只能接受指定IP来源的app发起的请求
  • 2.api限制,指定app只能访问授权访问的api

• Token缓存

  所以客户端在调用API之前都会访问GetToken方法,所以建议在服务端和客户端都增加缓存。

  • 服务端视角

  • 客户端视角

• 限流

  如果对访问的次数不加控制,很能会造成API被滥用,甚至被 DDos 攻击。 根据使用者不同的身份对其进行限流,可以防止这些情况,减少服务器的压力。 比如可以设置，用户每个小时允许发送请求的最大值

• 压测

  • 1.自己写程序,开启多线程发起模拟请求
  • 2.压测工具，如loadrunner

总结

熟悉阿里的童鞋应该知道,阿里有个"大中台,小前台"的思想。俗称"中台战略"。马玉希望让前台的一线业务更加敏捷,可以更快速适应瞬息万变的市场,而中台则能够整合整个企业的数据能力和产品技术能力,对各个前台业务员形成强有力的支撑。

参考

• REST APIv3
• 跟着Github学习Restful HTTP API 设计
• 《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》

微信公众号：码农商业参谋