第1页
前后端分离中 API 接口与数据 Mock 的思考与应用
吕伟
第2页
2016-
第3页
关于我
• 现任职于美团大众基础终端组 • 在美团大众负责过考试系统的开发 • 曾负责百度音乐 FM,主站 webapp 的开发 • 在 Node 工程工具和自动化方面有较丰富的经验
第4页
模版时代
模版传递数据
项目高度耦合 项目间数据复用度低
联调的进化
前后端分离时代 串行开发时代 单项目并行开发时代
前端必须等待 API 开发完成后才能开发
开发者闲置率高
多项目间假数据复用率低 无法统一控制流程
多项目持续 并行开发时代
第5页
前后端并行开发时代的声音
• 约定好的 API 又变了,半个月 之后我才知道这件事
• 这么多 mock 方案我选哪个?
• 公司这个服务的 API 上哪查文 档?
• 文档写起来好费时
• 写文档就够烦了,测试就免了 吧
第6页
联调面临的现状
• 大量项目选择前后端完全分离 • microservices 大势所向 • 广义上后端通常也是作为其他服务的前端
第7页
广义的前端
网页端
SSO 服务
业务服务
iOS 端
存储服务
这里只有“存储服务”不作为广义前端
第8页
广义的前端都可能需要 mock
网页端 iOS 端
业务服务
SSO 服务
存储服务
1,2,3,4,5 在开发初期都可能需要 mock
第9页
这是个充满轮子的世界
网页端
mock.js
Nocilla
iOS 端
手写轮子
业务服务
手写轮子
SSO 服务
使用测试服务
存储服务
网页端、iOS 端几乎无法复用 API 假数据
第10页
轮子真的非常之多
比如 Github 上的 mock 相关仓库就有 1.3w 个之多
第11页
我不想造轮子,能不能用三方的方案?
免 费
开 源
语言中 流程 自动单 立 控制 元测试
沙盒化
文档生 文档 成 共享
多协议 侵入用 支持 户代码
mock.js o o x x x
o
xx0
o
第12页
总结现有轮子的常见问题
1. 各工具设计语言不中立,难以共享定义 2. 大多难以做到沙盒化 3. 难以确保 API 的可用性
第13页
如何解决这些问题
第14页
1.定义一次 API 而可以处处复用
第15页
API 定义中心化
生成 API 文档
流程约束
API 定义
API mock
API 单元测试
只需要定义一次 API 即可自动完成 API 文档生 成, mock 假数据,单元测试 API,以及流程约
束
第16页
2. 沙盒化
第17页
沙盒常常意味着 CS 架构
• 类似于 github 和 git 的关系 • 在封闭环境里也能持续测试 • 平台仅用于共享,开发时可以脱离平台
第18页
开发去中心化(沙盒化)
被开发程序
发布 API
联调客户端
安装 API
API 平台
开发测试环境
外部环境
第19页
一般 mock 开发模式示意
浏览器
假数劫持
代理流量 代码注入
业务接口服务
第20页
mock 接入
API 平台
浏览器
劫持 API
联调客户端
请求并缓存 API 定义到本地
剩余请求
业务接口服务
类似MIMT,客户端的接入完全透明,且语言中立
第21页
如何确保 API 的可用性
第22页
一般 RD 的 API 开发流程
单测工具
发送 mock 请求 检测返回是否正确
开发用服务
8080 端口
需要费时间自己写测试,甚至费时去调试测试代码本身
第23页
API 测试接入
API 平台
获取并缓存 API 定义到本地
联调客户端
发送 mock 请求 检测返回是否正确
开发用服务
开发服务依赖的其它 API
第24页
将 API 测试加入到 CI 过程
• 通过把 API 测试过程加入到 CI 流程,保证 去掉 mock 后前端能无缝对接上后端
第25页
流程控制
• API 变更的递归通知 • 项目成员间的 Approve 和 Reject 机制
第26页
API 依赖树锁定
服务 A API 发生变化
服务 B
服务 C
服务 C
服务 D
递归的检测 API 变化所带来的影响
第27页
提升项目间协作效率
• 共享 API 的定义 • 通过定义我们可以轻松生成文档 • 持续优化 API 相关的垂直搜索
第28页
应用场景
第30页
Vane 联调平台
第31页
举一个简单开发场景示例
第32页
一些常被问的问题
第33页
道理我都懂 那 API 如何定义呢?
adoc (api documentation)
markdown 超集
渲染成文档
第34页
RPC Thrift
利用 code block 的语言声明语法 如 RPC 几乎可以根据实际情况随意扩展
第35页
有状态的 API 请求如何 mock ?
• 每个 API 是有多个 case 定义的 • 可以选中任一的 case 组成一个 scenario
第36页
我们并没有止步于此
• API 线上监测 • 服务调用将逐步 RPC 化 • 从 API 调用的源头入手,我们将从 RPC 库
开始尝试
第37页
通讯核心 nisper
• 一个非图灵完备的 lisp-0 语言 • 较 RPC 更为抽象灵活的一种思路 • 基于权限的语言,初始不含任何功能 • 项目地址:
第38页
问答
第39页
谢谢