1.问题提出
在上一篇短文的方案中第二步“实时计算”提到：
根据第3部分提到的漏损管理方法，编程开发专用的漏损定量管理系统，在抽取备份数据库的同时对数据进行实时计算，计算时利用流式引擎通过消息机制实现业务模型的异步计算，好处有：1）降低系统设计和开发的复杂度；2）减小系统之间的耦合度；3）提高数据处理的性能。
同时，配图2中有提到“业务报警事件”，文后有朋友提到感觉这个处理起来比较难。其实也并不困难，上面我们也特别提到了计算时利用流式引擎通过消息机制实现业务模型的异步计算。那么如何利用这个机制去实现业务报警事件的处理呢？而且可以比较方便的去更新和扩展该报警处理模型？
2.解决办法
做过分布式系统的朋友一下就明白是怎么回事啦，我们这里也借用了消息服务器，设备状态数据再解析完成后，后向消息服务器发一条特定主题的消息，例如“Snap.Device.DeviceServer"，关注该设备状态信息的子模块订阅这条主题的消息，然后根据需要对设备某个端口、自身状态数据按照一定的规则进行处理，这样你想可以同时对设备自身状态和采集的数据进行处理，比如：
A订阅者专门检查设备电压是否过低；
B订阅者检查设备通信信号强度；
C订阅者负责处理记录的供水压力是否存在异常情况……
当然，只要业务需要可以扩展N个报警事件处理模块，而且能够对这些模块进行热插拔，同时不丢失消息。同样，我们可以把不同阶段的报警事件处理放在不同地方去完成，使得系统有更好的伸缩性和性能，例如对于大表用户用水模式的判断和分析的话则不适合逐条处理，那么我们可以以周、月为单位来设计我们的数据分析、预警模型。
3.注意事项
上面只是对一般的业务报警事件的处理过程进行了简单的分析，若要实现通用的复杂业务事件报警，要注意处理以下问题：
1.一方面需要对适用的业务场景进行深入分析，另一方面也要注意将报警事件进行汇聚，避免大量的碎片化的报警事件，在业务层面重要的报警事件不要漏也不能被报警事件淹没。
2.注意处理报警事件在人为干预和自动恢复后设备状态的处置。
3.不同级别报警事件发生时，报警处理模块与外业（勤）系统的对接，例如哪种情况可以通过即时通信工具发送消息，哪种必须短信或电话通知等。
4.重大报警事件系统自动干预处置操作等。
4.扩展思考
其实不仅仅是业务报警事件的处理，利用同样的机制还可以做更多的事情，下回我将利用一个实际的场景来讲解它对于遗留系统的无痛升级改造。
我对这一块也没有做过很深入的分析，暂时想到这些，您有什么好的意见和建议欢迎指正，以帮助我有更多的认识，感谢。
