Twitter的六大架构设计经验谈

InfoQ · 公众号 · 科技媒体 · 2017-03-03 07:59

正文

请到「今天看啥」查看全文

总结技术亮点如下：

单个设备故障具有较小的影响范围。
水平带宽缩放能力。
路由引擎较低的CPU开销；路由更新更高效的处理能力。
由于较低的CPU开销，更高的路由容量。
每个设备和链路上的更细粒度的路由策略控制。
不再重复发生之前的几个已知问题：包括增加协议收敛时间、路线流失问题和伴随固有的OSPF复杂性的不可预期问题。
启用无影响机架迁移方案。

数据中心

Twitter的第一个数据中心是基于建模分析出的能力和已知系统的运行状态经验构建的。但是仅仅几年之后，数据中心比最初的设计扩大了400%。现在，随着Twitter应用程序堆栈的演变，Twitter正在变得更加分布式化，运行状态也在跟着变化。引导Twitter进行网络设计的最初假设场景已经不复存在了。

业务需求增长过快，导致针对整个数据中心进行重构已经不切实际。所以构建一个高可扩展的体系架构会让Twitter更容易增加能力，而不是采用叉车式的迁移方案。

高可扩展性的微服务需要高可靠性网络，可以支持处理各种业务。Twitter的业务范围从TCP长连接到离线的MapReduce任务，再到超短连接。针对这类多样性业务需求的应对方案是，部署具有深包缓冲区的网络设备，但是这样会带来一系列问题：更高的成本和更好的硬件复杂度。之后的设计Twitter使用了更加标准化的缓冲区大小，以及在提供切断开关功能的同时，提供了更好的TCP栈服务器，这样可以更好的处理网络风暴问题。

骨干网络

Twitter的骨干网流量每年都有大幅度正常，并且仍然可以看到数据中心之间的突发数据增长较正常状态的3-4倍情况存在。这种情况对于老的协议是一个特有的挑战，这些老的协议，例如MPLSRSVP协议，从来不是为应对突然爆发的网络风暴而设计的，它的目标是应对渐进式的缓慢的网络请求增长。为了获得尽可能快的响应时间，Twitter不得不花费大量的时间调整这些协议。此外，Twitter实现的优先次序可以处理网络高峰（特别是存储复制）情况。

Twitter需要确保在任何时候优先客户的传输流量，可以通过延迟低优先级的存储复制工作满足这个需求，存储复制这类工作有一天时间的SLA。这样就可以使用最大量的网络资源，让数据尽可能快速地移动。客户业务需求比低优先级的后台业务需求优先级高。而且，为了解决伴随着RSVP自动带宽而来的bin-packing问题，Twitter实现了TE++，这个工具当流量增加时创建额外的LSP，当流量下降时则会删除LSP。这使得Twitter可以有效地管理连接之间的网络业务，同时减少维护大量的LSP所造成的CPU负担。