著录项信息
专利名称 | 基于RabbitMQ和HAProxy的微服务高可用性部署方法 |
申请号 | CN202011512205.X | 申请日期 | 2020-12-19 |
法律状态 | 授权 | 申报国家 | 暂无 |
公开/公告日 | 2021-04-06 | 公开/公告号 | CN112615666A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | H04B7/185 | IPC分类号 | H04B7/185;H04L67/1008;H04L67/1034;H04L67/01;G06F9/50;G06F9/54;G06F11/14查看分类表>
|
申请人 | 河南方达空间信息技术有限公司 | 申请人地址 | 河南省郑州市自贸试验区郑州片区(郑东)博学路***
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 河南方达空间信息技术有限公司 | 当前权利人 | 河南方达空间信息技术有限公司 |
发明人 | 方圆;李聪;袁莹莹;吴豪杰;赵齐;荣文博;张华;申海桢 |
代理机构 | 郑州优盾知识产权代理有限公司 | 代理人 | 暂无 |
摘要
本发明提出了一种基于RabbitMQ和HAProxy的微服务高可用性部署方法,其步骤为搭载分布式微服务系统的架构,以HAProxy模块为调用入口,RabbitMQ集群作为消息队列;在RabbitMQ节点中设置消息持久化和消息确认机制,并配置RabbitMQ集群,使通信消息可靠传递;定义状态机Saga实例并通过fluent语法定义对应状态机,并将状态机Saga实例注册到ReceiveEndpoint上,实现通信消息数据最终一致性的配置;HAProxy模块中设置KeepAlived,在两个HAProxy服务器的节点上不断进行故障检测。本发明可快速切换备用HAProxy服务器,将系统停运时间减到最小,提高微服务系统的可靠性,同时大大减小了故障损失;且可实现多系统协同运行,灵活部署和扩展性能提升。
1.一种基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,其步骤如下:
步骤一:搭载分布式微服务系统的架构,以HAProxy模块作为系统调用入口,RabbitMQ集群作为消息队列;
HAProxy模块与接入交换机相连接,接入交换机与核心交换机相连接,核心交换机分别与MySQL集群、RabbitMQ集群和微服务节点相连接;
所述MySQL集群的MySQL数据库和RabbitMQ集群的负载均衡都通过HAProxy模块进行控制,微服务节点通过HAProxy模块来访问MySQL集群和RabbitMQ集群;
步骤二:微服务系统中的微服务节点通过MassTransit与RabbitMQ集群中的RabbitMQ节点相连接,在RabbitMQ节点中设置消息持久化和消息确认机制,并配置RabbitMQ集群,使通信消息可靠传递;
步骤三:MassTransit中提供的Automatonymous状态机组件定义状态机Saga实例并通过fluent语法定义对应状态机,并将状态机Saga实例注册到ReceiveEndpoint上,实现通信消息数据最终一致性的配置;
步骤四:HAProxy模块中设置KeepAlived,在两个HAProxy服务器的节点上不断进行故障检测,保证RabbitMQ集群能被正常访问。
2.根据权利要求1所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,所述微服务系统包括HAProxy模块、RabbitMQ集群和微服务节点,接入交换机与接入路由器相连接,接入路由器通过网络与监控系统的客户端相连接。
3.根据权利要求2所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,所述监控系统的服务端包含多个微服务节点,系统可配置连接多个服务端,监控系统上编写程序动态监测所有在线服务端的连接状态,并动态地配置服务端间的主备用关系。
4.根据权利要求3所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,所述RabbitMQ集群中配置多个RabbitMQ节点,RabbitMQ节点通过RPC调用单元与微服务节点的MassTransit消息总线相连接,MassTransit是在消息队列之上构建的消息总线机制,可以集成RabbitMQ节点实现消息订阅、发布、处理的功能;一系列微服务节点整合成服务端,为客户端提供卫星数据接收系统所需的业务逻辑处理和服务;所述MySQL集群中布置多个分布的MySQL数据库,通过集群技术,构成一个虚拟单一的数据库逻辑映像;服务端通过HAProxy模块与MySQL集群连接;所述客户端通过网络连接到HAProxy模块的HAProxy服务器,HAProxy服务器根据负载均衡配置将客户端连接到相应的RabbitMQ集群的RabbitMQ节点,RabbitMQ节点的消息中间件完成客户端与微服务节点中的信息交互,完成消息发布与消息处理。
5.根据权利要求4所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,所述HAProxy模块可配置多个RabbitMQ节点,通过HAProxy服务器里的负载均衡算法计算决定实际连接的RabbitMQ节点;HAProxy模块包括HAProxy服务器I和HAProxy服务器II,HAProxy服务器I和HAProxy服务器II的连接状态检测、连接控制和主备切换通过KeepAlived完成。
6.根据权利要求2或4所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,所述客户端与监控系统服务端的信息交互是通过访问HAProxy模块,由HAProxy模块选择合适的RabbitMQ节点并传递至服务端,由服务端配置系统工作参数或者调度系统执行相关流程,并将系统状态更新反馈至客户端;服务端在执行业务逻辑处理时如果需要反馈给客户端,先把需要反馈的信息封装成一条条RabbitMQ的消息,然后通过HAProxy服务器选择RabbitMQ节点把消息发布出去;客户端也是通过HAProxy服务器来连接RabbitMQ节点,客户端按需订阅RabbitMQ的消息,服务端发布出消息,客户端接收并处理这些消息,完成客户端和服务端之间的信息交互;
所述RabbitMQ集群的配置方法为:假设两个节点都已启动RabbitMQ;把
RabbitMQServer‑A服务器和RabbitMQServer‑B服务器加入集群,在RabbitMQServer‑A服务器上操作;重启RabbitMQServer‑A服务器上RabbitMQ服务;在RabbitMQ指令终端上输入如下命令:rabbitmqctl stop_app,停止RabbitMQServer‑A服务器上的RabbitMQ服务;在RabbitMQ指令终端上输入命令:rabbitmqctl reset,重置RabbitMQServer‑A服务器上的RabbitMQ服务;在RabbitMQ指令终端上输入如下命令:rabbitmqctl join_cluster ‑‑ram rabbit@RabbitMQServer‑B,加入RabbitMQServer‑B集群;在RabbitMQ指令终端上输入命令:rabbitmqctl start_app,启动RabbitMQServer‑A服务器上的RabbitMQ;在RabbitMQ指令终端上输入命令:rabbitmqctl cluster_status,在任意节点查看集群状态。
7.根据权利要求6所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,所述微服务系统是基于API网关的微服务体系,API网关是一个中间层,充当整个系统的服务入口,也作为一种边缘服务将整个系统作为托管的API网关公开给外部用户;所述MassTransit使用RabbitMQ节点的服务作为服务通信的基础设施,RabbitMQ节点由交换机、队列及绑定组成,交换机用于接收生产者发送的消息并将这些消息路由给服务器中的队列;队列用来保存消息直到发送给消费者,消息一直在队列里面,等待消费者连接到队列将其取走;绑定根据路由键规则对交换机与队列进行关联,决定消息发送的方向。
8.根据权利要求7所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,通信消息传递采用的方法为:
a) 设置RabbitMQ节点的交换机、队列和消息都为持久化可以保持不丢失相关通信消息,重点解决消息中间件服务器的异常崩溃而导致的消息丢失问题;
b) 设置消息确认机制,保证消息的产生者知晓消息已经正确到达了目的地;同时保证消息的消费者有足够的时间来处理消息;
通过MassTransit框架提供的API接口配置RabbitMQ节点的消息中间件,实现消息持久化和确认,具体代码为:
消息确认机制:h.PublisherConfirmation=true;
消息持久化:cfg.Durable=true;其中,h表示RabbitMQ服务实体;
PublisherConfirmation表示通信机制设置为确认机制,cfg表示消息实体,Durable表示消息持久化,true表示设置为“真”;
c) 配置RabbitMQ集群保证不会因为任何一台RabbitMQ节点故障而造成系统故障的情况。
9.根据权利要求1或8所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,所述状态机Saga实例中通过一个Guid类型的CorrelationId字段将消息串联起来维护消息的状态,同时MassTransit将NHibernate、EF、MongDB、Redis进行集成,完成状态机Saga实例的持久化工作;NHibernate为对象、关系数据库的映射工具,EF是ORM即对象关系映射框架;MongDB是基于分布式文件存储的数据库;Redis是高性能key‑value数据库;
定义状态机Saga实例的方法为:public Guid CorrelationId(get,set),对应的状态机实例定义为:1)事件和状态的初始化;2)定义状态和事件的关系;3)定义状态;4)定义事件;最后通过MassTransit定义的IRabbitMqBusFactoryConfigurator类的
LoadStateMachine‑Sagas()方法将状态机实例注册到ReceiveEndpoint上,完成通信消息数据最终一致性的配置。
10.根据权利要求9所述的基于RabbitMQ和HAProxy的微服务高可用性部署方法,其特征在于,所述HAProxy服务器I和HAProxy服务器II的配置方法为:
haproxy配置:打开“haproxy.cfg”文件,对haproxy进行配置;
配置全局参数:在“haproxy.cfg”文件中写入:
global
nbproc 1
daemon;
配置默认参数:在全局参数下面写入默认参数;
配置MySQL:使用创建的Haproxy检测用户‘haproxy_root’和检测MySQL状态,并在默认参数下面写入配置参数;
配置RabbitMq:在默认参数下面写入RabbitMq配置参数;
配置状态监控:写入监控配置状态参数;
根据设置的端口及用户名密码,打开监控界面,对MySQL数据库及RabbitMq节点的状态进行监控;
所述KeepAlived的配置在keepalived.conf的配置文件中进行;KeepAlived的配置方法为:配置keepalived全局参数;制作监控HAPproxy进程脚本;配置监控HAPproxy进程参数;配置主用HAPproxy服务器相关参数;配置备份HAPproxy服务器相关参数。
基于RabbitMQ和HAProxy的微服务高可用性部署方法
技术领域
[0001] 本发明涉及服务通信的技术领域,尤其涉及一种基于RabbitMQ和HAProxy的微服务高可用性部署方法。
背景技术
[0002] 遥感卫星数据接收系统主要任务是搜索、跟踪卫星,接收并记录卫星遥感数据、遥测数据及卫星姿态数据。遥感卫星数据接收系统从功能上划分为天伺馈分系统、发射分系统、接收信道分系统、多功能数字基带分系统、调制解调器分系统、监控分系统等。
[0003] 传统遥感卫星数据接收系统的软件系统采用集中式架构,部署结构简单,整个系统的所有业务单元都集中部署在单一节点上,所有功能均通过集中处理。这一定程度上能适应传统遥感地面站的独立部署、功能单一、用户量不多的特点,但也会带来代码耦合,开发维护困难,无法针对不同模块进行针对性优化,扩展性差,单点容错率低等一系列问题。
[0004] 随着遥感领域的快速发展,要求遥感卫星数据接收系统具有更灵活的部署方式,功能业务越来越复杂,同时要具备更高的可用性和可靠性。传统架构的遥感卫星数据接收系统已无法满足日益增长的遥感卫星数据接收需求,主要存在如下不足之处:
[0005] (1) 现有遥感卫星数据接收系统通常采用单客户机/服务器体系架构,设备和软件的冗余备份设计简单,极易出现单点故障,且故障恢复过程复杂,长时间稳定运行性能差,系统可靠性和可维护性较低。
[0006] (2) 传统遥感卫星数据接收系统采用集中式部署,无法适应在目前数据接收业务功能扩展,以及多站多址、多站协同等部署模式,其扩展性和灵活性有限。
发明内容
[0007] 针对现有遥感卫星数据接收系统的可靠性和可维护性较低,扩展性和灵活性有限的技术问题,本发明提出一种基于RabbitMQ和HAProxy的微服务高可用性部署方法,满足遥感卫星数据接收系统的单点控制、异地部署、长时间稳定工作的特点。
[0008] 为了达到上述目的,本发明的技术方案是这样实现的:一种基于RabbitMQ和HAProxy的微服务高可用性部署方法,其步骤如下:
[0009] 步骤一:搭载分布式微服务系统的架构,以HAProxy模块作为系统调用入口,RabbitMQ集群作为消息队列;
[0010] 步骤二:微服务系统中的微服务节点通过MassTransit与RabbitMQ集群中的RabbitMQ节点相连接,在RabbitMQ节点中设置消息持久化和消息确认机制,并配置RabbitMQ集群,使通信消息可靠传递;
[0011] 步骤三:MassTransit中提供的Automatonymous状态机组件定义状态机Saga实例并通过fluent语法定义对应状态机,并将状态机Saga实例注册到ReceiveEndpoint上,实现通信消息数据最终一致性的配置;
[0012] 步骤四:HAProxy模块中设置KeepAlived,在两个HAProxy服务器的节点上不断进行故障检测,保证RabbitMQ集群能被正常访问。
[0013] 所述微服务系统包括HAProxy模块、RabbitMQ集群和微服务节点,HAProxy模块与接入交换机相连接,接入交换机与接入路由器相连接,接入路由器通过网络与监控系统的客户端相连接;所述接入交换机与核心交换机相连接,核心交换机分别与Mysql集群、RabbitMQ集群和微服务节点相连接。
[0014] 所述MySQL集群的MySQL数据库和RabbitMQ集群的负载均衡都通过HAProxy模块进行控制,微服务节点通过HAProxy模块来访问MySQL集群和RabbitMQ集群;所述监控系统的服务端包含多个微服务节点,系统可配置连接多个服务端,监控系统上编写程序动态监测所有在线服务端的连接状态,并动态地配置服务端间的主备用关系。
[0015] 所述RabbitMQ集群中配置多个RabbitMQ节点,RabbitMQ节点通过RPC调用单元与微服务节点的MassTransit消息总线相连接,MassTransit是在消息队列之上构建的消息总线机制,可以集成RabbitMQ节点实现消息订阅、发布、处理的功能;一系列微服务节点整合成服务端,为客户端提供卫星数据接收系统所需的业务逻辑处理和服务;所述Mysql集群中布置多个分布的Mysql数据库,通过集群技术,构成一个虚拟单一的数据库逻辑映像;服务端通过HAProxy模块与Mysql集群连接;所述客户端通过网络连接到HAProxy模块的HAProxy服务器,HAProxy服务器根据负载均衡配置将客户端连接到相应的RabbitMQ集群的RabbitMQ节点,RabbitMQ节点的消息中间件完成客户端与微服务节点中的信息交互,完成消息发布与消息处理。
[0016] 所述HAProxy模块可配置多个RabbitMQ节点,通过HAProxy服务器里的负载均衡算法计算决定实际连接的RabbitMQ节点;HAProxy模块包括HAProxy服务器I和HAProxy服务器II,HAProxy服务器I和HAProxy服务器II的连接状态检测、连接控制和主备切换通过KeepAlived完成。
[0017] 所述客户端与监控系统服务端的信息交互是通过访问HAProxy模块,由HAProxy模块选择合适的RabbitMQ节点并传递至服务端,由服务端配置系统工作参数或者调度系统执行相关流程,并将系统状态更新反馈至客户端;服务端在执行业务逻辑处理时如果需要反馈给客户端,先把需要反馈的信息封装成一条条RabbitMQ的消息,然后通过HAProxy服务器选择RabbitMQ节点把消息发布出去;客户端也是通过HAProxy服务器来连接RabbitMQ节点,客户端按需订阅RabbitMQ的消息,服务端发布出消息,客户端接收并处理这些消息,完成客户端和服务端之间的信息交互;
[0018] 所述RabbtiMQ集群配置方法为:假设两个节点都已启动RabbitMQ;把RabbitMQServer‑A服务器和RabbitMQServer‑B服务器加入集群,在RabbitMQServer‑A服务器上操作;重启RabbitMQServer‑A服务器上RabbitMQ服务;在RabbitMQ指令终端上输入如下命令:rabbitmqctl stop_app,停止RabbitMQServer‑A服务器上的RabbitMQ服务;在RabbitMQ指令终端上输入命令:rabbitmqctl reset,重置RabbitMQServer‑A服务器上的RabbitMQ服务;在RabbitMQ指令终端上输入如下命令:rabbitmqctl join_cluster ‑‑ram rabbit@RabbitMQServer‑B,加入RabbitMQServer‑B集群;在RabbitMQ指令终端上输入命令:rabbitmqctl start_app,启动RabbitMQServer‑A服务器上的RabbitMQ;在RabbitMQ指令终端上输入命令:rabbitmqctl cluster_status,在任意节点查看集群状态。
[0019] 所述微服务系统是基于API网关的微服务体系,API网关是一个中间层,充当整个系统的服务入口,也作为一种边缘服务将整个系统作为托管的API网关公开给外部用户;所述MassTransit使用RabbitMQ节点的服务作为服务通信的基础设施,RabbitMQ节点由交换机、队列及绑定组成,交换机用于接收生产者发送的消息并将这些消息路由给服务器中的队列;队列用来保存消息直到发送给消费者,消息一直在队列里面,等待消费者连接到队列将其取走;绑定根据路由键规则对交换机与队列进行关联,决定消息发送的方向。
[0020] 所述通信消息传递采用的方法为:
[0021] a) 设置RabbitMQ节点的交换机、队列和消息都为持久化可以保持不丢失相关通信消息,重点解决消息中间件服务器的异常崩溃而导致的消息丢失问题;
[0022] b) 设置消息确认机制,保证消息的产生者知晓消息已经正确到达了目的地;同时保证消息的消费者有足够的时间来处理消息;
[0023] 通过MassTransit框架提供的API接口配置RabbitMQ节点的消息中间件,实现消息持久化和确认,具体代码为:
[0024] 消息确认机制:h.PublisherConfirmation=true;
[0025] 消息持久化:cfg.Durable=true;其中,h表示RabbitMQ服务实体;
PublisherConfirmation表示通信机制设置为确认机制,cfg表示消息实体,Durable表示消息持久化,true表示设置为“真”;
[0026] c)配置RabbitMQ集群保证不会因为任何一台RabbitMQ节点故障而造成系统故障的情况。
[0027] 所述状态机Saga实例中通过一个Guid类型的CorrelationId字段将消息串联起来维护消息的状态,同时MassTransit将NHibernate、EF、MongDB、Redis进行集成,完成状态机Saga实例的持久化工作;NHibernate为对象、关系数据库的映射工具,EF是ORM即对象关系映射框架;MongDB是基于分布式文件存储的数据库;Redis是高性能key‑value数据库;
[0028] 定义状态机Saga实例的方法为:public Guid CorrelationId(get,set),对应的状态机实例定义为:1)事件和状态的初始化;2)定义状态和事件的关系;3)定义状态;4)定义事件;最后通过MassTransit定义的IRabbitMqBusFactoryConfigurator类的LoadStateMachine‑Sagas()方法将状态机实例注册到ReceiveEndpoint上,完成通信消息数据最终一致性的配置。
[0029] 所述HAProxy服务器I和HAProxy服务器II的配置方法为:
[0030] haproxy配置:打开“haproxy.cfg”文件,对haproxy进行配置;
[0031] 配置全局参数:在“haproxy.cfg”文件中写入:
[0032] global
[0033] nbproc 1
[0034] daemon;
[0035] 配置默认参数:在全局参数下面写入默认参数;
[0036] 配置MySQL:使用创建的Haproxy检测用户‘haproxy_root’和检测MySQL状态,并在默认参数下面写入配置参数;
[0037] 配置RabbitMq:在默认参数下面写入RabbitMq配置参数;
[0038] 配置状态监控:写入监控配置状态参数;
[0039] 根据设置的端口及用户名密码,打开监控界面,对MySQL数据库及RabbitMq节点的状态进行监控;
[0040] 所述KeepAlived配置都在keepalived.conf的配置文件中;KeepAlived配置的方法为:配置keepalived全局参数;制作监控HAPproxy进程脚本;配置监控HAPproxy进行参数;配置主用HAPproxy服务器相关参数;配置备份HAPproxy服务器相关参数。
[0041] 与现有技术相比,本发明的有益效果。
[0042] (1) 可靠性提升
[0043] HAProxy模块通过HAProxy负载均衡集群技术,在卫星数据接收系统发生故障时,快速切换备用HAProxy服务器,在故障发生时仍可以继续工作,将系统停运时间减到最小,系统的平均无故障时间MTBF(Mean Time Between Failure)和平均修复间隔MTTR(Mean Time to Repair)的指标大幅提高,提高微服务系统的可靠性,同时也大大减小了故障损失。
[0044] (2) 灵活部署和扩展性能提升
[0045] 采用分布式架构使得系统可以以较低成本快速实现扩展和多点部署,同时部署多个服务端和多个客户端,主备间实现灵活热切换。针对分布式布站需求,可快速搭建软件,并实现多系统协同运行。
附图说明
[0046] 为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
[0047] 图1为本发明的微服务系统的原理图。
[0048] 图2为RabbitMQ基本概念图。
[0049] 图3为本发明RabbitMQ集群的配置流程方法。
[0050] 图4为本发明状态机的定义流程图。
[0051] 图5为本发明HAProxy服务器配置的流程图。
[0052] 图6为本发明Haproxy服务器配置的代码。
[0053] 图7为本发明KeepAlived配置的流程图。
具体实施方式
[0054] 下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
[0055] 一种基于RabbitMQ和HAProxy的微服务高可用性部署方法,其步骤如下:
[0056] 步骤一:搭载分布式的微服务系统的架构,以HAProxy模块作为系统调用入口,RabbitMQ集群作为消息队列。
[0057] 如图1所示,微服务系统包括HAProxy模块、RabbitMQ集群和微服务节点,HAProxy模块与接入交换机相连接,接入交换机与接入路由器相连接,接入路由器通过网络与监控分系统客户端相连接;所述接入交换机与核心交换机相连接,核心交换机分别与Mysql集群、RabbitMQ集群和微服务节点相连接。接入交换机和接入路由器用于构建完整网络连接,将客户端、服务端(微服务节点)、HAProxy服务器、Mysql数据库、RabbitMQ节点等连接起来。
MySQL集群的数据库和RabbitMQ集群的负载均衡都通过HAProxy模块进行控制,微服务节点通过HAProxy模块来访问MySQL集群和RabbitMQ集群。
[0058] 卫星数据接收系统的监控系统服务端包含多个微服务节点,可在核心交换机上连接多个监控系统服务端,其主备用关系通过程序进行控制。通过监控系统的程序来动态监测所有在线服务端的连接状态,并动态地配置服务端间的主备用关系。当主用服务端无法访问时,程序控制将备用服务端切换为主用。RabbitMQ集群中配置多个RabbitMQ节点。
[0059] 系统的用户可以是外部软件,也可以是卫星数据接收系统的监控系统客户端,多个监控系统客户端/外部软件可以同时连接到接入路由器访问监控系统服务端。如果服务端配置了主备用关系,则多个客户端都访问一个主用服务端,其它服务端作为备用。当主用服务端宕机时,用程序控制切换,将其中一台备用服务端切换为主用,供客户端访问。
[0060] HAProxy服务器是系统访问入口,客户端通过网络连接到HAProxy服务器,HAProxy服务器根据其负载均衡配置,将客户端连接到相应的RabbitMQ集群的RabbitMQ节点,RabbitMQ节点的消息中间件完成客户端与服务端(微服务节点)中的信息交互,完成消息发布与消息消费处理。例如,服务端通过RabbitMQ节点发布消息,客户端通过RabbitMQ节点订阅消息,并完成消息的处理;也可以是客户端通过RabbitMQ节点发布消息,服务端通过RabbitMQ节点订阅消息,并完成消息的处理。服务端指的是卫星数据接收系统/监控系统的服务端,可由一系列微服务节点整合而成,为客户端提供卫星数据接收系统所需的业务逻辑处理和服务。
[0061] Mysql集群的作用是,可以布置多个分布的Mysql数据库,提供数据库的冗余和备份功能,通过集群技术,构成一个虚拟单一的数据库逻辑映像,但对于连接到该虚拟单一的数据库逻辑映射的服务端而言,就像是连接到一个Mysql数据库一样。服务端是通过HAProxy模块与Mysql集群连接。假设Mysql集群里有两个Mysql数据库,数据库A和数据库B,分布于两台计算机上,两者的数据是互为备份的,数据库A的数据进行更新,相应的数据更新将同步到数据库B上。HAProxy服务器里,两个数据库都进行了配置,并设置一个统一的虚拟的数据库连接地址,服务端通过连接HAProxy服务器访问数据库时,实际访问的可能是数据库A也可能是数据库B,但是对于服务端而言,并不需要关心这一点。如果数据库A不可用,HAProxy服务器会切换数据库B,来供服务端访问。
[0062] HAProxy模块包括HAProxy服务器I和HAProxy服务器II,HAProxy服务器I和HAProxy服务器II通过KeepAlived实现连接状态检测和切换。RabbitMQ集群由至少一个RabbitMQ节点组成,RabbitMQ节点通过RPC调用单元与微服务节点的MassTransit消息总线相连接, MassTransit是在消息队列之上构建的消息总线机制,可以集成RabbitMQ节点实现消息订阅/发布/处理等功能。本发明用MassTransit总线通过RPC机制调用RabbitMQ节点来实现发送/接收消息等具体功能。微服务节点中的Nhibernate是一个对象/关系数据库映射工具。采用Log4Net以提供便捷的日志信息输出。Autofac是一个IoC依赖注入容器。
[0063] 客户端与服务端的信息交互通过访问HAProxy模块,由HAProxy模块选择合适的RabbitMQ节点并传递至服务端,由服务端配置系统工作参数或者调度系统执行相关流程,并将系统状态更新反馈至客户端。HAProxy模块会配置多个RabbitMQ节点,选择使用哪个RabbitMQ节点是通过HAProxy服务器里的负载均衡算法计算决定的。在HAProxy服务器上,虚拟一个RabbitMQ节点,对于服务端而言,直接连接的是HAProxy服务器设置的这个虚拟RabbitMQ节点,实际的RabbitMQ节点连接,通过HAProxy服务器进行选择。配置系统工作参数或者调度系统执行相关流程是服务端具备的业务功能,比如说配置跟踪卫星的设备参数,和调度跟踪卫星的流程。服务端同时也具备更新系统状态等业务功能,比如说服务端执行到跟踪卫星流程里的第一步,相应的状态上报给客户端,客户端界面则可显示这一流程执行的进度状态。具体实现过程是:服务端在执行业务逻辑处理时,将需要向客户端反馈的信息封装成一条条RabbitMQ的消息,然后通过HAProxy服务器选择的那个RabbitMQ节点,把消息发布出去;客户端也是通过HAProxy服务器来连接RabbitMQ节点,客户端可以按需订阅RabbitMQ的消息,服务端发布出消息,客户端可以收到并处理相应的消息,完成客户端和服务端之间的信息交互。
[0064] 多个服务端可以连接到核心交换机,通过程序控制其主备用关系。服务端通过HAProxy服务器访问MySQL数据库和RabbitMQ节点。多个客户端可以连接到接入路由器,并连接到HAProxy服务器,进而连接到RabbitMQ节点,通过RabbitMQ节点与主用的监控系统服务端进行信息交互。
[0065] 本发明采用集成HAProxy、KeepAlived、MassTransit、RabbitMQ中间件搭建微服务系统的架构,可以很好支持.net框架下开发的微服务系统的软件应用的运行。微服务系统本质上是由一组服务的集合,每个服务都实现了单个轻量级的业务功能,并且每个服务之间都是松耦合关系,在最理想的情况下,每个服务都可以独立地开发、测试、发布、部署、扩展、集成和维护。要使微服务架构真正成功,需要解决跨服务/系统之间的问题,比如:
[0066] (1)服务注册与发现:启用服务查找并查找服务端点的机制;
[0067] (2)高可用性:服务在故障期间自动采取纠正行动的机会;
[0068] (3)服务通信:服务之间提供可靠的消息传递。
[0069] 步骤二:微服务系统中的微服务节点通过MassTransit与RabbitMQ集群中的RabbitMQ节点相连接,在RabbitMQ节点中设置消息持久化和消息确认机制,并配置RabbitMQ集群,使通信消息可靠传递。
[0070] 本发明的微服务系统设计基于API网关风格的微服务体系,API网关是一个中间层,其充当整个系统的服务入口,也可以作为一种边缘服务来将整个系统作为托管的API网关公开给外部用户。服务入口指的是HAProxy服务器和RabbitMQ节点等组成的这一个体系。
客户端/或者其他软件通过网络连接进来,采用相应的软件接口就可以访问到服务端及微服务节点。微服务节点具有服务注册与发现、负载均衡、高可用、数据最终一致性等功能。本发明通过使用HAProxy和KeepAlived相互组合实现基于微服务访问的高可用性,负载均衡和故障迁移,通过MassTransit和RabbitMQ集群完成整个系统的服务通信可靠传递、服务注册与发现和数据最终一致性。
[0071] 微服务系统本质上是一个分布式软件系统,各个服务节点之间或者与外部用户的通信需要考虑通信消息可靠传递、通信消息的数据最终一致性等问题。针对这些问题,本发明采用MassTransit框架来完成微服务之间的通信。MassTransit是一个自由、开源、轻量级的消息总线,用于使用.net框架创建分布式应用程序。MassTransit在现有消息传输上提供了一组广泛的功能,从而使开发人员能够友好地使用基于消息的会话模式异步连接服务。
[0072] MassTransit默认使用RabbitMQ服务作为服务通信的基础设施,RabbitMQ是一个开源的消息代理和队列服务器,通过AMQP协议在完全不同的应用之间共享数据,或者简单地将作用排队以便让分步式服务器进行处理。RabbitMQ由交换机(Exchange)、队列(Queue)以及绑定(Binding)组成,如图2所示,交换机用于接收生产者发送的消息并将这些消息路由给服务器中的队列;队列用来保存消息直到发送给消费者,是消息的容器,消息一直在队列里面,等待消费者连接到这个队列将其取走;绑定根据路由键规则对交换机与队列进行关联,决定消息发送的方向。图2中Publisher是消息生产者,也是一个向交换器发布消息的客户端应用程序;Broker是消息队列服务器实体,作为RabbitMQ服务的载体;Connection是连接关系,用于应用程序与消息队列服务器实体进行关联连接;Channel是消息通道,每一个消息通道代表一个回话任务,所有操作可在消息通道中进行;Consumer是消息消费者,标识从消息队列中取得消息的客户端应用程序。
[0073] 通信消息在分布式系统中传递是不可靠,通信消息代理节点或者通信消息消费节点的异常、链路的不正常都会造成通信消息的丢失。为了保证消息的可靠传递可以采用如下方法:
[0074] a) 设置RabbitMQ节点的交换机、队列和消息都为持久化可以保持不丢失相关通信消息,重点解决消息中间件服务器的异常崩溃而导致的消息丢失问题;
[0075] b) 设置消息确认机制,保证消息的产生者知晓消息已经正确到达了目的地;同时保证消息的消费者就有足够的时间来处理消息,不用担心处理消息过程中消息的消费者进程挂掉后消息丢失的问题,因为RabbitMQ节点会一直等待并持有消息,直到消息的消费者确认了该消息。消息的产生者指产生消息的程序实体;消息的消费者指接收并使用消息的程序实体。
[0076] 通过MassTransit框架提供的API接口可以配置RabbitMQ消息中间件,实现消息持久化和确认,具体代码为:消息确认机制:h.PublisherConfirmation=true;
[0077] 消息持久化:cfg.Durable=true。其中,h表示RabbitMQ服务实体;
PublisherConfirmation表示通信机制设置为确认机制,cfg表示消息实体,Durable表示消息持久化,true表示设置为“真”。
[0078] c) 通过配置RabbitMQ集群,保证不会因为任何一台RabbitMQ节点故障而造成系统故障的情况。RabbtiMQ集群配置方法,如图3所示,假设两个节点都已启动RabbitMQ;把RabbitMQServer‑A和RabbitMQServer‑B加入集群,在RabbitMQServer‑A上操作;重启RabbitMQServer‑A上RabbitMQ服务;在RabbitMQ指令终端上输入如下命令:rabbitmqctl stop_app,停止RabbitMQServer‑A上的RabbitMQ;在RabbitMQ指令终端上输入如下命令:
rabbitmqctl reset,重置RabbitMQServer‑A上的RabbitMQ;在RabbitMQ指令终端上输入如下命令:rabbitmqctl join_cluster ‑‑ram rabbit@RabbitMQServer‑B,加入RabbitMQServer‑B集群;在RabbitMQ指令终端上输入如下命令:rabbitmqctl start_app,启动RabbitMQServer‑A上的RabbitMQ;在RabbitMQ指令终端上输入如下命令:rabbitmqctl cluster_status,在任意节点查看集群状态。
[0079] 步骤三:MassTransit中提供的Automatonymous状态机组件定义状态机Saga实例并通过fluent语法定义对应状态机,并将状态机Saga实例注册到ReceiveEndpoint上,实现通信消息数据最终一致性的配置。
[0080] 分布式系统的数据最终一致性是数据对象在没有新的更新前,最终所有获取数据的请求都将返回最后更新值。在分布式环境微服务系统的架构下,不同微服务都有自己的数据源,如果多阶段事务执行中任务一个阶段失败都会造成数据的不一致性,这就需要保证多服务之间的事务型事务执行时业务交易的数据一致性又保证从多个服务获得一致性数据的可用性。
[0081] 本发明的微服务系统的框架是通过MassTransit提供的Saga组件可以保证分布式系统的数据一致性。Saga组件最早由Hector Garcia‑Molina和Kenneth Salem在1987年提出,作为分布式事务的代替品已解决长时间运行的分布式事务问题。
[0082] MassTransit中提供了Automatonymous状态机组件定义状态机Saga实例并通过fluent语法定义对应状态机。状态机Saga实例中通过一个Guid类型的CorrelationId字段将消息串联起来,来维护消息的状态,同时MassTransit还可以将NHibernate,EF,MongDB,Redis进行集成,完成状态机Saga实例的持久化工作。NHibernate为对象/关系数据库映射工具,EF是ORM,对象关系映射框架(数据持久化框架);MongDB是基于分布式文件存储的数据库;Redis是高性能key‑value数据库。实现的系统里没有采用EF:ORM/ MongDB/ Redis这些框架或数据库,这里提到是说明系统未来可以将这些集成进来,具有巨大的可扩展性。
[0083] 定义状态机Saga实例的方法为:public Guid CorrelationId(get,set),其对应状态机实例定义参见图4所示,1)事件和状态的初始化;2)定义状态和事件的关系;3)定义状态;4)定义事件。最后通过MassTransit定义的IRabbitMqBusFactoryConfigurator类的LoadStateMachine‑Sagas()方法将状态机实例注册到ReceiveEndpoint上,完成通信消息数据最终一致性的配置。
[0084] 微服务环境中微服务的实例会依据运行环境和业务要求动态的变化,这时要实现服务注册与发现变得相对更加复杂。本发明因采用RabbitMQ作为通信机制,服务调用者(监控系统服务端)和微服务的实例之间完全进行了解耦,服务的调用者无需知道微服务的实例的存在,反之亦然。只要服务调用者能将服务调用消息发送至RabbitMQ节点,RabbitMQ节点就能将服务调用消息转发到可用的微服务的实例上,这一切对服务调用者是完全透明的。
[0085] 步骤四:HAProxy模块中设置有KeepAlived,在两个HAProxy服务器的节点上不断进行故障检测,保证RabbitMQ集群能被正常访问。
[0086] 本发明采用微服务系统架构将业务逻辑分散到了各个微服务当中,微服务间通过网络层进行通信。网络通信带来了额外的延迟和复杂性,需要多个物理组件和逻辑组件共同协作,这些组件都有可能出现故障。
[0087] 为了最小化局部故障所带来的影响,本发明采用HAProxy和KeepAlived实现整个微服务框架的高可用性访问。HAProxy服务器是WillyTarreau开发的一款提供高可用性、负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理开源软件。HAProxy服务器支持虚拟主机、全透明代理、连接拒绝等功能,可以很简单安全的整合进现有系统的架构中,其支持节点轮询算法、节点权重轮询、最少用户算法、源IP地址算法、URI选择算法等多种负载均衡的算法。
[0088] KeepAlived是一个基于虚拟路由器冗余协议VRRP(Virtual Router Redundancy Protocol)来实现的服务高可用方案,其能实现多机热备需求的一款开源软件,利用Keepalived所提供的浮动IP功能,可以简单实现一个多机热备的高可用功能。
[0089] 如图1所示,HAProxy服务器I和HAProxy服务器II提供对RabbitMQ集群访问,通过设置KeepAlived,在HAProxy服务器I和HAProxy服务器II的节点上不断进行故障检测保证RabbitMQ集群能被正常访问。在接入交换机后配置HAProxy服务器I和HAProxy服务器II实现对RabbitMQ集群的负载均衡,当用户访问量急剧增长时,能够有效的解决RabbitMQ集群中的单台服务器成为访问瓶颈的问题。KeepAlived不断检测HAProxy服务器I和HAProxy服务器II的状态,若HAProxy服务器I宕机或则工作出现故障,自动完成故障迁移由HAProxy服务器II为用户提供访问服务,待用HAProxy服务器I恢复正常,KeepAlived自动将其加入到检测集群中,不需要人工干预,保证整体系统的高可用。如图6所示,Haproxy服务器的配置主要代码。
[0090] 如图5所示,HAProxy服务器I和HAProxy服务器II的配置方法为:
[0091] haproxy配置:打开“haproxy.cfg”文件,对haproxy进行配置。
[0092] 配置全局参数:在“haproxy.cfg”文件中写入如下内容:
[0093] global
[0094] nbproc 1
[0095] daemon;
[0096] 配置默认参数:
[0097] 在全局参数下面写入默认参数,内容如下:
[0098] defaults
[0099] mode tcp
[0100] retries 3
[0101] option abortonclose
[0102] maxconn 2000
[0103] timeout http‑keep‑alive 10s
[0104] timeout check 3s
[0105] log 127.0.0.1 local0 err
[0106] 配置MySQL:使用创建的Haproxy检测用户‘haproxy_root’和检测MySQL状态,并在默认参数下面写入如下配置参数,内容如下:
[0107] listen mysql
[0108] bind *:7777
[0109] mode tcp
[0110] balance leastconn
[0111] timeout client 8h
[0112] timeout server 8h
[0113] timeout connect 80000ms
[0114] option tcpka
[0115] option clitcpka
[0116] option mysql‑check user haproxy_root
[0117] option redispatch
[0118] server Server‑B localhost:3306 check inter 500 fastinter 300 rise 2 fall 2
[0119] server Server‑A 192.168.128.10:3306 check inter 500 fastinter 300 rise 2 fall 2
[0120] 配置RabbitMq:在默认参数下面写入RabbitMq配置参数,内容如下:
[0121] listen rabbitMq
[0122] bind *:9999
[0123] mode tcp
[0124] balance roundrobin
[0125] timeout connect 5s
[0126] timeout client 3h
[0127] imeout server 3h
[0128] server Server‑A 192.168.128.10:5672 check inter 1s fastinter 500 rise
2 fall 2
[0129] server Server‑B 192.168.128.11:5672 check inter 1s fastinter 500 rise
2 fall 2
[0130] listen rabbitMqCtrl
[0131] bind *:9998
[0132] timeout connect 5s
[0133] timeout client 5s
[0134] timeout server 5s
[0135] option redispatch
[0136] option httpchk
[0137] option forwardfor
[0138] mode http
[0139] balance leastconn
[0140] server Server‑A 192.168.128.10:15672 check inter 2s rise 2 fall 3[0141] server Server‑B 192.168.128.11:15672 check inter 2s rise 2 fall 3 backup
[0142] 配置状态监控:最后写入监控配置状态参数,内容如下:
[0143] listen status
[0144] bind 0.0.0.0:8888
[0145] mode http
[0146] timeout connect 5s
[0147] timeout client 5s
[0148] timeout server 5s
[0149] stats refresh 30s
[0150] stats uri /
[0151] stats auth admin:admin
[0152] stats hide‑version
[0153] stats admin if TRUE
[0154] 根据设置的端口及用户名密码,打开监控界面,对MySQL数据库以及RabbitMq节点的状态进行监控。
[0155] 如图7所示,KeepAlived配置的方法为:配置keepalived全局参数;制作监控HAPproxy进程脚本;配置监控HAPproxy进行参数;配置主用服务器相关参数;配置备份服务器相关参数。
[0156] KeepAlived的配置全都在keepalived.conf的配置文件中,如图6所示。
[0157] 本发明提供了一种以系统客户端软件加上HAProxy模块作为系统调用入口,RabbitMQ集群作为消息队列,利用了HAProxy模块负载均衡集群特性及RabbitMQ集群的高可靠性的遥感卫星数据接收系统的高可用性部署方法,增加了系统部署的灵活性、可靠性以及可维护性。
[0158] 以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
法律信息
- 2022-07-15
- 2021-04-23
实质审查的生效
IPC(主分类): H04B 7/185
专利申请号: 202011512205.X
申请日: 2020.12.19
- 2021-04-06
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有引用任何外部专利数据! |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |