科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网服务器频道虚拟化/云计算日800万访客20万RPS网站有9个可用性架构

日800万访客20万RPS网站有9个可用性架构

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

日访问人次达800万,每秒请求多达20万,AOL的人气确实令人艳羡。然而难得可贵的是,在如此高流量下AOL始终保持着99.999%的可用性,这里我们走进AOL设计于6年前的架构。

作者:Dave Hagler 来源:CSDN 2014年2月21日

关键字: AOL 开源 架构 大数据

  • 评论
  • 分享微博
  • 分享邮件

当下,AOL.com的架构已发展到第五代,也可以说是20年内重建了5次;现在使用的架构是在6年前设计,虽然整体保持不变,但组件的更新和添加却从未停止。在6年的持续改进过程中,代码、工具、开发、部署等环节都得到了充分的调优,也让AOL.com在当下的数据洪流中屹立不倒。

AOL.com工程团队一直保持在25人左右,包括了开发、测试及运维人员,公司的主要工作地点在Dulles和Virginia,也有一小部分在Dublin及Ireland。应对如此流量并将可用性保持在5个9从来都不是件容易的事情,在系统架构中我们使用了多种技术:Java、JavaServer Pages、Tomcat、Apache、CentOS、Git、Jenkins、Selenium和 jQuery等。

设计原则

关于架构的设计我们有着明确的思路,其中最重要的就是冗余一切,在系统中某个部分发生故障,或者需要离线维护时,有个备份无疑省时省力,而5个9的可用率要求每年不超过5分钟宕机时间。

第二个原则就是AOL.com不能依赖任何共享基础设施去交付页面,即使某个系统或内容发生故障,AOL.com仍然需要维持着高可用。在这个架构设计后不久,AOL大部分的网络内容都共享一个被称为Big Bowl的基础设施,这样会存在一个非常致命的问题——不同内容之间的相互影响。为了解决这个问题,当下的AOL专门设计了不同内容之间的隔离,任何依赖AOL.com的内容都会被一个保护服务前移至一组更少的主机上,保护服务负责将调用聚集到下游系统。因此,取代从上万个服务器上接收请求,下游系统可能只会从20个不同的服务器上获取请求,响应同样会被缓存来减少负载。同时,运维团队还会对AOL.com备份外部数据库。这样一来,在整个系统中只有网络和协议服务被共享。

物理基础设施

AOL.com部署在3个不同的数据中心,两个在Northern Virginia,一个在California,这些数据中心都由公司自主运营。虽然每个数据中心的规模都足以支撑整个AOL.com,但是AOL.com仍然坚持同时运行这三个数据中心,多冗余让数据中心的离线维护变得简单。

当请求接入时,负责跨数据中心负载均衡的Akamai GSLB将为用户指向离他最近的数据中心。为静态内容使用了Akamai CDN,一旦确定某个数据中心,进一部的请求(数据库或者是服务)都会传入这个数据中心。用户的会话信息会保存在cookies里,并通过请求发送;因为不需要保存状态,所以请求可以在任何服务器上被执行。

在数据中心上,请求会被发送给Netscaler组件,并通过负载均衡的方式将请求传送给前端应用服务器,当下3个数据中心前端服务器的数量已接近700。鉴于所有前端都是虚拟服务器,运维人员可以根据需要快速的添加容量,每个服务器配备了2 个虚拟CPU、4GB RAM和80GB的磁盘空间。每个前端服务器都单独运行了Apache和Tomcat,Apache会被请求发送给本地主机上的Tomcat,而Tomcat则负责大多数请求的处理,调用数据库或者服务以及执行应用程序逻辑。

流量

AOL.com的流量遵循常见的互联网使用模式——通常情况下流量不会有太大的变化,当然现实世界中发生大事件时除外。

每天流量最低的时候是早上3-6点,10点之前则是一个流量剧增期,会持续5个小时保持在20万点击每秒,在下午5点后降低。在一般情况下,工作日的流量会高于周末。

这些流量由个数据中心共同支撑,两个东海岸的数据中心各负责40%,西海岸则负责剩余的20%,流量分布不均匀的原因归结于用户分布的不均匀,同时也因为加拿大、英国、法国等国家的用户也被路由给了东海岸数据中心。

监视

所有的应用程序都运行在AOL数据中心,包括AOL.com,都由一个自主研发的工具监控,类似于Amazon的CloudWatch,已投入使用多年。监视工具会实时的收集软硬件信息,并通过一个客户端应用程序提供报告、图及仪盘表,提供了主机、CPU、接口、网络设备、文件系统、网络流量、响应代码、响应时间、应用程序度量等众多信息。服务器端点更是每分钟都进行检查,并在超过基于可用性及响应时间设置的阈值时进行报警。

内容管理系统

大部分的AOL.com内容及许多的业务逻辑都来自Content Management System,CMS同样是个自主研发系统,建立在相同的Java/JSP上,它的功能远超越一般的CMS。编辑使用它来创建AOL.com上的可见内容,开发者使用它来配置应用程序;它同样还是个仪表盘,让编辑可以实时的了解页面上所有部分的执行情况。

同样,AOL的首页远不止单一域名 www.aol.com上的一个页面。它其实由不同域名商的数十个版本组成,它们之间可能存在明显或细微的区别。CMS允许这些不同的版本在同一个地方制作,任何一个版本都可以从相同层上的多个父类继承不同内容,版本间的区别可以包括不同页面上的品牌化Logo、不同ID造成的内容不同等等,比如因为国际化的和访问设备造成的不同。

因此,内容管理系统减少了或者消除了手动的复制粘贴。比如,某个突发的事情只与美国相关,那么编辑只会在美国接口上呈现这个页面,然后这个内容将传播到美国网站的所有份数网站,同样也可以实现为自助的传播到下行网站。

在投放前,我们曾给这个项目进行了一定的尝试。为了更好的测试,我们建立了多变量、多单元并行测试工具。持之以恒的进行测试,并找出优化的途径。首先,我们选择一定比例的测试受众,他们将访问一个不同的版本(可能只是按钮颜色不同,也可能是完全不同的浏览体验),通过浏览器cookie进行追踪,通常往往会测试好几周才会确定一个结果。

数据库

AOL.com上的内容是高度动态的,因此需要为每次页面访问都制定数据库和应用程序连接规则。除了在页面上提示,CMS同样包含了许多规则和条件内容,如果你在旧浏览器上,你可能会在顶部看到一个浏览器升级提示。因此,CMS数据需要足够的快,有能力处理流量的爆发,并且一直可用。我们当下使用的是MySQL 5,区别于前端的虚拟服务器,数据库服务器拥有更多的容量——16 CPU的物理服务器。

CMS数据库使用了30个从副本,每个数据中心10个;同时,我们还会在一个数据中心建立主节点,同时还建立这个主节点的备份节点。除了主从设计之外,还会在每个数据中心设立1个中继器(reapeater)——主节点的另一个备份,负责与整个数据中心的从节点通信,repeater的作用是减少跨数据中心的数据通信;同时,在这种情况下,如果主节点和其备份节点都宕掉,中继器中的1个将会被指派为新的主节点。

应用程序通过1个HTTP接口访问数据库,AOL还为MySQL开发了1个Apache模块。每个数据库主机都有一个安装了Apache模块的Web服务器,它们负责管理数据库的连接池,给GET请求做SQL查询,结果则以XML格式返回。对于AOL.com这样的Java应用程序,还会有一个Java客户端,负责抽象HTTP调用并将XML解析成对象类型。

之所以使用HTTP数据库接口有多个原因:首先,它让客户端可以更轻松的访问数据库,因为任何语言都可以做HTTP调用,开发者不必再去考虑MySQL客户端驱动及连接池;其次,它有利于应用程序扩展——应用程序通过指定的URL访问数据库,URL对应负载局衡器的IP地址,当新的从节点加入时候,客户端应用程序不需要进行重新配置。此外,使用HTTP接口还有利于监视。标准的Web服务器访问日志和监视工具可以提供数据库事务量、查询次数及错误,然而在查询包含了URL作为参数后,日志将变得更加明了;同时,因为Apache模块中还加入了管理员接口,因此运维人员可以在任何浏览器上获取数据库状态。

缓存

AOL的架构中多处使用了缓存,而在CMS中就有两个级别的缓存。第一,CMS中访问数据的Java代码使用了内存缓存。鉴于CMS中的内容片都被版本化了,只要是新版本的话就不会有什么改动,因此数据可以被缓存来减少数据库IO。这种缓存是在Tomcat实例级别,每700实例使用1个单独的缓存。

但是为了得知是否有新的版本加入,我们仍然需要时常的查询数据库,这将带来大量的数据库IO,通常情况下返回的还是相同的结果。鉴于我们的数据库查询都由HTTP接口通过Apache模块完成,使用Varnish Cache来缓存查询将异常简单。数据库查询都是非常简单的HTTP GET请求,使用了URL做参数的完全SQL,因此Varnish显著的减少了访问数据库服务器的流量。

Akamai CDN被用于缓存所有的静态内容,除了静态内容之外,AKmai每隔几秒还会缓存AOL.com的静态版本,这个副本被用于极端情况下的灾难恢复——所有数据中心都不可访问时,用户将直接访问这个副本的类容,直到数据中心恢复。

系统中最后一处缓存用于AOL.com前端JSP代码,前端代码的作用是从CMS收集众多的页面并将它们聚合到HTML。我们开发JSP标签库让开发者可以缓存聚合HTML所需的任何部分,比如指定页面的那个部分需要缓存只需要用<cache:cache> </cache:cache>这对标签包含它们。

开发过程

大部分的时间,AOL团队都遵循Scrum开发过程,但是也不乏因为业务需求需要加班加点的时候。大部分的网站修改都可以通过CMS完成,避开了建立或代码开发过程。这种类型的更新每天可能发生数起至数十起,耗费的时间也是几分钟到几天不等。

开发团队会订阅一份iPhone周刊来监视应用程序状态,一旦发现异常数据,比如下游系统丢失,因为冗余策略虽然不会立刻影响到终端用户,但是却是在事情进一步恶化之前的提醒。除了应用程序方面,运维团队在网络、主机、数据库问题上都建立了类似的机制,让团队可以应对任何状况。

开发者在局部环境工作,大部分都使用装有Netbeans或Eclipse的Macbook Pro笔记本。在开发过程中存在6个不同的生产环境——与生产环境配置相同,但是规模较小。

代码在发布前需要经过严格的QA过程,同时鉴于AOL.com的多版本,测试环节所需要做的事情更加复杂(详情见原文)。

回顾和展望

当下AOL.com的技术堆栈已非常成熟,鉴于系统的架构设计于6年前,部分设计在今天可能已经不是第一选择,比如Java/Tomcat/JSP已经给Python和PHP应用让路,Apache可能也会略逊于Nginx,同时NoSQL数据库也带来了更多的选择,许多选择已运用在AOL的其它系统中。

不能免俗的是,架构中带来灵活和稳定的部分同样阻碍了新技术的采用,然而这并不能阻碍我们给系统做出有益的改变,比如:从实体到虚拟机、添加Varnish Cache以及引入Jenkins。同时,我们现在还在重写前端的HTML和CSS以清理历史遗留代码,同时也有助于多年前不可能关注的响应速度。总而言之,根据需求不停的演变架构以迎合产业的需求才是关键所在。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章