让我们先回顾下TripAdvisor的架构。2011年6月，TripAdvisor发布其架构。过去一年多我们的业务发展迅速，让我来总结下我们的成绩：
每月5600万访问者
每天3.5亿页面访问量
Hadoop集群运行着120TB数据，并快速增长中
这个夏天，我们从大学招聘了60名兼职，其中包括Luke Massa和Victor Luu，他们像我们的全职工程师一样工作，很快融入了我们。一直以来总有一个问题纠缠着我：为什么要使用云计算?Luke Massa和Victor Luu通过在AWS部署我们的服务，总结了在过去这个夏天他们在TripAdvisor发生的一切。
图：AWS帮助企业节省大量成本
2012的夏天，TripAdvisor对我们的产品全部迁移到AWS进行了实验性的评估。首先，我们开始试验将www.tripadvisor.com和所有国际域名运行在AWS EC2环境，我们的工程师开始还怀有最简单的问题：放弃我们已有的硬件，迁移到AWS上真的划算吗?(AWS)能运行的完好吗?(注：停电、飓风以及其它不可知的原因，AWS今年已经出现两次大规模故障。或许，TripAdvisor考虑过在自己的服务器上运行OpenStack，这个开源平台允许企业架设自己的私有云，它兼容AWS的大部分API。)
几个月以前，我们开始试验性与云计算亲密接触，当然结果并不是非好即坏。我们在过程中学到了大量经验，不仅仅是AWS提供的价值，还包括帮助我们改造了原有托管服务器集群的架构。这一切都归功于AWS的灵活性，我们将DNS切换，流量转换到AWS，这非常实用，是非常好的学习工具!
目标
在EC2上建立网站的全部，评估实际生产环境的流量压力
建立成本模型
确认架构升级后我们可以减少支出，并增加扩展性
在转换到AWS后，我们需要找到方法提升我们现有的架构
EC2的支出
支出包括三个主要部分：实例、EBS和网络。假定生产环境的网络流量为200GB/小时，支出为14.30美元/小时。可以预见，实例的支出占据整个支出的大部分。
实际对比
部署每个数据中心需要大约220万美元，加上每年30万美元的升级和扩展费用。固定资产支出(Capex)大约100万美元/年，假设数据中心的初始成本分摊到3年中。运营成本包括空间、电源以及带宽，这些大概30万美元/年。合计成本为130万美元/年/数据中心。我们在每个数据中心有超过200台设备，每台典型设备的成本为7000美元。
如果我们将130万美元全部花在EC2上，签订1年期合同，我们会得到下面的架构：
550个前端和后端实例
64个缓存实例
10个数据库实例
成本1486756.96美元。
这意味着我们将增加60%的容量(目前已有340个前端和后端实例，32个缓存实例，5个数据库实例)。
如果我们签订3年合同，将享有惊人的优惠，这个架构的成本仅为88万美元/年。如果我们想在三年内花掉390万美元，我们将得到如下的架构：
880个前端和后端实例
64个缓存实例
20个数据库实例
一个有趣的现象是，即便是这个架构我们只使用了1760个内核(每个服务器2个CPU内核)，然而我们现在使用(CSDN注：指传统的服务器托管方式)总共3500个内核。显然，我们确信当下的架构存在一些垃圾和潜在的威胁，运行效率十分低下。
成本节省总结
保留实例的前提下，我们计算后发现，签订1年合同情况下，年化成本将节省一半。同时，我们不需要为流量高峰或系统备份预留实例，从而节省我们的总成本。
每个实例均可定制，以符合实际的需求。而现在，我们只能使用每台服务器的一部分性能。
运维人员-运维更加高效，因为我们知道实例会一直在那里运行。
几点失败
前端存在一些“BigIP喜好”(CSDN注：BigIP是F5公司推出的系列负载均衡设备)的类型实例。我们该怎么做，来减少对BigIP的依赖?
我们的负载均衡由Amazon管理，当Amazon出现故障时会发生什么?参考资料建议，全DNS名要好于IP地址，但这只适用于一般情况。
自动伸缩性帮助我们运行适当的前端和后端实例。然而，重建缓存实例需要很长时间，而且需要重复的数据库热备。
最佳实践
任何事情都可以通过AWS管理控制台搞定，它提供了命令行工具。你可以尽情的通过它自动完成许多启动过程。
在自动化启动过程中，在等待后确保实例运行并且达到要求：
“ec2-describe-instances”告诉你实例是否在运行
新版的“ec2-describe-instance-status”告诉你实例是否通过，以及系统状态检查
早期，开发了一些系统来监控实例的运行状态。但这关系到GUI问题。尽管你可以通过tag和名字监控任何事情，你还是需要一个更加自动的方式来管理这一切。举个例子，我们有一个PostgreSQL开发服务器来管理这一切。
停掉一个实例还不如终止它。这就是云计算的优势，当一个实例发生问题，常用的办法是启动一个全新的实例代替他，而不是进行重启。当然，你也可以找到并解决实例发生的那些故障。
值得注意的是，通过“terminated instances”来终止某个实例后，当你运行“ec2-describe-instances”依然会显示这个实例的名字。如果你用名字来区分实例的话，这的确是个问题，因为两个实例都会显示出来。
建议清理你的EBS卷。存储的成本增加非常快。同时建议及时清理快照，因为他们和卷有差不多的价格。
不要忘记短暂的存储，不要忘记他们是短暂的。一些积累下来的文件十分有用，如错误日志。用定时任务来保存重要的数据。
充分利用副本和快照完成快速扩展。
细节监控相当酷，不过我发现CloudWatch的自动排列功能已经够用。对于整个系统而言，检查状态时间间隔1分钟与间隔5分钟的区别并不重要。不过，对于监控特定的实例组还是有帮助。
ELB(Amazon Elastic Load Balancing，弹性负载均衡)也是一个监控实例状态的好工具，即使我们实际上没有用到。
许多令人崩溃的网络问题可以通过小心照看安全设置组来解决。
总结
实际上，除了本文开始介绍的停电、实例磁盘空间不足这些问题外，TripAdvisor在迁移到AWS过程中还遇到了种种困扰，包括数据丢失、实例不可用、NGinx故障等等，详细请阅读原文“Problems Along The Way”部分。显然，你不能指望云计算解决所有问题，而且就目前云计算的成熟度而言，企业还需要强大的技术积累，如需要在本地做好重要实例的备份。
