关于javascript:最佳实践|亚马逊可持续发展的架构模型

32次阅读

共计 6134 个字符,预计需要花费 16 分钟才能阅读完成。

在过来的十年外面,亚马逊云科技始终都致力于帮忙企业和开发者实现数字化转型,包含如何应用云技术帮忙企业进步经营中资源利用率;如何通过云基础架构、容器、DevOps 进行业务的翻新和敏捷性;将来的十年,亚马逊云科技将帮忙开发者和企业开始新的可继续倒退转型。让开发者能够应用雷同的工具更专一于可持续性工作,并通过最佳实际和整体基础架构,帮忙你应答在可继续倒退转型过程中的新挑战。

亚马逊云科技开发者社区为开发者们提供寰球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、流动与比赛等。帮忙中国开发者对接世界最前沿技术,观点,和我的项目,并将中国优良开发者或技术举荐给寰球云社区。如果你还没有关注 / 珍藏,看到这里请肯定不要匆匆划过,点这里让它成为你的技术宝库!

在致力于云自身的可持续性倒退转型的同时,咱们将实际和教训做出了总结,并设计了无效的工具和服务提供给开发者。

作为云上的可持续性倒退指标,咱们认为有两方面的工作是十分重要的:

第一,要继续升高工作负载的能耗。第二,要一直进步工作负载组件之间的工作效率。

基于以上两个指标,咱们总结了六个方面的最佳实际,帮忙开发者构建云上可继续倒退的架构模型,包含:区域的抉择、正确应用云资源、软件的架构、数据应用、硬件的抉择以及开发部署

亚马逊可持续性倒退的最佳实际

抉择适合的区域来部署你的工作负载

亚马逊云科技的区域

亚马逊云科技在寰球提供了 30 多个区域以及 99 个可用区。咱们的构建者能够依据业务需要来抉择不同可用区的资源,包含网络提早,数据合规要求等等。而可持续性倒退,也就是节能减排的指标也应该在抉择适合的可用区时纳入考量。

亚马逊云科技别离在北美洲、欧洲、中东和非洲、以及亚太区域通过 310 个可再生能源我的项目,实现了共计 15.7 千兆瓦可再生能耗。不同的区域针对不同的可再生能源我的项目,失去的能耗节俭略有不同。其中 32 个亚太地区的可再生能源我的项目包含中国山东和吉林的两个可再生能源我的项目。山东我的项目是 100 兆瓦 (MW) 的太阳能我的项目,目前曾经投入经营,每年可产生 12.8 万兆瓦时 (MWh) 的清洁能源。吉林我的项目是亚马逊在中国反对的第二个可再生能源我的项目,是 100 兆瓦 (MW) 的风能我的项目。该我的项目也将很快投入经营,届时每年可提供超过 30 万兆瓦时(MWh)的可再生能源,相当于为超过 15 万户中国普通家庭提供电力反对。

咱们倡议的最佳做法是抉择凑近这些可再生能源我的项目的区域,利用亚马逊现有的成绩实现第一步的节能减排。

正确应用云资源

咱们的第二个倡议是 正确应用云资源。

这一点十分重要。和自建数据中心不同,云上的资源按需付费。少数企业,并没有将企业外部数据中心的建设老本均匀到具体业务所占用的服务老本,因而依照自建数据中心的形式生产云资源,对于单个利用来说,云上资源耗费没有特地显著的劣势。因而建设新的应用习惯,标准云资源的应用形式,特地是退出制订明确的可继续倒退指标,将其与 SLA 相平衡为前提来设计利用的交付形式,比方:按需扩张、打消闲置资源、依据所在地理位置油画工作负载的天文布局、以及依据可继续倒退指标,优化云上资源的应用行为。通过标准云上资源应用行为,能够帮忙开发者进一步实现麻利、高效、自动化,同时放慢实现可继续倒退转型。

通过具体案例来看一下,什么是正确的云资源应用形式:

咱们把某个具体的服务运行在两个可用区,通过实现从一个可用区到另一个可用区的实时故障切换,来取得高可用性。不言而喻,这个服务在每个可用区都须要预留与理论工作负载相匹配有闲暇资源。因而每个可用区的理论工作负载的能耗要限度在整体资源的 50% 以内。

然而,如果咱们通过三个可用区实现这个服务的高可用性。那么咱们在每个可用区只有预留总资源的 2/3 就能够满足实时的故障切换。因而咱们能够看到,对于实时故障切换的高可用要求,三个可用区的抉择,资源均匀利用率更高,老本更低,故障的影响最小。

很简略,这就是云上资源的正确应用形式之一。

还有一个案例也很乏味,这是一个均衡 SLA 和可继续倒退指标的案例:

针对非实时的故障切换业务,它们重要的考量因素是老本,用故障切换期待的工夫来换取尽可能大的资源节俭。

对于非实时故障切换的业务需要,咱们能够通过优化故障切换的时长来实现可继续倒退的指标。具体的形式是抉择“冷容量”作为故障切换时服务资源的。

当须要故障切换的时候,咱们在可用区外面寻找或者期待闲暇的资源,再去做故障切换。尽管咱们在切换的过程中就义了响应的工夫,然而咱们大幅度的缩小了资源闲置所造成的节约和能耗,从运行老本上实现可继续倒退的指标。

其实如何正确的应用云上资源来实现可持续性倒退的指标,最大的考量点是均衡不同业务的 SLA 和整体业务的可继续倒退指标。在均衡工作负载的部署、业务部署、架构部署时做出正确的抉择,这就是咱们的最佳实际。

优化软件与架构

咱们能够通过扭转软件和架构来缩小资源耗费和产生的影响。包含:异步和调度、应用高能效的编程语言、移除或重构使用率低甚至是无用的负载组件、低代码化、优化开发者的终端设备产生的影响,应用匹配的数据拜访和存储模式的软件以及架构。

通过性能调度,缩小因为“峰值”所产生的能耗

图中展现了一个服务在它业务生命周期中的性能曲线。三条基准线别离示意:

  • 均匀能耗的耗费线 (Average)
  • 业务峰值的能耗 (Peak)
  • 业务运行所须要的资源 (Provisioned Capacity)

咱们发现:服务应用的理论资源和能耗并不是均匀能耗曲线下的面积,而是配置容量线下的面积。值得注意的是配置容量的大小取决于该利用的能耗峰值。通常状况下,基于高可用的考量,配置容量是能耗峰值的两倍。

如果,咱们通过就义肯定的 SLA 来低峰值,或者咱们调整业务运行的形式,以整个业务周期来均匀工作负载,再或者咱们通过施行了一个队列来平滑负载。

如下图所示:

那么咱们就能均衡能耗从峰值到均匀的更好比例,就能升高能耗峰值,就能调低配置的容量。从而实现更少的资源占用,更少的能源消耗。

举个例子:

大多数企业都应用零碎默认的工夫运行 Crontab。这是一个通用的服务。试想云上所有企业的所有 Crontab 都在深夜 3 点被触发。那么 Crontab 在这一时间点上产生的能耗峰值就会推高他们所需云上资源的总容量。从可持续性倒退的指标登程,这是能够被优化的。事实上,对于 Crontab 这样的服务,非实时的需要响应,不会对业务自身造成影响。因而能够通过事件驱动的架构和技术来平滑服务需要的峰值。具体的实现形式是通过事件路由器,如 Amazon Event Bridge 或者 Amazon SNS,将服务需要放入相应的缓冲区,再在通过队列服务如 Amazon SQS,Amazon MQ 来实现异步的、并行的解决和对 Crontab 需要的响应。

当然,也能够本人调度作业,或操作流程,不要对立在凌晨 3:00 触发,而是将触发事件分散开来,来升高服务能耗峰值。然而显然用事件驱动的架构,无服务器技术来实现自动化水平更好,能耗峰值升高的成果更显著。

Crontab 服务业务场景是通过队列或缓冲区的伎俩升高业务能耗峰值,升高总容量配置,从而取得保障 SLA 的同时缩小整体资源的应用和影响。除此之外,咱们还能够通过优化伎俩在不扭转老本的前提下,来缩小资源争抢而进步性能,从而均衡 SLA 和可持续性倒退的指标。

典型的场景有:应答工作的减少而扩充规模。扩容过程和扩容自身就应用了资源,如果把它降到最低。同样能够应用事件驱动,无服务器技术,通过队列或缓冲器来按需弹性扩缩容,从而平滑需要的峰值,并放弃所用资源处于高的继续利用率。

高效的编程语言有助于缩小能耗

对于开发者来说,应用高能效的编程语言来编译软件也是一个很好的可继续倒退教训。当然这对于很多开发者来说,也是一个十分大的难题:

什么才是高能效的语言?

它的规范是什么?

怎么去掂量它?

很多科学家早就为此做过钻研,在 2017 年的报告中:

科学家设计了 10 个测试场景,比照了 27 种比拟支流的语言在执行工夫、能耗以及最大内存等不同场景下的能耗。后果 C 语言和 Rust 在能效方面无可争议的击败了其余的语言。它比开发者罕用的 Java 能耗节俭了 50%,比 Python 的能耗节俭了 98%。

Linux 的创始人也曾说过,他认为 Rust 是一门能够很好地解决问题的编程语言。Rust 在比肩 C 的效率的同时,还能防止各种不平安的危险。

亚马逊云科技向咱们的开发者举荐 Rust 语言,同时亚马逊自身也是 Rust 语言的践行者。在亚马逊的多个重要的开源我的项目中,如用于反对无服务器计算的开源虚拟化技术 Firecraker、基于 Linux 的容器化操作系统 Bottlerocket 都应用了 Rust 语言进行开发,并获得了微小的胜利。在亚马逊,Rust 曾经成为构建大规模基础设施的要害,为 Amazon S3、Amazon EC2、Amazon CloudFront 等提供关键性服务。亚马逊对 Rust 的信赖还体现在对他放弃继续的奉献。自 2019 年以来亚马逊始终是 Rust 我的项目的赞助商,2020 年开始雇佣 Rust 维护者和贡献者,2021 年成为 Rust 基金会的开创成员。

硬件

硬件的抉择和优化对于可持续性倒退转型的影响包含:

  • 用起码的硬件满足需要
  • 抉择适合的计算实例
  • 应用托管服务
  • GPUs 资源的优化

首先是计算实例上的抉择所产生的影响。咱们倡议,应用能满足要求且影响最小的实例类型,帮忙缩小碳脚印。

以开发者熟知的 Graviton 为例:

Graviton 2 是由亚马逊云科技设计并开发的 ARM 架构的处理器。相比最近一代的 X86 实例,在应用服务器、微服务、视频编码、高性能计算、电子设计、自动化、游戏、开源数据库、内存缓存和基于 CPU、机器学习推理等等宽泛的工作负载中,它都能够提供高达 40% 的性价比,非常容易实现且迁徙的老本不高。Graviton 2 是亚马逊云科技目前最省电的处理器之一。

在整个工作负载的运行过程中,Graviton 2 确实帮忙开发者实现了能耗的节俭。基于 Graviton 2 咱们也公布了 Graviton 3。它与 Graviton 2 相比,价格性能又进步了 25%,能耗升高了 60%。在亚马逊云科技的很多外围的利用和服务,包含容器服务,无服务器服务等,目前都与 Graviton 2 兼容。

可见,只是从计算实例上抉择适合的计算实例,就能够帮忙开发者在整体的可持续性倒退指标进行优化。

数据

当然还要思考数据。实现了工作负载和数据迁徙当前,对于数据的正当治理,寄存介质的抉择,也可能帮忙开发者进一步实现可持续性倒退的指标。这里有一些可供参考的最佳实际,包含:

  • 抉择适合的数据拜访和存储技术;
  • 制订数据分类政策;
  • 应用生命周期策略来主动删除不必要的数据;
  • 最大限度地缩小超额配置
  • 删除不须要的或多余的数据
  • 应用共享文件系统或对象存储来拜访公共数据
  • 尽量减少网络间的数据挪动
  • 数据备份

具体来说,抉择适合的存储介质和技术来寄存不同类型的数据。或者应用智能分层的形式动静存放数据,都能够帮忙开发者节俭能耗。

例如在对象存储 Amazon S3 中,就提供了各种类型供开发者抉择:

筛选适合的存储介质和技术

从热数据,暖数据,冷数据,到须要删除或者归档的数据,开发者都能够抉择不同的存储介质和技术。它们会对响应工夫、寄存老本、以及数据类型提供对应的技术撑持。一方面开发者能够很容易地实现数据的智能分层,另一方面也对数据无效的生命周期进行治理。

通过自动化的形式对不常常应用的数据进行归档,对所有数据进行标记和审查并设置报警机制,依据数据拜访要求制订规定,应用策略来迁徙或革除数据等等,能够大量的缩小不必要存储资源的耗费,从大的层面上保障咱们云上的计算或者是云上的业务更进一步的靠近可持续性倒退的一个指标。其实接下来我有一个小的基于亚马逊本人的研发工程师的一个小的实际,可能去优化咱们的存储资源的,它就是优化日志存储。

数据拜访及存储

优化日志存储

咱们会发现咱们每天各个利用都会产生大量的日志文件,如果咱们把大量的非结构化日志文件归档,或者寄存在咱们的 Amazon S3 的对象存储外面,其实就能够去通过这种零散的数据联合在一起,可能让咱们的空间有一个十分大的节俭。咱们自身的教训实际是节俭了一个 EB 的,大家晓得一个 EB 其实是有 100 万兆字节的这样一个容量的节俭。另外其实咱们的服务团队也对这种不同的压缩算法进行了大量的尝试。咱们会发现从 gzip 到 LZ4 再到 ZSTD,其实它的压缩的成果是逐步递减是显著的。咱们也把它不同的压缩比展现给大家,大家能够依据理论的状况去做一个正当的抉择。

开发和部署

缩小构件工具大小

最初一个方面实际就是对于开发和部署的,这是一个十分大的话题。首先咱们通过一个有意思的实在案例作为引入,大家对 Amazon SDK for JavaScript 可能大家都不生疏,因为你每当浏览器或者是 node.js 的代码调用亚马逊云科技的服务的时候,简直都会用到这样一个工具包。随着应用开发频次的减少,应用次数的一个减少,这个服务包的库的正本也会缓缓一直的收缩,就会导致 SDK 的包越来越大。

咱们晓得大包的治理,其实对于能耗的耗费以及你的治理的人的耗费是是十分十分大的。于是咱们在 SDK for Javascript 的第三个版本中,就引入了模块化的这种形式去来优化它。咱们把大家共用的那些工具和代码去把它抽取进去,做成一个根本包。这个根本包以它为根底,再去下面去叠加你的个性化的一些代码,或者是你的一个工具。这个根底包就跟你之前你的开发如果要去实现一个具体的开发我的项目所去产生的附加的包比起来,它的容量节俭了 75%。在这个包的根底之上,再去叠加不同的利用和工具的时候,也会去通过删减,去通过一系列的优化的形式,再去进一步的节俭。咱们会发现具体的利用在包的之上,再去叠加你的个性化的,或者是你特地须要的一些工具或者服务的时候,会在 75% 的节俭之上,再去节俭 50% 的容量。这个其实也是一个教训提供给各位,各位能够去来优化你的开发工具,实现你的资源的能耗,云上资源能耗的进一步的一个节俭。

总而言之,其实咱们会发现可持续性倒退不是咱们在某一个环节设定的指标,它就能实现的。就像在这个话题刚开始的时候所跟大家分享的一样,它是一个十分大而远的这么一个指标,咱们其实是能够把它细分成不同的阶段性的、小的、可达的一个指标。在你的整个的开发和测试的流程外面,在每个过程外面去实现不同的可持续性倒退的指标。积小成多,最终肯定会可能放慢你整体的可持续性倒退指标的一个实现。

心愿大家通过这期的内容,接下来可能去设置你的指标,并且去寻找你正当的工具去来理解这些最佳实际和这些教训,并且通过这些最佳实际去来在你的理论的工作中失去验证,产生新的最佳实际,欢送与咱们分享。

作者
郑予彬
亚马逊云科技资深开发者布道师,20 年 ICT 行业和数字化转型实际积攒,专一于亚马逊云科技云原生、云平安技术畛域。18 年架构师教训,致力于为金融、教育、制作以及世界 500 强企业用户提供数据中心建设以及软件定义数据核心等解决方案的征询及技术落地。

文章起源:https://dev.amazoncloud.cn/column/article/63fc5d2af699155a74c…

正文完
 0