BBC在线云迁移成功的8个原则
作者 | Matthew Clark
译者 | 王者
策划 | 万佳
在过去几年，BBC 的设计和工程团队彻底重建了 BBC 网站，将一个托管在数据中心里的网站变成一个基于云设计和构建的新站点。同时，为网站提供支持的大多数工具和系统也都迁移到云端。我们不仅使用了现代化的方法和技术，比如无服务器架构，而且刷新了设计、方法和编辑工作流程，为未来做好了准备。
过去一年在云端重新创建的一些页面示例
BBC 是个大型的网站，超过一半的英国人每周都在使用它，在全世界还有成千上万人也在使用它。它提供 44 种不同语言的内容，超过 200 种不同类型的页面——从节目、文章到游戏和食谱。
就像科技的发展一样，停滞不前就是倒退。BBC 网站的大部分内容都是用 PHP 开发的，并且托管在伦敦附近的两个数据中心里。在 2010 年，这样的技术决策算得上是一个明智的选择，但放到现在来看就不是了。
BBC 的网站由多种服务组成 (如 iPlayer、Sounds、News 和 Sport)，我们要确保它们都使用了最新最好的技术。它们要非常可靠，还要速度快，并具有良好的可访问性。
所以，在过去的几年里，这些就成了我们重建 BBC 网站的策略，几乎每个部分都被迁移到了云端。我们已经充分利用了云平台带来的诸多好处——例如配置新服务的灵活性。我们使用了具有最佳实践的工具和技术——比如 React 框架和 DevOps 模型。
重建一个大型网站很容易受“第二系统效应”（出自《人月神话》）的影响。对于新项目来说，在需求和所采用的方法方面很容易变得太过激进。对完美的追求使得人们倾向于选择最复杂的解决方案，而不是最简单的。我们需要防止出现这种情况，以确保能够获得良好的价值和交付速度。下面是我们的一些指导原则。
在重建像 BBC 这样的大网站时，人们可能会忍不住从零开始考虑一切。这样做可以最大程度地控制局面，但成本巨大。一个现成的解决方案可能只能给你 90% 的你想要的，但如果能在 10% 的时间内交付，那么这个权衡就是值得的。这适用于技术、用户体验、业务分析以及其他很多方面。大多数问题已经在其他地方解决过了，所以不需要再重复解决它们了。
采用无服务器架构就是一个很好的技术方面的例子。大约一半的 BBC 网站内容都是通过 AWS Lambda 渲染的。管理虚拟机 (或容器) 成本高昂——要保证它们的安全性、可靠性和可伸缩性非常耗费时间。无服务器架构已经为我们解决了这些问题，所以我们不需要自己做这些工作。
当有多个团队时，出现重复是不可避免的。多个团队将会遇到相同的问题，并提出自己的解决方案。从某些方面来看，这是好事——团队应该被赋予拥有和解决挑战的权力，但如果不加以审视，可能会出现多个不兼容且维护成本很高的解决方案。
在重建 BBC 网站的过程中，我们移除了多年来积累起来的大量重复和差异内容。多个定制系统被替换成一个通用的系统。这是一种一石二鸟的好处，因为除了提升效率 (成本更低)，还让我们可以专注于为单个系统提供更好的解决方案。正因为如此，BBC 网站现在的性能和可访问性比以往任何时候都要好。
不过，我们也要警惕太过于简单化。从业务的角度来看，用一个系统代替多个系统看起来很好，但软件的复杂性却呈指数级增长：每个新功能的开发成本都比之前更高。从某种程度上说，两个简单的系统比一个复杂的系统更好。
例如，我们将 BBC 的全球服务站点与英文站点分开。全球服务的需求 (比如在恶劣的网络条件下仍能正常工作) 要求更高，需要一个单独的解决方案。在这种情况下，两个简单的网站比一个复杂的网站要好。
英文网站 (左) 和世界服务网站 (右) 的渲染是分开的，避免单个解决方案过于复杂
重建一个新的 BBC 网站需要很多团队的参与。要想取得成功，我们需要这些团队比以往任何时候都更具协作精神。否则，我们很容易就会得到一个小于其各部分之和的东西。
无论怎样，沟通的价值都是不可磨灭的。没有它，团队就无法理解他们的工作与其他团队是如何协调的。缺少了这种理解，他们就看不到分享的可能性，甚至可能开始不信任彼此。
交流带来了理解，而理解能让文化发生变化。团队不再孤立地做自己的事情，而是自然地分享、协作，并灵活地满足彼此的需求。他们超越了严格意义上的团队职责范围，并且知道其他人也会这样做，这最终会为每个人带来更好的解决方案。
最近几个月，我听到一些人说“其他团队很忙，所以我们要帮助他们”或者“我们要让我们的技术决策与其他团队保持一致”。这种高水平的协作是我以前没见过的。通过理解大局以及每个人如何发挥各自的作用，我们创造了一种信任和保持一致的文化，这正是我们希望看到的局面。
这个“洋葱图”解释了如何一次性解决公共关注点和能力问题（在中间部分）。让团队可以更专注于外环的专业性工作。
即使有了良好的文化和沟通，多个团队在一起也不一定会做出更好的东西，这就是经常被提到的康威定律。
“负责设计系统的组织，它们所产出的设计就是组织沟通结构的副本。”——Melvin Conway
BBC 历来都是由单独的站点组成的——新闻站点、体育站点，等等。每个站点都有一个单独的团队负责。为了改变这种状况，建立一个大网站，我们需要进行重组。但该如何做？一支庞大的团队是行不通的，所以我们按照最有效的方式对团队进行拆分。我们根据页面“类型”来组建团队——主页、文章页、视频页，等等。我们还组建了处理常见问题（比如如何开发和托管站点）的团队。总而言之，它将尽可能地减少重叠和重复，并允许每个团队在各自领域拥有或成为专家。
在设计大型的软件系统时，我们需要找到微妙的平衡。我们必须为未来作好计划，既要满足当下的需求，也要满足未来的需求，但我们又不想过度设计。我们不能确定未来会怎样，需求会发生改变，云供应商的技术也会推陈出新。世界——尤其是科技领域——的变化速度比以往任何时候都要快。
好的分析、计划和设计是不可替代的，研究可供选择的机会是确保项目沿着正确方向行进的关键。但我们要注意不要对解决方案进行过度思考，因为那可能是一个无法触及的未来。
敏捷软件开发的美妙之处在于，我们可以在开发过程中发现并适应挑战。业务计划和架构也需要基于我们在项目演化过程中所学到的东西而不断演化。在确定某些问题确实是需要解决的问题时再去解决它们。
我们要小心不要过早地进行优化。大型软件项目在某些时候将不可避免地遇到性能问题，预测这些问题何时以及如何出现是很困难的事情。所以，不要去预测。只有当性能问题真正出现时，再利用敏捷开发方法来解决它们。
正如上面所提到的，现在 BBC 的很多站点都在使用 AWS Lambda 进行无服务器渲染。在项目开始的时候，我们怀疑 Lambda 大规模渲染网页的速度究竟有多快，所以还计划了另一个方案。但最终，我们发现根本不需要这个备选方案，无服务器的渲染性能非常出色。由于没有过早地进行优化，我们节省了大量的精力。
这就是加尔定律（Gall's Law）：
一个可用的复杂系统总是由一个可用的简单系统进化而来的。一个从零开始设计的复杂系统永远不可用，也不能通过修补来让它变得可用。你必须从简单的系统重新开始。”——Joh Gall
从现有系统中消除复杂性是很困难的。我们本来想要合并多个复杂的站点，但这些站点的合并需求超出了任何一个单个系统的承受能力。所以，我们必须重新开始，回到最基本的共同需求点。
我们为 WebCore 项目做的月度状态报告片段
一个非常实用的原则：确保你能够快速行动，这样才能总结经验并适应新的情况。尽早发布，并且经常发布——即使只是针对一小部分用户。正如前面所讨论的，预测未来是出了名的困难，了解未来的最好办法是以最快的速度到达那里。
与此相反的一个观点是，变化会带来风险。对于像 BBC 这样受欢迎的网站来说，可靠性是至关重要的。BBC 一直有一个强大的运营流程 (包括 24/7 的团队管理服务和 DevOps 实践)。我们继续在这个领域投入，我们组建新的团队专注于基础设施和开发者体验 (DevX)。
更频繁地发布更小的版本，也是最小化风险的好办法。
把上述原则付诸实践，下面是改造 BBC 网站的一个技术概览。
首先，访问 www.bbc.co.uk 或 www.bbc.com 的所有流量都到达全局流量管理器 (Global Traffic Manager)。这是一个基于 Nginx 的内部流量管理解决方案，每秒可以处理数万个请求。由于规模和对极低延迟的要求，它有一部分位于我们自己的数据中心中，一部分位于 AWS 上。
对于站点的某些部分，有时候会使用第二个流量管理层。(在内部，它们被称为 Mozart 和 Belfrage)。这些服务托管在 AWS EC2 上，每秒处理大约 10000 个请求。它们提供了缓存、路由和负载均衡能力，并通过错误发现和回退让底层系统能够从故障中恢复，在保持站点弹性方面发挥了关键作用。
BBC 的绝大多数网页都是通过 React 在 AWS 上渲染的。因为 React 的同构性，我们可以在服务器端渲染页面 (以便获得最佳性能)，然后在客户端进一步做一些更新操作。
越来越多的渲染发生在 AWS Lambda 上，大约每秒钟有 2000 次 Lambda 调用，用于创建 BBC 页面，我们预计这个数字还会增长。如前所述，无服务器降低了运维成本，而且伸缩速度非常快。当出现突发新闻事件时，我们的流量水平会瞬间飙升，Lambda 可以以 EC2 自动伸缩做不到的方式来处理这个问题。
内部的一个叫作 WebCore 的新项目为创建 BBC 网站提供了一种新的标准方式，它提供了一些公共能力 (比如文章、主页和视频页) 构建的。它是一个单体代码库，最大化提供共享内容的可能性，并让升级 (例如 React 版本) 变得更容易。我们专注于创建一个站点，而不是多个，因此在性能、可靠性和 SEO 方面获得显著的改进。
比较旧页面 (左) 和新版本页面 (右)，上面的数字是 Lighthouse 的性能评分。
正如前面所说的，我们将全球服务站点作为一个单独的实现，让它能够专注于满足来自世界各地不同用户的需求。(这个项目叫作 Simorgh，是开源的，可以在 GitHub 上找到。) 我们的 iPlayer 和 Sounds 站点也是分开的，虽然仍然存在大量的共享内容 (例如在网络、搜索和底层数据存储等方面)。
渲染层只负责呈现，业务逻辑更适合放在“业务层”。它的职责是向网站渲染层提供 (REST) API，其中包含创建页面所需的内容。BBC 的应用程序也使用了这个 API，从中获得同样的好处。
BBC 有各种各样的内容类型 (比如节目、Bitesize 修订指南、天气预报等)。每个数据库都有不同的数据和自己的业务逻辑。为每种内容类型创建一个独立的系统成本太高了。它们不仅要求逻辑正确，还需要能够可靠、安全地运行。
因此，策略中最关键的部分是简化创建业务层的过程。我们有一个叫作快速无关性业务层 (Fast Agnostic Business Layer) 的内部系统，不同的团队可以创建属于自己的业务逻辑，而不需要操心大规模运维问题。访问控制、监控、伸缩和缓存等问题都通过标准的方式来处理。根据我们的原则，我们会确保不会重复解决同一个问题。
最后两个层提供了广泛的服务和工具，可以创建、控制、存储和处理网站内容。这方面的内容超出了这篇文章的范围，但原则是一样的：这些服务从数据中心转向云端、解决差异、去重，确保它们处于最有利的位置，能够随着 BBC 的演化而演化。
BBC 现在 (几乎) 完全迁移到了云端，变得更快、更好、更可靠。我们已经总结了一些关键原则，介绍了所使用的技术。最令人感到兴奋的是，这并不是结局，而是新的开端。技术和文化保证了我们能够让 BBC 变得更好，而这就是我们要做的。
相关内容
微信扫码咨询专知VIP会员