扩展 Twitter 以支撑新负载峰值

对于许多人而言，Twitter 已经变成一种不可或缺的通讯工具。个人和企业每天都在以一种更深广的方式使用Twitter，甚至所有人都对“其扩展性如何”感兴趣。本月初，Twitter 经历并无缝地处理了一次每秒143199 条tweet 的新负载峰值——与当前每秒5700 条tweet 的稳定状态相比，这一数值可谓是大幅飙升。Twitter 平台工程副总裁Raffi Krikorian报道了这项新纪录，并花时间回顾了已经进行的工程变更，它们扩展了Twitter，使其流量达到了这样一个新的水平。

三年前，围绕2010 世界杯的活动使Twitter 达到了每秒2000 条tweet 的峰值，导致了重大的稳定性问题，也使Twitter 工程团队意识到重构系统的必要性。后续工程检查发现，Twitter 拥有世界上最大的Ruby on Rails 部署，所有东西都在一个代码库中，应用程序和工程团队均是一个庞大而统一的整体。它的MySQL 存储系统已经达到上限，硬件资源却没有充分利用，而反复“优化”又致使代码库僵化。Krikorian 在报告中指出，通过此次检查，Twitter 确立了几大目标：机器数量减至十分之一；迁移到松耦合的面向服务的体系架构，该架构边界更清晰而且内聚性更高；可以通过更小的获得授权的团队更快地推出新功能。

Twitter 放弃了 Ruby，转而使用 JVM。它已经达到了 Ruby 进程级并发模型的上限，于是需要一种能够提供更高吞吐量而且能够更好地利用硬件资源的编程平台。通过在 JVM 上重写代码库，Twitter 获得了 10 倍的性能提升，现在每台主机每秒可以推送 10-20K 次请求。

Twitter 体系结构的最大变化是以 tweet、“时间线（timeline）”和用户服务等三个“核心名词”为重点，迁移到面向服务的体系结构。基于“契约式设计（design by contract）” 的开发方法，使各团队可以按照预先约定的接口定义独立地进行接口实现。服务具有自治和自包含的特点，这也在新的工程团队结构中得到了反映。异步 RPC 平台 Finagle 的创建，使所有的工程团队可以用一种标准的方式处理并发、故障恢复及负载均衡。

新体系结构在 Twitter 工程团队的构成中得到了反映。服务和团队都有自治且自包含的特点，而且每个团队都有自己的接口和问题域。因此，不需要任何人成为整个系统的专家，也不需要每个人都考虑 Twitter 的可扩展性。团队的关键能力是抽象出每个需要的人都可以使用的 API。

Krikorian 说，即使运用了淡化整体性的体系结构，持久化依然是一个巨大的瓶颈。因此，Twitter 已经利用 Gizzard 把单一的主 MySQL 数据库替换成一个具有容错性的 Sharded 数据库的分布式结构。

这里强调一个扩展大型系统的共同点，即可观测性和统计信息是管理系统和提供具体数据支持优化工作的关键工具。Twitter 的开发平台包含了这样的工具，使开发人员可以非常容易地提供请求跟踪和统计报告。

Twitter 扩展故事的最后一部分是在运行时环境配置和测试环境方面做了许多工作。在“Twitter 扩展”过程中，测试实际上只能在生产环境完成，部署新功能也需要团队间具有挑战性的协作水平。因此，Twitter 创建了 Decider 机制，在该机制下，新功能只有在部署完成后才能启用。在部署时，新功能可以设定为“关闭（off）”状态，然后或者以二进制方式（一次性）启用，或者按操作比例逐步启用。

总的来说，现在的 Twitter 比以前更具扩展性、更有弹性且更灵活，其流量正在打破新纪录，而且它可以在不受重大干扰的情况下推出新功能。在博文的末尾，Krikorian 鼓励读者继续关注 @twittereng ，以了解 Twitter 重构的更多细节。

查看英文原文： Scaling Twitter to New Peaks