关于我们 | 联系我们

亚搏手机版app下载-登录入口

荣誉资质
当前位置:主页 > 荣誉资质 >

全球最大新闻媒体BBC在线的云迁移实践

本文摘要:在已往几年,BBC 的设计和工程团队彻底重建了 BBC 网站,将一个托管在数据中心里的网站酿成一个基于云设计和构建的新站点。同时,为网站提供支持的大多数工具和系统也都迁移到云端。 我们不仅使用了现代化的方法和技术,好比无服务器架构,而且刷新了设计、方法和编辑事情流程,为未来做好了准备。已往一年在云端重新建立的一些页面示例配景先容BBC 是个大型的网站,凌驾一半的英国人每周都在使用它,在全世界另有成千上万人也在使用它。

亚博手机版app下载

在已往几年,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 ConwayBBC 向来都是由单独的站点组成的——新闻站点、体育站点,等等。每个站点都有一个单独的团队卖力。为了改变这种状况,建设一个大网站,我们需要举行重组。

但该如何做?一支庞大的团队是行不通的,所以我们根据最有效的方式对团队举行拆分。我们凭据页面“类型”来组建团队——主页、文章页、视频页,等等。

我们还组建了处置惩罚常见问题(好比如何开发和托管站点)的团队。总而言之,它将尽可能地淘汰重叠和重复,并允许每个团队在各自领域拥有或成为专家。

计划未来,着眼当下在设计大型的软件系统时,我们需要找到微妙的平衡。我们必须为未来作好计划,既要满足当下的需求,也要满足未来的需求,但我们又不想过分设计。我们不能确定未来会怎样,需求会发生改变,云供应商的技术也会推陈出新。

世界——尤其是科技领域——的变化速度比以往任何时候都要快。好的分析、计划和设计是不行替代的,研究可供选择的时机是确保项目沿着正确偏向行进的关键。

但我们要注意不要对解决方案举行过分思考,因为那可能是一个无法触及的未来。敏捷软件开发的美妙之处在于,我们可以在开发历程中发现并适应挑战。业务计划和架构也需要基于我们在项目演化历程中所学到的工具而不停演化。在确定某些问题确实是需要解决的问题时再去解决它们。

先构建,后优化我们要小心不要过早地举行优化。大型软件项目在某些时候将不行制止地遇到性能问题,预测这些问题何时以及如何泛起是很难题的事情。所以,不要去预测。

只有当性能问题真正泛起时,再使用敏捷开发方法来解决它们。正如上面所提到的,现在 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 变得更好,而这就是我们要做的。原文链接:https://www.bbc.co.uk/blogs/internet/entries/8673fe2a-e876-45fc-9a5f-203c049c9f9c延伸阅读:Microsoft 云接纳框架,助力企业快速完成云迁移-InfoQ关注我并转发此篇文章,私信我“领取资料”,即可免费获得InfoQ价值4999元迷你书,点击文末「相识更多」,即可移步InfoQ官网,获取最新资讯~。


本文关键词:全球,亚博手机版app下载,最大,新闻媒体,BBC,在线,的,云,迁移,实践

本文来源:亚博手机版app下载-www.qzsthg.cn

Copyright © 2000-2022 www.qzsthg.cn. 亚博手机版app下载科技 版权所有 备案号:ICP备26557748号-1