BBC Online转向AWS，无服务器

在接下来的几周里，BBC在线将发布一系列关于如何利用云计算等方式进行变革的帖子，本文是其中的第一篇。

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

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

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

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

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

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

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

在创建像BBC Online这样大的网站时，从零开始考虑一切可能很有诱惑力。这样做提供了最大的控制力，而且千方百计。但这样做的代价可能是巨大的。现成的解决方案可能只给你想要的90%，但如果能在10%的时间内交付，这可能是一个值得的权衡。这适用于科技、用户体验、商业分析，以及几乎所有其他领域。大多数问题已经在别处解决了，所以不要再解决了。

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

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

随着我们重建BBC在线，我们消除了多年来积累的大量重复和差异。多个定制系统已被一个通用系统取代。这是一个双赢，因为除了更高效(更便宜)之外，我们还可以专注于让新的单一方法比多个旧方法更好。正因为如此，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上，每秒处理约10,000个请求。它们提供缓存、路由和负载平衡。它们还在保持网站弹性方面发挥了关键作用，它们可以发现错误，“服务过时”，并后退以允许底层系统从故障中恢复。

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

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

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

找出不同之处：将旧页面(左)与基于云的新版本(右)进行比较。这些数字是灯塔表演得分。

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

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

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

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

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

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

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

我为我们所取得的一切感到非常自豪--对所有参与其中的人，谢谢你们。