我为什么做了 ApiChain——一个10年老程序员的造轮子心路

凌晨三点手机响了。我盯着屏幕上那条报错短信愣了两秒脑子还没完全清醒——“订单服务告警核心接口超时率突破阈值”。这是上个月第三次上线这次只是改了一个用户头像上传的接口。用户模块和订单模块八竿子打不着的东西怎么就挂了一块爬起来、开机、连VPN打开监控一看用户服务CPU飙到98%然后像多米诺骨牌一样把下游的订单、支付、库存全带崩了。一查代码好家伙同事上周重构了用户服务的数据层用了一个新的缓存策略结果缓存穿透把数据库打死了。他测了吗测了。用户模块全绿。那订单呢没人想到要测。我坐在电脑前突然觉得特别疲惫。不是身体上的是心里的那种。我是方海亮在上海做了10年程序员。这10年我待过创业公司也待过大厂见证过无数次上线翻车自己也被坑过无数次。说出来不怕你们笑话刚入行那会儿我还觉得写代码是最难的事。后来才发现代码写得再好也扛不住屎山一样的历史包袱测试再全面也覆盖不了所有人祸。我经历过最离谱的一次事故是改了一个统计报表的接口结果把短信服务搞挂了。为啥因为那个报表服务引用了一个公共的日期工具类工具类里有个单例模式的缓存组件内存泄漏了。连续跑7天内存爆掉触发OOM进程重启然后所有依赖这个进程的服务全部超时。这种事你能用单元测试覆盖吗你能用接口测试覆盖吗覆盖不了。你都不知道这两个东西有关系。这些年我总结出一个规律线上事故十次有八次不是代码本身的问题而是变更管理的问题。你改A可能B挂了你测了B但C依赖B的方式变了。这种事太多了。做接口测试这些年我用过不少工具。最早是Postman简单粗暴点两下就能发请求。用了两年后来发现一个问题这玩意儿本质就是个高级版的curl根本没法管理测试用例。你测完一轮想复用行自己建文件夹自己命名自己记得住规则。下次迭代来了你敢保证还记得上次怎么测的Swagger更别提了那玩意儿是给前端看文档用的不是给测试用的。你能在Swagger上跑自动化用例吗能导出回归测试集吗基本做梦。后来用过一阵子Apifox界面确实好看功能也全项目管理那套玩得很溜。但用久了总觉得哪里不对——它还是在用项目的思维在管接口而真实的开发工作流是围绕迭代走的。什么意思你一个迭代里改了什么接口这些接口需要测哪些用例上线之后这些用例能不能直接变成回归测试的一部分Apifox能帮你管文档、管Mock、管接口定义但它不解决一个根本问题当你改了一个迭代的代码你怎么确保这个迭代改的东西没有破坏已有的功能没人能确保。至少现有工具给不了这个保证。那天凌晨三点之后我开始认真思考一个问题为什么我们有这么多接口测试工具却没有一款真正为迭代回归而生的工具我回顾了一下自己的日常工作发现一个很讽刺的事实我们团队有几十个微服务每次迭代改动的可能就两三个服务但回归测试的时候要全量跑一遍。测三天还测不完。测不完怎么办挑着测。挑着测怎么挑靠经验、靠感觉、靠运气。然后上线了翻车了。这不是团队的问题是工具链缺失的问题。我当时就有一个念头如果有一个工具能够做到迭代级用例管理——每次迭代的改动用例单独维护上线后一键导出做项目级回归——那能省多少事儿说干就干。2023年年中我开始用业余时间写ApiChain。说是业余时间其实大家都知道程序员哪有什么业余时间。晚上孩子睡了之后、周末偷个懒的时候拿出来写两行代码。就这样一点一点攒大概半年时间出了一个能跑起来的版本。第一个版本其实很丑界面简陋得很后端服务也是怎么简单怎么来连Docker部署都没考虑。我记得第一次部署到服务器上连端口都配错了折腾了一晚上。但核心逻辑是对的。我把迭代作为一级概念而不是项目。什么意思呢你进来先看到的是迭代列表而不是项目列表。每个迭代里你可以维护这个迭代改动的接口和用例。迭代上线之后一键把这些用例合并到项目级别作为回归测试的基础。这个设计看起来简单但做的时候踩了不少坑。最大的坑是数据归并。迭代内的用例是独立的有自己的环境变量、自己的一些测试数据。上线之后要合并到项目里这些东西怎么统一最后我设计了一套规则迭代内的公共配置可以覆盖项目的项目级别的统一环境变量会被继承。这样既保证了迭代的独立性又维护了项目的整体性。还有数据库断言这个问题。传统的接口测试只能验证接口返回但你有时候需要直接查数据库来验证状态。我加了一个功能可以直连测试数据库执行SQL然后和接口返回值做交叉比对。这个功能当时写的时候遇到了连接池的问题还有关闭连接时脏数据清理的问题折腾了得有半个月。最让我头疼的是随机数据。接口测试最怕什么怕数据被污染。你第一次跑通过第二次跑就失败了因为数据被改掉了。所以我加了随机函数的支持、randomInt、$randomEmail等等。每次跑用例自动生成随机数据用完自动清理。这个功能看着简单背后的逻辑其实挺复杂的要追踪每次生成的数据ID确保清理的时候能找得到。还有一次我花了整整一周重构了执行引擎因为原来的设计跑并发用例的时候会有竞争条件数据清理的顺序不对导致测试结果不稳定。那段时间头发都快薅秃了。现在的ApiChain大概是第三代了。界面重写了两遍架构也从最初的单体方案演进到了现在的Electron客户端Runner服务分离的架构。Runner用Docker部署MySQL 8.x做存储一键启动对新手友好了一点。功能上主要有几个我觉得真正解决痛点的点一个是迭代文档自动归并。迭代内独立维护用例上线关闭后一键按微服务合并到项目。这解决了我们团队最大的一个问题——以前迭代文档和项目文档是割裂的现在统一了。一个是数据库深度断言。接口测试不只是测返回值还要测数据库状态。这个在支付、订单这类核心链路里特别有用。还有精准拦截回归风险。这是我自己最满意的一个设计——你改了什么就测什么不用全量回归。迭代用例导出到项目执行项目级回归测试只覆盖你改动过的服务相关的用例。环境变量我设计成了四级体系全局、项目、迭代、单测。这个也是被坑出来的经验——以前环境配置混乱得一塌糊涂经常测着测着发现用的不是正确的配置。最近还加了基于大模型的RAG智能检索功能。你可以让AI帮你回答关于接口的问题比如这个接口的鉴权逻辑是什么、哪些接口依赖了这个基础服务之类的。这功能还比较初级但方向是对的。ApiChain是开源的在Gitee上https://gitee.com/onlinetool/apichain说实话开源出来没指望靠这个赚钱。我自己用过知道这东西的价值但也知道它不够完美。用户界面还可以做得更好看文档还可以写得再详细点现在还缺少多语言支持……但它能解决真实的问题。我做这个工具的初衷很简单不想再看到凌晨三点的告警短信不想再经历那种明明只改了一行代码怎么线上全挂了的绝望。如果这个工具能让一个团队少发生一次上线事故那我就觉得值了。有时候朋友问我你都35了还自己写工具不累吗累是真累。但你让我回去用那些工具我是真不愿意。有些痛只有踩过的人才知道。ApiChain解决的不是什么高深的技术难题它解决的是一个很土的问题当你改了一个迭代的代码你怎么确保你没有破坏已有的东西这个问题困扰了我很多年。现在我自己写了一个答案。如果你是做后端开发的如果你也在被迭代回归折磨欢迎试试ApiChain。不敢说多好但至少它是按照真实的工作流设计的。用过有问题的地方或者有什么想法欢迎来提Issue。我不一定能第一时间回复但每一条都会认真看。就这样吧写得有点长了。能看完的都是同行。祝大家少点上线事故多点正常睡眠。