130 秒揭秘 EDAS 3.0 如何平滑应对突发流量高峰
"在 PaaS 层面，我们始终拥抱开源技术，并保持和社区版本兼容的时效性；在企业特性上，例如服务治理、应用监控等方面，我们提供一个稳定成熟的产品，来降低企业构建互联网化应用的门槛，例如企业级应用服务 EDAS 3.0 就是这样一个典型的产品。"
——阿里巴巴合伙人、阿里云智能基础产品事业部高级研究员 蒋江伟
EDAS 3.0作为应用托管和微服务管理的PaaS平台，支持 Spring Cloud、Apache Dubbo、Service Mesh 等服务运行环境，提供应用开发、部署、监控、运维等全栈式解决方案，同时平台通过 AIOps (智能运维)为托管应用提供性能和稳定性保障。
通常，企业在云上构建互联网应用，都会遇到以下这些问题：
如何来确定一个分布式系统的容量？
如何实现更加智能的弹性的伸缩，用最低的成本，实现最高的容量？
当系统出现问题时，如何进行快速定位和诊断？
带着这三个问题，我们来看看 EDAS 3.0 的云原生架构是如何满足真实场景下的流控难题和单点故障引起的交易成功率下降的问题的，详情如视频所示：
演示系统
视频中演示应用是模拟了一个电商购物交易系统主要包括：系统网关、交易中心、商品中心和购物车四个模块，各个模块之间选择了 Dubbo 和 Spring Cloud 作为微服务框架进行系统间交互。整个应用选择了阿里云 ACK 容器服务集群作为部署底座，同时将该集群一键托管到 EDAS 3.0 平台进行微服务治理、应用监控、以及应用部署运维操作。
整个演示流程，我们按照电商大促活动前系统压测演练为背景，使用 PTS (Performance Testing Service性能测试)来模拟用户请求流量， EDAS 3.0 通过限流降级、智能弹性、故障诊断以及异常实例摘除等功能为整个压测演练保驾护航。接下来，我们按照演示流程对每个环节中涉及到的技术进行一一解读分析。
容量探测
对于大促系统压测演练，首先我们需要知道压测目标值(这个需要产品和运营根据历史活动和用户量进行评估)，视频中的目标值为 8000TPS (Transaction Per Second, 每秒事务数)。明确目标值以后，我们需要进行压测获取单机水位，这里我们利用了最佳压力值结合接口 RT (Response Time,接口返回时间)进行单机容量评估。
如上图所示，最佳压力值指的是系统在最佳性能运行，连续成功率低于 98% 的点的前一个量级，同时结合我们对接口的 SLA 的 RT 上限 800ms 可以得出单机 TPS (Transaction Per Second, 每秒事务数)在 850 左右(视频中选择了4台机器压测)。可以看出单机容量评估流程需要一定人工经验以及反复测试才可以完成，目前 EDAS 3.0 已经在和 PTS 合作针对压测场景进行自动化容量评估以及性能诊断。完成上述单机水位评估后，我们即可根据目标值对系统容量进行手动扩容，在 EDAS 3.0 系统中可以完成上述操作。完成扩容以后，通过 PTS 模拟需要压测的目标值 8000TPS ，观察扩容后的系统指标 RT 和交易成功率是否符合预期要求。
性能优化
像大多数首次上线的应用一样，这个电商交易模拟系统作为一个全新 demo 系统，也是经历了多轮压测以及性能调优才达到最后视频中展示的效果。作为一个典型的 Dubbo 微服务系统，这里分享一下整个调优过程中两个比较典型问题的调试过程。整个调试过程我们主要借助 EDAS 3.0 的应用监控中心、日志中心以及 Arthas 工具进行排查和诊断。
首先来看第一个问题，完成第一步容量探测此时 PTS 的压力值为 3400RPS ，紧接着直接进行扩容来进行下一步目标值压测，在完成扩容后可以看到RT监控指标反而有上升波动同时会出现一段时间请求错误，这个和预期不符的。我们利用 EDAS 3.0 监控的接口快照链路定位到下游 checkout 服务问题，同时利用实例监控定位具体是扩容前某个 pod 问题。接下来在日志中心检查该 pod 相应日志发现了 Dubbo 线程池满的错误日志，同时发现 Dubbo 多次重试的错误日志。综合分析可以得出根因是，节点调用下游超时重试导致线程池沾满，针对这种情况我们将超时时间、重试次数以及 Dubbo 线程池进行了调整，经过多轮压测后得到合适参数。
完成上述优化以后，由于后续限流降级的需求我们代码引入了 AHAS 的 SDK ，同样在容量探测完成以后直接进行手动扩容来进行下一步目标值压测的时候，再次出现短暂的失败率反而上升的问题。有了上一轮调优经验，这一轮我们也是轻车熟路配合 Arthas 的使用以及 AHAS 引入时间点，定位到这次问题主要是 AHAS 的 SDK 初始化会导致 RPC 首次调用耗时增加，同时扩容后新节点自身需要预热问题，大流量直接打在新节点上会导致超时失败。针对这两点问题，我们通过启动主动调用 AHAS 的 SDK 初始化方法以及修改 Dubbo 的延时注册和预热配置进行解决。
作为一个交易核心链路新系统上线进行压测是必不可少的环节，这也体现了云上 PTS 的压测系统对于用户重要性，在压测过程中遇到问题我们需要进行一轮轮调优，调优过程中 EDAS 3.0 的监控中心和日志中心起到了重要作用，将整个条有过程变得有章可循同时节省了排查时间。最后，我们可以看到微服务线程池配置、超时配置以及重试配置等是比较常见的微服务问题，未来我们 EDAS 3.0 智能运维(AIOps)可以将这些问题排查变得更加自动化帮助客户节省更多时间。
限流降级
在当今日益复杂的应用环境下，应用设计应该遵循“面向失败”的设计原则，对上下游的依赖零信任。借助流量控制、熔断降级模块，应用就有能力对流量采取限流控制，并对下游依赖进行降级处理。
面对视频中超过系统预估容量的突增流量，服务限流降级功能显得尤为重要了，我们知道一旦突发高流量将系统打垮，后续恢复将十分艰难，重启应用的预热，流量迁移等等给用户带来不好体验。EDAS 3.0 提供的一键接入服务限流降级功能，只需要您在部署阶段勾选接入限流降级服务，您的应用即可享受流量防护模块给您的应用全方位保护。目前该防护模块支持主流的 Java 框架，包括 HTTP 和 Dubbo ，同时可以实时监控框架的 QPS （Queries per Second，每秒查询数）、线程数、响应时间、异常数等指标。
完成上述接入以后，在 EDAS 3.0 监控详情页的服务/接口监控的限流降级菜单可以对接口进行规则配置以及实时指标监控，有了限流降级模块的保护，应用就可以从容面对线上突增流量的出现。
智能弹性
在分布式应用管理中，弹性伸缩是很重要的一个运维能力。弹性伸缩能够感知应用内各个实例的状态，并根据状态动态实现应用扩容、缩容，在保证服务质量的同时，提升应用的可用率。在弹性伸缩方面，EDAS 3.0 提供了更加智能丰富的弹性扩缩策略，包括监控指标策略和自定义弹性策略。同时，针对业务周期性我们还提供了定时弹性来支持该特定业务场景。
视频演示流程中突发流量在限流降级模块的保护下，应用抵挡住了超过系统容量上限的流量。该应用同时配置了单机 QPS 自定义指标的弹性扩缩策略，智能弹性模块会根据当前外部最新请求量进行智能弹性扩容，从而将超过预估的流量一并吃掉，保证系统稳定性的同时也提升了用户使用产品体验。
离群摘除
在微服务架构中，当服务提供者的应用实例出现异常，而服务消费者无法感知时会影响服务的正常调用，并影响消费者的服务性能甚至可用性。离群实例摘除功能会检测应用实例的可用性并进行动态调整，以保证服务成功调用，从而提升业务的稳定性和服务质量。目前，EDAS 3.0 微服务治理中的离群摘除功能会在客户端统计服务的指标数据，比如调用次数和错误次数，根据用户的规则配置进行流量摘除。
智能运维
互联网时代，应用并发量激增，业务流程更加复杂，如何保证系统稳定性越发困难，系统可观测性越来越重要。
EDAS 3.0 系统在满足应用运行态和发布态可观测性的基础上，又进一步做到了智能运维(AIOps)。目前，智能运维已成为了应对IT系统与日俱增的复杂性的很好的解决方案， 它基于大数据、数据分析和算法来提供洞察力，并为现代基础设施和软件所需的管理任务提供更高水平的自动化。
全球最具权威的IT研究与顾问咨询公司 Gatner 公司最新 AIOps 报告预测到 2023 年，全球 40% 的 DevOps 团队会使用 AIOps 工具。EDAS 3.0 作为监管控一体化 PaaS 平台，已经在 AIOps 领域深耕多年，并将其落地在应用运行态和发布态等多个场景。
如上图所示， Gartner 总结当下 AIOps 中涉及的三个主要流程 Observer、Engage 和Act， EDAS 3.0 的智能运维(AIOps)也是依照上述流程进行整体诊断分析。
整体来看， EDAS 3.0 智能运维流程主要包含以下三个部分：异常检测、根因分析和诊断处理。其中，异常检测阶段选择了应用黄金指标中的 RT (接口响应时间)和错误率作为检测目标，利用算法和应用历史指标数据进行异常检测分析。
在根因分析阶段，系统会根据单机、服务以及关联事件三个维度对异常进行解释和分析。通过三个维度指标检测最终会给出故障可能的原因，在复杂的微服务系统中可以很好的辅助运维人员对故障进行排查和复盘。
在完成根因分析以后， EDAS 3.0 智能运维系统会根据分析结果进行相应的修复建议、运维自动化处理，同时会给出一份诊断报告对本次故障进行问题定位分析帮助开发同学进行问题排查。诊断报告包含了故障定界、根因分析结果以及相应的建议或者推荐。
演示视频中，通过制造下游节点 fullgc 故障，从而引发上游接口 RT( 响应时间)的上升。EDAS 3.0 智能运维系统自动会检测到此次 RT (响应时间)上升的异常，并会针对 RT 突增异常进行分析检测，最终根据检测结果进行相应的修复手段，如视频中所见在检测出是下游的单机 fullgc 问题后，智能运维系统通过 EDAS 3.0 微服务治理提供的离群摘除能力将故障机器进行隔离，隔离后故障恢复。
最后综述， EDAS 3.0 作为分布式架构、数字化转型上云的首选在线业务应用托管平台，在微服务治理、应用发布变更以及智能运维等多个维度为用户应用提供智能化、自动化的解决方案，欢迎大家使用，点击文末“阅读原文”，了解更多产品相关。
扫码加入钉群，可咨询产品相关问题：
作者信息：
陈晨，花名陆昆，阿里云中间件技术开发，2017 年加入阿里巴巴，专注于分布式任务调度系统、PaaS平台开发以及AIOps。