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

AOL.com，American Online（美国在线），美国著名的新闻聚合网站，也是美国最大的互联网服务提供商之一。当下，AOL.com的天访问人次已超过800万，月PV更达10亿之巨。近日，Lead Squirrel创始人、AOL架构师兼工程团队负责人、拥有10年架构经验的Dave Hagler在HighScalability上撰文分享了AOL高可用性（99.999%）网站架构，以下为译文：

当下，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里，并通过请求发送；因为不需要保存状态，所以请求可以在任何服务器上被执行。