一旦你成为多数人的信息来源，尤其是排名靠前的站点，每逢出现社会热点事件，将会受到来此全社会定向发动的 DDoS。与国内的微博一样，Twitter 也需要面对这样的问题。超级碗、世界杯和世界新年庆典等等都会挑战 Twitter 的基础设施。本文将从数据中心优化和硬件优化两个方面，沿着历史挑战、当前成果、未来展望这样的脉络道出 Twitter 的基础设施优化之路。

数据中心优化

历史挑战

像 Twitter 这样级别公司的硬件和数据中心的规模少有其他公司能够达到。然而，在达到这样的规模之前，必然会有一段艰辛的拓荒之路。经过硬件的提升和基础软件的优化，Twitter 服务的运行日趋稳定。

曾经有一段时间，故障如家常便饭，由于软件的限制经常发生中断，硬件或基础设施级物理故障时常出现。经常需要汇总整理各种各样的故障信息以进行风险评估，进而确定需要的冗余服务数量。由于业务迅速的扩展，服务客户数量爆发式增长，发展战略逐渐演变为有效地和有弹性地支持服务。

软件从最原始的仅仅依赖单晶硅到现在需要依赖数据中心运营和维护正常运行时间的能力、光纤连接和整体环境。这些离散的物理故障域必须在分布式服务的基础上进行评估以确保有足够的容错能力。当专业化选址、运作和设计都处于起步阶段时，选用哪个数据中心服务提供商、做到何种规模等等决定已经做出。早期由于设备错误、数据中心设计缺陷、维护问题和认为错误导致了一系列的服务中断。作为结果，工程师只能不断重复地迭代物理层设计，以增加硬件和数据中心运行的弹性。

因为物理原因导致的服务中断包括服务器组件层级、机架交换机的顶部和核心交换机的硬件错误。打个比方，在最初评估定制的服务器期间，硬件团队确定的第二电源的成本不足以保证服务器电源故障率低的要求，最终它们从设计中被移除。数据中心电源拓扑通过单独的物理鞭到齿条来提供冗余，而这需要使用第二电源。第二电源的去除毁掉了冗余电源路径，使得供电系统的硬件在分布式错误产生期间变得脆弱。为了减轻单电源的影响，ATS 单元需要被添加到机架级，以此提供电源的第二路径。

当前成果

Twitter 团队从前车之鉴中学会了对物理错误域（比如建筑的电源、冷却、硬件和光纤等等）和分布其中的服务之间的依赖进行建模，更好地预测容错性并进行改进。他们增加了数据中心的区位多样性，这样可以转移自然灾害带来的风险，也消除了相当一部分在升级、部署期间出现意外可能导致的失败。同时也提供了分级部署机制来减少代码部署对数据中心整体的影响。他们通过扩大环境外壳的工作范围和在更高的工作温度下设计高弹性硬件提升了数据中心的电源利用率。

未来展望

Twitter 的数据中心持续在策略和运行方式上进行优化，可以在不中断的情形下实时地改变运行网络和硬件。在未来几年内，他们将持续专注于在现有物理基础之上通过优化和保持灵活性来持续提升效率。

软硬件优化

历史挑战

在最开始，硬件工程团队通过检测和验证市场上的硬件性能来购买现成的硬件，慢慢演变成通过定制硬件来裁减成本和优化性能。以 Twitter 这样的规模来购买硬件是一件极具挑战的任务。为了满足内部用户的需求，他们专门成立了一个团队来检测并保证购买的硬件的质量。这个团队首要关注的部分是性能和可靠性测试，以保证满足系统的需求，并对硬件进行系统性的测试来验证硬件的表现是可预测的，并不会出现太多的 bugs。

由于之后需要扩展主要工作负载（Mesos、Hadoop、Manhattan 和 MySQL），市场上现有的产品明显已经不能满足需求。现有的服务器都带有企业功能，如 raid 控制器和热插拔电源。这些组件可以在小规模使用时提升可靠性，但在大规模使用时会增加成本并降低性能。例如一些 raid 控制器会降低 SSD 的性能，造成性能损耗。曾有一段时间，他们大量使用 MySQL。SAS 介质的供应和性能都出现了问题。它们大多数部署在 1u 服务器中，驱动器的数量加上一个回写缓存可以将系统时间性能限制在 2000 IOPS。为了能继续扩展工作负载，团队通过增加 CPU 核心数和硬盘容量来达到 IOPS 需求值，当时没有其它有成本效益的解决方案。最终硬件数量到达了临界值，Twitter 决定投资一个硬件工程团队来定制白盒方案来减少资本支出并增加性能指标。

探索与进步的道路上，Twitter 团队多次迁移技术栈：

• 2012 - SSDs 成为了 MySQL 和键值对数据库的主要存储介质。
• 2013 - 开发了为 Hadoop 工作负载开发了定制的解决方案，并成为了主要的大容量存储解决方案。
• 2013 - 开发了 Mesos、TFE 和缓存工作负载的定制解决方案。
• 2014 - 开发了定制的基于 SSD 的键值对服务器。
• 2015 - 开发了定制的数据库解决方案。
• 2016 - 为推理和机器学习模型开发了 GPU 系统。

当前成果

硬件工程团队的目标是在持续提升性能指标的基础上减少资本支出和运营支出。Twitter 的工作负载分为四个主要部分：存储、计算、数据库和 GPU。Twitter 为每个维度均定义了总体需求，使硬件工程团队能够聚焦于各个维度的功能。这种方法使得他们能够在一些设备被闲置或利用不足的情况下优化组件选择。例如，专门为 Hadoop 的工作负载设计的存储配置比原来 OEM 解决方案低 20% 的 TCO。同时，该设计改善了性能和硬件的可靠性。同样，对于计算版块，硬件工程团队通过去除不必要的功能提升了这些系统的效率。

很快 Twitter 已经不能通过减少组件来降低费用，特别是计算版块，最好的解决方案是将多个节点替换成一个，同时依赖 Aurora/Mesos 来管理容量。他们确定了先将两个前代计算节点替换成一个来验证方案。在设计验证阶段先设定了一系列粗放的性能基准，然后以2作为比例因子进行了一系列的生产负荷实验。这次性能提升大部分的原因是 CPU 线程数的增加，但实验证实每个线程的性能提升了 20%-50%。此外，每个线程的电源效率提僧了 25%，原因是在更多的线程之间共享服务器的开销。

在最初部署的时候，监测器显示替换因子是 1.5，低于最初的设计目标。经过检查的性能数据显示，负载特性中有一个需要被识别的错误假设。硬件工程团队的初步行动是开发一个模型来预测在各种硬件配置中当前 Aurora 任务集的打包效率。该模型正确地预测到了观察到的比例因子，并暗示他们由于意料之外的存储需求导致部分核心停止运行。另外，模型还显示通过优化内存配置可以提高比例因子。改变硬件配置需要一些时间才能生效，所以硬件工程团队确定了几个大的工作方向，与 SRE 团队一起调整调度需求以减少需要的存储。这些优化被快速部署了，结果是比例因子瞬间提升到了 1.85。

为了彻底地解决上述的问题，硬件工程团队需要调整服务器的配置。简单地扩大安装内存和硬盘容量，就使得 CPU 使用率提升了 20%。硬件工程团队与制造合作伙伴一起对这些服务器出货量的初始材料清单进行了调整。后续观到了值为 2.4 的比例因子，大大超过了设计目标。

未来展望

Twitter 正在不断寻找提高效率和优化基础设施的方法。作为其中的一部分，Twitter 定期通过对比公共云提供商和其产品来验证自己的 TCO 和对基础设施的性能期望。Twitter 也有一个自己的公共云平台，并将持续利用公共云，因为这是最好的选项。