作者：冠钰
云原生下的服务治理
在云原生技术的演进过程中，依托云原生技术能力，形成一个可以向下管理基础设施，向上管理业务应用的技术中台，越来越成为企业期望的云原生技术落地趋势。随着云原生技术中台 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 流量防护能力，合理地配置流控降级规则，做好事前防护，能够更加稳定的保障线上业务应用运行稳如磐石。
