Twitter数据中心网络及软件体系建设经验

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介:

Twitter起步时正是服务器供应商统治数据中心的时代。自从那之后,Twitter团队没有停止前进的步伐,他们一直致力于使用开源社区的网络、软件技术和硬件,高效地提升集群性能,发布尽可能强的产品。Twitter目前的硬件使用情况分布如下:

37971487817276.png

网络流量

2010年初,Twitter团队开始考虑将集群从第三方主机上迁出,这个决定和动作意味着Twitter团队需要学习如何构建和运行内部的基础设施,由于需要在有限的可视化情况下了解核心基础设施需求,团队开始调研各种网络设计、硬件,以及供应商。

到2010年下半年,Twitter团队完成了第一个网络体系结构设计,解决了科罗拉多主机集群遇到的扩展性和服务问题。该方案有深度缓冲设计,支持对于突发的流量请求以及确保电信核心交换机在网络层没有超载。这个方案支撑了Twitter的早期版本,创造了一些比较出名的业绩,例如打破了TPS数据记录的“天空之城”事件(每秒处理34000条记录)以及应对2014年世界杯。

此后的几年时间里,Twitter的数据中心运行在五大洲的成千上万的服务器,网络覆盖很广。从2015年上半年开始,Twitter开始遭受到了成长过程中的痛苦,由于不断变化服务系统架构和增加容量需求,最终达到了数据中心物理可扩展性的上线,网状拓扑结构不再支持通过增加新的机架提升性能,即不再支持增加额外的硬件。另外,Twitter现有的数据中心开始由于不断增加路由规模和复杂的网络拓扑结构导致出现不稳定异常情况。

为了解决这个问题,Twitter开始将现有的数据中心转换为Clos拓扑+BGP,这是一种必须在现场做的网络转换工作。尽管很复杂,但是Twitter在一个相对较短的时间内完成了这个转换,并且对服务影响最小。网络拓扑图看起来是这样的:

63901487817276.png

总结技术亮点如下:

  • 单个设备故障具有较小的影响范围。

  • 水平带宽缩放能力。

  • 路由引擎较低的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负担。

然而主干网从最初开始就缺少任何业务工程设计,后来增加了帮助Twitter可以根据业务增长进行扩展的特性。为了实现这一点,Twitter完成了角色分离,使用单独的路由器分别处理核心和边缘路由请求。这也使得Twitter能够低成本效益地扩展,而不需要购买复杂的带边缘功能的路由器。

在边缘路由层,Twitter有一个核心连接所有网络,并且可以支持水平扩展,例如每个站点有很多路由器,不止两个,因为Twitter有一个核心层互联所有的设备。

为什么扩展路由器的RIB(路由信息库,即Routing InformationBase),Twitter引入了路由反射机制,这样就可以适配扩展需求,但是在做这个的过程中,需要移植到变更设计,Twitter也做了路由反射的客户端!

存储设计

每天有数以百万计的的推文(微博)被发送出来。这些推文需要被处理、存储、缓存、服务以及分析。对于如此庞大的信息内容,Twitter需要一个稳定的基础设施。存储和消息占据了45%的Twitter的基础设施空间。

存储和消息团队提供了如下服务:

  • 用于运行计算和HDFS的Hadoop集群

  • 用于所有的低延迟键值存储的Manhattan集群

  • Graph用于存储MySQL集群存储分片

  • Blobstore集群用于所有的大型对象(视频、图片、二进制文件等等)

  • 缓存集群

  • 消息集群

  • 关系型存储(MySQL、PostgreSQL以及Vertica)

92391487817276.png

在这个规模的多租户领域,Twitter遇到了一些困难,其中有一个是必须解决的问题。很多时候客户有一些很奇怪的用例,这些用例实施后会影响其他租户,这种案例带来了专有集群设计。许多专有集群增加了运行的工作量用于保持程序运行。

Twitter的集群设计没有什么特别的,不过倒是有一些有意思的地方可以分享:

  1. Hadoop:Twitter有多个集群存储了超过500PB的数据,这些数据被分为四组(实时数据、处理数据、数据仓库,以及冷数据仓库)。Twitter最大的集群有超过1万个节点组成。该集群每天运行15万个应用程序,启动13亿个容器。

  2. Manhattan(Tweets、直接消息、Twitter账号以及其他一些东西的后端):Twitter运行了一些集群针对不同的用例,例如大型多租户、小型的非常用功能、只读的,以及针对重写/重读业务模式下的读写。只读集群可以处理几千万QPS,而读/写集群可以处理百万级的QPS。Twitter观察到的性能最好的集群每天处理几十万的写请求。

  3. Graph:Gizzard/MySQL这样的基于分片的集群用于存储Twitter的图片。这个集群可以管理顶峰时间段千万级别的QPS,平均到每台MySQL服务器大约3万-4.5万QPS。

  4. Blobstore:Twitter的图片、视频,以及大型文件的存储量已经达到了数以百亿计。

  5. Cache:Redis和Memcache集群,缓存Twiiter用户、时间表、推文,以及其他一些内容。

  6. SQL:包括MySQL、PostgreSQL和Vertica。MySQL/PosgreSQL被用于强一致性场景,就像内部工具一样管理广告活动、广告切换。

Hadoop/HDFS也是日志管道的后端存储,但是在过渡到Apache Flume的最后的测试阶段,作为一种替换方案解决了选择客户端聚合时缺乏速率限制、缺乏传递类型保证等局限性,并且解决了内存奔溃问题。Twitter每天处理一兆条信息,并且所有的信息被处理后超过500个类别,然后有选择地在所有集群内拷贝。

缓存设计

虽然缓存只占用基础设施的3%,但是它确实对于Twitter很关键。缓存保护后端存储层远离业务风暴,允许存储流动成本很高的对象。Twitter在巨型规模内使用了几款缓存技术,例如Redis和Twemcache。更具体地说,Twitter有一个专用和多租户混用的Memcached(twemcache)集群,以及夜鹰集群(分布式Redis)。Twitter也迁移了几乎所有的主要的缓存到Mesos,以降低运行成本。

对于Cache来说,扩展性和性能是首要挑战。Twitter运营了数个集群,总计每秒320M数据包的数据包速率,提供超过120GB/s的数据给客户,Twitter的目标是即便在高峰段,也要确保每次响应的延迟约束在0.1%到0.01%之间。

为了满足Twitter的高吞吐量和低延迟服务水平目标(SLO),Twitter需要持续测试系统性能,寻找更有效的优化方案。为了帮助内部做到这一点,Twitter写了rpc-perf工具,更好地理解缓存系统是如何工作的。当Twitter尝试从专有机器上迁移到现在的Mesos基础设施时这个工具的作用就很重要了,帮助制定了容量规划。这些优化努力的结果是Twitter在没有延迟的基础上每台机器的吞吐量提升了一倍以上。Twitter仍然坚信存在很大的调优空间。

Twitter作为一家互联网服务提供商,它在建设通信软件服务时遇到的网络问题、软件系统架构问题、软件技术选型等等都值得我们学习。Twitter发表的文章有助于读者从整体理解互联网软件开发、发布、问题解决等整个体系结构相关知识,也帮助读者从侧面完成技术选型。



本文出处:畅享网
本文来自云栖社区合作伙伴畅享网,了解相关信息可以关注vsharing.com网站。

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2月前
|
移动开发 JSON 监控
网络协议解析:在员工上网监控软件中实现HTTP流量分析
随着企业对员工网络活动的监控需求不断增加,开发一套能够实现HTTP流量分析的网络协议解析系统变得愈发重要。本文将深入探讨如何在员工上网监控软件中实现HTTP流量分析,通过代码示例演示关键步骤。
144 0
|
5月前
|
监控 数据可视化 数据库
转:公司网络监控软件有哪些
随着信息技术的快速发展,公司网络管理的问题也逐渐突出,员工在上班时间网上聊天、网购等问题越来越严重,管理人员不能实时巡视员工的上班情况。为了更方便地监控员工在使用公司电脑时的上网行为,许多公司依赖于公司网络监控软件,这些工具不仅能够监控网络性能,还可以帮助识别潜在的风险和威胁。下面列举一些有哪些好用的公司网络监控软件:
172 0
|
6月前
|
缓存 算法 网络协议
【网络编程】第2章(3) 客户软件的设计算法和实现技术
【网络编程】第2章(3) 客户软件的设计算法和实现技术
|
5天前
|
JSON 监控 网络安全
使用Perl编写的上网监控管理软件:网络数据包拦截与分析功能
网络安全一直是互联网时代的重要议题之一。随着网络技术的不断发展,网络攻击和数据泄露等问题也变得日益严重。为了有效监控和管理网络流量,开发了一款基于Perl语言的上网监控管理软件,该软件具有强大的网络数据包拦截与分析功能,能够帮助网络管理员实时监控网络流量,并及时发现和应对各种网络安全威胁。
18 0
|
15天前
|
监控 Java 持续交付
内部网络监控软件的Groovy应用:持续集成与部署的自动化监控
在当今高度数字化的环境中,对于内部网络的监控变得至关重要。为了保证系统的稳定性和安全性,监控软件的自动化变得越来越必要。本文将介绍如何利用Groovy编程语言实现持续集成与部署的自动化内部网络监控软件,并通过代码示例展示其实现方式。
61 3
|
5月前
|
Rust 监控 并行计算
用Rust构建电脑网络监控软件:内存安全性和多线程编程
在当今数字化世界中,网络安全一直是至关重要的问题。电脑网络监控软件是确保网络系统安全和高效运行的关键工具。然而,编写电脑网络监控软件需要处理复杂的多线程编程和内存安全性问题。Rust编程语言提供了一种强大的方式来构建安全的电脑网络监控软件,同时避免了许多常见的编程错误。
244 0
|
1月前
|
自然语言处理 UED
ROSTCM6软件下载及语义网络分析详细操作教程(附网盘链接)
ROSTCM6软件下载及语义网络分析详细操作教程(附网盘链接)
190 0
|
2月前
|
Linux 开发工具 C语言
【Qo聊天软件】安装muduo网络库
【Qo聊天软件】安装muduo网络库
|
3月前
|
机器学习/深度学习 数据可视化 算法
神经网络模型结构框架可视化的在线与软件绘图方法
神经网络模型结构框架可视化的在线与软件绘图方法

热门文章

最新文章