Twitter 的支撑架构：扩展网络与存储并提供服务

Twitter 工程团队近期提供了 Twitter 核心技术的演进和扩展的详细资料，这些核心技术支撑了 Twitter 自营数据中心的系统架构，用于提供社会媒体服务。他们分享的关键经验包括：超越原始规格和需求进行系统架构，并在流量趋向设计容量上限时迅速做出大刀阔斧的改进；不存在所谓的“临时更改或变通方案”，因为变通方案会成为技术债务；聚焦于为任务提供适合的工具，但这意味合理领会所有可能的用例；对内部的和社区最佳实践的文档工作已成为一种“力量倍增器”。

根据近期 Twitter 工程博客上的一篇博文，Twitter 作为社会网络和在线新闻服务创建于 2006 年，在那个时期，“统治数据中心”的是企业级实体厂商所提供的硬件。在 Twitter 运行的头十年中，快速增长的用户群已对硬件层提出了很多工程上的挑战。虽然 Twitter 在公共云上“运行良好”，但是他们已经开始重点投资自身的私营架构。至2010 年，Twitter 已从第三方的主机托管服务迁移到自身私营的数据中心架构，该数据中心架构在随后六年中“持续地设计和更新……有效地利用了技术和硬件的最新开放标准”。

至2010 底，Twitter 最终完成了首个内部网络架构，从设计上解决了在第三方主机托管架构中所遇到的扩展性和服务问题。最初，深度缓冲（Deep Buffer）机柜顶部（ToR，Top of Rack）交换机和电信级核心网络交换机的使用，使Twitter 支持了2014 年世界杯这样的全球事件所产生的前所未有的每秒交易（TPS，Transaction Per Second）量。在随后数年中，Twitter 架构团队在五大洲部署了网络服务提供点 （PoPs，point-of-presence）。2015 年，Twitter 从传统的层次数据中心网络拓扑结构迁移到使用边界网关协议（BGP，Border Gateway Protocol）路由的 Clos 网络。Clos 方法的显著优点包括：更小的设备单点故障的“波及范围”、更好的水平带宽扩展能力，以及由更低的 CPU 开销导致的更高路由性能。

在 Twitter 网络架构扩展的过程中，Twitter 的工程团队汲取到一些重要的经验教训：

• 超越原始规格和需求进行系统架构，并在流量趋向设计容量上限时迅速做出大刀阔斧的改进。
• 根据数据和指标做出正确的技术设计决策，并确保这些指标可被网络操作人员理解。这对于托管主机和云环境是尤为重要的。
• 并不存在所谓的“临时更改或变通方案”的东西。在很多情况下，变通方案会成为技术债务。

在 Twitter 架构中，45% 的规模用于存储和消息。架构团队为内部用户提供了多种服务，包括： Hadoop 集群、Twitter 的 Manhattan （Apache Cassandra-esque）分布式数据库集群、 FlockDB 图存储集群（使用了 Gizzard 和共享 MySQL）、 Blobstore 集群、 Twemcache 及“Nighthawk”共享 Redis 缓存集群、 DistributedLog 消息集群（用于 Heron 的处理）以及关系存储（MySQL、PostgreSQL 和 Vertica ）。在 2010 年曾使用 Cassandra 作为度量数据存储的解决方案，但是在 2015 年 4 月启用 Manhattan 后，就禁用了 Cassandra。

几乎全部的 Twitter 主缓存已从“裸机”迁移到大规模部署的开源集群管理系统 Apache Mesos 上（Twitter 也是 Mesos 代码库的主要贡献者之一）。推文的时间线缓存 Haplo 是尚未部署到 Mesos 的最重要组件。Haplo 使用定制版的 Redis 实现。对于该缓存，最严峻的挑战在于可扩展性和性能，因为 Twitter 运行上百个集群，合计包速率可达 3.2 亿包 / 每秒，每秒为客户提供 120GB 的内容。为达到高吞吐量和低延迟的服务水平目标（SLO，Service Level Objective），工程师要持续测量系统的性能，寻找优化效率的方法。例如，Twitter 工程师创建了一个测试缓存性能的开源工具 rpc-perf ，使用它可以更好地了解各种负载场景下缓存系统的运行情况。

存储和缓存实现中的主要经验教训包括：

• 为更好地处理特定的流量模式，Twitter 的 Manhattan 分布式数据库中采用了额外的存储引擎（LSM，B+ 树等）。通过发送背压信号并允许查询过滤，防止了对存储层的滥用。
• 聚焦于为任务提供适合的工具，这意味合理领会所有可能的用例。“适合各种场景”的解决方案是很少起作用的。对个别极端案例的处理采用临时解决方案即可，无需过多考虑如何能省时省力。
• 迁移到 Mesos 对于 Twitter 是一个“巨大的运营成就”，这允许了对架构配置的编纂整理，并使得规划部署成为可能。规划部署用于维持缓存命中率，并避免导致持久化存储层故障的问题。
• 根据用户、推文、时间线等对缓存做逻辑分区，通常每个缓存集群都根据特定的用途做了优化。

Twitter 使用 Puppet 实现所有的系统配置管理和 kickstart 后的软件包安装，Puppet 的代码有 500 多个模块，1000 多个角色，每个月都有 100 多位提交者。Puppet 有三个被其称为环境的分支，分别允许实现受控测试、金丝雀测试（Canarying）以及最终推动变更到生产环节。对于不断增长中的 Pupper 代码库，到目前为止影响最大的更改是代码查错（Code Linting）、代码模式检查钩（Style Check Hook）、最佳实践的文档化以及正常办公时间保持：

• 考虑到整个公司内有 100 多名 Puppet 提交者，对内部和社区最佳实践的文档工作已经成为“力量倍增器”。
• 归一的参考文档改进了代码交付的质量和速度。
• 当任务单和交流通道不足以满足交流的需要，或是不能表述要完成的工作整体情况时，需要保持正常的办公时间，这样员工可以提请援助（有时需要邀请），可进行一对一的交流。

更多扩展 Twitter 平台架构的相关信息，参见 Twitter 工程博客帖子“ Twitter 后台架构：扩展”。前期补充的博客帖子“ Twitter 后台架构：效率和优化”内容聚焦于 Twitter 私有平台即服务（PaaS）的演进。

查看英文原文： The Infrastructure Behind Twitter: Scaling Networking, Storage and Provisioning

感谢王纯超对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。