分布式消息系统技术方案

本申请公开了一种分布式消息系统，包括：集群；指标采集器，用于从所述集群采集监控指标；运维管理系统，通过所述指标采集器进行指标数据的查询和读取，并下发客户端资源元数据以使应用使用资源。本申请的目的至少在于，能够提供可视化的运维监控和安全性的运维平台从而更有效解决生产中集群可能发生的故障。

Distributed message system

【技术实现步骤摘要】
分布式消息系统
本申请涉及分布式消息系统的集群运维管理
，具体来说，涉及一种分布式消息系统的集群运维管理方法和装置。
技术介绍
分布式消息作为中间件成员中不可缺失的部分，在目前绝大部分的系统架构中都使用分布式消息来解决系统或应用间异步通讯的问题。分布式消息经历了多次重大的架构升级后，核心技术架构已日趋成熟。现阶段主流的开源分布式消息系统都是基于Topic(主题)和Group(组)的概念实现整个分布式消息系统。其中，ApacheKafka、ApacheRocketMQ(RocketMetaQueue，开源的消息中间件)、ApachePulsar是开源分布式消息系统大军中的领军代表。越来越多的系统或应用使用分布式消息系统来实现系统或应用间的异步解耦、削峰限流等功能来提升自身系统或应用的高并发性能，以及保障系统或应用的安全性和稳定性。然而，即使是再成熟的系统，也离不开日常的监控巡查，也离不开出现异常问题的处理，更离不开人工的参与。在分布式消息系统中，一个或多个物理集群构成整个分布式消息的整体逻辑服务形态，在一个简单的集群中至少包含3-5台物理或虚拟服务节点。如此庞大的服务节点规模给运维带来了巨大的压力和挑战。因此，分布式消息系统非常需要一套完善的可视化的运维工具，帮助开发人员和运维人员高效地完成日常巡检，问题处理等工作。经调研，ApacheKafka、ApacheRocketMQ和ApachePulsar作为目前几款主流的分布式消息系统，在可视化运维工具方面都存在诸多问题。例如，ApacheKafka作为大数据、流处理首选的分布式消息系统，原生只提供了命令行工具来获取Kafka集群运行时的监控数据。命令行代码效率极低，交互性较差，而且提供的监控数据极为有限，对开发人员和运维人员日常监控和问题排查带来了极大的困难。而ApacheRocketMQ作为后起之秀，在金融等高安全、高要求的领域占有一席之地。RocketMQ原生除了提供类似Kafka一样的命令行工具外，也提供了原生的可视化控台。与kafka相比，以及较大的降低了开发人员和运维人员使用的难度，提升了运维工作的效率。但是，RocketMQ原生可视化控台无论从功能性，还是可视化角度都略显简陋。现有技术存在的问题：ApacheRocketMQ提供了一套简单可视化控台RocketMQConsole。RocketMQConsole可以简单的监控集群的配置、实时的健康状态，消息流入流出的统计等功能。RocketMQConsole在权限方面没有做任何控制，作为一款在生产环境运行的管理系统，权限本身就是保障安全的第一道关卡。RocketMQConsole本身除了提供简单的运维监控功能外，还提供了直接对集群产生直接影响的多种操作。例如：创建Topic、删除Topic、创建Group、删除Group等等。诸如此类的操作都有可能威胁到集群的稳定性和安全性。没有权限的保障，任何有权访问RocketMQConsole的人员都有可能对生产造成有意或无意的影响。RocketMQConsole只对集群中的Broker(RocketMQ最核心模块，主要负责Topic消息存储、管理和分发)有实时健康状态的监控，没有对NameServer的健康状态进行监控。NameServer是ApacheRocketMQ整体架构中重要的角色之一，NameServer主要管理整个集群的元数据内容，所有生产和消费实例都必须通过NameServer中的元数据来找到对应的Broker，才能正常的收发消息。所以，NameServer的健康状态同样重要。RocketMQConsole虽然可以维护集群上的消息资源，如Topic、Group等。但是无法对物理资源进行管理，如：Broker、NameServer等。由于RocketMQConsole本身没有监控NameServer的状态，因此也没有提供任何对NameServer服务节点的管理方法。RocketMQConsole能够实时监控Broker的健康状况，但是当出现Broker发生异常状态时，如磁盘损害、网卡损害、服务器故障等等，RocketMQConsole可以检测到集群中的异常Broker处于不可用状态，但没有任何告警提示，也没有提供动态摘除替换功能。
技术实现思路
针对相关技术中的上述问题，本申请提出一种分布式消息系统，至少能够提供可视化的运维监控和安全性的运维平台从而更有效解决生产中集群可能发生的故障。本申请的技术方案是这样实现的：根据本申请的一个方面，提供了一种分布式消息系统，包括：集群；指标采集器，用于从集群采集监控指标；运维管理系统，通过指标采集器进行指标数据的查询和读取，并下发客户端资源元数据以使应用使用资源。根据本专利技术的实施例，集群包括NameServer集群和Broker集群，其中，NameServer集群管理Broker集群中所有Broker的元数据。根据本专利技术的实施例，运维管理系统支持集群正向迁移和集群反向回滚迁移。根据本专利技术的实施例，运维管理系统基于基本角色管理资源使用权限和资源查询权限，第一基本角色具有第一资源使用权限和第一资源查询权限，第二基本角色具有第二资源使用权限和第二资源查询权限。根据本专利技术的实施例，监控指标包括发送端通用指标、消费端通用指标，其中：发送端通用指标包括：发送每秒事务处理率(TPS)、发送总量、发送者实例数和发送者连接中的至少一种；消费端通用指标包括：消息堆积量、消费速率、消费者实例数和消费者连接中的至少一种。根据本专利技术的实施例，监控指标包括服务端通用指标，服务端通用指标至少包括：集群发送每秒事务处理率、集群发送总量、集群发送者实例数和集群发送者连接、集群消息堆积量、集群消费速率、集群消费者实例数和集群消费者连接中的至少一种。根据本专利技术的实施例，运维管理系统调用经扩展的分布式消息系统服务端摘除接口将故障节点加入黑名单且不再接收黑名单中故障节点的上报信息；运维管理系统将不在黑名单中故障节点分配新创建资源。本申请的有益技术效果在于：充分利用原生命令行工具，为开发人员和运维人员提供更丰富的数据和统计汇总信息，且通过可视化的方式给开发人员和运维人员提炼关键指标数据展现，帮助他们处理日常的巡检和问题排查工作；解决了运维平台安全性的问题，可以有效避免系统在“裸跑”状态下隐藏的安全风险；对集群故障相关的处理提出了更好的解决方案，可以在开发人员和运维人员发现集群当中存在故障节点后，快速的摘除故障节点，并且快速的替换新的节点来恢复集群状态，从而降低故障发生后影响的时间，节约开发人员和运维人员的故障处理时间。附图说明为了更清楚地说明本申请实施例，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是根据本申请实施例的本文档来自技高网...

【技术保护点】
1.一种分布式消息系统，其特征在于，包括：/n集群；/n指标采集器，用于从所述集群采集监控指标；/n运维管理系统，通过所述指标采集器进行指标数据的查询和读取，并下发客户端资源元数据以使应用使用资源。/n

【技术特征摘要】
1.一种分布式消息系统，其特征在于，包括：
集群；
指标采集器，用于从所述集群采集监控指标；
运维管理系统，通过所述指标采集器进行指标数据的查询和读取，并下发客户端资源元数据以使应用使用资源。


2.按照权利要求1所述的分布式消息系统，其特征在于，所述集群包括NameServer集群和Broker集群，其中，所述NameServer集群管理所述Broker集群中所有Broker的元数据。


3.按照权利要求1所述的分布式消息系统，其特征在于，所述运维管理系统支持集群正向迁移和集群反向回滚迁移。


4.按照权利要求1所述的分布式消息系统，其特征在于，所述运维管理系统基于基本角色管理资源使用权限和资源查询权限，第一基本角色具有第一资源使用权限和第一资源查询权限，第二基本角色具有第二资源使用权限和第二资源查询权限。


5.按照权利...

【专利技术属性】
技术研发人员：周晔，穆海洁，顾恩，
申请(专利权)人：上海汇付数据服务有限公司，
类型：发明
国别省市：上海;31