从SOA监控预警到自适应调整01(5.27)

对于SOA治理管控，特别是SOA监控预警方面的文章，在我博客上谈过多次，仅仅监控预警我们就考虑了服务监控，基准监控，异常监控等多种方式，同时可以灵活的对监控的服务范围，监控的KPI关键指标，监控的周期等进行配置，在触发阈值后自动进行监控。

对于SOA监控预警，实际上我们应该看到存在两个层面的监控，一个是性能监控，一个是异常监控，当然异常监控本身也可能触发到性能监控。或者说对于监控我们需要考虑两个方面，一个是直接影响到ESB总线能否稳定运行的监控，一类就是对于ESB运行没影响，但是出现大量服务调用异常的监控。

对于影响到ESB性能稳定性的监控，一定需要及时处理和管控，否则导致整个总线出现故障而影响所有服务。而对于异常类监控，则更多的是及时通知到服务提供方和消费方，先是告警，在多次告警没有得到有效处理后才需要进行相关的管控措施。而现在实际我们看到监控预警发生后更多的是人为去跟踪和处理，而真正需要的则是完全做到：

设定监控规则和指标-》实时监控-》发现问题后自适应调整触发管控规则-》自适应恢复。

即我们更加需要的是整个过程完全不需要太多的人为去干预，而是系统自动的处理和管控，触发的管控规则主要还是服务限流和熔断处理。而对于服务限流和熔断，在分析后可以看到更多的是对服务限流，这个限流不仅仅针对单个系统的粒度，而是可以针对到具体的单个系统+单个消费方+单个服务的粒度。

举例来说同样一个查询服务，有10个消费方，但是当前只有一个消费方出现非法大并发异常调用，那么我们只需要对该消费方调用该服务进行限流或熔断，而不是对整个服务进行熔断。毕竟其它的9个消费方并没有出现非法调用，我们不能因为一个消费方的问题而将整个服务熔断处理。我为什么这么强调自适应调整，因为只有实现了自适应调整，才能够真正走向自动化运维。而不是需要安排专门的运维人员进行日常的跟踪和监控，问题的处理，手工的管控措施调整等。

打个比方来说，如果仅仅实现了监控预警，类似于汽车有了定速巡航功能，但是这个时候还是需要人工随时盯着并处理，而又了自适应调整，就类似真正实现了自适应巡航和自动驾驶功能，这样在人工上才能真正解放。监控运维的自动化和自适应调整，正是一种初级的人工智能，如果从IT从业人员可替代性来说，这块可以讲是最容易被人工智能和自动化所取代的地方。包括我们常说的有强大的知识库支撑的人工智能客服等。

从整个方案上来看，实际上和传统我们讲监控预警没有太大的区别，即：

1. 监控预警规则，监控预警KPI指标的设置

2. 实时的性能数据采集和分析

3. 讲采集数据和预设的规则进行比对，看是否会触发到具体的规则

4. 在规则触发后进行具体的自动化管控行为，包括发短信邮件，自动进行限流或熔断等

5. 进一步监控，给出具体的管控措施的自动化退出和恢复措施

整个过程要做到不需要人工去干预，那么我们预设的判断规则和准则就务必准确，否则就很容易出现误判的情况。如何做到规则准确，那么就需要我们已经用历史数据进行了大量的分析，基于前期历史数据的分析基础上往往才能够给出最佳的判断准则和管控方法。