专栏首页只喝牛奶的杀手计算资源合并模式

计算资源合并模式

上下文和问题

云应用程序通常实现各种操作。 在某些解决方案中,合理的做法是最初遵循问题分离的设计原则,将这些操作划分成分别进行托管和部署的单独计算单元(例如,作为单独的应用服务 Web 应用、单独的虚拟机或单独的云服务角色)。 但是,虽然此策略可以帮助简化解决方案的逻辑设计,不过将大量计算单元作为相同应用程序的一部分进行部署可能会增加运行时托管成本并使系统管理更复杂。

作为示例,下图显示使用多个计算单元实现的云托管解决方案的简化结构。 每个计算单元都在其自己的虚拟环境中运行。 每个函数都作为在其自己的计算单元中运行的单独任务(标记为任务 A 到任务 E)来实现。

每个计算单元都会消耗应计费资源,即使它处于空闲状态或不常使用。 因此,这并不总是最经济高效的解决方案。

在 Azure 中,此问题适用于云服务、应用服务和虚拟机中的角色。 这些项在其自己的虚拟环境中运行。 运行设计为执行一组定义完善的操作,但需要作为单个解决方案的一部分进行通信和协作的单独角色、网站或虚拟机的集合可能对资源的使用较为低效。

解决方案

若要帮助降低成本、提高利用率、加快通信速度并减少管理,可以将多个任务或操作合并到单个计算单元。

任务可以按照基于环境提供的功能以及与这些功能关联的成本的条件进行分组。 一种常见方法是查找在其可伸缩性、生存期和处理要求方面具有类似特征的任务。 将它们组合在一起可使它们作为一个单元进行缩放。 借助许多云环境提供的弹性,可以根据工作负载来启动和停止计算单元的附加实例。 例如,Azure 提供自动缩放功能,可以应用于云服务、应用服务和虚拟机中的角色。 有关详细信息,请参阅 Autoscaling Guidance(自动缩放指南)。

作为用于演示如何使用可伸缩性确定不应组合在一起的操作的计数器示例,请考虑以下两个任务:

  • 任务 1 轮询发送给队列的对时间不敏感的少见消息。
  • 任务 2 处理大量网络流量突发。

第二个任务需要可能会涉及到启动和停止大量计算单元实例的弹性。 将相同缩放应用于第一个任务只会导致更多任务在相同队列中侦听少见消息,是一种资源浪费。

在许多云环境中,可以在 CPU 核心数、内存、磁盘空间等方面指定可供计算单元使用的资源。 一般情况下,指定的资源越多,成本便越高。 为了节省资金,请务必最大程度提高昂贵计算单元执行的工作量,不要让它长时间处于非活动状态。

如果有在短暂突发中需要大量 CPU 能力的任务,请考虑将这些任务合并到可提供所需能力的单个计算单元。 但是,请务必平衡此需求以使昂贵资源在面对可能发生的争用(如果它们处于超负荷状态)时保持繁忙状态。 例如,长时间运行的计算密集型任务不应共享相同的计算单元。

问题和注意事项

在实现此模式时,请考虑以下几点:

可伸缩性和弹性。 许多云解决方案通过启动和停止计算单元实例,在计算单元级别实现可伸缩性和弹性。 应避免将具有冲突可伸缩性要求的任务分组到相同计算单元中。

生存期。 云基础结构会定期回收托管计算单元的虚拟环境。 当一个计算单元中存在许多长时间运行的任务时,可能需要配置该单元以防止在这些任务完成之前回收它。 或者,使用检查点方法设计任务,该方法使任务可完全停止,然后在计算单元重新启动时在中断位置处继续执行。

发布节奏。 如果任务的实现或配置经常更改,则可能需要停止托管更新的代码的计算单元,重新配置和重新部署该单元,然后重新启动它。 此过程还需要相同计算单元中的所有其他任务停止、重新部署并重新启动。

安全性。 相同计算单元中的任务可能会共享相同安全性上下文,并能够访问相同资源。 任务之间必须存在高度信任,并且确信一个任务不会对其他任务造成损坏或产生负面影响。 此外,增加在计算单元中运行的任务数会增大单元的攻击面。 每个任务的安全性只与具有最多漏洞的任务相同。

容错。 如果计算单元中的一个任务失败或行为异常,则它可能会影响在相同单元中运行的其他任务。 例如,如果一个任务未能正确启动,则它可能会导致计算单元的整个启动逻辑失败,并阻止相同单元中的其他任务运行。

争用。 应避免在相同计算单元中的任务之间出现竞争资源的争用。 理想情况下,共享相同计算单元的任务应表现出不同的资源利用率特征。 例如,两个计算密集型任务不应位于相同计算单元中,两个占用大量内存的任务也是如此。 但是,混合使用计算密集型任务与需要大量内存的任务是可行的组合。

备注

可考虑仅对已在一段时间内处于生产环境的系统合并计算资源,以便操作员和开发人员可以监视系统并创建标识每个任务如何利用不同资源的热度地图。 此地图可以用于确定非常适合用于共享计算资源的任务。

复杂性。 将多个任务合并到单个计算单元会向单元中的代码增加复杂性,从而更加难以进行测试、调试和维护。

稳定的逻辑体系结构。 设计和实现每个任务中的代码,以便即使运行任务的物理环境发生更改也无需更改代码。

其他策略。 合并计算资源只是可帮助降低与并发运行多个任务关联的成本的一种方式。 它需要进行仔细规划和监视以确保保持为有效方法。 其他策略可能更为合适,具体取决于工作的性质以及运行这些任务的用户所处的位置。 例如,工作负载的功能分解(如计算分区指南中所述)可能是更好的选择。

何时使用此模式

对于在其自己的计算单元中运行时不怎么经济高效的任务,可使用此模式。 如果任务长时间处于空闲状态,则在专用单元中运行此任务可能成本高昂。

此模式可能不适合执行关键容错操作的任务,或是处理高度敏感或私有数据并需要其自己的安全性上下文的任务。 这些任务应在其自己的隔离环境、在单独的计算单元中运行。

本文分享自微信公众号 - 只喝牛奶的杀手(killerhub),作者:azure

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-12-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 挎斗模式

    将应用程序的组件部署到单独的进程或容器中,以提供隔离和封装。 使用此模式还可以使用异构组件和技术来构建应用程序。

    只喝牛奶的杀手
  • Spring Cloud Gateway中异常处理

    最近我们的项目在考虑使用Gateway,考虑使用Spring Cloud Gateway,发现网关的异常处理和spring boot 单体应用异常处理还是有很大...

    只喝牛奶的杀手
  • Ribbon负载均衡策略

    载均衡算法数量较多,而且可以根据一些业务特性进行定制开发,抛开细节上的差异,根据算法期望达到的目的,大体上可以分为下面几类。

    只喝牛奶的杀手
  • 【计算神经科学】脑科学与人工智能的必要桥梁

    引言:一个国际神经学家团队朝着在计算机上模拟人类大脑迈出了小而重要的一步:建模老鼠大脑。他们公布了鼠脑组织至今最为详细的数字重建:模拟了3万个神经元和大约4千万...

    新智元
  • 入门 | 机器学习研究者必知的八个神经网络架构

    机器之心
  • opencl:获取每个计算单元(CU)中处理元件(PE)的数目

    版权声明:本文为博主原创文章,转载请注明源地址。 https://blog.csdn.net...

    用户1148648
  • 中国工程院院士卢锡城谈智能计算:应当夯实技术基础,避免重蹈传统计算产业覆辙

    AI 科技评论按:2019 年 5 月 17 日下午,天津世界智能大会专题论坛「新一代人工智能核心技术及治理高峰论坛」在天津梅江会展中心举行。本次论坛由科学技术...

    AI科技评论
  • io.Reader 解析

    简介 io.Reader 是一个 Interface 类型,功能非常强大,在任何需要读的地方我们都尽量使用它。先来看下它的原型: type Reader int...

    李海彬
  • Python之面向对象(1)

    面向过程的程序设计的核心是过程(流水线式思维),过程即解决问题的步骤,面向过程的设计就好比精心设计好一条流水线,考虑周全什么时候处理什么东西。把完成某一个需求的...

    不羁的程序员小王
  • self,和类实例化加不加括号的理解

    skylark

扫码关注云+社区

领取腾讯云代金券