提前锁票 InfoQ 最具价值感的视频栏目 | InfoQ 大咖说 了解详情
写点什么

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

2021 年 2 月 05 日

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

本文最初发布于 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 年 2 月 05 日 16:002679

评论

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

SpringBoot之自定义启动异常堆栈信息打印

false℃

爱了!腾讯技术官吹爆的Spring Security笔记开源

Crud的程序员

spring 架构

APM 行业认知系列 - 二

东风微鸣

APM Trace 可观察性

面试磕磕碰碰,辛得蚂蚁高级工程师的技术笔记指导,终获P7岗offer

Java成神之路

Java 程序员 架构 面试 编程语言

《经济学人》2021年2月20日刊精彩文章导读及资源下载

wbliu85

APM 行业认知系列 - 三

东风微鸣

APM Trace 可观察性

2020回顾,2021学习目标

叫练

学习 2021年展望 2020年度总结

架构设计篇之微服务实战笔记(一)

小诚信驿站

架构师 刘晓成 小诚信驿站 28天写作 架构师成长笔记

区块链商品溯源平台开发,区块链公共服务系统开发方案

WX13823153201

区块链商品溯源平台开发

IDEA 敏捷开发技巧——后缀完成

程序员小航

Java 后端 IDEA

LoadRunner测试中遇见的不可思议的问题及其解决方法

陈磊@Criss

全网最新、最全面蚂蚁金服面经分享:简历模板/面试题库/Java核心技术笔记

比伯

Java 编程 程序员 面试 技术宅

面试官:Java性能调优你会多少?一个问题就把我问的哑口无言,哭了!

996小迁

架构 Java性能调优 Java性能调优面试

备受开发者青睐的“Spring全家桶”(双重理念)技术实战与面试结合

Java成神之路

Java 程序员 架构 面试 编程语言

【LeetCode】数组的度Java题解

HQ数字卡

算法 LeetCode 28天写作 2月春节不断更

产品训练营--第四期作业

曦语

产品训练营

电子产品中EMC隔离设计的方法

不脱发的程序猿

二月春节不断更 电路设计 EMC 电子产品

大小厂必问Java后端面试题(含答案)

yes的练级攻略

Java 面试 后端

干货来袭!阿里大佬“亲码”Java全线笔记,差距不止一点点

程序员小毕

Java 程序员 面试 分布式 微服务

APM(应用性能监控) 行业认知系列 - 一

东风微鸣

APM Trace 可观察性

阿里P8技术官带你玩转Spring全家桶,从Spring到Boot到MVC在到Cloud微服务实战

Java成神之路

Java 程序员 架构 面试 编程语言

读书总结2020

IT民工大叔

#读书

EMC设计中电缆屏蔽使用方法

不脱发的程序猿

二月春节不断更 电路设计 EMC 电子产品 电缆屏蔽

Java实体映射利器---MapStruct

是小毛吖

Java MapStruct

你的面试专属!JVM G1GC的算法+实现,90张图+33段代码

Java架构追梦

Java 架构 JVM 调优 G1GC

APM 行业认知系列 - 四

东风微鸣

APM Trace 可观察性

MySQL事务浅析|由浅入深

云流

MySQL 编程 架构

Angular性能优化实践——巧用第三方组件和懒加载技术

Geek_Willie

angular SpreadJS

Elasticsearch踩坑记之深度分页

topsion

大数据 elasticsearch 深度分页

如何 0 改造,让单体/微服务应用成为Serverless Application

阿里巴巴云原生

Docker Serverless 容器 微服务 云原生

滚雪球学 Python 番外系列,自动化测试是个啥?

橡皮擦

Python 28 天写作 2月春节不断更

打造 VUCA 时代的 10 倍速 IT 团队

打造 VUCA 时代的 10 倍速 IT 团队

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