Rabbitmq消息中心_消息中心总体方案

消息中心方案

一、消息中心简介

为了将各个应用系统之间进行业务解耦，对业务的透明化处理及技术架构的统一管理，方便对各应用的整体把控，保证系统的稳定性，也方便各应用的消息中间件的快速搭建，因此搭建消息中心，提供整体的解决方案。
相对于传统应用间定时或事件驱动获取数据的方式，使用消息中心让各应用感知其他应用的变动，采用主动推送的方式对数据的变化进行通知。
二、消息中心业务场景

2.1应用系统间解耦合

应用之间的业务耦合过深，应用中的单个服务不可用可能会导致大面积的业务故障。

2.2
异步

应用中或应用间的业务调用存在同步方法，调用时间过长导致性能下降，用户体验差。例如用户登录时，需要记录用户的审计日志等信息，需要消耗时间，但是这是用户登录所不必须的，使用消息中心后可异步实现，从而节约不必要的时间，快速登录提高用户的登录体验。
2.3
业务数据变化通知

各应用之间的数据变化需要通知其他应用并做相应的数据处理，比如基础数据的业务变化需要通知到相关的业务系统。

 

2.4
业务事件通知

各业务系统的通知、提醒、待办、待阅等信息发送到消息中心，由消息中心再发送到对应的负责人。

2.5
流量控制

流量控制，可以对大数据量的数据上传通过消息中心异步保存，提高系统的性能和稳定性。

2.6
大数据交换空间

应用中有大量历史数据需要迁移或者需要大数据量进行进行堆积处理，可通过消息中心进行中转。

三、消息中心结构组成

3.1
认证授权和访问控制

1）认证授权

第一：检查链接消息中心的用户是否有使用虚拟主机的权限，如果没有拒绝链接；

第二：检查是否有权限操作虚拟主机中的资源（交换机和队列）。

通过以上的检查机制，消息中心可以对用户能够访问的资源列表进行控制，从而达到管理的目的。

2）访问控制

对以上的认证授权机制外，还可以对接入消息中心的客户端（发送端和接收端）使用ip列表和接入的服务端检查进行访问控制,可使用插件rabbitmq_auth_backend_ip_rang或rabbitmq_auth_backend_amqp；

3.2 可靠性

消息发送的可靠性需要保证：消息发送者把消息发送到消息中心，消息中心的消息存储和消息中心把消息投递给消息接收者。

其中消息中心与消息发送端和接收端部门需要消息发送一致性进行支持，数据操作与消息发送放置在同一事务中，要不同时成立要不同时不成立。对于消息中心本身的稳定及存储安全保证设计一下的架构进行保证：

对最终消息架构选型Rabbitmq集群部署，并提供只是一个的磁盘节点（Disc）和多个内存节点。使用HAProxy对集群进行负载均衡分发，还可以对HAProxy进行主备部署用Keepalived进行负载。

3.3
安全

消息中心的发生端和接收端的安全主要基于ssl和ca认证进行安全管理，可参见《消息中心安全方案》。

3.4
消息追踪

发送的所有消息进行记录，能够进行查找追踪，可使用插件rabbitmq_tracing(该插件官方标注为实验性插件)，详细信息参见《消息追踪方案》。

3.5
消息日志分析

对于发送的消息进行转存，然后根据数据的进行各种维度的分析。

 

四、消息中心对应用的支持

各应用接入消息中心时候，根据不同的业务要求消息中心需要提供以下支持：

4.1
消息发送一致性

消息发送与应用的业务操作要求强一致性（两者要不同时成立要不同时失败）的需要提供相应的支持，具体可参见《消息中心一致性方案》。消息发送的一致性要求保证与返回消息状态的速度成反比，平台可以根据消息发送一致性强弱要求和对性能的要求提供一下三种方案。

1）同步方式的完全一致性

将发送消息和业务操作在发送端用进行事务管理，该情况是采用同步方式进行支持，发送消息的效率会比较慢，但是是唯一能保证完全一致性的方案。
2）异步到交换器的一致性

异步到交换器的一致性是指业务的操作与消息的发送同样采用事务进行管理，但是消息一致性要求不是特别高（比如登录大平台的时候会产生一条登录的审计信息，但是该消息有没有被接收端接收，对平台的影响可以忽略并且相关数据的数据量特别大，则可采用该一致性方案）。该方案的消息保证消息进入交换器后异步返回结果。
3）异步到消费端的一致性

异步到消费端的一致性是指数据一致性和处理性能都有一定要求的情况下，消息发送端异步感知消费端对消息的处理。
4.2
消息发送优先级设置

当消息中心内部消息堆积量比较大的时候，消息发送的优先级直接关系到消息接收时效性，并且在同步一致性的情况下直接影响发送的应用的反应效率。

 

4.3
消息延迟发送

延迟消息消息是指消息发送端发送指定时间后消息接收端才接收到消息。比如用户添加一张订单后，要求在30分钟之内进行付款，那可以要求消息发送端发送消息30分钟后接收端再去检查用户的付款情况，并做相应处理。

延迟发送（具体参见《消息中心延迟发送方案》）：

1）可以通过rabbitmq-delayed-message-exchange插件实现；

2）需要rabbitmq的ttl与dle进行实现，延迟可以。架构大致如下：

 

4.4
保证消息顺序

保证消息顺序：对于多条依赖顺序的消息表达一个信息的时候，需要消息消费者可以识别多条消息的顺序性，以正确读取消息的内容。应用场景：例如先后发送两天消息，对同意用户修改信息和删除用户，接收端接收的消息是先进行删除操作，在进行修改操作。

 

4.5
重复消息处理

由于消息发送各个环节、消息发送内部机制等原因，可能会导致一条消息发送之后消息接收端接收到多条同样的消息，此时需要消息接收端能够判断并处理相同消息或消息中心保证同一条消息消费端只接收一次。

五、应用接入管理办法

为了方便各应用能快速接入消息中心加快开发进度，方便消息中心对接入的应用进行统一管理，也为后续消息中心进行消息发送的日志和统计信息等开展（对消息中心的健壮性功能性的扩展），从以下方面制定接入消息中心的管理办法（具体参见《消息中心接入管理办法》）：

5.1
应用管理

1）对所有的铁路管理系统的应用进行编号和编码命名（比如基础平台编号为1，编码为base，即时通编号为5为jst）。
2）接入消息中心时为该应用创建命名的用户进行管理：一对一或一对多情况，在按照发送端的应用创建的用户内部创建虚拟主机，并创建相应的资源（exchange和queue）；多对一的情况按照接收端的应用创建的用户内部创建虚拟主机；多对多创建单独的应用并在内部进行关联；
3）按照以上的管理办法为每一类消息进行统一的资源编号，并且进行全局统一管理（比如平台1的审计信息和登录审计的编号为1-1和1-2）。
5.2
消息体管理

1）消息设置唯一ID进行管理；

2）消息应用包含所属应用的编号，如平台1消息编号为1；

3）消息设置发送时间（方便追踪）；

 

六、应用接入

7.1
前期对接

各应用接入消息中心需要满足以上的场景，若不符合以上场景却想接入的需要与基础平台组进行沟通，提出接入理由和应用场景等等。最后取得基础平台组同意。

7.2
填写接入对接文档

按照《消息中心接入方案模板》填写接入消息中心的一下信息：

1）发送方、接收方；

2）消息发送的数据量；

3）大致消息内容；

4）对消息发送一致性的要求；

5）消息发送的优先级；

6）是否需要支持延迟发送消息；

7）是否需要支持消息发送顺序控制；

8）重复发送消息处理的支持。

7.3
审核并接入

对接入文档进行审核，并分析应用现有消息中心是否对即将接入的应用的业务支持，并按照以上的”应用接入管理办法”为应用创建接入条件，并进行统一管理。