写点什么

避免不完全的云原生(六):为什么你可能不需要弹性伸缩?

  • 2021-02-05
  • 本文字数:1669 字

    阅读完需:约 5 分钟

避免不完全的云原生(六):为什么你可能不需要弹性伸缩?

本文最初发布于 The Startup 博客,经原作者授权由 InfoQ 中文站翻译并分享。


云原生开发最常见的其中一个特性是弹性伸缩。许多公司告诉我们,他们认为弹性伸缩是他们的团队评估云平台的关键需求。然而,我们很少听到这些团队告诉我们,他们为什么需要弹性伸缩。


事实上,我们甚至可以说弹性伸缩是“在云上”的标志之一。所有云平台都提供某种弹性伸缩支持。不管是 Kubernetes 中的Horizontal Pod Autoscalers(根据观察到的 CPU 利用率自动扩展 Pods 的数量),还是像AWS Autoscaling(它会自动缩放 EC2 实例、Dynamo DB 表和许多其他资源类型)这样的供应商特性,通常,弹性伸缩都被视为最想要的云特性。


如果你是一家全新的初创公司,正在构建一个新的 B2C 应用程序,那么弹性伸缩可能至关重要,因为你无法预测你的业务何时会突然腾飞。但大型企业不是初创公司。它们有现有的客户群,而且它们的使用模式在很大程度上是已知的。相反,在大多数企业中,我们看到,公司是将所有不同的工作负载作为一个整体来运行,这些工作负载大致可以分为以下几类:

  • 最大的一类是静态负载,它是可预测的、不变的负载;这可能占所有应用程序的 65%。

  • 第二大类是计划内的伸缩(季节性、批量处理或计划内的活动)——可能占所有应用程序的 35%。

  • 剩下的就是计划外的伸缩(不可预测的负载);剩下的可能非常少——在许多企业,这样的应用程序可能只有 5%。


下图展示了这个划分(取自一个真实的客户,仅用于说明这种情况):



各种伸缩情况的占比


问题是,许多团队在构建他们的应用程序时,都将其当成是这 5%的一部分,而实际上,只有很少的应用程序属于这 5%,这 5%总是受到计划外负载的影响。现在,这并不是一个新问题。在相对更传统的应用程序环境中,常见的方法是准备远超需要的基础设施,“以防万一”。显然,这是一种浪费,也是团队想要迁移到云的原因之一。然而,理想的云原生方法假定每个功能都部署成可无限扩展的。然而,对于我们与之合作的那类大型企业,更好的方法是设法识别这 5%的功能,将它们从庞大的单体中分离出来,并以云原生的方式构建它们(例如,它们可能是 Strangler 模式的早期候选对象)。


因此,假设所有的云原生程序都必须具有弹性和无限的可伸缩性,通常是一种误导——相反,对于 95%的企业应用程序来说,更重要的是弹性而不是弹性伸缩。反之,如果我们需要的是横向稳定性(这是实现横向伸缩的必要条件),那么,这些程序就是那 5%确实需要横向稳定性的。


因此,换句话说,如果一个节点或实例丢失、替换或重启,程序应该可以继续稳定地运行,而服务不会中断——与突然需要额外增加节点的扩展相比,这要常见得多。现在我们发现,关键的云原生要素(如松耦合、不使用共享数据库以及仅通过 HTTP 和消息传递系统等标准的、可伸缩的协议进行进程间通信)是实现这一目标的好方法。因此,以云原生方式编写应用程序仍然是正确的做法,但原因可能和你想的不同。


而且,对于许多企业来说,弹性伸缩都是一种反模式。例如,当我们与一家银行谈论弹性软件许可模型时,我们被告知,鉴于他们进行应用程序成本规划的方式,对于新项目的业务案例,他们实际上需要预先确定软件成本。遗憾的是,我们合作的很多企业都是如此。


一个我们会反复听说的可怕的故事(太经常了,我们都希望它是虚构的,但不幸的是我们见证了不只一个这样的例子)是,一个团队新部署了一个具备自动伸缩能力的云原生应用程序,第一个月因为自动伸缩而产生了一个巨额的云提供商账单,这不是因为客户使用率高,而是因为在测试中未遇到的意外错误导致在正常负载下 CPU 利用率反常升高。在成本模型和财务规划赶上技术发展的步伐之前,你最好以云原生的方式构建应用程序,但部署的时候要么固定资源数量,要么采用有资源限制的自动伸缩设置。


查看英文原文:

A Cloud-Native Coda: Why You (probably) Don’t Need Elastic Scaling


延伸阅读:

避免不完全的云原生(五):目标和收益

避免不完全的云原生(四):技术和基础设施角度

避免不完全的云原生(三):架构和设计角度

避免不完全的云原生(二):人员和流程要素

避免不完全的云原生(一):云原生到底意味着什么?

避免不完全的云原生

2021-02-05 16:004111

评论

发布
暂无评论
发现更多内容

关于 TDengine 3.0 数据订阅,你需要知道这些

TDengine

tdengine 时序数据库 国产时序数据库

自动驾驶汽车:AI技术的未来之路

测吧(北京)科技有限公司

测试

Generative AI 新世界 | 扩散模型原理的代码实践之采样篇

亚马逊云科技 (Amazon Web Services)

机器学习 #人工智能 生成式人工智能 Amazon SageMaker 大语言模型

AI革命:如何改变我们的工作和生活

测吧(北京)科技有限公司

测试

人工智能伦理—面对技术的道德挑战

测吧(北京)科技有限公司

测试

AI在医疗保健中的潜力与挑战

测吧(北京)科技有限公司

测试

聚势共创 多元共生——中科美菱联动清华大学助力产研融合!

联营汇聚

百度智能云 AI 加速器第二期今日开营,42家AI原生应用企业入选

极客天地

写SAE评测,获 Airpods 2大奖【集结令】!

Serverless Devs

Serverless 云原生 AIGC

如何访问TDH中Inceptor 底层的元数据库TxSQL

明哥的IT随笔

大数据 hive

华为3场重磅主题演讲先睹为快,顶级云原生&开源盛会即刻出发

华为云开源

华为 开源 云原生 KubeCON

开启 Kerberos 安全认证的大数据环境中如何正确指定 HS2 的 jdbc url 地址?

明哥的IT随笔

大数据 hive kerberos

HarmonyOS使用多线程并发能力开发

HarmonyOS开发者

HarmonyOS

自动驾驶汽车—AI技术的未来之路

测吧(北京)科技有限公司

测试

软件测试/测试开发丨利用ChatGpt编写测试方案

测试人

人工智能 程序员 软件测试 测试方案 ChatGPT

从技术创新到应用实践,百度智能云发起大模型平台应用开发挑战赛!

不叫猫先生

百度智能云 千帆大模型平台

彻底告别传统FTP,新的替代FTP产品比你想象的好的多

镭速

传输协议 FTP传输替代方案

华为云API对话机器人CBS的魅力—要是有AI,我要做“李白”- 5分钟开发作诗机器人

华为云PaaS服务小智

云计算 软件开发 华为云

如何在低代码平台中应用可视化编程

力软低代码开发平台

DevOps|研发效能团队组织架构和能力建设

laofo

DevOps cicd 研发效能 持续交付 组织架构

用友系列之 YonBuilder 低代码平台概论和基本使用

YonBuilder低代码开发平台

低代码 可视化

活动预告 | 中国数据库联盟(ACDU)中国行第三站定档成都,邀您探讨数据库前沿技术

墨天轮

MySQL 数据库 oracle postgresql zabbix

Git Stash:临时保存和切换工作状态的利器

凌览

git git stash

上新啦!腾讯云云原生数据湖产品DLC 2.2.5版本发布,来看特性详解

腾讯云大数据

数据湖

体验亚马逊的 CodeWhisperer 感觉

亚马逊云科技 (Amazon Web Services)

Java 人工智能

OpenHarmony自定义组件介绍

OpenHarmony开发者

OpenHarmony

ICCV 2023|小红书 4 篇入选论文亮点解读,「开集视频目标分割」获得 Oral

小红书技术REDtech

算法 ICCV

跨网传输文件时,如何通过日志记录来审计追溯?

镭速

跨网文件传输

机器学习:解码人工智能的核心技术

测吧(北京)科技有限公司

测试

人工智能塑造未来城市生活

测吧(北京)科技有限公司

测试

避免不完全的云原生(六):为什么你可能不需要弹性伸缩?_软件工程_Kyle Brown_InfoQ精选文章