OpenApi开放平台架构实践

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架构转型之道-阿里巴巴中台战略思想与架构实战》

---

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