流量测试软件

TDD is dead, again

以互联网服务为代表的后台软件开发有了巨大的变化。传统的软件开发的理论已经越来越无法适应新常态的需求了。比如以下几点...

以下通篇为无脑神论，没有半点事实支撑。

以互联网服务为代表的后台软件开发有了巨大的变化。传统的软件开发的理论已经越来越无法适应新常态的需求了。比如以下几点

系统的微服务拆分，大量地使用 RPC 组织业务逻辑。一个节点自身的逻辑越来越少，给一线工程师的自由度也越来越少
快速迭代。一天数次上线。严重依赖小流量和在线特性开关的形式来做质量的校验。
线下测试的成本越来越高，迭代速度快，线下搭环境都跟不上。

同时相配套的设施也在跟上

机器越来越便宜。性能优化对于普通的业务系统来说微不足道（除非你的业务是安全或者CDN这些）。
大量的代理被广泛使用，从nginx到haproxy，从mysql代理到codis
Dapper 的论文，导致各家都在实现在线的rpc日志，搜集与存储
影子表等技术使得在线压测成为可能

一个总体的形势是，线下的验证已经被在线验证全面压制了。各个大厂都在在线监控与质量验证方面投入巨大。线下测试通过了不说明任何问题，只有在线上跑过了，才算是久经考验的。在线上的基础设施可以保证

问题被及时发现，通过监控
问题被及时定位，通过日志
问题被及时控制，通过切流量

以前经常嘲笑的一个做法是“在线修改PHP文件”。但是现在越来越发现，在线改PHP文件是获得反馈地最有效的方式。因为线下没有真实的流量，没有真实的环境，没法低成本地复制一套出来。

但是目前的基础设施还有三个问题没有解决：

线下开发问题。因为开发还是在线下的，没有办法从线上引流，以及直接利用线上的环境。导致开发阶段很难去跑业务逻辑，本地验证新写的代码。从质量保证的角度来说，小流量和开关是足够的。从效率地角度和开发者幸福感方面，仅仅上线才可以验证自己的代码是远远不够的。
灰度和开关都是拿用户做小白鼠，是有损的。这就决定了，使用必须很谨慎，开得很慢。速度受到影响。
各种日志，服务发现，影子表等技术，都是需要侵入代码的。对于混合语言的公司来说，成本很高。而且每个公司的基础架构都在重复解决类似的问题。

所以我的判断是

将来软件开发会越来越往在线的方向发展。用在线的流量，在线的环境去验证新写的代码变得越来越方便。
proxy会越来越普遍。随着硬件的进步，跨进程通信的成本越来越低。各种基础架构问题会逐步地以代理地方式解决。

这些包裹在业务逻辑外面的proxy可以把以下问题给通用地解决掉

服务发现
高可用
流量调度
日志记录
监控埋点
流量捕捉
流量回放
测试流量读写影子表

业务逻辑里唯一需要做的事情是上下文传递。需要把当前流量性质和trace_id做一个上下文的透传。

基于这样的基础设施，可以实现在线的软件开发。直接在线上写代码，线上拿真实流量测试，拿线上环境看运行结果。从而实现低成本地敏捷开发。再也不用在每个语言，每个框架里搞mock，去做费劲地写单元测试了。重构变得很低成本，不用总是担心放线上去会挂。

对于基础架构部门可以避免重复投入。有一套通用的平台可以在上面跑任意语言，任意框架写的业务逻辑。

网络rpc和队列领域，需要一种类似docker的技术，让基础架构的服务被通用化地方式提供给业务。让所有的业务形态（无论语言，无论框架，无论rpc编解码方式，无论rpc传输协议）都可以享受到一致地基础设施。

以下列出，微信，微博，QQ群，论坛，等交流方式。

QQ群：领测老贺聊软件测试 22386432
微信公众号：领测软件测试网
新浪微博：领测软件测试
喜马拉雅订阅频道：http://www.ximalaya.com/2581641/album/6011135
蜻蜓FM订阅频道：http://www.qingting.fm/#/vchannels/198184

苹果广播：搜索“领测老贺”

荔枝FM：FM1663127 领测老贺聊软件测试

目前暂定每周不定期更新，您的关注，转发，打赏就是我们坚持的动力！