根据近期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架构中，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是一个“巨大的运营成就”，这允许了对架构配置的编纂整理，并使得规划部署成为可能。规划部署用于维持缓存命中率，并避免导致持久化存储层故障的问题。 根据用户、推文、时间线等对缓存做逻辑分区，通常每个缓存集群都根据特定的用途做了优化。考虑到整个公司内有100多名Puppet提交者，对内部和社区最佳实践的文档工作已经成为“力量倍增器”。 归一的参考文档改进了代码交付的质量和速度。 当任务单和交流通道不足以满足交流的需要，或是不能表述要完成的工作整体情况时，需要保持正常的办公时间，这样员工可以提请援助（有时需要邀请），可进行一对一的交流。

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