房地产景区网站建设方案,重庆有什么好玩的地方景点介绍,公司网页内容,做网站有要求吗作者#xff1a;冠钰 云原生下的服务治理
在云原生技术的演进过程中#xff0c;依托云原生技术能力#xff0c;形成一个可以向下管理基础设施#xff0c;向上管理业务应用的技术中台#xff0c;越来越成为企业期望的云原生技术落地趋势。随着云原生技术中台 CNStack 发布… 作者冠钰 云原生下的服务治理
在云原生技术的演进过程中依托云原生技术能力形成一个可以向下管理基础设施向上管理业务应用的技术中台越来越成为企业期望的云原生技术落地趋势。随着云原生技术中台 CNStack 发布具有革新意义的新一代 2.0 版本其提供的云原生技术能力不仅可以支撑大规模业务系统也可以将内部不统一的体系集中管理起来通过中台化的方式输出云原生技术能力。通过 CNStack 可以低成本实现业务应用的云原生改造并且 CNStack 云原生平台可以为接入的应用提供业务监控、流量管理、服务开放等多种能力。
深入到微服务体系中CNStack 平台为复杂的微服务架构系统提供了多方面的服务治理与可视化监控能力其中通过配合可视化数据监控与限流降级能力运维人员可以确保业务系统不论是在正常运行时、发布变更过程中、还是流量猛增的状态下都可以平稳对外提供服务。诸如常见的线上突发流量导致服务流量超过承载能力、服务下游依赖出现不可用导致影响自身服务稳定性等场景CNStack 提供了全方位的流量防护能力以流量与容错为切入点从流量控制、不稳定调用隔离、熔断降级、热点流量防护、系统过载保护等多个维度来帮助保障服务和网关的稳定性同时提供秒级的流量监控分析功能。
快速玩转流量防护
一键接入防护能力
CNStack 平台提供了非常便捷友好的应用接入方式通过工作空间下的应用管理能力可以快速创建应用并且通过应用管理接入的应用均会默认自动接入流量防护能力可以为应用快速全方位配置流量防护。选择 Java 类型创建的托管应用会通过挂载探针的方式接入流量防护能力不需要对业务代码进行任何埋点改造对业务应用无侵入。 通过 CNStack 平台接入的应用可以获得秒级业务监控、限流熔断防护、自定义行为配置等多项能力保障服务稳定运行。相比社区流行的开源 sentinel 等流量防护接入方式使用 CNStack 平台不需要任何代码改造也不要添加任何额外的配置可以一键针对所有接入应用开启防护能力。并且 CNStack 平台原生地为所有接入应用提供了更加强大的流量防护能力以及稳定的秒级监控系统可以在平台上一站式完成线上系统维护。 为了快速玩转 CNStack 流量防护能力接下来针对一些常见的线上业务场景介绍如何在 CNStack 中通过配置流量防护规则保障业务应用在各类不稳定场景下正常提供服务。
场景 1. 线上流量激增
线上流量有很强的随机性与不可预测性因为重要新闻发布、活动促销等因素都会导致突发的激增流量。然而线上系统的容量是有限的如果突发增长的流量超出了系统承受能力会导致大量请求处理堆积CPU/Load 飙高请求处理缓慢甚至报错。因此在系统设计时需要针对这种突发流量设置保护措施在尽可能处理请求的同时保障服务不被打垮。
例如当下火爆的 ChatGPT在发布短短数天时间内用户量达到百万级别注册用户之多甚至导致服务器爆满国内也有多个团队及公司发布类 ChatGPT 的对话机器人用户注册同样火爆。设想这样一个场景企业研发并上线了一个类 ChatGPT 对话机器人业务业务应用集群部署的规模预期可以承载数万用户同时访问但随着业务上线受到广泛关注并且涌入大量用户注册使用线上用户规模迅速激增至十万在对线上系统不做流量保护的情况下大量用户的访问请求可能会将系统直接打垮导致整个服务瘫痪陷入不可用。但是在 CNStack 流量防护场景下使用流控规则可以预防线上的突发激增流量保障系统在可承受的范围内稳定运行。创建一条流控规则的配置参数可以参考下图 按照上述示例中配置的流控规则流控策略会将每秒访问 /startTalk 接口的请求次数限制为 600每秒 600 次以内的请求会全部正常通过当一秒内的请求量达到 600 后会触发限流限流后超出 600 个的请求会按照顺序排队等待通过排队等待时间超出 500ms 后快速失败。最终流控效果如下图所示当初始流量较低时所有请求均正常通过当流量快速增长达到阈值 600 时会触发限流每秒放行 600 个请求通过其余请求会被拒绝保障了阈值范围内流量的正常访问。 场景 2. 微服务自我保护
微服务架构中不同的服务之间可能会存在依赖关系例如调用第三方的 API、数据库、远程服务并由不同服务之间相互调用组成复杂的调用链路。然而被依赖服务的稳定性是不能保证的如果依赖的服务出现了不稳定的情况请求的响应时间变长那么调用服务方法的响应时间也会变长线程会产生堆积最终可能耗尽业务自身的线程池服务本身也变得不可用。
假设如下场景微服务通过数据库查询用户信息所有的查询任务会提交至线程池队列异步去数据库查询用户信息。由于数据库索引变更或者刷脏页等原因产生了慢 sql进而使得查询的线程池任务堆积并最终导致线程池耗尽整个服务不可用。在 CNStack 流量防护场景下可以针对这样的场景配置熔断规则对于不稳定的依赖调用进行自动熔断降级防止下游依赖问题导致自身线程池堆积影响服务稳定性达到保障整体系统稳定运行的效果。创建一条熔断规则的配置参数可以参考下图 按照上述示例中配置的熔断规则熔断策略会在有请求访问 /getUserInfo 接口时开启长度为 30 秒的统计窗口并统计访问该接口请求的响应时间所有响应时间超过 500ms 的请求会被记录为慢调用请求。当一个 30 秒的统计窗口中响应时间超过 500ms 的慢调用请求在所有请求中所占的比例超过 80%熔断策略会立即触发 60 秒的熔断熔断时间内所有请求都会快速失败。熔断时间到达后熔断策略会允许新的请求通过如果新请求正常通过响应时间未达到慢调用 RT 阈值将会结束熔断恢复正常访问否则重新进入熔断状态。 熔断降级特性基于熔断器模式的思想在服务出现不稳定因素如响应时间变长错误率上升的时候暂时切断服务的调用等待一段时间再进行渐进式恢复尝试。一方面防止给不稳定服务“雪上加霜”另一方面保护服务的调用方不被拖垮。目前支持两种熔断策略基于响应时间和基于错误可以有效地针对各种不稳定的场景进行防护。 场景 3. 细粒度流量控制
线上 Web 流量通常具有非常多的业务属性与参数如 IP、用户 ID、商品 ID 等有的业务场景下仅仅从接口纬度配置流控规则是不够的往往需要与这些业务属性参数结合针对性的配置流控规则。假设一大波突发请求针对某个热点商品 ID无法准确预知流量的量级、分布、热点访问情况大量的请求会击穿缓存直接打到 DB 层导致 DB 访问缓慢挤占正常商品请求的资源池最后可能会导致系统挂掉。因此针对细粒度的请求属性控制是非常重要的可以实现热点商品防刷IP 防刷等一系列更加细粒度的高可用防护策略。
假设某电商平台上架了一批折扣促销商品其中一款商品被大量用户下单订购大量的下单修改库存请求打到 DB 层并拖慢整个 DB 访问速度影响了其余商品的正常下单导致整个平台购物链路变得不可用。在 CNStack 流量防护场景下使用 web 防护规则可以针对这样的场景自动分析请求中对应请求属性的值对每个热点参数限制访问请求次数防止因为对于热点资源请求数的倾斜挤占整体正常请求的资源池达到保障整体系统稳定运行的效果。创建一条 web 防护规则的配置参数可以参考下图 按照上述示例中配置的 web 防护规则web 防护策略会在请求访问 /takeOrder 接口时自动分析请求中的 URL 参数针对 URL 参数名称为 keyboard 的请求每秒访问次数限制为 20 个从业务参数纬度对请求进行针对性的进行拦截。当线上用户对该商品大量下单后对于 URL 参数匹配到该商品的请求会快速失败被拒绝掉访问其余商品的请求会正常通过保障平台整体链路正常下单达到细粒度流量控制的效果。通过这种细粒度维度的控制不仅可以在 Web 服务端实现 IP 防刷、热点商品防刷等一系列的细粒度高可用防护策略也可以实现每个用户每个 API 每分钟限制访问 N 次的具有业务含义的流量管控策略。 总结
CNStack 2.0 以更全面和更轻量的形态为客户打造了具有竞争力的云原生平台并且为业务应用托管提供了更加云原生化的方式。具体深入到微服务架构中CNStack 原生地提供了全方位的流量防护能力包含流控、熔断降级、web 防护、系统防护等一系列的微服务流量防护手段可以有效的针对微服务架构以及中间件依赖全链路全方位地为服务集群提供可用性保障。对于云原生时代下微服务的架构设计更加需要面向失败设计的意识结合 CNStack 流量防护能力合理地配置流控降级规则做好事前防护能够更加稳定的保障线上业务应用运行稳如磐石。
