电商靠山系统中，动静系统是一个必不行少的成果模块，其焦点是辅佐靠山人员实时相识业务动静，保障业务正常运行。本文作者以此为出发点，具体的概述了电商靠山中的系统动静的设计思路，与各人分享。

靠山系统是一个复杂的成果体系，实时的相识每个成果的利用状况，保障业务正常举办是每个系统的重点。凡是系统内会开拓大量的监控成果(可视化的报表和非可视化的报表)来对这些业务举办监控，同时通知相应的认真人以实时相识业务和处事器状况。

常见的一些监控成果，如账号异常(账号异地登录、账号多次暗码输入错误)、运营通知(勾当上架、勾当下架)、订单异常（订单会萃、派单会萃）、处事器异常（处事器宕机、CPU过载）、剧本异常（剧本卡死、历程过多）等等。

本日带各人来设计一个系统动静通知模块，通过简朴的配置，完成本性化的动静发送，而且减轻后期代码的维护事情。首先我们来看看常见动静发送成果是如何实现的以及它们的优缺点。

01 实现 *** 1.1 直打仗发

直打仗发是将动静发送的逻辑和详细的业务代码逻辑写在一起，当满意条件时，触动员静发送成果。

利益：开拓简朴，假如成果封装好后，代码粘过来，十分钟成果根基就能完成；动静发送较量实时，动静发送逻辑和业务逻辑在一起，满意条件就会当即触发。

缺点：后期假如需要添加、编辑或删除吸收人信息，就需要修改代码，维护起来较量贫苦。熟悉代码的人大概几分钟就搞定了，新人预计就得看半天代码了。

我参加过多个系统的开拓，发明这么干的人照旧挺多的。总结一下应该有以下几个原因：

写起来简朴，因为发送逻辑一般都是封装好的，只需要粘代码，修改一下发送参数就完事

一般靠山业务系统较量多，利用的编程语言较量多，各语言之间彼此挪用需要设置基本处事，本钱太大

动静通知凡是属于系统基本成果，产物司理根基上不会去存眷，也就不会去统一筹划这个成果，技能就本身随意发挥了^_^

1.2 动静池

通过将所有动静先收集到一个动静池(如Mysql、Redis、Kafka等)中，然后再统一通过系统调治将动静发送给吸收人。

利益：成果模块化，可以做到统一打点，代码的挪用可以更简捷，后期维护本钱可以降到更低。

缺点：动静会有延迟，动静池它是一个异步发送 *** ，动静的出产和发送是两个彼此独立的进程；需要开拓设置内容页面，开拓量稍微大一点，可是后期能减轻更多的维护本钱，我认为长短常值得的。

02 动静池模子

系统筹划的目标就是让成果布局清晰，后期维护更轻松，所以上面之一种的实现 *** 就不讲了，主要接头一下动静池成果是如何实现的。先来看一下动静池成果的模子图：

上面的模子主要分四层：

动静来历: 动静来历从开拓角度来说，也称为动静出产者，它主要是指动静的生成 *** 和位置。在复杂的靠山系统中，技能架构会分别出多个业务模块，各自的的业务模块都由差异的开拓人员维护，差异的业务组利用的语言也各不沟通，所以在完成沟通成果时，书写 *** 也是各不沟通，这个是没有步伐统一的。

动静池: 主要浸染是存储要发送内容信息，如动静内容，发送时间等。市面上常见的软件有Mysql、Redis、Kafka、RabbitMQ等。所以对动静数据的存储我们是可以做到统一的。

动静分发：主要浸染是获取待发送的动静列表，并按照已配置的吸收人信息，找到详细的吸收人并发送动静。技能上凡是会启动相应的任务措施一连的监控动静池，当动静池中有需要发送的数据，就执行相应业务逻辑。

吸收人: 详细的动静吸收人，吸收人的吸收 *** 有手机、邮箱或站内信。

03 成果阐明

设计详细成果前先来阐明一下动静通知都涉及哪些成果。

3.1 动静范例

在系统运行进程中，会涉及到很多业务成果的监控，如订单业务中，订单付出是否有未乐成、订单分派是否有会萃的环境、派单成果是有会萃环境；再如运营业务中，商品运营勾当已经配置上线时间，到点上线后需要实时通知运营人员上线是否乐成，制止影响勾当结果。

为了可以或许实时让维护人员相识问题，凡是都对动静举办归类，如账号异常、处事器告诫、数据库异常、运营通知、订单异常、剧本异常等。

3.2 紧张水平