# TripAdvisor 架构-4,000 万访客，200M 动态页面浏览，30TB 数据 > 原文： [http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html)  *这是 TripAdvisor 工程部副总裁 [Andy Gelfond](http://www.linkedin.com/in/andrewgelfond) 的特邀帖子。 安迪（Andy）在 TripAdvisor 呆了六年半，在早期就写了很多代码，并一直在建立和运营一流的工程和运营团队，该团队负责全球最大的旅游网站。 史诗般的 TripAdvisor 更新：[上有此文章的更新：为什么不在云上运行？ 盛大实验](http://highscalability.com/blog/2012/10/2/an-epic-tripadvisor-update-why-not-run-on-the-cloud-the-gran.html)。* 对于 [TripAdvisor](http://en.wikipedia.org/wiki/TripAdvisor) 而言，可扩展性已渗透到我们组织的多个层次上-数据中心，软件体系结构，开发/部署/运营，最重要的是在文化和组织内部。 拥有可扩展的数据中心或可扩展的软件架构是不够的。 设计，编码，测试和部署代码的过程也需要可扩展。 所有这一切都始于招聘，一种文化和一个组织，该组织重视并支持复杂，高度可扩展的消费者网站的分布式，快速，有效的开发和运营。 ## 截至 6/2011 的统计数据 * 每月超过 4000 万的唯一身份访问者（Comscore），2000 万成员，4500 万评论和意见 * 超过 29 种销售点，20 种语言 * 我们的移动产品可在 iPhone，iPad，Android，诺基亚，Palm 和 Windows Phone 上使用，每月吸引 1000 万用户 * 每天超过 200M 个动态页面请求，而所有静态资源（例如 js，css，图像，视频等）都通过 CDN 进行服务 * 每天执行超过 2.5B 的分布式操作（服务，数据库，内存缓存），以满足页面请求 * 每天流式传输超过 120GB 的日志文件（压缩） * Hadoop 上 30 TB 的数据，预计明年初将达到 100 TB-每天修补程序，以“需要今天退出”功能/修复 * 从来没有计划过停机时间，正常运行时间接近 4 9 * 在北京单独部署以支持 daodao.com * 每周发布周期，每天发布“补丁”。 开发周期可以是一天，可以是一周，可以是一个月 * 超过二十个小型团队（略多于 100 名工程师）一次处理 50 多个同步项目，每周部署 20-30 个项目 * 团队包括：搜索引擎营销（SEM），搜索引擎优化（SEO），内容管理，客户关系管理（CRM），移动网络，移动应用，社交网络（FB），酒店，餐厅，论坛，旅行清单，视频平台，航班，度假租赁，企业列表，内容分发，API，中国 ，亚太地区，销售和营销活动，数据中心运营，开发运营，分析和仓储，质量检查 ## 一般建筑 * 开源 Linux，Apache，Tomcat，Java，Postgres，Lucene，Velocity，Memcached，JGroups * 保持非常简单-易于构建，调试，部署，维护和操作 * 非常简单的无状态 Web 服务器库，运行简单的 Java 和 Velocity 模板 * 每个“功能”区域（媒体，成员，评论，旅行清单等）都打包为服务 * “服务”库-每个服务都是针对总体性能进行优化的高级，面向业务的 API * 假设事情失败了。 集群中有大量节点（Web 服务器，服务机），或者具有真正的 N + 1 冗余（数据库和数据中心本身） ## 控制流程 * 控制流程非常简单：解析请求 URL，从各种服务中收集内容，然后将其应用于模板。 * 我们的 URL 结构经过深思熟虑，即使在重新设计网站和重构代码的情况下，也能保持很长一段时间的稳定性。 * 请求通过负载平衡器路由到 Web 服务器。 请求是在基于 cookie 的“池”（服务器的集合）中随机分配的。 池用于部署管理和 A / B 测试。 请求本质上是无状态的-浏览器 cookie 中存储着“会话”信息。 登录的用户将从数据库中获取其他状态。 * Java servlet 解析 url 和 cookie 信息并确定所需的内容，从而调用各种服务。 服务 API 定义为 Java 接口，而 Servlet 会发出 0 到十几个服务请求。 服务呼叫通常需要 2 到 15 毫秒。 服务调用通过具有可重试逻辑的软件负载平衡器进行，该逻辑可基于每种方法进行定义。 * 每个服务都具有针对业务和/或使用模式进行了优化的 API，例如，获取成员的评论或位置的评论。 大多数服务本质上是数据库前面的大型智能缓存，例如，局部 LRU，内存缓存，数据库调用在内存部分树/图中。 Jgroups 有时用于在需要时使缓存保持同步。 大多数服务在不同的共享/物理计算机上运行 4 个实例，有时为服务实例分配自己的计算机。 * 从服务调用返回的内容集经过处理，并由 Java 代码组织成对象集，这些对象集传递给 Velocity 模板（有点像弱 JSP） * 有多种逻辑可根据上下文选择不同形式的 Servlet 和/或 Velocity 模板，其中可能包括 POS，语言，功能等。还有用于选择 A / B 和其他代码的不同代码和模板路径的基础结构 测试 * 我们的 Web 服务器排列在“池”中，以允许进行 A / B 测试并控制部署。 我们的每周发布过程将部署到一个小型池中，并让代码运行几个小时，以确保在部署到所有池之前一切正常 ## 科技类 * BigIP 冗余对，Cisco 路由器 * 64 个无状态 Web 服务器，运行 Java servlet 的 Linux / Apache / Tomcat，每天处理 200M +请求的库 * 40 台运行约 100 个实例的无状态服务机（约 25 个服务实例），Jetty / Java，每天处理 700M +个请求 * Postgres，在 6 对（DRDB）机器上运行，每天处理 700M +次查询 * Memcached，3 个独立的群集，运行在 350GB 以上的 Web 服务器上。 Spy Memcache 客户端的可配置池-异步，NIO 以扩展请求。 进行了优化和其他更改以监视 java 客户端以实现规模和可靠性。 * Lucene 包含在我们的服务基础结构中，拥有 5000 万个文档，55GB 索引，每天 8M 搜索，每日增量更新，每周一次完全重新生成。 -隐藏引用文字- * 当没有其他选择时，JGroups 用于服务机之间的状态同步。 * Hadoop，具有 192TB 原始磁盘存储的 16 个节点群集，192CPU，10GB 网络 * Java，Python，Ruby，PHP，Perl 等用于工具和支持基础架构 * 监视-仙人掌，nagios，自定义。 * 两个数据中心，位于 N + 1 配置中的不同城市，一个以 R / W 模式接收流量，另一个以 R / O 模式同步通信，准备进行 24/7 故障转移，定期按季度交换活动数据 * 每个数据中心总共约有 125 台计算机，所有标准 Dell 设备 * 日志记录-120GB（压缩）应用程序日志，apache 访问日志，财务敏感数据的冗余日志记录-流式（记录）和非流式 ## 发展历程 * 满载的 Mac 或 Linux 计算机，SVN，Bugzilla，30 英寸显示器 * 数以百计的虚拟化开发服务器。 每位工程师专用一位，按需提供其他服务 * 每周部署周期-每个星期一都会发布整个代码库 * 那些“今天需要离开”的人的每日补丁程序/修复 * 大约 100 个工程师同时处理 50 多个并发项目，每周部署约 25 个 * 工程师端到端地工作-设计，代码，测试，监控。 您设计一些东西，然后编写代码。 您编写一些代码，然后进行测试。 * 工程师跨整个堆栈工作-HTML，CSS，JS，Java，脚本。 如果您不了解某些内容，则可以学习。 * 发布过程在各个高级工程师和工程经理之间共享和轮换 * 可用的测试框架多种多样：单元，功能，负载，烟雾，硒，负载和测试实验室。 它是您的代码，选择最适合您的代码。 * 多种机制可帮助您提供最优质的功能：设计审查，代码审查，部署审查，运营审查 ## 文化 * 与运行两个同时启动的新兴公司相比，TripAdvisor 的工程技术最好，它们都在同一代码库上运行，并且在一个通用的分布式计算环境中运行。 这些团队中的每个团队都有自己的业务目标，每个团队都有能力并对其业务的各个方面负责。 交付项目的唯一障碍是您，因为您应该在各个级别上工作-设计，代码，测试，监视，CSS，JS，Java，SQL，脚本。 * TripAdvisor 工程是按业务职能组织的-有两个以上的“团队”，每个团队负责直接与他们的业务同行在 SEM，SEO，移动，商务，CRM，内容，社交应用程序，社区，成员资格，销售和营销解决方案上合作 ，中国，亚太地区，商家信息，度假租赁，航班，内容联合供稿等。 我们没有传统的架构师，编码员，质量检查人员 * 我们的运营团队是一个团队，负责所有其他团队使用的平台：数据中心，软件基础架构，DevOps，仓储。 您可以将 Operations 视为我们的内部“ AWS”，将我们的 24/7 分布式计算基础架构作为服务提供，并且将代码/开发/测试/部署全部整合为一个。 该团队包括两名负责数据中心和软件基础架构的技术运营工程师和两名现场运营工程师。 * 每个团队的运作方式都最适合其独特的业务和个人需求，我们的流程被形容为“敏捷后/混乱”。 * 责任文化-您端到端拥有您的项目，并负责设计，编码，测试，监视。 大多数项目是 1-2 位工程师。 * 记录和测量-大量数据，大量指标 * 黑客周-每个工程师每年都有一个星期从事他们想要的任何项目。 您可以与其他人一起解决更大的项目 * 工程交换。 来自不同团队的工程师对将交换几个星期的时间，以传播知识和文化 * Web 工程程序。 一个新的计划，适用于希望在许多不同的团队中工作几个月的工程师。 * 夏季星期五-在夏季改变您的星期几并释放星期五的时间 * 每年的慈善日-整个公司外出并为当地的慈善机构捐款-绘画，园艺等 * TripAdvisor 慈善基金会。 员工可获得数百万美元的资助，可以向自己所参与的慈善组织申请赠款。 ## 关于我们学到的东西，我们如何工作的随机想法 * 可扩展性始于您的文化，即您的雇用方式，雇用对象和设定的期望。 * 工程师。 雇用聪明，快速，灵活的工程师，他们愿意从事任何类型的工作，并为学习新技术而兴奋。 我们没有“建筑师”-在 TripAdvisor 上，如果您设计某些东西，编写代码，然后对它们进行测试。 不喜欢走出舒适区的工程师，或者觉得某些工作在他们“之下”的工程师将很容易受阻。 * 雇用从交付有用的事物中获得乐趣的人。 技术是达到目的的手段，而不是最终目的。 * 您拥有自己的代码及其效果-设计，测试，编码，监控。 如果您弄坏了东西，请修复它。 * 最好是在两天之内交付 20 个带有 10 个错误的项目，而错过 5 个项目，而不是交付 10 个完全且及时的项目。 * 鼓励学习和突破极限-在这里工作的每个人在开始的几个月中都会犯许多错误，并且随着时间的推移，偶尔还会犯错。 重要的是您学到了多少，不要一次又一次犯同样的错误。 * 保持设计简单，并着眼于近期业务需求-不要设计得太远。 例如，随着我们的会员功能从数万个扩展到数百万个到数千万个，我们已经重写了我们的成员功能。 当我们需要的数以万计的时候，我们为数千万的设计本来就很糟糕。 我们更快地交付了每个阶段的问题，并且与每个阶段所学的相比，重写的成本很小。 * 您可以在垂直扩展数据库方面走得很远，尤其是在最小化联接使用的情况下，尤其是可以将所有内容放入 RAM 的情况下。 * 仅在必要时才进行分片，并保持简单。 我们最大的单个表具有超过 1B 的行，并且可以轻松垂直扩展，直到我们每天需要更新/插入数千万行，达到写入 IOP 限制。 到那时，我们通过将其拆分为 12 个表在服务级别上进行了分片，并且目前在 2 台计算机上（每台都有 6 个表）运行它。 我们可以轻松地将其扩展到 3、4、6，然后是 12 台机器，而无需更改哈希算法或数据分布，只需复制表即可。 我们没有任何可衡量的性能下降（读取或写入），并且执行此操作的代码很小，易于理解且易于调试。 每天有超过 700M 的数据库操作，因此我们离分拆任何其他表都不远。 * 尽可能避免加入。 我们的内容类型（成员，媒体，评论等）位于单独的数据库中，有时在共享计算机上，有时在其自己的计算机上。 比执行联接要好得多（执行两个查询（获取具有其成员 ID 的评论集，然后从该 ID 集合中获取所有成员并在应用程序级别将其合并））。 通过将数据存储在不同的数据库中，可以轻松地将每个数据库扩展到一台计算机。 保持内容类型的可伸缩性也更加容易-我们可以以模块化的方式添加新的内容类型，因为每种内容类型都是独立的。 这也与我们的面向服务的方法非常吻合，该服务由数据库支持。 * 承担单个工程师的端到端责任。 当一个人拥有一切（CSS，JS，Java，SQL，脚本）时，就没有等待，瓶颈，调度冲突，管理开销或“所有权”的分配。 可以采用模块化方式添加更多项目/人员，而不会影响其他所有人。 * 服务。 拥有一组与业务和使用模式对齐的已知的块状协议（针对有线网络进行了优化）协议，使组装页面变得更加容易，并允许您根据业务需求扩展每个服务。 搜索流量大增？ 添加更多搜索服务器。 还可以使您更仔细地考虑使用模式和业务。 * 硬件-保持非常简单。 没有花哨的硬件-没有 SAN，没有专用设备（用于网络设备）-我们运行所有戴尔的商品。 假定任何组件都会随时发生故障，并且具有 N + 1 设计或足够的资源来弥补故障。 我们的网络服务器库可以处理大量失败-高达 50％。 数据库为 N + 1，具有重复的热（基于 DRDB）故障转移。 服务在多台计算机上运行多个实例。 负载平衡器和路由器均具有热备用和自动故障转移。 我们在不同城市拥有两个完整的数据中心，一个处于活动 R / W 模式，可处理所有流量，另一个处于最新状态，R / O 模式可随时用于流量。 我们每三个月进行一次“故障转移”，以确保随时准备好“备份”，并为我们的数据中心提供连续/增量的维护。 * 软件-保持非常，非常，非常简单。 有一些您不想自己写的系统-Apache，Tomcat，Jetty，Lucene，Postgres，memcached，Velocity。 我们自己构建了其他所有内容-分布式服务体系结构，Web 框架等。这并不难做到，您可以理解和控制所有内容。 * 处理。 越少越好。 您需要使用源代码控制。 您需要成为一个良好的代码公民。 您需要交付有效的代码。 您需要传达您的设计及其工作水平。 “需要”或“需要”没有太多其他内容。 如果您很聪明，则将对设计进行审查，对代码进行审查，并编写测试和适当的监视脚本。 雇用了解您想要这些东西的人，因为它们可以帮助您提供更好的产品，而不是因为它们是“必需品”。 如果您犯了一个错误，并且您会犯错，并且将其修复。 重要的是要找到自己的错误，而不要依靠别人为您找到错误。 * 设计评论。 邀请所有工程师进行每周设计审查。 如果您有一个项目会影响其他项目（数据库，内存使用，新的 servlet，新的库，重要的东西），那么您应该在设计审查时介绍您的设计并进行讨论。 这不仅是对整个系统提供指导和监督的好方法，而且是每个人互相学习并了解正在发生的事情的好方法。 * * * 我非常感谢 Andy Gelfond 对 TripAdivsor 所做的工作提供了非常有用的描述。 好工作。 如此注重细节，不难看出为什么 TripAdvisor 如此有用。 谢谢。 TripAdvisor 正在[招聘](http://www.tripadvisor.com/careers/)。 ## 相关文章 * [黑客新闻主题](http://news.ycombinator.com/item?id=2701936) > Postgres，在 6 对（DRDB）机器上运行，每天处理 700M +次查询 是 DRBD（http://en.wikipedia.org/wiki/DRBD），对吗？ > 工程师端到端地工作-设计，代码，测试，监控。 您设计一些东西，然后编写代码。 您编写一些代码，然后进行测试。 > 工程师跨整个堆栈工作-HTML，CSS，JS，Java，脚本。 如果您不了解某些内容，则可以学习。 > 交付项目的唯一障碍就是您，因为您应该在所有级别上工作-设计，代码，测试，监视，CSS，JS，Java，SQL，脚本。 don't you end up with dissimilar code all over the place? are you allowing your dev to design the way your apps interact with end users? don't you know that dev rarely design good user interfaces? if the same dev is also responsible for supporting their code throughout its lifetime, don't you eventually get into a situation where that dev/team will do nothing but fix bugs in their existing code and don't have enough time to work on new projects? DRBD 是正确的，谢谢 Progga 嗨，mxx， 我们的系统并不完美-每个团队都需要决定对他们而言重要的事情并做出选择。 是的，有时我们确实会得到重复的代码，但这并没有您想的那么糟糕。 我们依靠工程师来做正确的事，并且我们进行了大量的代码审查。 开发人员在其“生命周期”中并不总是对其代码负责，您对您的项目负责，并且各种各样的人可能会介入并使用您的代码来做事-这有其优点和缺点。 系统对我们来说运作良好，而且最重要的是，可以使人们参与其中-您在整个堆栈中工作，并且您可以进行自己的软件设计和测试。 而且，不，开发人员不会执行 UI 或图形设计，这种情况在很多年前在我们的网站上有了足够的 wtf 后就结束了。 “设计”是软件设计。 其他团队负责 UI /图形。 安迪 1）大概是数据库写操作从 R / W 数据中心复制到 R / O 数据中心（通过 Postgresql 9.0 复制？）如何处理复制滞后？ 例如，如果我提交了酒店评论，它将被写入 R / W 数据中心。 现在，如果我再次访问该酒店的页面，则可能会将我路由到 R / O 数据中心，由于复制滞后，该数据中心可能尚未接受新提交的评论。 在这种情况下，用户可能认为他的评论已丢失。 你如何处理？ 2）为什么每周都要重新生成 Lucene 索引？ 谢谢。 嗨安迪， 我们使用 Postgres8.x。 复制是通过一种较旧的查询复制方法（类似于 slony）完成的，多年来，我们已对其进行了升级（例如，通过批量查询以提高性能）。 活动数据中心将复制到另一个数据中心和我们的“本地”办公室数据中心。 有一个滞后-每个人可能要花几分钟才能赶上。 但是，数据中心处于 N + 1 配置-只有一个（R / W）正在获得流量。 另一个（R / O）处于活动状态并且可以传输流量，但是 DNS 仅指向活动的一个-因此，我们没有遇到您提到的问题，因为我们有两个数据中心用于可靠性，而不是规模。 我们研究了日志和/或流复制（我相信这就是 Postgres 9 所做的），但是它并不像我们想要的那样可靠-数据传输中的损坏会产生重大影响。 使用查询复制（并非如此）以及使用查询复制，我们还可以根据需要手动调整数据（我们需要做几次）。 我们在北京也有一个数据中心，该数据中心的延迟和连接性很差-考虑到它的情况，查询复制对我们来说效果更好。 Lucene 索引再生-我们发现，随着时间的推移，增量更新会导致索引碎片化和性能下降，因此我们每周进行一次完整重建，以使其保持“干净”。 另外，索引更改（无论是增量重建还是完全重建）都是在脱机状态下完成的，我们每天重新启动 lucene 以使用新索引-我们永远无法获得“实时”的工作。 我们经营一小堆的 Lucene 包裹式服务，因此没有停机时间。 很有可能有一种更好的方法可以做到这一点-我们尝试了许多方法，并且到目前为止，这种方法效果最好。 “每个服务都具有针对业务和/或使用模式进行了优化的 API-例如，获取成员的评论或位置的评论。大多数服务本质上都是数据库前面的大型智能缓存，对于 例如，局部 LRU，memcached，数据库调用在内存局部树/图形中； Jgroups 有时在需要时用于使高速缓存保持同步；大多数服务在不同的共享/物理计算机上运行 4 个实例，有时为服务实例分配自己的计算机。 ” 和： “ 40 台无状态服务银行，运行约 100 个实例的〜25 服务，Jetty / Java，每天处理 700M +个请求 在 6 对（DRDB）计算机上运行的 Postgres，每天处理 700M +次查询 “ 我有些困惑：服务进行大量缓存，但是每天的请求数似乎与数据库上每天的查询数相匹配。 我猜想也许对数据库的大量查询与这些服务无关？ 1.您最初是如何进行负载测试并选择 Tomcat 进行此类负载的？ 2.当前如何对整个堆栈进行负载测试？ 3.您具有哪些 CI 设置和单元测试？ 4.您是否使用 JMX 或其他方法监视应用程序事件？是否通过 HTTP 将日志事件传输到浏览器以监视批处理程序的进度。 Thanks. 嗨，您好， 非常感谢您的出色描述！ 来自 Web 公司，我很惊讶地将 Java 视为后端。 您对选择 Java 作为后端语言的满意程度如何？ 我真的很喜欢它，但是我很难抗拒更多“炒作”语言（如 Ruby，Python，Scala，JS 等）的诱惑。 我想成千上万的词，您会基于 Java 再做一次，为什么或为什么不呢？ > 您是否允许开发人员设计应用程序与最终用户交互的方式？ 您不知道开发人员很少设计良好的用户界面吗？ > 如果同一个开发人员还负责在其整个生命周期内支持其代码，那么您最终是否会陷入这种情况，即该开发人员/团队除了修复现有代码中的错误之外什么都不做，没有足够的时间来 在新项目上工作？ 通常，将向开发人员提供图形设计和产品营销团队的模型。 “这是它的外观”。 工程师的职责通常在发布后一周就结束，因为很明显没有与此相关的直接问题（尤其是性能问题）。 到那时，您便可以开始其他工作了。 哪一个确实可能是错误修复或其他人项目的功能增强。 期望所有工程师都可以使用任何代码库工作。 长期代码拥有权比我在其他地方看到的要少得多。 因此，开发人员最终会看到彼此足够多的代码，而这些代码最终不会因阅读或使用而异样。 安迪 感谢您的解释。 > >我们从未能够获得“实时”的工作。 您尝试了哪种类型的实时 Lucene 实现，但无法使其正常工作？ Lucene 2.9 添加了 NRT（近实时）。 您使用的是早期版本，还是 Lucene NRT 根本不适合您？ 很想在这里详细了解您的经历。 安迪，您提到您的运营团队包括两名技术工程师和两名现场工程师-当然，这不能成为整个团队吗？ 您能否提供更多有关团队规模及其组成的见解？ 谢谢你写的好。 罗伯 Andy. 那真是太棒了。 我的问题之一是，您是否在完全使用开源架构运行 4 9 的正常运行时间基础架构？ 以及如何确保应用程序响应时间达到目​​标。 另外，想知道如何监视基础架构？ 我将尝试回答尽可能多的问题： 丹： 服务调用和数据库调用的数目大致相同是巧合，并且数据库调用的数目更多是猜测（我们将 db 调用记录在 Java 代码中），但这是正确的。 我们的许多网页进行多个服务调用，而我们的许多服务进行多个数据库调用，但是每天大约有 1B +内存缓存调用保持了数据库的负载。 由于我们缓存对象而不是查询，因此许多对象可能代表几个数据库调用。 如果我们不使用 memcached，则可能一天会执行 2B +查询。 我一直发现有趣的是，将我们从不同来源收集的所有数字进行关联是多么困难。 Mohan： -当我们开始（11 年前）时，我们使用了标准的 Linux / Apache / Tomcat / Java / Postgres 堆栈。 那时我还没来得及，但我认为决策周围没有太多的结构化流程，我也不认为当时还有许多其他开源选项 -负载测试是一个有趣的领域。 我们有不同的测试工具和测试，测试实验室，有时我们使用辅助数据中心。 有时我们使用实时数据中心（例如，将 1/2 台 Web 服务器淘汰掉以查看会发生什么）。 负载测试是在我们认为需要的地方进行的，并且说实话，这是一门艺术。 我们了解到的一件事是，即使重放日志文件，也永远无法真正进行负载测试。 我坚信一切都会失败，并确保您有恢复的方法。 -不熟悉“ CI” -监视是通过 Nagios，Cacti 和许多自定义脚本来完成的，这些脚本分析我们的日志并显示数据。 我可以按 servlet，日期和小时向下钻取，以获得页面请求的总时间，cpu，数据库，服务调用数据（经过时间和调用次数）。 主持人： -我对 Java 非常满意，尤其是对于服务。 天哪，强大的线程和状态支持对于构建高性能服务至关重要。 我不确定如何实现可共享的进程内缓存以及如何使用其他语言处理线程。 我们的服务机每秒可以处理数千个请求，并且仍以 15％的负载运行。 如果我要再做一遍，我会考虑一些脚本语言用于前端工作（我们在该领域的一些实验并未显示出许多弊端的实际好处），但是对于服务器工作线程却能够保持 状态（共享内存）对于我们的用例至关重要。 steveo： 谢谢 SteveO :-) Andy： 我们尝试通过 api 逐步更新索引，但存在很多问题。 这是几年前的事，我不记得具体情况。 拥有 NRT 对我们来说很好，但并不关键。 Robbo：​​ 我们过去曾为两个数据中心配备一名技术运营工程师，但发现我们需要再增加一名：-) 我们有两个以上的空缺，因为我们计划扩大规模。 因此，我们有： 2 位数据中心和我们的开发环境（很多 xen 服务器）的技术运营（数据中心）人员 2 位负责软件基础架构的“站点运营”工程师。 发布工程由我们的网站运营工程师和各种技术经理（需要给他们做一些有趣的事情）完成。 来自各个团队的 10 多位工程师可以访问该网站并提供补丁程序帮助， 发行，软件开发，数据库，数据中心等。 对于我们的工作方式，重要的是，软件团队从字面上看要是真正的“游戏皮”。 “ Dan： 服务调用和数据库调用的数量大致相同是巧合，并且数据库调用的数量更多是猜测（我们将 db 调用记录在 Java 代码中），但这是正确的。许多 我们的网页中有多个服务调用，而我们的许多服务也有多个数据库调用，但每天大约有 1B +内存缓存调用保持了数据库的负载。由于我们缓存对象而非查询，因此许多对象可能代表 几个数据库调用。如果我们不使用 memcached，我们可能一天会进行 2B +查询。我一直发现有趣的是，将我们从不同来源收集的所有数字关联起来是多么困难。” 谢谢安迪。 同意，关联是建立对我们系统的理解的关键挑战。 实际上，我觉得这里总是会有一些近似值，因为数字是由具有不同上下文量的不同层产生的，这是我们用来将事物捆绑在一起的上下文。 即使是简单的东西，例如使用系统时钟来确定时间段内的顺序或相关数据的收集，也是有问题的。 另一个挑战是在不影响用户感知性能的情况下捕获信息。 一个人要么避免捕获数据，要么接受其中的某些数据可能丢失。 我倾向于默认使用后者，因为有些信息总比没有好。 大话题，值得啤酒讨论！ 最好， Dan. 克里希纳坎特： 我们使用多种监视技术，包括用于外部“第三方”监视的 Gomez 以及自定义脚本和工具。 我们的“ 4 9”并不是统一的衡量标准。 有一些功能对我们的业务很重要（基本站点的建立，商务和评论），这实际上是衡量标准的来源。我们的站点非常复杂，具有许多不同的内容类型和功能。 如果基本站点，商务和评论正在运行，则我认为该站点已“启动”。 更重要的是，我的老板也是如此：-)我不确定其他所有设备的正常运行时间，但是大概是 3 个 9。 关于开源与“商业”解决方案-事实是，它们都失败了。 永远不要相信任何组件，尤其是 SAN。 组件声称“完全可靠”的越多，由于最终信任它，您可能会遇到更多麻烦。 设计失败。 正常运行时间可以通过多种方式实现： 三个基本规则：简单性，围绕所有组件均发生故障的事实进行设计，并使软件工程师和管理人员始终承担起运营责任。 -我们让事情变得非常简单-商品硬件，以及软件的基础知识（Linus / Apache / Tomcat / Java / Postgres / Lucene / Memcached / jgroups）。 我们仅使用简单的系统/软件，我们了解它们的深入工作原理，经过实践证明，具有良好的运营支持，更重要的是，我们知道疣在哪里，因此我们可以对其进行管理。 -保持操作尽可能简单和可见（自动），但请确保您可以在任何步骤进行干预。 -我们的许多工程师都具有丰富的操作知识，可以随时待命，并可以为现场站点及其操作提供帮助。 我们的运维团队非常小，但“虚拟”运维团队非常庞大，其中包括许多经理。 团队中很少有工程师不会感觉到现场的“热度”。 -假设一切失败。 我们不仅对所有“关键”部分（路由器，负载平衡器，数据库和其他“关键”计算机）进行了加倍（N + 1 配置），而且还可以容忍多台计算机宕机的 Web 服务器和服务库。 而且，整个数据中心在 N + 1 配置中翻了一番。 这不仅为我们节省了一些时间（当 BigIP 出现两次故障时您将不胜感激，并且可以在 5-10 分钟的停机时间内解决这个问题），而且还使我们能够进行认真的机器/网络维护和安全性升级。 Hi Andy, 您的 3 层架构（web- >服务-> db）有多严格？ 是为了保持体系结构简单而实施的，还是为了某些本地的简化/可管理性而尝试减少某些地方的层？ 开发人员如何工作？ 在本地启动这 25 个服务中的一些服务，本地数据库并针对它们开发 Web 服务器？ 您说过要对服务进行负载平衡：Web 和服务层如何通信？ （http，RMI 甚至是 Corba？）为什么您决定支持硬件的软件负载平衡？ 感谢您分享所有这些！ Stefan 您好 Stefan， 好问题- 我们的三层体系结构未强制执行。 我们希望看到所有来自服务的数据库调用。 不幸的是，由于大多数是遗留原因，而且并非所有主要功能都在服务中，有时我们需要做的一些简单事情不值得将服务组合在一起，因此 Web 服务器确实会进行数据库调用。 当解决变得很重要时，那些“优先拥有项目”可能会被优先考虑。 但是，我们确实有所谓的“ DBR” db 读取数据库。 这些是只读数据库，每天更新一次，并且处于负载平衡配置（我认为我们有 3 个），因为我们已经将所有可写操作移到了服务上。 因此，服务获得了令状，大多数读取得到了，并且有些数据可以直接读取。 我们有一些常见的服务和数据库库，因此，如果您仅在 Web 层上工作，那么您所需要的只是前端。 如果您正在使用某项服务，则除了运行 Web 服务器或测试工具外，您所需要的只是运行自己的服务版本-您的个人 ini 文件可以访问并混合并与任何地方的服务匹配。 服务接口的更改需要向后兼容，因此效果很好。 如果您需要添加/更改表，则可以对共享数据库之一进行操作，因为这些更改还需要向后兼容。 很少有人需要运行自己的数据库服务器。 对于某些不向后兼容的模式更改的项目，还有其他整个流程可付诸实践，因为现在我们面临着巨大的实时站点部署挑战。 这偶尔发生。 服务是 XML / HTTP。 这样做的目的很简单，它使我们能够看到正在发生的事情，并轻松生成测试用例。 但是，恕我直言，一旦您有什么值得编码的地方，XML 就会像二进制格式一样流行。 因此，我们现在通过 xstream 进行序列化（那里有很多优点/缺点）。 服务调用是由 Java 接口定义的，我们有一个代理，它将接受方法调用，并根据配置设置将它们分配给服务器。 设置将重试逻辑确定为方法级别（等待时间长短，一台计算机上多少次退休，多少台计算机重试）。 负载平衡是通过生成 ini 文件设置来完成的-例如，给定的服务通常将映射到 4-8 台计算机，并且不同的 Web 服务器将具有不同的顺序。 如果其中一个不起作用，它将尝试下一个，并在一段时间后重置为原始配置。 有点笨拙（它是多年来开发的），存在一些问题，但是非常可靠，并且非常容易通过编辑其配置文件来调整计算机。 我们可以通过旋转一台新的服务机并调整一台 Web 服务器来轻松地在站点上测试服务的新代码。 对于本地开发，这也非常有用。 由于历史上的增量开发，我们选择了软件负载平衡方，但是我们的负载平衡需求非常复杂，有时需要以临时方式进行调整，需要开发人员进行修改以供本地使用，并且我们也希望能够 打开登录以提供正在发生的事情的详细信息。 我们已经讨论过将其移至负载均衡器的方法，但是我们不了解如何以数据驱动（ini 文件）的方式进行此操作，如何让每个开发人员都有自己的设置，或允许 Web 服务器调出 任何 HTTP 服务（例如，不在同一网络上）。 对于更改负载均衡器上的代码以及如何正确测试它，也存在极大的恐惧。 帖子不错，谢谢您的分享。 谢谢，安迪， 特别是您对负载均衡器的洞察力非常有趣。 我在一个非常相似的网站上工作，但是房地产和德语（仅德语），可能占您页面浏览量的十分之一，而且我们确实有硬件负载平衡器。 结果是，即使开发人员几乎不了解 devop，对于开发人员来说，这个主题也是一个（遥远的）黑匣子，并且是唯一的可操作事情。 此外，还有很多与“开发人员因为开发环境没有 Big IP 负载平衡器而无法正确测试”有关的问题，您可能可以避免这种情况。 我只能建议您坚持这个决定。 最佳 Stefan 设计审查实践似乎非常有趣。 我同意我们不需要“ powerpoint”架构师，但有些开发人员更有经验。 您如何避免没有大的自我冲突导致拼凑而成的设计？ Hi Andy, 您提到您的内容按内容类型（成员，媒体，评论等）分隔，那么您的 20 种语言呢？ 每种语言都有一个数据库吗？ 也就是说，每种内容类型都有 20 个数据库吗？ 还是每种内容类型只有一个数据库（包括所有语言）？ Best, 马蒂亚斯 嗨，Uberto， 您从事和/或领导的项目的类型取决于您对我们系统的经验和知识-这样，如果您是新手或刚离开学校，则可以拥有自己的小型项目，或者与他人一起工作 一个更大的项目的高级工程师。 随着学习，您将获得“更大”的项目。 我以与代码审查相同的方式看待设计审查-您之所以不要这样做，不是因为期望，而是因为您真正地感觉到它们是帮助您交付最佳代码的好方法。 我发现，比较成功的工程师是积极寻求代码和设计审查的工程师。 关于自我。 通过明确我们的工作方式，许多信息在面试过程中被过滤掉了-许多“非常高级”的工程师不想编写代码或进行测试，因此他们会转到其他公司。 我发现，当有人被迫在同行面前讨论他们的设计，并且他们需要进行自己的编码和测试时，设计往往会更简单，更实用和更清洁。 虽然要求人们回头重新考虑其设计的某些方面在某种程度上很普遍，但很少有真正的分歧。 我只能想一想我实际上必须介入并做出决定的地方-团队总是做出一个令我满意的决定（我可能会以相同的方式做）或我足够自在（也许不是） 我会做的方式，但效果很好，至少 imo :-)。 我认为这与两件事有关：一是每个人都真正想做正确的事，人们真正尊重彼此的意见，而我们拥有可借鉴的巨大广度和经验。 第二个是我们的“设计”专注于方法/操作，这使事情变得实用。 事实是，您可以使任何语言工作和扩展-Python，Perl，Java，PHP，甚至 Ruby :-)-我们关注的重点是内存使用情况，代码所在的位置（Web 服务器，服务，离线）， 数据已存储（数据库，文本文件，日志文件，内存），通过网络传输的内容，什么样的缓存（本地，本地 LRU，memcached 等），算法复杂性以及数据模式是什么。 我们很少涉及类和类结构或特定的代码。 而且，如果您想引进新技术，则需要同时做功课以及为什么不能使我们当前的技术适合您的用例。 是的，我们有时最终会在网站的不同部分出现“不同的设计”。 这并没有您想的那么糟糕，最后，我更喜欢为团队提供方法上的灵活性（在多年来已经确定的某些界限之内），尤其是考虑到团队需要真正感受到其工作的主人翁感。 此外，令人惊讶的是您从不同的方法中学到了什么。 嗨 Matlias， 内容不会按语言划分，但是会按语言和 POS 来源进行标记。 Hi Andy, 谢谢回答。 我明白了，当您说“避免联接”时，您是在谈论数据库之间的联接，不同内容类型之间的联接，但是显然每个内容类型数据库内部都有很多表（包含所有标记为 POS，语言等）。 也就是说，在不同数据库之间进行联接非常昂贵，如果它们位于不同的计算机上，联接成本甚至更高。 然后，由于使用的是 DRDB，因此可以在许多位置（也许是？）以多种语言提供内容，就像您所说的那样，它可以使您进行重复的热故障转移，同时可以减少对不同国家/地区的延迟，因为 您的服务器位置。 我对么？ Hi Andy, 关于内容，您是否实施了一些用于更改数据的捕获？ 你能评论一下吗？ 知道您如何处理具有成千上万个项目（酒店，评论等）的内容版本化将非常有趣。 Best, Matias 我认为允许进行一些不同的设计和代码复制是一个好主意。 否则，您将获得严格的标准，这将使您的应用程序/代码不再发展。 看到这发生在其他地方，这就是为什么我要说。 一旦规则变得比创造力，实时思考更重要，发展就不再与业务联系在一起。 此外，DRY 的难看面孔是强耦合。 国际海事组织的最佳选择总是介于极端之间。