Twilio的混沌工程实践
极客时间编辑部
讲述:杜力大小:1.05M时长:02:17
近日,Twilio 团队分享了他们的初次混沌工程实践,他们使用 Gremlin 往自家的队列系统中注入故障,测试系统的自动恢复能力。
Twilio 提供 SMS 和电话网关服务,开发者可以在他们的代码中调用 Twilio 的 API。Twilio 架构的核心部分是他们的分布式队列系统和速率限定系统。它提供了持久化的队列,解决了系统故障和消息处理的延迟问题,避免消息丢失。这个队列系统叫作 Ratequeue,由 Twilio 团队开发。
Ratequeue 对消息出队速率进行了限定,每个电话号码都有一个自己的临时队列。因为开发者有可能以很快的频率调用 API,所以速率限定是很有必要的,而 Twilio 将消息推送到电话网络的速度也需要加以控制。
Ratequeue 是基于 Redis 开发的,可以进行横向扩展。单个分片故障并不会影响到其他分片。另外,为了高可用,每个分片都有自己的主节点和副本。
以前,如果有分片发生故障,需要由人工手动将副本提升为主节点。这就要求先定位到拥有相同分片数量的主机,然后把它加到负载均衡器中。为了对这一过程进行自动化,Twilio 团队开发了两个系统,一个自动化的失效备援系统,一个用于测试前者的故障注入系统。故障注入系统属于混沌工程,通过制造随机的故障来测试系统的自我恢复能力。
测试的首要目的是保证零数据丢失,其次要保证能够自动检测出故障,并推举出新的主节点。Twilio 团队基于亚马逊 Kinesis、Nagios 和 Lazarus 开发了自己的解决方案,也就是他们的集群自动化服务。每个 Ratequeue 副本将主节点的心跳情况发送给 Nagios,如果达到某个阈值,Nagios 就向 Kinesis 推送通知。Lazarus 监听 Kinesis,检查集群的健康状况,如果出现故障,就进行恢复。
为了测试自动故障恢复能力,Twilio 团队开发了一个叫作 Ratequeue Chaos 的工具,它会选择一个分片,停掉它的主节点,然后监控其自我恢复过程。还有一个叫作 Gremlin 的服务,用于将故障注入到系统中,触发失效备援。Gremlin 支持可控的故障注入,Ratequeue Chaos 通过 Gremlin 提供的 API 来调用它。据介绍,Twilio 的 staging 环境每 4 个小时就会重复一次这个过程。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论