将BBC在线迁移到云端

这是关于BBC Online如何利用云计算等方式改变的一系列帖子中的第一篇。要获得最新消息，请关注“BBC设计+工程”中的空白处--关注按钮位于页面底部。

在过去的几年里，我们英国广播公司的设计+工程团队已经完全重建了英国广播公司的网站。我们已经用一个为云设计和构建的新网站取代了我们数据中心托管的网站。为该网站提供动力的大多数工具和系统也已经转移。我们使用了现代的方法和技术，比如无服务器。我们已经更新了设计、方法和编辑工作流程，为未来做好了准备。几年来，已经有数百人参与其中。就快完成了。

这篇文章是关于什么、为什么，最重要的是如何创建一个为未来做好准备的新网站的方法的几篇文章中的第一篇。快速有效地提供高质量的技术变革。

英国广播公司的网站非常庞大。超过一半的英国人口每周都会使用它。全世界还有数千万人在使用它。它有44种不同语言的内容。它提供了200多种不同类型的页面-从节目和文章，到游戏和食物食谱。

就像科技的情况一样，如果你原地踏步，你就会倒退。直到最近，BBC的大部分网站都是用PHP编写的，托管在伦敦附近的两个数据中心。当它在2010年制造时，这是一个明智的技术选择；但现在不是了。

BBC的网站由几个服务组成(如iPlayer、声音、新闻和体育)。对于他们所有人来说，我们需要确保他们使用最新和最好的技术。这是确保他们在所做的事情上做到最好的唯一方法。它们都需要在规模上非常可靠，而且速度快，设计良好，并且所有人都可以访问。

因此，在过去的几年里，我们的战略是重建BBC在线。几乎每个部件都已在云上重建。我们充分利用了云带来的诸多优势，例如几乎可以立即灵活地调配新服务。我们还使用了最佳实践工具和技术，例如Reaction框架和DevOps模型。我们稍后将更多地了解该方法，但首先，让我们讨论一下基本原则。

重建一个庞大的网站很容易受到第二个系统效应的影响。新项目很容易在需求和方法上过于雄心勃勃。追求完美使得人们很容易选择最复杂的解决方案，而不是最简单的解决方案。我们需要防止这种情况的发生，以确保物有所值、按部就班地交付。以下是帮助我们做到这一点的一些原则。

当构建像BBC Online这样大的东西时，可能会诱人地从头开始考虑所有事情。这样做提供了最大的控制力，并且千方百计。但这样做的成本可能是巨大的。现成的解决方案可能只给您想要的90%，但如果它可以在10%的时间内交付，这可能是一个值得的权衡。这适用于技术、用户体验、商业分析，以及几乎所有其他领域。大多数问题已经在别处解决了，所以不要再解决了。

这方面的一个很好的技术例子是使用无服务器。英国广播公司大约一半的网站是通过AWS Lambda无服务器呈现的。管理虚拟机(或容器)成本高昂-保持它们的安全性、可靠性和可扩展性需要时间。无服务器主要为我们解决了这个问题。其他地方解决的问题意味着我们不应该自己做。

当团队很多时，重复是不可避免的。两个团队将各自遇到相同的问题，并创建自己的解决方案。在某些方面这是好的-团队应该被授权拥有并解决他们的挑战。但如果不加以检查，它可能会创建多个不兼容且维护成本高昂的解决方案。

随着我们重建BBC在线，我们消除了多年来积累的大量重复和差异。多个定制系统已被一个通用系统取代。这是一个双赢，因为除了更高效(更便宜)之外，我们还可以专注于使新的单一方法比多个旧方法更好。正因为如此，BBC网站现在的性能和可访问性比以往任何时候都要好。

然而，我们必须警惕过于简单化。从业务角度来看，用一个系统替换多个系统看起来很棒。但软件复杂性呈指数增长：每一项新功能的成本都比前一项更高。到了一个点，两个简单的系统比一个复杂的系统要好。

例如，我们选择将BBC的世界服务站点与主要的英语BBC站点分开。世界服务的需求(如在恶劣的网络条件下正常工作)是足够专业的，足以保证单独的解决方案。在这种情况下，两个更简单的网站比一个复杂的网站要好。

创建一个新的BBC网站涉及到许多团队。为了取得成功，我们比以往任何时候都更需要这些团队的联合和协作。否则，我们可以很容易地创造出比各部分之和还小的东西。

沟通的价值怎么夸大都不为过。没有它，团队就不能理解他们的工作如何与其他团队的工作相适应。如果没有这种理解，他们就看不到分享和结盟的机会。团队甚至可能开始相互不信任。

交流带来理解，这使得文化得以改变。团队不是孤立地做自己的事情，而是自然地共享、协作和灵活地满足彼此的需求。他们超越了严格意义上的团队职权范围，知道其他人也会这样做。这最终为每个人提供了更好的解决方案。

近几个月来，我经常听到团队说‘那个团队很忙，我们正在帮助他们摆脱困境’，或者‘我们正在让我们的技术选择与其他团队保持一致’。这是我以前从未见过的协作水平。通过了解更大的图景，以及每个人如何扮演自己的角色，我们创造了一种信任和结盟的水平，这是一种令人欣喜的看到。

即使有很好的文化和沟通，多个团队也不一定会走到一起来构建正确的东西。当然，这就是被广泛引用的康威定律。

“设计系统的组织[…]。被限制为生产这些组织的通信结构的副本的设计。“。

英国广播公司历来有不同的网站--新闻、体育等。每个人都有一个独立的团队。要改变这一点，建立一个网站，我们需要重组。但怎么做呢？一个庞大的团队是行不通的，所以我们把团队分成最有效的方法。我们为每个页面的“类型”创建了团队-主页、文章页面、视频页面等等。我们还创建了团队来处理常见的问题，比如网站是如何开发和托管的。总而言之，它最大限度地减少了重叠和重复，并允许每个团队拥有并成为各自领域的专家。

在设计大型软件系统时，我们需要找到一个微妙的平衡点。我们必须规划未来，这样我们既能满足今天的需要，也能满足明天的需要。但我们也不想过度设计。我们不能肯定未来会带来什么。要求将会更改。云提供商将提供新技术。世界--尤其是科技世界--的变化速度比以往任何时候都要快。

好的分析、规划和软件设计是不可替代的。研究可用的机会和选择是确保项目朝着正确方向开始的关键。但我们必须抵制过度思考解决方案的危险，因为这可能是为了一个永远不会到来的未来。

敏捷软件开发的美妙之处在于，我们可以在前进的过程中发现并适应挑战。业务计划和体系结构也需要根据我们在项目发展过程中所学到的知识进行发展。不要解决问题，除非你确定它们是你实际存在的问题。

在上述基础上扩展，我们必须注意不要太快优化。大型软件项目在某些时候不可避免地会遇到性能问题。很难预测这些问题将在何时以及如何出现。所以，不要这么做。只有当性能问题成为现实时，才能利用敏捷开发的好处来应对这些问题。

如上所述，很多BBC网站现在都使用AWS Lambda进行无服务器渲染。在项目开始时，我们怀疑Lambda能够以多快的速度大规模呈现网页。我们计划了另一种方法。但最终，我们并不需要它。使用无服务器的性能一直非常出色。由于没有过早优化，我们节省了大量的精力。

“人们总是发现，一个运行良好的复杂系统是从一个运行良好的简单系统演变而来的。一个从零开始设计的复杂系统永远不会工作，也不能通过修补来使其工作。你必须从一个简单有效的系统开始。“。

从现有系统中去除复杂性是很困难的。在我们的例子中，我们有多个想要合并的复杂网站。这些站点的集体需求会使任何一个系统不堪重负。因此，我们不得不重新开始，回到需要哪些共同能力的基础上。

最后，一个非常实用的原则：确保你能够快速移动，这样你就可以学习和适应。提前发布，并且经常发布-即使它只面向一小部分观众。正如前面所讨论的，预测未来是出了名的困难。了解未来的最好方式是更快地到达那里。

与此相反的论点是，变化会带来风险。对于像BBC Online这样广受欢迎的服务，可靠性至关重要。BBC一直有一个强大的运营流程(包括全天候管理服务的团队，以及确保系统开发人员也负责维护服务的DevOps方法)。我们继续在这一领域进行投资，新的团队专注于基础设施和开发人员体验(DevX)。我们将在未来的博客文章中详细介绍。

将上述原则付诸实践，下面是BBC网站如何运作的超高概述。

首先，前往www.bbc.co.uk或www.bbc.com的所有流量都会到达全球流量管理器(GTM)。这是一个基于Nginx的内部交通管理解决方案。它每秒处理数以万计的请求。由于其规模和提供极低延迟的需要，它部分位于我们自己的数据中心，部分位于AWS。

对于我们站点的某些部分，有时会使用第二个流量管理层。(在内部，这些被称为莫扎特和贝尔弗拉格)。这些服务托管在AWS EC2上，每秒处理约2,000个请求。它们提供缓存、路由和负载平衡。它们还通过发现错误、“服务过时”和后退以允许底层系统从故障中恢复，在保持站点弹性方面发挥了关键作用。

BBC的绝大多数网页都是使用REACT在AWS上呈现的。Reaction的同构特性允许我们在服务器端呈现页面(以获得最佳性能)，然后在客户端进行一些进一步的更新。

越来越多的渲染发生在AWS Lambda上。大约有2000个Lambdas每秒运行来创建BBC网站；我们预计这个数字还会增加。如前所述，无服务器消除了运营和维护成本。而且它的伸缩速度要快得多。当有突发新闻事件时，我们的流量水平可能会瞬间飙升；Lambda可以以EC2自动伸缩无法处理的方式处理这一问题。

一个名为WebCore的新内部项目为创建BBC网站提供了一种新的标准方式。它是围绕通用功能构建的(例如一篇文章、一个主页和一个视频页面)。它是作为Monorepo创建的，目的是最大限度地增加共享的机会，并使升级(例如升级到Reaction版本)变得更容易。通过专注于创建一个站点，而不是创建多个站点，我们看到性能、可靠性和SEO都有了显著的提高。

正如前面所讨论的，我们将我们的世界服务网站作为一个单独的实现来保留，这样它就可以专注于满足全球不同受众的挑战。(这个名为Simorgh的项目是开源的，可以在GitHub上获得。)。我们的iPlayer和Sound网站也是分开的，尽管仍有相当数量的共享(例如，在网络、搜索和底层数据存储等领域)。

渲染层只关注表示。获取和理解内容的逻辑最好放在“业务层”中。它的工作是向网站渲染层提供(RESTful)API，其中包含创建页面所需的正确内容。BBC的应用程序也使用此API，以获得相同的好处。

BBC有各种各样的内容类型(比如节目、Bitesize修订指南、天气预报等等)。每一个都有不同的数据，需要自己的业务逻辑。为每种内容类型创建数十个独立的系统是昂贵的。它们不仅需要正确的逻辑，而且还需要可靠、大规模和安全地运行。

因此，我们战略的一个关键部分是简化创建业务层的过程。称为快速不可知业务层(Fast Anostic Business Layer，FABL)的内部系统允许不同的团队创建自己的业务逻辑，而无需担心大规模运营的挑战。访问控制、监控、缩放和缓存等问题以单一的标准方式处理。按照我们的原则，我们要确保不会把同一个问题解决两次。

最后两层提供广泛的服务和工具，允许创建、控制、存储和处理内容。谈论这个领域超出了这篇文章的范围。但原则是一样的：这些服务正在从数据中心转移到云端，同时解决差异和重复问题，并确保它们处于随着BBC Online增长而发展的最佳位置。

因此，BBC Online现在(几乎)完全是在云端。因此，它更快、更好、更可靠。我们已经讨论了如何实现这一改变的关键原则。我们已经看到了所用技术的摘要。有关这一点的更多信息，请参见稍后的帖子。

最令人兴奋的是，这不是结束，只是新事物的开始。科技和文化确保我们处在一个辉煌的位置，让BBC在线变得最好。这就是我们要做的。

我为我们所取得的一切感到无比自豪--对参与其中的每一个人，谢谢你们。

我们将在接下来的几周里深入研究细节-如果需要通知，请订阅这个“BBC设计+工程”媒体频道。