扩展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