压测工具从单机到Master/Worker/Counter分布式架构：由真实用户反馈驱动的迭代

这套压测工具的第一期实现只花了大约一周的业余时间，采用的是单机版本，先解决了”压测接入耗时2~3天”这个最痛的问题，让接入时间大幅缩短。但项目上线、各事业部同学开始真实使用之后，陆续暴露出三个第一期没有覆盖到的问题：一是单机压测本身”马力不足”，打压力度有时候不够，无法模拟真正大规模的并发流量；二是接入Thrift服务时，用户还需要自己提供Thrift生成的客户端代码，操作依然繁琐，大家希望只上传一个Thrift文件就能自动打压；三是用户希望能看到被压测目标机器自身的资源使用情况（CPU、内存），而不只是响应时间这类应用层指标。团队针对这三个问题逐一做了架构升级：为解决打压力度问题，把系统从单机扩展成分布式架构，拆出Master（负责任务分发）、Worker（负责实际发起打压）、Counter（负责汇总打压结果写入InfluxDB）三种角色，靠增加Worker数量来提升整体打压能力；为解决Thrift接入繁琐的问题，在原有简单模型基础上做更高层的封装，用户只需上传Thrift文件，系统自动把它编译成模板代码并生成对应接口；为解决机器资源可见性问题，在压测目标机器上部署agent，持续采集并上报机器层面的性能指标。这个演进路径提示了一条务实的产品/工具开发原则：第一期不需要、也不可能一次性预判所有可能的痛点，先用最小的投入解决当下最痛的那个问题（接入耗时），尽快让真实用户开始使用，再根据这批真实反馈精确定位下一轮该往哪个方向投入（打压力度/接入便利性/可观测性），比闭门造车预先设计一个”大而全”的第一版更高效。