TripAdvisor架构

TripAdvisor架构 - 每月4千万用户访问，每天2亿动态内容PV，30T数据(2011-06-28 16:30:35)
转载
标签：系统架构it 分类：技术
TripAdvisor，网址是 www.tripadvisor.com ，中文网站叫到到网。下面是这家公司的架构介绍。

1、2011年6月份的统计数据

. 每月超过4千万独立访客，2千万会员，4千5百万评论
. 超过29个销售点，20种语言
. 我们的移动产品支持iPhone、iPad、Android、Nokia、Palm和Windows phone，每月吸引了1千万用户
. 每天的动态PV请求超过了2亿，象js/css/images/video等静态内容都是用CDN进行加速访问的
. 为了满足页面访问，每天进行了2.5亿次分布式操作请求，包括内部服务调用、数据访问和memcached访问
. 每天的日志压缩完后超过了120GB
. Hadoop上的数据有30TB，明年早期就达到100TB
. 从来没有过计划当机，可用性接近4个9
. 单独部署在北京支持daodao.com
. 每周发布周期，每天都发布丁。开发周期可以是一天，一周或者是一个月
. 超过两打小团队(略多于100个工程师)，同时为50多个项目工作，其中20到30个项目每周有新发布

2、总结构说明

. 用开源的linux/apache/java/postgre sql/lucene/velocity/memcached/jgroups
. 真的保持简单模式 － 容易建立、调试、部署、维护和运营
. 一系列简单无状态网站服务器，上面运行java和Velocity模板
. 每个功能(媒体，成员，评论，旅行列表等)都包装成服务的形式
. 一系列的服务 － 每个服务按业务导向设计访问接口，并针对网络访问性能做过优化
. 假定所有事情都会出问题。要么在集群(web服务器和服务服务器)中有大量的节点，要么保持真正的N+1冗余(在数据库和数据中心本身)

3、控制流说明

. 控制流也很简单：先解析请求的url，访问各个内部服务获取数据，替换到模板后，返回给用户
. 我们的url结构也是经过慎重考虑过的，已经稳定了很长时间，经历了网站重新设计和代码重构
. 请求用负载均衡设备转发给网站服务器。负载均衡器根椐用户的cookie选择对应的服务器组，再随机从中挑选一台将请求转给它。采用不同的服务器组，方便进行软硬件的布署管理和A/B测试。请求本身是无状态的，在浏览器cookie中存了状态信息。已经登陆的用户将从数据库中获取额外的状态信息
. 一个Java servlet解析URL和cookie信息，并确定它需要的内容，再访问不同的内部服务。一个servlet将访问0到10几个服务不等。每个服务访问将占用2~15毫秒。服务调用将通过一个软件负载均衡器，它可以为某个方法定义重试机制
. 每个服务接口都是按业务使用模式特别优化过，如查询一个会员的评论，查询一个地点的所有评论。大部分服务是数据库的一个智能缓存。用jgroups来同步缓存与数据库的内容。大部分服务跑在4个不同的虚拟机或物理机上，有些服务实例使用单独的服务器
. 服务访问返回的内容按java对象的方式组织，并传给velocity模板
. 有许多机制来选择不同的servlet和velocity模板，可以根椐用户位置、使用的语言、功能等等进行选择。在基础架构中还可以选择不同的代码和模板路径，以方便进行A/B切换和其它测试
. 我们的服务器放到不同的服务器池中，以便进行A/B测试，对部署进行更好的控制。每周的发布过程，会把代码发布到一个小池子上，运行几个小时，确保一切运转良好之后才会发布到所有机器池上


4、技术

. 冗余的BigIP组，思科路由器
. 一组64台无状态网站服务器，每台机器是linux/apache/tomcat，上面运行java程序，每天处理超过2亿的请求
. 一组40台无状态处理服务的服务器，上面运行25个左右服务，jetty/java，每天处理7个多亿的请求
. Postgre运行在6组服务器上，每组通过DRDB连在一起，每天处理7个多亿的查询
. 3个不同的memcached运行在网站服务器上，数据量超过350GB。用Spy memcache客户端，异步模式，NIO扩展请求。对spy java客户端进行了优化和别的改动，以保证扩展性和可靠性
. Lucene，包装在服务结构里，5千万文档，55GB的索引，每天查询8百万次。对索引按天进行增量更新，每周完全重建一次索引
. 用JGroups在不同的服务器之间进行状态同步，也没有别的选择
. 在16个节点集群上运行hadoop集群，192TB的裸磁盘容量，192个CPU，运行在万兆网络上
. java/python/ruby/php/perl等用来作工具和配套的基础设施
. 监控用cacti/nagios加自定义工具
. 两个数据中心，分布在不同的城高。一个承担流量，处理读写状态，另一个跟它保持同步，工作在只读模式，7x24小时随时准备切换。每个季度定期对两个数据的中心的角色进行切换
. 在每个数据中心总共大约有125台服务器，都是标准的Dell服务器
. 120GB压缩日志，包括应用程序日志，apache访问日志

5、开发

. 全配置的Mac或linux机器，SVN，Bugzillia，30"显式器
. 几百个虚拟的开发机。每个工程师有自己单独的开发虚拟机，额外需求用另外的虚拟机
. 按周为周期进行代码发布 － 每周一发一大包
. 每天会发布丁，处理缺陷和应急功能
. 100个左右的工程师同时为超过50个项目工作，每周有25个左右的项目发布新版本
. 工程师从设计、编码、测试到监控，全面负责。你设计，你自己写代码。你写了代码，你自己测试它
. 工程师负责HTML/CSS/JS/Java/Scripting所有方面的工作。如果你对其中一方面不熟悉，你可以去学习它
. 由不同的高级工程师和管理人员一起负责代码的最终发布过程
. 这边有许多测试框架可以使用：单元/功能/负载/冒烟等等。代码是你的，由你选择最适合的工具
. 同样有很多机制来帮助你高质量地完成新特性：设计评审／代码评审／部署评审/运维评审

6、文化

. TripAdvisor就象同时运行的两打初创公司那样，所有工作在同一个代码库，并​​在一个共同的分布式计算环境中运行。每个小组都有自己的经营目标，每队为其业务的所有方面负责。你工作在各个级别 - 设计，编码，测试，监测，CSS，JS，java，SQL脚本都归你
. TripAdvisor工程师按业务功能进级组织 －有超过2打的小组。每组直接为他们的业务目标服务，如SEM/SEO/Mobile/China等等。我们没有传统的架构／编码／QA角色
. 所有其它组使用的基础平台由运维组负责，这里包括：数据中心、软件基础设施、DevOPs、仓储。你可以把运维当成我们内部的AWS，提供7x24小时的分布式计算基础设施服务，编码/开发/测试/部署都统一到一处。这个小组包括2个操作工程师，2个负责数据中心和软件基础设施的网站工程师
. 每个小组都按适合对应业务特点和个人需要的方式工作，我们过程可以很好描述为“后敏捷”
. 负责文化 － 你为你的项目从头负责到底，负责设计、编码、测试、监控。大部分项目都是1到2个工程师
. 日志和度量 － 记录大量数据和度量数据
. 黑客周 － 每个工程师在每一年可以挑选任何项目，为之工作一周。你也可以与其它团队一起推进大型项目
. 工程师互换 － 不同项目中结对工程师可以互换几周时间，以传播知识和文化
. 网络工程项目 － 这是一个新项目，让工程师在不同的小组中工作几个月

7、想到哪就说到哪

. 可扩展性始于你的文化 － 你如何招聘，招什么样的人，你对他们提出了什么期望
. 工程师。招聪明、反应快、灵活的工程师，这些人愿意做任何类型的工作，乐于学习新技术。在TripAdvisor，我们没有架构师，如果你设计了一些，你就负责写对应的代码，并测试它们。对于那些只想工作在自己的舒适区，认为某些工作很低下的工程师，在里面工作只会碍别人的事情
. 招聘很高兴实现能用的东西的人。技术只是一个手段，本身不是目的
. 你负责你的代码和它的影响，如果你打破了某些事情，你去修复它
. 实现20个项目，带着10个BUG，另外3个项目延迟两天，这种情况比及时完成10个项目，一个bug也没有的情况更可取一些
. 鼓励学习和推动事情 －在这里工作的每一个人在最初的几个月里都会犯许多错误，经过一段时间偶尔仍然会犯错误。重要的事情是你从错误中学到多少东西和不要多次犯同样的错误
. 让设计尽可能保持简单，聚焦在近期的业务需求上 －不要超前设计。比如，我们从几万用户到几百万用户，再到几千万用户时，分别重写了我们的会员功能。当我们需要一个几万用户的产品时，如果按几千万用户的方式去设计，设计的结果可能很差。在某个阶段我们迟早会以更少的问题实现的，跟某个阶段所学到的比，重写的代价相对很小，
. 你可以用垂直扩展的方式，扩展数据库，这样也能走很远，特别是你减少使用联合查询，同时所有内容都能加载到内存中时更是如此
. 只有绝对必要的时候再拆分，并尽可能简单。我们最大的单表在超过1亿行数据的时候工作得很好，而且一直简单地垂直方式扩展，一直到我们每天需要更新或插入几千万数据，快接近修改的IO极限时，我们才按服务级别拆分成12个表，当前是12个表，分在两台机器上，每台机器是6个表。我们能轻易到扩展到 3，4,6，然后是12台机器，不需要修改我们的哈希算法或重新分布数据，只需要简单地复制表就可以做到。我们没有发现有任何读写性能下降，实现这一部分的代码也很简单，很容易理解和调试。每天超过7亿的数据库操作的情况下，我们仍然没有必要去拆分别的表
. 尽可能地避免联合查询。我们不同的内容类型存在不同的数据库中，有时共享同一台机器，有时用独立的机器。做两次查询(先查评论，再根椐评论中的ID查询会员，然后由应用程序对数据进行合并)比联合查询要好。通过将不同的数据放在不同的数据库，很容易扩展成一台机器负责一个数据库。这当然也使得你方便扩展你的内容类型，只要每个类型的内容不相互依赖，我们可以象增加模块似的增加新的类型。这也非常符合我们的服务导向的方法，每个服务是由对应的数据库支持的
. 让一个工程师负责所有的方面。当一个人负责所有的(css,js,java,sql,scripting)，这里没有等待、瓶颈、计划冲突、管理开销或者所有权重新分配。更多的项目和人可以以模块的方式加进来，而不影响现别的人和项目
. 服务。使用一组已知的矮胖协议，适合业务和使用模式，能容易地组装页面，以方便扩展各自的服务。搜索流量增加了不少？那就增加更多的搜索服务器。这也要求你更细致地思考你的业务和使用模式
. 硬件。尽可以保持简单。没有华丽的硬件，没有SAN和专用设备，我们所有的机器都是通用的DELL服务器。
. 软件。真的保持简单。有些系统你不会自己去写，如apache/tomcat/jetty/lucene/postgre/memcached/velocity。其它的东西都是我们自己打造的。这样不太难，同是你明白也能控制所有的事情
. 流程。少即是好。你需要使用源代码管理，需要成为一个好的代码编写者，需要实现能工作的代码，需要交流你的设计和他们的努力程度。其它没有什么还是需要或必须的了。如果你很聪明，你会得到你的设计评审，代码审查，你会写测试和相应的监控脚本。招聘那些明白你需要做这些事，是因为它们能帮助你实现更好的产品，不是因为他们是必须的人
. 设计评审。所有工程师每周邀请参加设计评审。如果你的一个项目会影响其它的项目(数据库，内存占用，新的库等)，期待你呈现在设计评审会上呈现你的你的设计并让大家讨论。这不仅仅是一个提供指导并对整个系统进行监督的好方式，同时也是让所有人相互学习并了解事情进展的好方式