/**
* 献给我最尊敬的偶像Martin Fowler
* 原文出处:https://martinfowler.com/bliki/SyntheticMonitoring.html
* @author dogstar.huang <chanzonghuang@gmail.com> 2017-03-26
*/
本翻译已征得Martin Fowler同意,并链接在博客原文下方。
合成监控(也称为语义监控 [1])会定期对线上生产系统执行应用程序中自动化测试的一个子集。其结果会推送到监控服务,如果失败则触发警告。这项技术结合了自动化测试和监控以便能检测生产环境中失败的业务需求。
在小型独立服务和频繁部署的时代,很难用与后面会出现在生产环境上完全相同的版本组合来测试预生产环境。缓解这个问题的一个途径是将可测试性从预生产环境扩展到生产环境 -- 即生产环境上的QA背后的想法。这样做,可把思维模式从关注平均故障时长(MTBF)切换到关注平均修复时间(MTTR)。
对于大部分F的类型,平均修复时间 > 平均故障时长。 -- John Allspaw
这样的一项技术则是合成监控,我们曾经使用在了一个客户的身上,它是一个遍布数十个国家有着数百万分类信息的汽车数字市场。他们在生产环境上有近百个服务,每个服务在一天内部署多次。在服务部署到生产环境前,测试会在一个持续交付的管道里运行。对于集成测试的依赖并没有使用模拟测试,而是直接运行使用了生产环境中的组件。
这些测试中有一个例子,非常适合于合成监控。它模拟一个用户把一个分类添加到她的收藏列表。她要执行的步骤如下:
-
去到首页,登录后如果有收藏则全部删除。这时收藏的个数为0。
-
选择一些过滤标准并执行搜索。
-
通过点击旁边的星星,把结果中的两个条目添加到收藏里。星星从灰色变成黄色。
-
去到首页。这时收藏的个数应该是2个。
为了从分析中执行测试请求,我们在URL里添加了一个参数(例如excluderequests=true
)。这个参数会被处理并传递到全部下游的服务,当它设置为true时,下游的每个服务将抑制分析和第三方脚本。
在后端数据储存中,我们可以使用excluderequests
参数来标识这些数据是合成的。在我们这个案例中则无所谓,因为我们重用了相同的用户账号,并在测试开始时清空了它的状态。缺点是我们不能并行地执行这个测试。或者,我们可以为每次测试运行创建一个新用户账号。为了让这些测试用户能轻易识别,这些账号应该在邮箱地址中带有一个特定的前缀或后缀。另外一个方案可以是在每次请求中发送一个自定义的HTTP头部以便识别它是一个测试,虽然这种做法对于API来说更为常见。
每5分钟我们就使用Selenium webdriver和PhantomJS对生产环境的服务运行测试。这些测试的结果会被输入到监控系统,然后显示在团队的仪表盘上。根据测试失败的重要性,失败也可以触发on-call监控警告。
在测试金字塔顶部的Broad Stack Tests非常适合用于合成监控。这里有UI测试、用户旅途测试、针对网页应用的用户验收测试或点对点测试;或者针对API的消费者驱动契约测试(CDCs)。运行一个UI测试套件的一个变种 -- 例如在批量处理作业的上下文 -- 可以是把一个合成事务提供给系统然后对其期望的最终状态进行断言,如数据库条目、队列消息或目录文件。
扩展阅读
- Building Microservices: Designing Fine-Grained Systems -- Sam Newman (译者注:中文版请见《微服务设计》)
- 微服务架构的测试策略 -- Toby Clemson
致谢
感谢Henry Lawson的反馈。
特别感谢Martin Fowler的支持、建议和帮助我们完善这篇Bliki的宝贵时间。
注解
1: Ryan Murray铸造了“语义监控”(Semantic monitoring)这个术语并发表于2012年的ThoughtWorks Technology Radar。然而“合成监控”看起来是使用更为广泛的术语,并且通常构建在合成事务这个概念之上。
------------------------
本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议进行许可。
- 本文翻译作者为:dogstar,发表于艾翻译(itran.cc);欢迎转载,但请注明出处,谢谢!