消息的处理方法、系统、终端设备以及存储介质与流程

1.本发明涉及通信技术领域，尤其涉及消息的处理方法、系统、终端设备以及存储介质。


背景技术：

2.统一消息平台支持发送短信、彩信、富信、5g、微信、app推送等渠道消息，包括单条发送、群发相同内容(纯文本、静态模板、动态模板)、群发不同内容(纯文本、动参文本、动态模板)、策略发送、文件发送。整套统一消息平台网关服务架构中，各服务之间通过redis中间件进行通信，客户操作统一消息管理后台或者客户自身的系统对接统一消息平台接口进行消息发送。但现有的技术架构中每一个消息渠道几乎都有一套独立的网关服务，例如，对于短信，统一消息平台的后台或客户系统调用短信网关(sms gateway)提供的接口接收消息并转到短信转发服务(sms spgate)，期间经过一系列的业务处理后，最终发送到运营商网关服务；而对于富信和5g，统一消息平台的后台或客户系统，调用5g接收服务(rcs receiver)提供的接口接收消息,转到5g业务服务(rcs business)进行相关的业务处理,再依次转到5g转发管理服务(rcs resmgt)及5g转发服务(rcs spgate)，最终发送到运营商网关服务,即每一个渠道都有一套独立的网关服务，导致服务太多，对于运维人员而言部署难度较大。


技术实现要素：

3.本发明的主要目的在于提供一种消息的处理方法、系统、终端设备以及存储介质，旨在解决简化渠道网关服务部署的问题。
4.为实现上述目的，本发明提供一种消息的处理方法，所述消息的处理方法应用于第一服务器，所述消息的处理方法包括以下步骤：
5.接收第二服务器发送的各渠道下行消息，其中，所述第二服务器接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行消息内容处理，所述第三服务器通过预先添加的标准接口接收所述各渠道下行消息；
6.对所述第二服务器发送的各渠道下行消息进行消息检测处理，并将消息检测处理后的各渠道下行消息发送至运营商网关，以供所述运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息；
7.接收所述下行状态报告消息，并对所述下行状态报告消息进行转换处理，得到转换处理后的下行状态报告消息；
8.将所述转换处理后的下行状态报告消息发送至第四服务器，以供所述第四服务器将所述转换处理后的下行状态报告消息发送至客户系统。
9.本发明还提供一种消息的处理方法，所述消息的处理方法应用于第二服务器，所述消息的处理方法包括以下步骤：
10.接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行拆包处
理，得到业务数据，其中，所述第三服务器通过预先添加的标准接口接收各渠道发送的各渠道下行消息；
11.对所述业务数据进行消息内容处理，得到所述消息内容处理后的各渠道下行消息；
12.识别所述消息内容处理后的各渠道下行消息的所属通道号；
13.通过所述所属通道号将所述消息内容处理后的各渠道下行消息发送至第一服务器，以供所述第一服务器对所述消息内容处理后的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关。
14.本发明还提供一种消息的处理方法，所述消息的处理方法应用于第三服务器，所述消息的处理方法包括以下步骤：
15.通过预先添加的标准接口接收各渠道发送的各渠道下行消息；
16.将所述各渠道下行消息写入消息队列中间件，通过所述消息队列中间件将所述各渠道下行消息发送至第二服务器，供所述第二服务器对所述各渠道下行消息进行消息内容处理，并将消息内容处理后的各渠道下行消息发送至第一服务器，所述第一服务器对所述消息内容处理后的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关。
17.此外，为实现上述目的，本发明还提供一种消息的处理系统，所述消息的处理系统包括第一服务器、第二服务器、第三服务器、第四服务器以及运营商网关：
18.所述第三服务器通过预先添加的标准接口接收各渠道下行消息，通过消息队列中间件将所述各渠道下行消息发送至所述第二服务器；所述第二服务器对所述各渠道下行消息进行消息内容处理，并发送处理后的消息至第一服务器；所述第一服务器对所述消息内容处理后的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至所述运营商网关；所述运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息；所述第一服务器对所述下行状态报告消息进行转换处理，得到转换处理后的下行状态报告消息并发送至第四服务器；所述第四服务器将所述转换处理后的下行状态报告消息发送至客户系统；
19.所述运营商网关接收到用户上行消息，将所述用户上行消息发送至所述第一服务器；所述第一服务器通过转发服务协议层接收所述运营商网关发送的用户上行消息；通过转发服务业务层根据所述用户上行消息生成上行消息接收话单与待推送上行消息数据；将所述上行消息接收话单写入数据库，并将所述待推送上行消息数据发送至所述第四服务器，以供所述第四服务器将所述待推送上行消息数据消息发送至客户系统。
20.此外，为实现上述目的，本发明还提供一种终端设备，所述终端设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的消息的处理程序，所述消息的处理程序被所述处理器执行时实现如上所述的消息的处理方法的步骤。
21.此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有消息的处理程序，所述消息的处理程序被处理器执行时实现如上所述的消息的处理方法的步骤。
22.本发明实施例提出的一种消息的处理方法、装置、终端设备以及存储介质，通过接
收第二服务器发送的各渠道下行消息，其中，所述第二服务器接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行消息内容处理，所述第三服务器通过预先添加的标准接口接收所述各渠道下行消息；对所述第二服务器发送的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关，以供所述运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息；接收所述下行状态报告消息，并对所述下行状态报告消息进行转换处理，得到转换处理后的下行状态报告消息；将所述转换处理后的下行状态报告消息发送至第四服务器，以供所述第四服务器将所述转换处理后的下行状态报告消息发送至客户系统。通过将从第二服务器接收的各渠道下行消息进行消息检测处理后发送至运营商网关，实现了对各渠道下行消息的统一处理和服务，通过将接收到的运营商发送的下行状态报告消息进行处理并发送至第四服务器，实现了对下行状态报告的统一处理与推送，通过第三服务器、第二服务器、第一服务器以及第四服务器将全套网关服务模块化，极大地简化了运维部署的难度。
附图说明
23.图1为现有技术中整套统一消息平台网关服务的架构示意图；
24.图2为本发明消息的处理装置所属终端设备的功能模块示意图；
25.图3为本发明消息的处理方法一示例性实施例的流程示意图；
26.图4为本发明实施例中第一服务器下行消息的时序示意图；
27.图5为本发明实施例中第四服务器进行消息推送的时序示意图；
28.图6为本发明消息的处理方法另一示例性实施例的流程示意图；
29.图7为本发明实施例中第二服务器下行消息的时序示意图；
30.图8为本发明消息的处理方法又一示例性实施例的流程示意图；
31.图9为本发明实施例中第三服务器渠道消息下行的时序示意图；
32.图10为本发明实施例中消息的处理系统的架构示意图。
33.本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
34.应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
35.本发明实施例的主要解决方案是：通过接收第二服务器发送的各渠道下行消息，其中，所述第二服务器接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行消息内容处理，所述第三服务器通过预先添加的标准接口接收所述各渠道下行消息；对所述第二服务器发送的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关，以供所述运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息；接收所述下行状态报告消息，并对所述下行状态报告消息进行转换处理，得到转换处理后的下行状态报告消息；将所述转换处理后的下行状态报告消息发送至第四服务器，以供所述第四服务器将所述转换处理后的下行状态报告消息发送至客户系统。通过将从第二服务器接收的各渠道下行消息进行消息检测处理后发送至运营商网关，实现了对各渠道下行消息的统一处
理和服务，通过将接收到的运营商发送的下行状态报告消息进行处理并发送至第四服务器，实现了对下行状态报告的统一处理与推送，通过第三服务器、第二服务器、第一服务器以及第四服务器将全套网关服务模块化，极大地简化了运维部署的难度。
36.本发明实施例涉及的技术术语：
37.mq(message queue)消息队列，是基础数据结构中“先进先出”的一种数据结构。一般用来解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。
38.统一消息平台支持发送短信、彩信、富信、5g、aim、微信、app推送等渠道消息，包括单条发送、群发相同内容(纯文本、静态模板、动态模板)、群发不同内容(纯文本、动参文本、动态模板)、策略发送、文件发送。参照图1，图1为现有技术中整套统一消息平台网关服务的架构示意图，如图1所示，各服务之间通过redis中间件进行通信，客户操作统一消息管理后台或者客户自身的系统对接统一消息平台接口进行消息发送，渠道消息下行(mt)、上行(mo)、推送(push)流程具体说明如下:
39.短信和aim消息直接发送：统一消息管理后台或客户侧系统调用短信网关提供的接口接收消息并转到短信转发服务，期间经过一系列的业务处理后，最终发送到运营商网关服务。
40.5g和富信消息直接发送：统一消息管理后台或客户侧系统调用5g接收服务提供的接口接收消息,转到5g业务服务进行相关的业务处理，再依次转到5g转发管理服务及5g转发服务，最终发送到运营商网关服务。
41.微信消息直接发送：统一消息管理后台或客户侧系统调用统一消息接收服务提供的接口接收消息并转到微信转发服务，期间经过一系列的业务处理后，最终发送到运营商网关服务。
42.app推送消息直接发送：统一消息管理后台或客户侧系统调用统一消息接收服务提供的接口接收消息并转到app推送转发服务，期间经过一系列的业务处理后，最终发送到运营商网关服务。
43.邮件消息直接发送：统一消息管理后台或客户侧系统调用统一消息接收服务提供的接口接收消息并转到邮件转发服务，期间经过一系列的业务处理后，最终发送到运营商网关服务。
44.统一消息策略发送：统一消息管理后台或客户侧系统调用统一消息接收服务提供的接口接收消息并转到统一分发服务。经过渠道路由后，若是走短信渠道，则将消息分发给短信网关，走5g或富信渠道，则将消息分发给5g业务服务，通过微信渠道，则将消息分发给微信转发服务，走app推送渠道，则将消息分发给app推送转发服务，走邮件渠道，则将消息分发给邮件转发服务，最终发送到运营商网关服务。
45.上行消息接收：运营商网关服务接收到用户上行消息后，转到统一消息平台的转发服务(不同的消息渠道转到不同的转发服务)，最后进行相关的上行业务处理。
46.短信消息推送:支持将短信消息推送给客户系统能力。
47.但现有技术中由于每一个消息渠道几乎都有一套独立的网关服务，服务太多，对于运维人员来说部署难度较大，并且由于后续统一消息平台还需要支持其他的消息渠道，如终端服务号等，几乎还要开发配套的网关服务，程序不易于扩展，开发成本较大。
48.本发明提供一种解决方案，通过一种基于分布式架构的统一消息渠道网关服务设计，新的技术架构方案各个服务都引入了模块化设计，其中业务接口还实现了标准化以及插件化设计，转发服务对接运营商的接口进行了抽象化设计，整套网关总共四个服务，与之前对比，少了很多个服务，大大降低了运维部署难度，也为后续扩展新消息渠道提供了便利。解决了目前整套网关服务部署难度大，不易于扩展的主要问题。此外，由于本方案中通过单节点技术性能最大化设计，系统整体处理能力可线性扩展，因此具有高性能的特点；由于单个中心内，无单点故障，单节点故障可由其它节点负载工作，节点故障恢复后可立即继续工作，因此具有高可用的特点。
49.具体地，参照图2，图2为本发明消息的处理装置所属终端设备的功能模块示意图。该消息的处理装置可以为独立于终端设备的、能够进行消息的处理的装置，其可以通过硬件或软件的形式承载于终端设备上。该终端设备可以为手机、平板电脑等具有数据处理功能的智能移动终端，还可以为具有数据处理功能的固定终端设备或服务器等。
50.在本实施例中，该消息的处理装置所属终端设备至少包括输出模块110、处理器120、存储器130以及通信模块140。
51.存储器130中存储有操作系统以及消息的处理程序，消息的处理装置可以将接收的所述第二服务器发送的各渠道下行消息、对所述各渠道下行消息进行消息检测处理，得到的消息检测处理后的各渠道下行消息、接收的所述下行状态报告消息，以及对所述下行状态报告消息进行转换处理，得到的转换处理后的下行状态报告消息等信息存储于该存储器130中；输出模块110可为显示屏等。通信模块140可以包括wifi模块、移动通信模块以及蓝牙模块等，通过通信模块140与外部设备或服务器进行通信。
52.其中，存储器130中的消息的处理程序被处理器执行时实现以下步骤：
53.接收第二服务器发送的各渠道下行消息，其中，所述第二服务器接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行消息内容处理，所述第三服务器通过预先添加的标准接口接收所述各渠道下行消息；
54.对所述第二服务器发送的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关，以供所述运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息；
55.接收所述下行状态报告消息，并对所述下行状态报告消息进行转换处理，得到转换处理后的下行状态报告消息；
56.将所述转换处理后的下行状态报告消息发送至第四服务器，以供所述第四服务器将所述转换处理后的下行状态报告消息发送至客户系统。
57.本实施例通过上述方案，通过将从第二服务器接收的各渠道下行消息进行消息检测处理后发送至运营商网关，实现了对各渠道下行消息的统一处理和服务，通过将接收到的运营商发送的下行状态报告消息进行处理并发送至第四服务器，实现了对下行状态报告的统一处理与推送，通过第三服务器、第二服务器、第一服务器以及第四服务器将全套网关服务模块化，极大地简化了运维部署的难度。
58.基于上述终端设备架构但不限于上述架构，提出本发明方法实施例。
59.本实施例方法的执行主体可以为一种消息的处理装置或终端设备等，本实施例以消息的处理装置进行举例。
60.参照图3，图3为本发明消息的处理方法一示例性实施例的流程示意图。所述消息的处理方法应用于第一服务器，所述消息的处理方法包括以下步骤：
61.步骤s10，接收第二服务器发送的各渠道下行消息，其中，所述第二服务器接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行消息内容处理，所述第三服务器通过预先添加的标准接口接收所述各渠道下行消息；
62.在渠道消息下行过程中，当第二服务器对各各渠道下行消息进行处理后，通过mq消息中间件将消息内容处理后的各渠道下行消息传递至第一服务器，通过第一服务器接收各渠道下行消息。其中，第一服务器的结构包括两部分，分别为转发服务业务层和转发服务协议层，转发服务器协议层内部集成netty网络框架对接运营商网关，转发服务业务层处理业务相关。
63.第二服务器对各渠道下行消息进行消息内容处理，包括：对所述各渠道下行消息进行拆包处理，得到业务数据，对业务数据进行消息内容处理：包括对消息基本信息、号段检测、空号检测、携号转网、敏感词、黑名单、白名单以及重发过滤进行校验的过程。
64.步骤s20，对所述第二服务器发送的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关，以供所述运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息；
65.参照图4，图4为本发明实施例中第一服务器下行消息的时序示意图，第一服务器对消息进行消息检测处理，所述消息检测处理包括限速、防重、多主多备以及长短信拆分中的一种或多种处理。
66.具体地，对所述消息内容处理后的各渠道下行消息进行重发过滤，包括删除所述消息内容处理后的各渠道下行消息中相同号码发送的相同内容信息，以防止一段时间内，相同信息内容相同号码重发，其中相同内容的判定规则为：短信或aim智能短信的号码与内容,富信或5g的号码与模板id对应相同即为相同内容；
67.各渠道下行消息在发送的过程中，可能会遇到网络拥塞或运营商网关内部异常等问题，此时要进行下行消息限速，主要通过滑动窗口控制各渠道下行消息的发送速度；
68.进一步地，还需判断所述消息内容处理后的各渠道下行消息中是否包括长短信消息，若所述消息内容处理后的各渠道下行消息中包括长短信消息，则根据所述长短信消息的属性将所述长短信消息拆分为相应字数的短消息。若所述长短信消息是国内短信，则最多1000字，每70个字拆分成一条；若所述长短信消息是英文短信，则最多2000字，每160个字拆分一条，拆分完后分条转发给运营商，运营商网关可以将消息发送给客户。
69.步骤s30，接收所述下行状态报告消息，并对所述下行状态报告消息进行转换处理，得到转换处理后的下行状态报告消息；
70.当第一服务器将所述消息检测处理后的各渠道下行消息发送至运营商网关后，运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息。第一服务器通过其中的转发服务协议层接收所述下行状态报告消息，进而通过转发服务业务层根据所述下行状态报告消息生成下行状态报告话单与待推送状态报告数据，再将所述下行状态报告话单写入数据库，并将所述待推送状态报告数据发送至第四服务器。
71.步骤s40，将所述处理后的下行状态报告消息发送至第四服务器，以供所述第四服
务器将所述处理后的下行状态报告消息发送至客户系统。
72.参照图5，图5为本发明实施例中第四服务器进行消息推送的时序示意图，如图5所示，第四服务器具有将下行状态报告消息推送给客户系统的能力，先由mq消息队列批量获取若干条待推送数据，通过取待推送mq队列数据线程写入待推送内存队列，通过取待推送内存队列数据线程异步读取待推送内存队列数据，并进行滑动窗口判断及打包推送数据，调用客户侧推送接收服务的推送接收接口，进而完成消息推送过程。
73.此外，第四服务器也可将用户上行消息推送至客户系统。当运营商网关接收到用户上行消息后，通过第一服务器的转发服务协议层接收所述运营商网关发送的用户上行消息，再通过转发服务业务层根据用户上行消息生成上行消息接收话单与待推送上行消息数据，进而将所述上行消息接收话单写入数据库，并将所述待推送上行消息数据发送至第四服务器。第四服务器按照与推送下行状态报告消息类似的方式将所述待推送上行消息数据消息发送至客户系统。
74.第一服务器可将现有技术中整套统一消息平台网关服务中的5g和富信消息转发服务、微信转发服务、app推送转发服务、邮件转发服务以及短信转发服务等转发服务进行集成，进一步减少了多个服务，大大降低了运维部署难度。
75.在本实施例中，通过接收第二服务器发送的各渠道下行消息，其中，所述第二服务器接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行消息内容处理，所述第三服务器通过预先添加的标准接口接收所述各渠道下行消息；对所述第二服务器发送的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关，以供所述运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息；接收所述下行状态报告消息，并对所述下行状态报告消息进行转换处理，得到转换处理后的下行状态报告消息；将所述转换处理后的下行状态报告消息发送至第四服务器，以供所述第四服务器将所述转换处理后的下行状态报告消息发送至客户系统。通过将从第二服务器接收的各渠道下行消息进行消息检测处理后发送至运营商网关，实现了对各渠道下行消息的统一处理和服务，通过将接收到的运营商发送的下行状态报告消息进行处理并发送至第四服务器，实现了对下行状态报告的统一处理与推送，通过第三服务器、第二服务器、第一服务器以及第四服务器将全套网关服务模块化，极大地简化了运维部署的难度。
76.参照图6，图6为本发明消息的处理方法另一示例性实施例的流程示意图。所述消息的处理方法应用于第二服务器，所述消息的处理方法包括以下步骤：
77.a10，接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行拆包处理，得到业务数据，其中，所述第三服务器通过预先添加的标准接口接收各渠道发送的各渠道下行消息；
78.在渠道消息下行过程中，第二服务器先通过mq队列中间件接收第三服务器发送的各渠道下行消息，拉取若干条数据后，读取mt接收消息mq数据线程池，经过mt待策略路由队列到策略路由处理线程池，然后对数据进行拆包处理，生成平台流水号。
79.a20，对所述业务数据进行消息内容处理，得到所述消息内容处理后的各渠道下行消息；
80.参照图7，图7为本发明实施例中第二服务器下行消息的时序示意图，如图7所示，
在对各渠道下行消息进行数据拆包处理后，进一步对业务数据进行消息内容处理，包括对消息基本信息、号段检测、空号检测、携号转网、敏感词、黑名单、白名单以及重发过滤进行校验的过程。其中，重发过滤过程与第一服务器中的重发过滤过程相同，包括删除各渠道下行消息中相同号码发送的相同内容信息，以防止一段时间内，相同信息内容相同号码重发。
81.a30，识别所述消息内容处理后的各渠道下行消息的所属通道号；
82.在对业务数据进行校验后，还需识别各渠道下行消息的所属通道号，在渠道路由中，渠道的类型包括短信、aim智能短信、彩信、富信、5g、邮件、微信、app推送等，在本发明实施例中，渠道路由支持的发送类型有两种：一种是直接发送，即指定某个渠道类型进行消息发送；二是业务场景发送，即建立一个业务场景规则，可以规定同时发送多个渠道类型消息，也可以在某个渠道类型消息发送失败时，换其它渠道类型进行消息发送。渠道路由就是要根据发送类型以及消息发送结果来确认接收信息该走哪种消息路由。在识别通道路由之前，由用户客户在统一管理后台建立sp账号，sp账号用于统一接口鉴权以及通道绑定，第二服务器通过sp账号与通道的绑定关系，确认消息使用哪个通道号进行发送。
83.a40，通过所述所属通道号将所述消息内容处理后的各渠道下行消息发送至第一服务器，以供所述第一服务器对所述消息内容处理后的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关。
84.在确定消息内容处理后的各渠道下行消息的所属通道号之后，所述第二服务器即可通过该通道号将消息内容处理后的各渠道下行消息发送至第一服务器，以供第一服务器对所述消息内容处理后的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将消息检测处理后的各渠道下行消息发送至运营商网关，从而完成渠道下行消息过程。
85.在本发明实施例中，通过接收第三服务器发送的各渠道下行消息，并对所述各渠道下行消息进行拆包处理，得到业务数据，其中，所述第三服务器通过预先添加的标准接口接收各渠道发送的各渠道下行消息；对所述业务数据进行校验，得到所述消息内容处理后的各渠道下行消息；识别所述消息内容处理后的各渠道下行消息的所属通道号；通过所述所属通道号将所述消息内容处理后的各渠道下行消息发送至第一服务器。通过第二服务器将各渠道下行消息进行拆包、校验及处理，与第三服务器和第一服务器通过消息队列中间件进行连接，对各渠道下行消息的统一处理和服务，实现了全套网关服务模块化，极大地简化了运维部署的难度。
86.参照图8，图8为本发明消息的处理方法又一示例性实施例的流程示意图。所述消息的处理方法应用于第三服务器，所述消息的处理方法包括以下步骤：
87.b10，通过预先添加的标准接口接收各渠道发送的各渠道下行消息；
88.在系统开发时，常常遇到接口大致相同，但是业务不同的场景，不同业务的实现有所不同。在分工方面，不同的业务场景，可能是由不同的工作人员开发，因此就可以通过插件化的方式，针对不同的业务场景，实现不同的插件，来满足业务的需求。例如客户a要求某个标准接口需要加几个个性化参数，那么可以开发一个满足该要求的个性化接口插件添加到第三服务器，另外要求系统提供短信和富信渠道消息能力即可，那么第二服务器、第一服务器、第四服务器只需要添加短信和富信渠道消息处理能力的插件，其他渠道消息的插件
移除即可。统一消息管理后台的通信管理系统模块，负责所有服务上的插件统一管理。与接入服务、第二服务器，第一服务器、推送服务的通信，通过redis的发布订阅功能进行异步解藕。在渠道消息下行过程中，统一消息管理后台或客户侧系统调用统一消息接收服务提供的标准接口接收各渠道消息，例如5g和富信消息等。
89.b20，将所述各渠道下行消息写入消息队列中间件，通过所述消息队列中间件将所述各渠道下行消息发送至第二服务器，供所述第二服务器对所述各渠道下行消息进行消息内容处理，并将消息内容处理后的各渠道下行消息发送至第一服务器，所述第一服务器对所述消息内容处理后的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至运营商网关。
90.参照图9，图9为本发明实施例中第三服务器渠道消息下行的时序示意图，如图9所示，由统一消息管理后台或客户侧系统调用统一消息标准接口，接收各渠道消息，然后通过netty服务调用业务处理方法，通过业务处理线程进行数据校验、重复请求过滤处理、鉴权处理以及生成流水号等，然后将接收的渠道消息写入内存缓冲队列。通过内存缓冲数据消费线程异步读取数据，再将数据写入mq消息队列，进而传递至第二服务器，以供所述第二服务器对所述各渠道下行消息进行消息内容处理，然后将消息内容处理后的各渠道下行消息发送至第一服务器，再由第一服务器对所述消息内容处理后的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，进而将消息检测处理后的各渠道下行消息发送到运营商网关，从而完成各渠道消息下行的过程。
91.在本实施例中，通过通过预先添加的标准接口接收各渠道下行消息；将所述各各渠道下行消息写入消息队列中间件，以通过所述消息队列中间件将所述各渠道下行消息发送至第二服务器。可以通过统一消息管理后台的通信管理系统模块，负责所有服务上的插件统一管理，与接入服务、第二服务器，第一服务器、推送服务的通信，从而实现通用功能组件化、同类业务插件化、代码模块化设计，所有业务可根据接口标准快速接入，方便扩展和二次开发，简化了运维部署的难度。
92.此外，本发明实施例还提出一种消息的处理系统，所述消息的处理系统包括：
93.若所述第三服务器通过预先添加的标准接口接收各渠道下行消息，通过消息队列中间件将所述各渠道下行消息发送至所述第二服务器；所述第二服务器对所述各渠道下行消息进行消息内容处理后发送至第一服务器；所述第一服务器对所述消息内容处理后的各渠道下行消息进行消息检测处理，得到消息检测处理后的各渠道下行消息，并将所述消息检测处理后的各渠道下行消息发送至所述运营商网关；所述运营商网关根据所述消息检测处理后的各渠道下行消息返回下行状态报告消息；所述第一服务器对所述下行状态报告消息进行转换处理，得到转换处理后的下行状态报告消息并发送至第四服务器；所述第四服务器将所述转换处理后的下行状态报告消息发送至客户系统；
94.若所述运营商网关接收到用户上行消息，将所述用户上行消息发送至所述第一服务器；所述第一服务器通过转发服务协议层接收所述运营商网关发送的用户上行消息；通过转发服务业务层根据所述用户上行消息生成上行消息接收话单与待推送上行消息数据；将所述上行消息接收话单写入数据库，并将所述待推送上行消息数据发送至所述第四服务器，以供所述第四服务器将所述待推送上行消息数据消息发送至客户系统。
95.参照图10，图10为本发明实施例中消息的处理系统的架构示意图，如图12所示，新
的技术架构方案各个服务都引入了模块化设计，其中业务接口还实现了标准化以及插件化设计，转发服务对接运营商的接口进行了抽象化设计，整套网关总共四个服务，与之前对比，少了很多个服务，大大降低了运维部署难度，也为后续扩展新消息渠道提供了便利。对于渠道消息下行(mt)、上行(mo)、推送(push)流程具体说明如下:
96.渠道消息下行:统一消息管理后台或客户侧系统调用统一消息接收服务(即第三服务器)提供的接口接收各渠道消息，通过mq中间件进行消息传递至智能业务服务(即第二服务器)，由智能业务服务对各渠道消息进行相关的处理，如黑名单、白名单、违禁词、携号转网、空号、渠道路由、通道路由、重发过滤等消息内容处理，然后发送至渠道转发服务(即第一服务器)，渠道转发服务处理限速、防重、多主多备、长短信拆分等流程，最终发送到运营商网关服务。
97.上行(mo)和下行状态报告(rpt)消息接收：运营商网关服务将用户上行(mo)消息和下行状态报告(rpt)消息转给渠道转发服务，由渠道转发服务接收并进行相关的消息检测处理。渠道转发服务的结构分为两大部分，分别为转发服务业务层和转发服务协议层，转发服务器协议层内部集成netty网络框架对接运营商网关，转发服务业务层处理业务相关。
98.消息推送:渠道转发服务将消息转发给统一推送服务(即第四服务器)，统一推送服务支持将各渠道上行(mo)消息和下行状态报告(rpt)消息推送给客户系统的能力。
99.在本实施例中，通过统一消息接收服务提供的接口接收各渠道消息；智能业务服务对各所述渠道消息进行消息内容处理处理，得到消息内容处理处理后的消息；通过渠道转发服务对所述处理后的消息进行消息检测，其中，所述渠道转发服务包括转发服务协议层与转发服务业务层；将消息检测处理后的消息发送至运营商网关服务。通过标准化的接口为后续扩展新消息渠道提供了便利，通过统一消息接收服务、智能业务服务以及渠道转发服务将全套网关服务模块化，极大地简化了运维部署的难度。
100.此外，本发明实施例还提出一种终端设备，所述终端设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的消息的处理程序，所述消息的处理程序被所述处理器执行时实现如上所述的消息的处理方法的步骤。
101.由于本消息的处理程序被处理器执行时，采用了前述所有实施例的全部技术方案，因此至少具有前述所有实施例的全部技术方案所带来的所有有益效果，在此不再一一赘述。
102.此外，本发明实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有消息的处理程序，所述消息的处理程序被处理器执行时实现如上所述的消息的处理方法的步骤。
103.由于本消息的处理程序被处理器执行时，采用了前述所有实施例的全部技术方案，因此至少具有前述所有实施例的全部技术方案所带来的所有有益效果，在此不再一一赘述。
104.相比现有技术，本发明实施例提出的消息的处理方法、系统、终端设备以及存储介质，通过标准化的接口为后续扩展新消息渠道提供了便利，通过第三服务器、第二服务器以及第一服务器将全套网关服务模块化，极大地简化了运维部署的难度。新的技术架构方案各个服务都引入了模块化设计，其中业务接口还实现了标准化以及插件化设计，转发服务对接运营商的接口进行了抽象化设计，整套网关总共四个服务，与之前对比，少了很多个服
务，大大降低了运维部署难度，也为后续扩展新消息渠道提供了便利。解决了目前整套网关服务部署难度大，不易于扩展的主要问题。此外，由于本方案中通过单节点技术性能最大化设计，系统整体处理能力可线性扩展，因此具有高性能的特点；由于单个中心内，无单点故障，单节点故障可由其它节点负载工作，节点故障恢复后可立即继续工作，因此具有高可用的特点；由于基于国密算法等安全设计，最大限度实现内外安全校验、内部安全访问、内部数据安全存储等，因此也提高了消息的处理的安全性。
105.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
106.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
107.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上的一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，被控终端，或者网络设备等)执行本技术每个实施例的方法。
108.以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。