转转QA Apimock 系统演进

笑哼 for 转转QA · November 12, 2018 · Last by uida3647 replied at July 01, 2019 · 854 hits

作者|陈秋

Api 接口文档管理平台,是http接口管理平台,目的是作为接口的唯一数据源,解决前后端等多方接口对接时接口数据问题。本文主要介绍转转的api 和 mock功能的演进。希望对大家有所帮助,少踩一些坑。

一期功能

转转业务刚起步,接口比较少(百个以内),大家都在wiki上维护,搜索和维护比较费力,于是我们实现了第一版。
主要功能很简单就是列表页和详情页。旧数据从wiki上导出,格式化之后批量导入。具体格式如下:

随着接口增多,接口增加了很多附加信息:所在模块,所在类,负责人,最后修改人,引入版本。接口字段是否上线(上线后不允许编辑)等,都是在随后的迭代中增加。

二期功能

Api平台在初期基本解决接口一致性问题。随后而来的是,前后端开发和联调数据的问题。在开发前期,server端只能提供写死的数据。前端/app端调试,希望各种数据都能有,满足所有的场景。
解决方案:参考业内实现方案,实现了第一版的http接口mock。Mock路由根据请求来源ip来做,mockserver使用mockjs来做,生成数据多样性很强。

这里的主要问题是:
mockjs格式的数据编辑是有门槛的,对于app同学,需要重新熟悉。
对于数组格式的数据很不友好,编辑成本是不可接受的。

三期功能

Mock功能,针对编辑复杂的问题。将mockjs直接替换成json。结构图如下:

其中:
App http请求:app端将所有的请求发送到mock平台。命中mock的返回mock数据,反之则转发。(需要app端提供切换域名的功能)
ip接口匹配,根据请求来源ip,匹配之前配置好的ip和mock规则对应关系。找到对应mock规则
pc/host 针对pc端mock场景。通过pc端设置host的方式,将所有的请求发送到mock平台,平台上nginx做一次反向代理,将请求发到mock 服务上,反之则转发。
如下是手机端使用的例子:

总结:功能基本满足了app端数据mock的需求,配置好mock环境(mock路由)和mock规则(mock数据),使用很方便。

四期功能

但还存在一些问题,创建mock环境这步骤还是比较麻烦,需要拿手机的ip,电脑的ip 。Mock环境这个功能,主要是将请求来源ip和用户的mock规则绑定。这步录入ip是不是可以省略,我们通过手机或者pc向mock平台发送一次请求。将pc、手机的ip带给mock平台。是否就可以?

通过如上的方式,手机用户扫描当前用户的二维码,pc用户做一次请求。将来源ip和用户绑定,也就是ip和mock规则绑定。省去上面的mock环境设置功能。

正在进行的迭代

如上api和mock的功能解决了基本的前后端联调和数据的问题。随着业务线和接口增多,出现了一些新的问题。
1.server端修改了线下接口,但是app/fe同学使用的是mock数据,不了解修改。导致联调时花费多余时间。
2.server端修改了线上接口,导致引用方报错。
这里的一致性问题,以及对于线上接口修改问题,使用方,更新api到平台上是不及时的,有时是不同步的,根本不会更新api 平台上的代码。
对此,我们做了如下修改:
1.Beetle平台进行编译分支时,自动扫描分支的接口,发送给api平台。Api平台和已经上线的接口校验。修改了线上的接口参数则编译不通过。
2.Beetle平台在分支上线完成时。通知api平台将对应的分支接口设置为线上接口。
3.以上我们能实时拿到接口的变更,在收到变更的情况下,向该接口的mock用户,发送变更通知。
4.Api平台去掉接口参数和数据类型修改功能,关闭这些信息的修改入口。
以上,对于接口变更方到使用方形成一个闭环。不再人为干预。
注:前提,server的同学按照一定的注解规则,完成对外接口。
多说一句,api作为最重要的基础数据之一,是很多流程的开始。随着公司业务的壮大,人员和接口的大量增多,接口增加附加信息几乎是必须的。将其整合到devops流程中,最大可能减少人的沟通成本,降低出错的概率,是很有必要的。
以上是转转在接口和mock的上的一些经验,每一次迭代都是为了提高使用方的效率。大家有更好的想法可以留言,一起交流探讨。

共收到 1 条回复 时间 点赞

你好,最近我也在想实现一个mock的平台,不知道你这个平台是否已经开源了吗?

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up