手机网站优化排名怎么做,珠海专业网站建设价格,大型公司为什么做网站,如何宣传推广自己品牌前言
弹性伸缩是云计算时代给我们带来的一项核心技术红利#xff0c;但是 IT 的世界中#xff0c;没有一个系统功能可以不假思索的应用到所有的场景中。这篇文章#xff0c;我们将应用企业级分布式应用服务-EDAS 的客户在进行系统架构设计时#xff0c;在弹性场景下遇到的…前言
弹性伸缩是云计算时代给我们带来的一项核心技术红利但是 IT 的世界中没有一个系统功能可以不假思索的应用到所有的场景中。这篇文章我们将应用企业级分布式应用服务-EDAS 的客户在进行系统架构设计时在弹性场景下遇到的点滴做了一个系统的梳理总结为五个条件和六个教训分享给大家。
五个条件
1、启动无需手动干预
是否需要手动干预是弹性伸缩和手动伸缩的本质区别。在传统应用的运维中一个进程的启动往往需要在机器上手动准备一系列的事情如环境搭建依赖服务的配置梳理本地环境配置调整等。如果是在云上的应用可能还需要手动调整安全组规则依赖服务的访问控制等但这些需要手动执行的动作在自动弹性时都会变得不可行。
2、进程本身无状态
确切的说无状态主要是指业务系统运行时对于数据的依赖程度数据是在进程执行的过程中产生的产生的数据会对后来的程序行为产生持续的影响程序员需要在编码逻辑的时候就考虑如果系统在一个新环境中重新拉起时这份数据是否对于行为会造成不一致的情况推荐做法是数据应该最终以存储系统中为准让存储计算做到真正的分离。
3、启动的要快走的要有“尊严”
弹性尤其是云上的弹性其中一个特点是会进行得很频繁。尤其是流量突发型的业务带着一定的不确定性。而启动后的系统往往处在一个“冷”的状态启动之后如何快速的“加热”是弹性有效性的关键。而在弹性结束之后往往伴随着一次自动的缩容由于这个过程也是自动的所以我们需要能从技术上能做到自动流量摘除的能力这里的流量不仅仅包括 HTTP/RPC也包括消息、任务后台线程池调度等。
4、磁盘数据可丢失
在应用启动过程我们的应用程序可能会使用磁盘配置一些启动依赖项之外在进程运行的过程中我们也会习惯性使用磁盘打印一些日志或者记录一些数据。而弹性场景是进程快起快没没了之后放在磁盘上的数据也都没了所以我们要做好磁盘数据丢失的准备可能有人会问日志怎么处理日志应该通过日志收集组件收走进行统一的聚合、清洗和查阅。这一点在 12 factor apps 中也做了强调。
5、依赖的服务充分可用
成规模的业务系统往往不是一个人在战斗。最典型的架构中也会使用到一些缓存、数据库等中心服务。一个业务弹性扩容上来之后很容易忽略中心依赖服务的可用性。如果依赖服务出现不可用对于整个系统可能就是一个雪崩的效应。
六个教训
1、指标值设置不合理
弹性整体分为三个阶段指标获取、规则计算、执行伸缩指标获取一般通过监控系统或者 PaaS 平台自带的组件获取。基础监控指标常见的如CPU/Mem/Load 等。短期内有一些基础指标数值会存在不稳定的特点但是时间拉长正常来看会处在一个“平稳”的状态我们设置指标的时候不能以短时间的特征为依据参考较长时间的某种水位数据才能设置一个合理值。且指标不宜过多同时缩容指标要和扩容指标存在明显的数值差。
2、把“延时”当指标
很多时候我们识别系统可用性的一个很大的判断就是看系统屏幕是不是在“转圈圈”即系统很慢。常理推断很慢就要扩容了。所以我们有一些客户直接把系统的平均 RT 当成了扩容指标但系统的 RT 是多维度的比如 health check 一般都是很快的这类 API 出现的频率稍高一点一下就拉低了平均值。也有的客户会精确到 API 级别可是 API 也是根据参数不同逻辑不一样的从而造成 RT 不一样。总之根据延时去做弹性策略是很危险的一种做法。
3、指定单一的扩容规格
扩容规格指的是资源的规格比如在云上的场景中对于同一种 4c8g 的规格我们可以指定内存型、计算型、网络增强型等。但是云上是一个大资源池对于某一种规格会存在售罄现象如果我们只指定了单一的规格就会出现资源无法提供而出现扩容失败的情况。这里最危险的还不是扩容失败本身是出现业务故障之后的排查过程会特别漫长。
4、只考虑RPC链路中的应用策略
针对单个应用往往都很简单的难的是整个业务场景的梳理。梳理思路一个简单的办法就是按照应用调用的场景进行从应用间调用的场景来看一般来说分为三种同步RPC中间件如 Spring Cloud、异步消息中间件如 RocketMQ、任务分布式调度中间件如 SchedulerX。我们一般会很快整理出第一种情况但是很容易忽略掉后面两种。而后面两种出现问题的时候问题排查诊断又是最为耗时。
5、没有配套相应的可视化策略
弹性伸缩是一个典型的后台任务在治理一个大集群的后台任务的时候最好是有一块大屏进行直观的可视化治理。对于扩容失败的情形不能静默处理。如果是核心业务出现扩容失败可能带来的就是直接的业务故障但是故障真正发生时很多时候不会去关心扩容策略是否生效如果真是因为扩容造成的故障也很难排查到这个点。
6、事前没做正确评估
虽然云计算给弹性提供了近乎无尽的资源池但这也只是解放了用户预备资源的工作而微服务系统本身复杂单一组件的容量变化会产生全链路的影响既解除一处风险之后系统瓶颈点可能会迁移有些隐形约束也会随着容量变化逐步显现所以做弹性策略大多数时候不能靠力大砖飞的思想需要做好全链路的压测、验证演练到适应于全局的弹性配置我们还是建议事前从高可用的多个维度了解各种技术手段形成多套预案以备使用。
尾声
云原生场景下弹性能力更为丰富可供弹性的指标也更具备业务定制能力。应用 PaaS 平台如企业级分布式应用服务 EDAS/ Serverless 应用引擎 SAE 等能结合云厂商在计算、存储、网络上的技术基础能力能让使用云的成本更低。但是这里对于业务应用会提出一点点挑战如无状态/配置代码解耦等等。从更广的侧面来看这是云原生时代应用架构面临的挑战。不过应用越来越原生的话云的技术红利也会离我们越来越近。
作者孤弋
原文链接
本文为阿里云原创内容未经允许不得转载。
