天津做网站哪个公司好,代理公司收费标准,企业网站可以做游戏类网站么,赣州做网站的公司有哪家好如何有效利用云产品做好我们的业务大促备战#xff0c;这是一个大家都比较关心的问题。今天趁着 618 大促来袭前#xff0c;谈一谈我们所积累的最佳实践。
点击链接#xff0c;立即查看视频讲解#xff1a;https://yqh.aliyun.com/live/detail/28697
大促的不确定性挑战 …如何有效利用云产品做好我们的业务大促备战这是一个大家都比较关心的问题。今天趁着 618 大促来袭前谈一谈我们所积累的最佳实践。
点击链接立即查看视频讲解https://yqh.aliyun.com/live/detail/28697
大促的不确定性挑战 上图是我们的一个业务大图大促时候我们会碰到许多的不确定性因素的挑战如流量不确定用户行为不确定安全攻击不确定研发变更风险不确定故障影响不确定。最好的方式从入口模拟和防护但是这么来看其实是不能解决所有问题所以需要 IDC 内部进一步做故障演练和流量防护。
因为流量不确定所以我们需要容量评估以及业务评估确定流量峰值然后通过限流将流量变成确定性的条件用户行为不确定所以我们需要通过仿真、多个场景模拟用户行为进行压测与演练我们需要做到更加真实的仿真并且及时发现系统的瓶颈与优化点并及时优化安全攻击的不确定性我们需要网关有 waf 防护的能力比如黑产刷单流量我们如何识别并且通过流控限制其访问量从而保护正常用户的流量关于研发变更风险的不确定我们需要通过变更管控来限制大促时进行不必要的变更因为担心出故障时影响面的不确定性所以我们需要通过不断的故障演练来锤炼我们的系统了解故障的影响面并且尽可能控制问题的影响面避免系统雪崩的问题出现大促是一个项目备战的方法论是把大促不确定性变成确定性希望能有一些方法论提供给大家配合我们产品的最佳实践帮助到大家。
目标确定
大促的目标有很多比如支撑 XX 的流量峰值30% 的成本优化流畅的用户体验等。大促备战的目标在技术同学看来一般围绕成本、效率、稳定性。成本我们考虑到 Nacos、云原生网关的资源成本以及应用的机器数量利用好 K8s 的弹性能力保证稳定性与成本的一个平衡在效率方面 PTS 全链路压测提供了开箱即用的全链路压测工具最接近用户的仿真压测流量可以极大地提升效率同时 MSE Switch 能力提供了动态配置能力帮助预案的使用在稳定性方面MSE 服务治理提供了端到端的流量控制能力以及弹性过程中的无损上下线能力保证大促过程中的流量平滑无损同时我们可以配合 MSE 服务治理的全链路灰度能力使用测试流量进行全链路的功能预演尽早暴露问题点。 备战流程
简单来说大促备战流程需要关心以下四个点容量评估、预案准备、预热、限流。将以下这些点都做到了就可以把不确定因素都变成了确定性的条件那么即使是面对大促的流量洪峰整个系统会非常的平稳。
容量评估
容量评估的目的为了实现成本与稳定性的最佳平衡因此我们需要基于大促的应用表现确定我们的应用在一定的业务条件下的性能基线同时另一方面出于成本优化的目标我们需要确定机器的成本预算。
通过性能评估以及性能优化确保应用的性能评估业务变化以及系统的变化基于业务模型评估确定全链路压测模型并进行全链路压测验收评估容量的极限水位保持 60% 的容量水位开启弹性扩缩容能力。性能评估
首先需要通过 PTS 平台对服务进行压测摸清系统对外核心接口的服务能力以及相应的系统水位。阿里云产品关于压测以及全链路压测首推的就是 PTS。
PTS 对比一般的压测工具具有以下优势
优势一功能强大
全 SaaS 化形态无需额外安装和部署。0 安装的云端录制器更适合移动端 APP 场景。数据工厂功能0 编码实现压测的 API/URL 的请求参数格式化。复杂场景的全可视化编排支持登录态共享、参数传递、业务断言同时可扩展的指令功能支持多形态的思考时间、流量蓄洪等。独创的 RPS /并发多压测模式。流量支持动态秒级调整百万 QPS 亦可瞬时脉冲。强大的报表功能将压测客户端的实时数据做多维度细分展示和统计同时自动生成报告供查阅和导出。压测 API/场景均可调试压测过程提供日志明细查询。
优势二流量真实
流量来源于全国上百城市覆盖各运营商可拓展至海外真实模拟最终用户的流量来源相应的报表、数据更接近用户真实体感。施压能力无上限最高支持千万 RPS 的压测流量。
当性能压测出系统瓶颈后我们需要分层次地对系统进行优化。
业务以及系统的变化
评估每次大促相比之前如果有参考的话的稳定性评估以及业务动向这次业务相比之前是否有量级的提升业务的玩法是否有变化比如 618 的预售以及抢红包、满减等业务玩法是否会对系统造成稳定性的风险对用户动向进行分析从全局视角看系统的关键路径保障核心业务梳理强弱依赖。
基于业务模型评估确定全链路压测模型并进行全链路压测验收要发起一次性能压测首先需要创建一个压测场景。一个压测场景包含一个或多个并行的业务即串联链路每个业务包含一个或多个串行的请求即 API。 通过压测可以对我们的系统做好一个风险识别与性能管理的目的通过全链路压测可以提前发现系统的瓶颈识别性能风险防止系统的性能腐化。
云产品的资源容量评估与参考MSE Nacos 容量参考评估 Nacos 注册配置中心水位我们可以从连接数、服务数来评估有些应用可能服务数特别多再加上大促时候流量徒增使得应用动态扩容随着 Pod 数增加连接数、服务提供者数量也会线性增加因此大促前保证 60% 以内的水位是必要的。
MSE 网关 容量参考评估网关水位最直观的就是按照 CPU 来判断建议 30%最高不超过 60%。为什么定的这么低参考水位是根据集团内部网关运维经验给的网关经常会有些突发流量尤其对于电商类业务例如大促、秒杀等还有要考虑流量攻击的因素例如 ddos 攻击等网关不能根据 CPU 跑 80%、90% 这样评估容量一旦有突发情况网关就很容易被打满。阿里内部网关比较极端网关 CPU 一般会控制在 10% 以下。同时还有一些因素网关突发流量一般都是瞬时的有可能网关瞬时 CPU 已经被打到很高了但是监控平均后不是很高因此网关的秒级监控能力也是非常必要的。
预案 一句话来描述就是有意识地为潜在或者有可能出现的风险制定应对处理方案。
比如很多影响用户体验、性能的开关一些日常为了观察分析用户行为的埋点等一些与业务无关的功能我们在大促的时候都是需要通过预案平台关闭掉这些功能当然预案还有一些业务流量相关的预案涉及到流控、限流、降级后面会详细介绍。
预热 为什么要做预热跟我们的流量模型有关很多时候我们的流量模型是自然上去慢慢的下来。但大促的时候可不是这样流量可能突然暴涨几十倍然后维持住慢慢下来。预热要预热什么我们当时做了很多预热数据的预热应用的预热连接的预热。
数据的预热
先讲数据的预热我们访问一个数据它的数据链路太长了其实离应用越近可能效果越好。首先数据预测要看什么数据该怎么预热首先把量特别大的数据跟用户相关的数据就是购物车、红包、卡券做数据库的预热。
模拟用户查询查询这个数据库把它的数据放到我们的内存里面。很多应用都是靠缓存挡住的缓存一旦失效数据库就挂掉因为数据库挡不住。这时要提前把数据预热到缓存里面。
做数据的预热的目的是为了减少关键的数据的链路可以从内存读到的就没必要去缓存中读可以从缓存中读的就不应该访问数据库。
应用的预热
1、小流量服务预热 相比于一般场景下刚发布微服务应用实例跟其他正常实例一样一起平摊线上总 QPS。小流量预热方法通过在服务消费端根据各个服务提供者实例的启动时间计算权重结合负载均衡算法控制刚启动应用流量随启动时间逐渐递增到正常水平的这样一个过程帮助刚启动运行进行预热详细 QPS 随时间变化曲线如图所示 应用小流量预热过程QPS曲线
同时我们可以通过调整小流量预热的曲线解决大促时扩容的机器流量平滑无损。 应用小流量预热过程原理图
通过小流量预热方法可以有效解决高并发大流量下资源初始化慢所导致的大量请求响应慢、请求阻塞资源耗尽导致的刚启动 Pod 宕机事故。值得一提的是 MSE 云原生网关也支持了小流量预热我们看一下实战中的效果68 节点是刚扩容的实例。 2、并行类加载
JDK7 上如果调用 Classloader.registerAsParallelCapable 方法则会开启并行类加载功能把锁的级别从 ClassLoader 对象本身降低为要加载的类名这个级别。换句话说只要多线程加载的不是同一个类的话loadClass 方法都不会锁住。
我们可以看 Classloader.registerAsParallelCapable 方法的介绍
protected static boolean registerAsParallelCapable()Registers the caller as parallel capable.The registration succeeds if and only if all of the following conditions are met:1. no instance of the caller has been created2. all of the super classes (except class Object) of the caller are registered as parallel capable它要求注册该方法时其注册的类加载器无实例并且该类加载器的继承链路上所有类加载器都调用过 registerAsParallelCapable对于低版本的 Tomcat/Jetty webAppClassLoader 以及 fastjson 的 ASMClassLoader 都未开启类加载如果应用里面有多个线程在同时调用 loadClass 方法进行类加载的话那么锁的竞争将会非常激烈。
MSE Agent 通过无侵入方式在类加载器被加载前开启其并行类加载的能力无需用户升级 Tomcat/Jetty同时支持通过配置动态开启类加载并行类加载能力。
参考材料http://140.205.61.252/2016/01/29/3721/
连接的预热
以 JedisPool 预建连接为例提前建立 Redis 等连接池连接而不是等流量进来后开始建立连接导致大量业务线程等待连接建立。
org.apache.commons.pool2.impl.GenericObjectPool#startEvictor
protected synchronized void startEvictor(long delay) {if(null ! _evictor) {EvictionTimer.cancel(_evictor);_evictor null;}if(delay 0) {_evictor new Evictor();EvictionTimer.schedule(_evictor, delay, delay);}
}
JedisPool 通过定时任务去异步保证最小连接数的建立但这会导致应用启动时Redis 连接并未建立完成。
主动预建连接方式在使用连接之前使用 GenericObjectPool#preparePool 方法去手动去准备连接。
在微服务上线过程中在初始化 Redis 的过程中提前去创建 min-idle 个 redis 连接确保连接建立完成后再开始发布服务。
JedisPool warm-internal-pool 同样有类似问题预建数据库连接等异步建连逻辑保证在业务流量进来之前异步连接资源一切就绪。
再谈预热
预热为什么要做。我们阿里云甚至有体系化的产品功能比如无损上线流量防护的预热模式等因为预热是保障系统在大促态稳定性的很重要的一环。通过预热帮助我们的系统进入大促态这个过程就好比于百米短跑。其他业务按照自然流来的都是长跑但是短跑你必须得热身没有热身起步阶段可能就出抽筋、拉伤等大问题。
流控限流 流控是保障微服务稳定性最常用也是最直接的一种控制手段。每个系统、服务都有其能承载的容量上限流控的思路非常简单当某个接口的请求 QPS 超出一定的上限后拒绝多余的请求防止系统被突发的流量打垮。市面上最常见的方案是单机维度的流控比如通过 PTS 性能测试预估某个接口的容量上限是 100 QPS服务有 10 个实例则配置单机流控 10 QPS。但很多时候由于流量分布的不确定性单机维度的流量控制存在一些效果不佳的情况。
典型场景 1精确控制对下游的调用总量 场景服务 A 需要频繁调用服务 B 的查询接口但服务 A 和 B 的容量存在差异服务 B 约定最多给服务 A 提供总共 600 QPS 的查询能力通过流控等手段进行控制。
痛点若按照单机流控的策略配置由于调用逻辑、负载均衡策略等原因A调用B到达每个实例的流量分布可能非常不均部分流量较大的服务 B 实例触发单机流控但总体限制量尚未达到导致 SLA 未达标。这种不均的情况经常会发生在调用某个依赖服务或组件如数据库访问的时候这也是集群流控的一个典型场景精确控制微服务集群对下游服务或数据库、缓存的调用总量。
典型场景 2业务链路入口进行请求总量控制 场景在 Nginx/Ingress 网关、API Gateway (Spring Cloud Gateway, Zuul) 进行入口流量控制希望精确控制某个或某组 API 的流量来起到提前保护作用多余流量不会打到后端系统。
痛点如果按照单机维度配置一方面不好感知网关机器数变化另一方面网关流量不均可能导致限流效果不佳而且从网关入口角度来讲配置总体阈值是最自然的手段。
MSE 服务治理集群流控
MSE 服务治理流控降级提供了以下特性
1、专业的防护手段
入口流量控制按照服务容量进行流量控制常用于应用入口例如Gateway、前端应用、服务提供方等。热点隔离将热点和普通流量隔离出来避免无效热点抢占正常流量的容量。对依赖方隔离 / 降级对应用和应用之间、应用内部采用隔离 / 降级手段将不稳定的依赖的对应用的影响减至最小从而保证应用的稳定性。系统防护MSE 应用流控降级可以根据系统的能力例如 Load、CPU 使用率等来动态调节入口的流量保证系统稳定性。
2、丰富的流量监控
秒级流量分析功能动态规则实时推送。流量大盘编排核心业务场景了然于胸。
3、灵活的接入方式
提供 SDK、Java Agent 以及容器接入等多种方式低侵入快速上线。
MSE 服务治理的集群流控可以精确地控制某个服务接口在整个集群的实时调用总量可以解决单机流控因流量不均匀、机器数频繁变动、均摊阈值太小导致限流效果不佳的问题结合单机流控兜底更好地发挥流量防护的效果。
对于上面的场景通过 MSE 服务治理的集群流控无论是 Dubbo 服务调用、Web API 访问还是自定义的业务逻辑均支持精确控制调用总量而无关调用逻辑、流量分布情况、实例分布。既可以支撑数十万 QPS 大流量控制也支持分钟小时级业务维度小流量精确控制。防护触发后的行为可由用户自定义如返回自定义的内容、对象。 防止突发流量将业务打垮
通过开启 MSE 流量防护能力根据压测结果中不同接口和系统指标配置限流、隔离以及系统保护等规则在最短的时间内接入并提供持续提供防护。碰到一些特殊的业务场景比预期的流量要大的多的时候通过提前配置流控规则及时地将多余的流量拒绝或排队等待从而保护了前端系统不被打挂。同时在一些核心接口也出现了突发的响应时间增大的情况下游服务挂掉导致从网关到后端服务整条链路 RT 飙高这时候利用 MSE 实时监控和链路功能快速定位到慢调用和不稳定服务及时进行流控和并发控制将系统从崩溃的边缘拉了回来业务迅速回到正常水平。这个过程就像“给系统做心脏复苏”可以有效保障业务系统不挂掉非常形象。
防止热点流量将业务打垮大促中我们还要防止热点流量一些“黑马”热点商品或者一些黑产刷单流量超出业务预期的流量进入我们的系统后很可能会将我们的系统拖垮我们通过热点参数流控能力可以将热点用户、热点商品的流量控制在我们业务模型预估的范围内从而保护正常用户的流量有效保护我们的系统稳定性。
保障调用端稳定性避免级联故障我们都知道当流量近似稳态时并发线程数 QPS * RT(s) 当我们调用的下游 RT 升高时那么并发的线程数将会飙高从而出现服务调用的堆积。这也是大促中常见的一个问题因为依赖的下游支付服务因网络抖动出现大量慢调用导致该应用的线程池全部被该服务调用占满无法处理正常业务流程。MSE 实时监控和链路功能可以帮助我们快速定位到慢调用和不稳定服务准确找到应用变慢的根因并对其配置并发隔离策略可以有效保证我们应用的稳定性。
保护重点业务避免雪崩雪崩是很可怕的一件事情当它发生时我们连救都救不回来了只能眼睁睁地看着应用一个个宕机。因此在业务高峰期某些下游的服务提供者遇到性能瓶颈甚至影响业务。我们可以对部分非关键服务消费者配置自动熔断当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断后续一段时间服务调用直接返回 Mock 的结果这样既可以保障调用端不被不稳定服务拖垮又可以给不稳定下游服务一些“喘息”的时间同时可以保障整个业务链路的正常运转。
大促的总结 每一次大促都是一次很宝贵的经验在大促后做好总结和复盘沉淀经验是必不可少的一环。我们需要收集整理系统的峰值指标系统的瓶颈与短板以及踩过的坑思考哪些东西是可以沉淀下来帮助下一次大促备战让下一次大促无需重头再来让下一次大促的用户体验可以更加丝滑。
大促还有许许多多的不确定性大促流量和用户行为是不确定的如何将不确定性风险变成相对确定的事情大促是一个项目备战的方法论是把大促不确定性变成确定性通过方法论推动产品最佳实践配合大促成功同时也通过大促这场考试锤炼我们的系统沉淀我们的最佳实践。在这里祝大家 618 大促考试顺利系统稳如磐石。为了用不停机的计算服务为了永远在线的应用业务Fighting
原文链接
本文为阿里云原创内容未经允许不得转载。
