6 微服务架构谈：从监控到故障定位( 三 ) _阈值

某故障由于业务规则配置出错，引起业务量下降导致，从数据上看，表现为返回参数与正常请求相比有明显缺失，比如：
参数维度1
参数维度2
参数维度3
正常系统调用
abc
def
[zzz,yyy, ...] (省略)
异常系统调用
abc
def
[]
显然，异常系统调用在参数维度3上有所体现。通过故障注入，我们便可以拿到历史故障数据，但是如果仅仅使用这些样本进行训练，检测系统也只能覆盖历史出现过的故障，极大的限制了系统的检测范围，所以我们将历史故障数据作为种子，在上面进行同类故障问题数据的扩展。
通过同类故障扩展，模型可以拥有覆盖一类问题的能力，扩大了故障覆盖范围，也更能符合真实的情况。后续我们也尝试基于遗传算法的创造式故障样本扩展，更全面的覆盖风险敞口。
基于拓展样本，我们构建了一个基于有监督算法的综合模型，对异常系统调用进行预测，同时结合特征重要性和实时参数来推理可能引起问题的参数，输出给定位模块。
八、故障注入与常态化演练
8.1 Chaos
曾发布过Chaos ，来阐述chaos工程师的相关工作。Chaos 包含4个原则：
Build aState ：把系统当成黑盒， chaos专注在系统does work ，而不是尽量验证它如何工作。例如当故障或某一个状态发生到恢复期间，系统的吞吐量，错误率，延时分布等。
Chaos 是最受关注的一个产品，顾名思义就是用来捣乱的，怎么捣乱？
把某些运算设备定制掉；把系统延迟时间调长等等。Chaos系列还可以模拟单机房故障。Chaos最新版本依赖于这个持续发布平台。
Vary Real-world ：实际创造真实环境的事件，比如硬件fail ，软件不可用来观察演练。
Runin ：系统的行为取决于环境和通讯模式，采样真正的流量是唯一的方法来可靠地捕获请求路径。为了保证系统运行的真实性和当前部署的系统的相关性的真实性， chaos喜欢直接在生产流量实验。
to Run ：chaos工程师通过手工的故障演练不可持续，因此构建自动化演练的机制。
8.2故障注入
结合chaos 不难得到结论，由于分布式系统把fail作为”常态”对待，不能等到出现问题采取解决它，应该通过练兵的方式做演习，而演习的目标要做到尽量可重复、安全、接近真实。
故障注入的方式之一通过服务路由来想办法，比如通过模式对于路由进行处理。下图简单示意了通过隔离服务路由，导入测试流量到演练机的一般方法。

文章插图
如上图所示，系统A>B>C ，系统A调用B ， B调用C 。假设选定对应集群中A 、B 、C 为测试机，则测试流量进入的时候通过服务路由中设置路由到正确的测试机；而正常流量会按照常规配置的路由策略路由到比如A-1-30.等其他机器中。
目前笔者所见的注入故障分类大致覆盖调用/负载变化、单机服务器故障（比如磁盘、cpu full、内存full等）、下游故障（DB响应变慢、下游返回失败结果等）。
8.3常态化演练
分布式系统有一个不成文的原则，就是面向fail设计。任何系统、任何资源都可能不可用，要考虑不可用的异常发生时，对应的解决方案。比如ebay的架构原则就有一条， Fails 。