混沌工程是什么
背景
随着服务化、微服务和持续集成的普及，软件研发效率和敏捷性得到了极大提升，但大规模服务节点和复杂架构应用背后，期待任何架构师能整体理解这些服务组件和交互模式、预测分布式服务所有可能的故障是不合理的，故障发生的随机性和不可预测性也大大增加了。大学电气工程的“信号和系统”课程中有一个拉普拉斯变换，是一种传递函数，将整个电路行为用一个数学函数来表达，函数描述的是系统在受到脉冲时如何响应，输入信号包含所有可能输入频率的总和，有了这个电路传递函数，就可以预测它受到所有可能的输入信号会如何响应，分布式系统中没有类似的函数，无法为复杂的分布式系统建立一个预测模型，无法推测出各种网络延迟、单点故障、上游服务不可用等行为下系统的表现和影响。
监控告警和故障处理都是事后响应与被动应对。
痛苦才能让人深度思考，Chaos Engineering是过去多年同稳定性持续战斗、每一次故障后深度思考的结果。
在复杂分布式系统中，人力无法阻止这些故障的发生，我们应该致力于在这些异常和故障被触发之前，尽可能多地识别导出这些异常的、在系统中脆弱的、易出故障的环节，当识别出这些风险，我们就可以有针对性的完善、加固和防范，不断地打造更具弹性和韧性的系统，树立和提升我们对分布式系统的信心，从而避免故障发生时所带来的的严重后果。
多米诺骨牌效应
搞破坏
小尺度和大尺度
面向失败编程和面向故障架构
措手不及、不知所措
“故障发生，不是由你来选择那一刻，而是那一刻选择你，你只能选择为之做好准备。” – 消防队长 Mike Burtch
定义
混沌工程（Chaos Engineering）是在分布式系统上进行受控试验的学科，目的是建立对系统抵御生产环境中失控条件的能力和信心。
可以把混沌工作看作是为了揭示生成环境中系统的未知弱点和脆弱环节而进行的试验，通过一系列试验帮助我们发现系统中潜在的、可导致灾难、或造成重大业务损失的脆弱环节，推动农我们主动解决这些环节，提升系统的弹性和韧性。
混沌工程是一门相对高级的系统稳定性治理的方法论，提倡采用探索式的研究实验，发生生产环境中的各种风险。要成功实施混沌工程，要求现有系统具备一定程度的弹性。
混沌工程并非简单的制造服务中断等故障，尝试破坏系统和服务很简单，但不能建设性和高效地发现问题，混沌工程期望可以最大化每个实验可以获得的信息。混沌工程的意义是，让复杂系统中根深蒂固的混乱和不稳定性浮出表面，更好理解这些系统性固有现象，从而推动更好的设计系统，提升系统弹性。
混沌工程正是一种既能发现系统中的问题点，又能避免大规模影响的方法论。
混沌工程部是制造问题，而是揭示问题。
混沌工程就是利用实验提前探知系统风险和弱点，通过架构优化来提升系统韧劲（弹性，恢复能力）。
价值
把故障带来的痛苦提到最前。
接种疫苗，提高故障免疫力。
让工程师形成了构建具备足够弹性和韧性服务的规约和规则。
VS 测试
混沌工程的核心是进行为了揭示系统未知弱点的试验，是能够发现系统新信息、新知识，探索系统的更多未知领域和问题的过程和实践。
故障注入是测试一种情况的方法，通过注入通信延迟和错误等失败来探索复杂系统可能出现的不良行为的表现。
故障测试是以某种预想的方式破坏系统，但没有探索出更多可能发生的奇怪场景。
测试和试验的一个重要区别是，测试中，进行断言：给定特定条件，系统将发出特定输出，判定是真还是假，只是将效价分配给它的已知属性，不会产生系统新的知识。
故障注入和故障测试是通过引入故障，让程序走一些不常经过的路径，以此提高程序覆盖率，是对特定条件、变量的验证。这个实践本质上不能挖掘系统内未知或尚不明确的认知。没有办法探索更广阔的、不可预知的、但很可能发生的事情。
混沌工程的前提条件
是判断是否要做系统实施混沌工程，需要确保系统已经具备一定的弹性和韧性，能够应对某个服务不可用、网络波动、瞬间流量突增的情况。混沌工程是用来揭示系统中未知的脆弱环节的，如果很明确系统的弹性水平非常弱，实施混沌工程没有很大的价值，也会导致严重的线上故障和业务影响。同时混沌工程还依赖监控系统，用来观测系统的各项状态和指标，让系统运行行为可见和透明，否则实验无法得到有效的信息和结论。
FIT故障注入测试
分布式系统中各种问题大多由预期外的事件或延迟导致的，故障注入测试（Failure Injection Testing）让工程师访问服务的请求中注入一些失败场景，注入失败的请求在系统中流转时，服务中被注入的故障锚点会根据不同的失败场景触发相应的逻辑。
试验的四个步骤
用系统在正常行为下的可测量的输出来定义“稳定状态”。
假设系统在控制组和试验组都会继续保持稳定状态。
在试验组引入反映真实世界事件的变量，如服务器崩溃、硬盘故障、网络连接断开等。
通过控制组和实验组之间的状态差异来反驳稳定状态的假说。
破坏稳态的难度越大，我们对系统行为的信心就越强。如果发现了一个弱点，那么我们就有了一个改进目标。避免在系统规模化之后被放大。
高级原则
建立一个围绕稳定状态行为的假说
关注可测量的输出，而不是系统的内部属性。
短时间内的度量结果，代表了系统的稳定状态。
验证系统是否工作，而不是如何工作。
多样化真实世界的事件
混沌变量反映了现实世界中的事件。
通过潜在影响或预估频率来排定事件的优先级。
任何能够破坏稳态的事件都是混沌试验中的一个潜在变量。
在生产环境中进行试验
系统的行为会因环境和流量模式有所不同。
为了保证系统执行方式的真实性和当前部署系统的相关性，混沌工程强烈推荐直接采用生产环境流量进行试验。
持续自动化运行试验
手工运行试验是劳动密集型的，是不可持续的，要让试验自动化并持续运行。
混沌工程要在系统中构建自动化的编排和分析。
最小化爆炸半径
在生产环境中进行试验会造成不必要的客户投诉，工程师需要考虑如何让试验影响最小化。
故障
故障类型故障故障说明故障应对方案
雪崩效应一个异常或故障会触发一个不断自我强化的循环，最终导致资源耗尽，拖垮整个应用。
级联故障因依赖关系引发的局部故障导致整个系统崩溃(俗称蝴蝶效应)切换转移
重试退避
超时机制
幂等操作
服务降级：当服务器压力剧增的情况下，有策略地减少或退化部分服务，以此释放服务器资源以保证核心 任务的正常运行，如只读模式、停用耗时耗资源的功能等。
拒绝服务：请求过载时，按优先级开始丢弃相应的请求。
服务熔断：若某个目标服务调用过慢或者有大量超时，直接熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回响应，快速释放资源，待目标服务情况好转则恢复调用。
宕机
混沌工程实践
建立稳定状态的假说
如何描述稳定状态
对于任何复杂系统，需要通用的方法来判断和区分什么系统行为是预期中，哪些是预期之外的。我们如何确定系统是否正常工作？如何判断系统处于健康状态？我们将系统正常运行时的状态定义为系统的“稳定状态”，来指代系统维持在一定范围内或一定模式的属性。跟生命特征指标一样，判断一个生命是否是健康的，会去检查他的脉搏、呼吸、血压、体温等，对于判断一个系统是否处于健康的运行状态时，会检测系统的吞吐率、错误率、T999、延迟、CPU和内存利用率等。
指标包含业务指标和系统指标。系统指标有助于帮助于我们诊断问题，发现功能缺陷，但在描述一个系统的稳定状态模型时，强烈推荐建立在业务接受的业务指标上，业务级别的指标是最有价值的，才是系统健康的真实反映（我们正在流失用户吗？当前黄金流程和核心功能是否可用？PV、UV、点击、转化如何？）。对于服务类的应用，需要把客户和服务之间的服务水平协议（SLA）纳入考量。定义和抓取一个具有全面反映系统稳定状态的业务指标是非常具有挑战的，Netflix使用的是SPS（Starts per Second），视频每秒开始播放数，整体反映Netflix核心业务的业务数据。业务指标的直接和实时性也是非常重要的。当无法用一个能全面反映系统健康状态的业务指标时，也可以挑选一道多个系统指标来反映系统的健康状态。
手工定期收集和检查系统是否处于稳定状态是不可取的，这是劳动密集型的，不可以长久持续的。
通过一个模型，基于所期望的业务指标，来描述系统的稳定状态。第一类为数值范围类的，如同人体体温在36.1℃～37℃被视为正常的，系统接口延迟平均20ms到100ms被认为是正常的，低于20ms可能是出现了大量无效业务数据，高于100ms可能是流量突增、死锁、应用挂起等造成的；第二类是波动模式类，很多业务和系统指标不能用简单的数值范围来考核，比如流量、UV/PV，他们是随着时间或营销事件波动的，对于Netflix来说晚间的SPS比白天高的多，系统的流量在晚上和白天10点比其他时段要高的多，大促618和双十一流量比平日流量大的多。指标能否呈现比较稳定的波动模式很大程度取决于行业，对于新闻类应用来说，突发性因素特别高。
建立假说
定义好指标并理解稳定状态的行为后，就可以使用他们来建立实验的假设，没有一个预先的假设，不清楚从数据中找什么，很难获得有价值和有效的结论。思考当向系统注入不同类型的事件时，稳定状态行为会发生什么变化，稳定状态是保持不变还是被破坏了，如果被破坏了，期待系统如何表现？一般的假设为：向系统注入的事件不会导致系统稳定状态发生明显的变化，试验事件不会使系统行为偏离稳定状态。例如：在通天塔注入一个楼层BI依赖的上游服务不可用的事件，通天塔主接口能否优雅降级BI，下发原始配置排序的楼层数据。定义偏离稳定状态的偏差是否在合理的范围是具有挑战的，只有定义清楚正常的偏差范围，才能活动一套验证假设的完善的试验集合。
多样化真实世界的事件
多元化的业务场景、大规模服务节点、复杂的系统架构，会遇到各式各样的故障，这些故障就是最真实的混沌工程变量。为了更有体感、立体和有效率的描述故障，从IaaS、PaaS、SaaS层角度把通用故障绘制成系统的故障画像。
故障画像
硬件故障、功能缺陷、状态转换异常、网络延迟或隔离、上下行输入大幅波动以及风暴、资源耗尽、服务之间不正常和预期外的组合调用、资源竞争、下游依赖故障：
在彻底阻止和消灭对可用性的各种威胁是不现实的，但我们可以尽可能减轻这些威胁。在决定引入哪些事件时，需要估算这些事件发生的频率和影响范围，然后权衡引入他们的成本和复杂度，不需要穷举所有可能对系统造成威胁的事件，只需要注入那些频繁发生且影响重大的事件，一定要强调的是，注入的事件一定是你认为系统能处理的，同时事件应该真实世界会发生的。同时要理解被影响的故障域（故障的影响范围和隔离范围称为故障域），在试验中验证预先定好的边界也是非常关键。
在生产环境运行试验
传统测试的观点是，对于问题或缺陷的发现应该尽可能前置，越远离线上环境越好，这对需求的逻辑性和可预期的问题来说是合理和可行的，但系统运行和提供服务时应该作为一个整体去看待它的行为，除了代码外，上游服务稳定性、网络波动、流量波动、中间件等对系统稳定性造成的不确定性威胁是很难全面预测和模拟的，测试/预发环境和生产环境在服务器规格、配置、上游等存在差异，无法真实有效的测试和验证各类事件。
混沌工程要建立的是对生产环境的信心，当然需要在生产环境中进行实验，否则会大大削弱实验的价值。
上游下游服务、第三方系统、中间件、网络、客户端、用户、流量都是系统无法控制的，生产环境才是系统和这些组件真实交互的唯一场所。
需要考虑实验的“外部有效性”（从有限样本中得出的研究结论，究竟在多大程度上能推广到总体中去），这个实验的结果能否概括我们真正感兴趣的现象？测量结果的产品运行环境是否是专门为了测试而准备的？不在生产环境进行实验对外部有效性构成很大的威胁。要尽可能的在离生产环境最接近的环境中运行。越接近生产 环境，对实验外部有效性的威胁就越少，对实验结果的信心就越足。
逃避混沌工程的借口
混沌工程实验要求系统已经具备一定程度的弹性，工程师对系统的成熟度具备一定的信心。如果系统明显是很脆弱的，很确定实验会导致宕机，那先专注于提升系统的弹性上。
宕机了就麻烦了。即使对系统的弹性具有很大的信心，但还是会担心实验揭示出系统薄弱环节的同时造成重大的破坏。有2个途径来最小化潜在的影响范围
支持快速终止实验。应该有一个用来立即终止实验的“大红色按钮”，最好是能自动化这个功能，监测到对稳定状态有潜在危害时立即终止实验。
最小化实验造成的“爆炸半径”
在设计实验时，要考虑如何既能从实验中获得有意义的结论，同时兼顾最小化实验可能造成的潜在危害。
持续自动化运行试验
自动化是最长的杠杆。
实验如果不是自动化的，那它就是作废的。
当今系统的复杂性意味着我们无法先验的知道，生产环境中哪些变动会改变混沌工程实验的结果，我们需要假设所有变动都会改变实验结果，生产环境实际上处在一个无时不刻变化的状态，理论上讲，对实验结果的信心是随着时间而衰减的。
实验如果不是自动化的，那它就不会被执行。
手动执行、手把手咨询没法规模化，是劳动密集型的，无法长久持续的，终究也是不会被执行的。
自动创建实验
混沌工程实验的挑战并非来自于定位导致生产环境崩溃的原因，这些在故障跟踪中有，真正想做的是找到那些本不应该让系统崩溃的事件的原因，还包括那些从未发生过的事件，然后持续不断的设计实验来验证，保证这些事件永远不会导致系统崩溃。这是非常困难的，导致系统波动的原因空间是非常巨大的，不可能有足够的时间和资源穷举所有可能导致问题得事件以及组合。
LDFI （Lineage-Driven Fault Injection）可以识别出可能导致分布式系统故障的错误事件组合。LDFI 的工作原理是通过推断系统正常情况下的行为来判断需要注入的候选错误事件。
流程录制和回放
最小化“爆炸半径”
切尔诺贝利事故
混沌工程师一项专业职责是要理解和降低生产风险。预期只影响一部分用户的测试，却由于级联故障导致了大规模节点中断，影响到了很多用户，这种情况是糟糕的，但不得不立即中断实验，所以随时遏制和停止实验的能力是必备的，以避免造成更大的危机。我们的实验通过很多方法来探寻故障会造成的未知的和不可预见的影响，所以关键在于如何让这些薄弱环节曝光出来而不会意外造成更大规模的故障。 我们称之为最小化“爆炸半径”。
能带来最大信心的实验也是风险最大的，混沌工程实验应该只承 受谨慎的，可以衡量的风险，并采用渐进的方式，每一步都基于前一步的基础之上。这种递进的方式 不断增加对系统的信心，而不会对用户造成过多不必要的影响。
要不要混沌工程
不管是低频次的迭代还是平缓的业务变更，都需要混沌工程，无论是激进的架构演进还是平缓的系统迭代，很多问题不是因为迁移上云才出现，只是迁移上云才被揭露出来了。
打法
顾旧立新
保留原有系统，搭建新系统支持新业务
平滑迁移
原有系统正常运行，逐渐进行优化和改造
不破不立
利用新技术和新思路搭建系统，替换老系统
试验
选定假设
确保on-call工程师掌握了整个应急流程
设定实验的范围
考虑“在生产环境运行实验”和“最小化爆炸半径”。
要尽可能最小化实验对用户造成的影响，应该从一个小范围的测试开始，而且要先在测试环境验证过，然后一步步扩大，直到我们认为系统可以应对预期的最大影响。
识别出要监控的指标
根据确定的假设和范围，评估实验结果的指标，要基于指标来验证假设，例如主数据库故障时，服务都正常。要清晰定义什么是服务正常。像响应时间和错误率，需要明确定义这些指标可以容忍的数值范围。
如果实验产生的影响比预期大，要做好立即终止实验的准备，也需要设定好明确的阈值，超过阈值按下“大红色按钮”终止实验。
在组织内沟通到位
跟上下游、业务周知，实验安排和可能的影响。
执行试验
盯住指标，随时终止实验的能力异常关键，实验可能对系统造成过度危害，影响用户。有足够的报警机制，能实时获取关键指标是不是超出了正常状态范围了。
分析试验结果
那实验指标数据来验证之前的假设是否成立，系统对于注入的事件是否具备足够的弹性，有没有任何预期外的事情发生。
实验暴露出来的问题会牵涉多方服务交互，要把结果反馈给所有的相关团队，一同从整体上来消除隐患。
扩大试验范围
逐步扩大，为了进一步暴露小范围实验无法发现的问题。
自动化试验
当有信心手动执行混沌工程实验后，可以开始周期性自动化运行试验，持续从中获得更大价值。
混沌工程成熟度模型
有标准来判断这个项目做得是好是坏，以及如何可以做得更好。
熟练度
等级说明
入门• 未在生产环境中运行实验;
• 全人工流程;
• 实验结果只反映系统指标，而不是业务指标;
• 只对实验对象注入一些简单事件，如“关闭节点”。
简单• 用复制的生产流量来运行实验;
• 自助式创建实验，自动运行实验，但需要手动监控和停止实验; • 实验结果反映聚合的业务指标;
• 对实验对象注入较高级的事件，如网络延迟;
• 实验结果是手动整理的;
• 实验是预先定义好的;
• 有工具支持历史实验组和控制组之间的比较。
高级• 在生产环境中运行实验;
• 自动结果分析，自动终止实验;
• 实验框架和持续发布工具集成;
• 在实验组和控制组之间比较业务指标差异;
• 对实验组引入如服务级别的影响和组合式的故障事件;
• 持续收集实验结果;
• 有工具支持交互式的比对实验组和控制组。
熟练开发流程中的每个环节和任意环境都可以运行实验;
全自动的设计、执行和终止实验;
实验框架和 A/B 测试以及其他测试工具集成以最小化影响;
可以注入如对系统的不同使用模式、返回结果和状态的更改等类型的事件;
实验具有动态可调整的范围以找寻系统拐点;
实验结果可以用来预测收入损失;
实验结果分析可以用来做容量规划;
实验结果可以区分出不同服务实际的关键程度。
应用度
等级说明
暗中进行• 重要项目不采用;
• 只覆盖了少量系统;
• 组织内部基本没有感知;
• 早期使用者偶尔进行混沌工程实验。
适当投入度• 实验获得正式批准;
• 工程师兼职进行混沌工程实验;
• 多个团队有兴趣并参与;
• 少数重要服务也会不定期进行混沌工程实验。
正式采用• 有专门的混沌工程团队;
• 所有故障的复盘都会进入混沌工程框架来创建回归实验;
• 大多数关键服务都会定期进行混沌工程实验;
• 偶尔执行实验性的故障复盘验证，例如“比赛日”的形式。
成为文化• 所有关键服务都高频率进行混沌实验;
• 多数非关键服务高频率进行混沌实验;
• 混沌工程实验是工程师日常工作的一部分;
• 所有系统组件默认要参与混沌工程实验，不参与需要特殊说明。
CMM 的两个坐标轴分别是“熟练度”和“应用度”。缺乏熟练度时，实验会比较危险、不可靠、且有可能是无效的。缺乏应用度时，所做的实验就不会有什么意义和影响。要在适当的时候变换在两个不同维度的投入，因为在任何一个时期，要发挥混沌工程项目的最大效果需要在这两个维度上保持一定的平衡。
闭环实验
实验可行性评估
从多个维度对实验技术的成熟度做了定性分析
架构抵御故障的能力:通过对实验对象的架构高可用性的分析和评估，找出潜在的系统单点风险，确定合 理的实验范围。
实验指标设计:评估目前实验对象判定业务正常运行所需的业务指标、应用健康状况指标和其他系统指 标。
实验环境选择:选择实验对象可以应用的实验环境:开发、测试、预生产、生产。
实验工具使用:评估目前实验对象对实验工具的熟悉程度。
故障注入场景及爆炸半径:讨论和选择可行的故障注入场景，并评估每个场景的爆炸半径。
实验自动化能力:衡量目前实验对象的平台自动化实施能力。
环境恢复能力:根据选定的故障注入场景，评估实验对象对环境的清理和恢复能力。
实验结果整理:根据实验需求，讨论确定实验结果和解读分析报告的内容项。
观测指标设计和对照
观测指标设计
观测指标的设计是整个混沌工程实验成功与否的关键之一，良好的系统可观测性会给混沌工程实验带来一个强有力的数据支撑，为后续的实验结果解读、 问题追踪和最终解决提供了坚实的基础。
• 业务性指标:价值最大，探测难度最大
• 应用健康指标:反映应用的健康状况
• 其他系统指标:较易获取，反映基础设施和系统的运行状况
观测指标对照
趋势随时间的 变化可以预期。如无法准确定义一个稳定状态， 那么我们也可以退而求其次，使用多个指标进行联合分析来对照。具体的联合分析方法包括: 静态阈值、指数平滑、双指数平滑、贝叶斯检测、马尔可夫链蒙特卡罗方法(MCMC)、鲁棒主成分分析(PCA)等。
实验场景和环境的设计
实验场景和环境的设计要努力遵循以下三大设计目标:
• 在生产环境运行实验
• 持续自动化运行实验
• 最小化实验场景的“爆炸半径”
故障注入场景
具体描述
依赖型故障
AWS 托管服务异常:ELB/S3 / DynamoDB/Lambda，...
主机型故障
EC2 实例异常终止，EC2 实例异常关闭，EBS 磁盘卷异常卸载，容器异常终止，容器异常 关闭，RDS 数据库实例故障切换，ElastiCache 实例故障切换，...
操作系统内故障
CPU、内存、磁盘空间、IOPS 占满或突发过高占用，大文件，只读系统，系统重启，熵耗 尽，...
网络故障
网络延迟，网络丢包，DNS 解析故障，DNS 缓存毒化，VIP 转移，网络黑洞，...
服务层故障
不正常关闭连接，进程被杀死，暂停/启用进程，内核奔溃，...
请求拦截型故障
异常请求，请求处理延迟，...
为了体现实验对照的效果，在生产环境 进行的混沌实验可以通过真实生产流量分支的方式，组建控制组和对照组，以此区分故障注入的影响，从一定程 度上控制了爆炸半径。
联合分析
联合分析方法包括: 静态阈值、指数平滑、双指数平滑、贝叶斯检测、马尔可夫链蒙特卡罗方法(MCMC)、鲁棒主成分分析(PCA)等
场景
故障演练可适用于以下典型场景：
衡量微服务的容错能力
通过模拟调用延迟、服务不可用、机器资源满载等，查看发生故障的节点或实例是否被自动隔离、下线，流量调度是否正确，预案是否有效，同时观察系统整体的 QPS 或 RT 是否受影响。在此基础上可以缓慢增加故障节点范围，验证上游服务限流降级、熔断等是否有效。最终故障节点增加到请求服务超时，估算系统容错红线，衡量系统容错能力。
验证容器编排配置是否合理
通过模拟杀服务 Pod、杀节点、增大 Pod 资源负载，观察系统服务可用性，验证副本配置、资源限制配置以及 Pod 下部署的容器是否合理。
测试 PaaS 层是否健壮
通过模拟上层资源负载，验证调度系统的有效性；模拟依赖的分布式存储不可用，验证系统的容错能力；模拟调度节点不可用，测试调度任务是否自动迁移到可用节点；模拟主备节点故障，测试主备切换是否正常。
验证监控告警的时效性
通过对系统注入故障，验证监控指标是否准确，监控维度是否完善，告警阈值是否合理，告警是否快速，告警接收人是否正确，通知渠道是否可用等，提升监控告警的准确和时效性。
定位与解决问题的应急能力
通过故障突袭，随机对系统注入故障，考察相关人员对问题的应急能力，以及问题上报、处理流程是否合理，达到以战养战，锻炼人定位与解决问题的能力。
什么是架构和架构组件？
架构分为水平和垂直两个维度：
水平架构：进程拓扑、容器拓扑、主机拓扑
垂直架构：进程、容器和主机之间的依赖关系
架构组件是指架构的组成部分，包含进程（应用进程、第三方组件进程、云服务）、容器、主机。
什么是熔断降级？
熔断降级是分布式服务中不可缺少的一种防护手段。其原理是当应用不稳定时，通常表现为响应时间或异常比例升高，则将不稳定应用降级甚至熔断，防止关联应用被不稳定的应用拖垮。
什么是系统防护？
系统防护是从系统表现，例如 Load、RT、QPS 和线程数四个维度出发，对应用的入口流量进行控制，让系统尽可能跑在最大吞吐量的同时保证系统稳定性。
功能特性
秒级流量分析功能，动态规则实时推送。
专业多样化的防护手段：
入口流量控制：按照服务容量进行流量控制，常用于应用入口，例如： Gateway、前端应用、服务提供方等。
热点隔离：将热点和普通流量隔离出来，避免无效热点抢占正常流量的容量。
对依赖方隔离 / 降级：对应用和应用之间、应用内部采用隔离 / 降级手段，将不稳定的依赖的对应用的影响减至最小，从而保证应用的稳定性。
系统防护：AHAS 应用流控降级可以根据系统的能力（例如 Load、CPU 使用率等）来动态调节入口的流量，保证系统稳定性。
实时的单机监控能力，强大的聚合监控和历史监控查询能力。
流量控制
流量塑形
流量清洗
风控
分流、切流量