Elastic distributed message queue service system

Abstract

The invention provides an elastic distributed message queue service system, which comprises a front-end service module, a back-end service module and a service factory, and is characterized in that the front-end service module is used for providing a visual interface of a message queue service product so that a user can perform management operation on the message queue service product on the visual interface; the corresponding operation instruction is sent to a back-end service module; the back-end service module is used for carrying out back-end setting according to the operation instruction and sending the operation instruction to the service factory; the service factory is used for creating virtual machines on nodes of the k8s cluster and creating a Rocket MQ 5.0 service on the created virtual machines if the received operation instruction is open, and increasing or reducing the number of the virtual machines so as to increase or reduce the scale of the Rocket MQ service cluster if the received operation instruction is capacity expansion and shrinkage; and if the operation instruction is a stop instruction, destroying the virtual machine where the Rocket MQ service cluster is located and the Rocket MQ 5.0 service created on the virtual machine. According to the invention, the capacity can be flexibly expanded and shrunk.

Description

Technical Field

[0001] The present invention relates to the technical field of message queues, and in particular to a resilient distributed message queue service system. Background Art

[0002] Traditional message queues lack elastic scaling capabilities and are difficult to cope with business volume fluctuations, resulting in performance bottlenecks during peak periods and waste of resources during off-peak periods. In addition, enterprises need to ensure high availability and reliability on their own. Building a multi-region backup and failover mechanism is complex and costly, and the management and maintenance workload is large. Enterprises need to invest a lot of manpower and material resources in hardware maintenance, software updates, and security management, which distracts from core business. In addition, in terms of cost, self-built infrastructure requires high initial investment and ongoing operating costs, making it difficult to pay on demand. Geographic restrictions also lead to high message delivery delays, affecting system response speed and user experience.

[0003] At present, Internet technology is developing rapidly, and the stickiness and dependence of various industries on Internet technology are increasing day by day. With the development of the industry, it relies more on information and digitalization to empower traditional industries, and the volume of business content is getting larger and larger. In particular, more and more application scenarios require message queues for decoupling and peak shaving. Although traditional message queues can be expanded locally, in a high-concurrency and high-traffic environment, services need to be expanded very flexibly, and traditional message queue services cannot be flexibly expanded or reduced. Summary of the invention

[0004] In response to at least one of the above technical problems, an embodiment of the present invention provides a resilient distributed message queue service system.

[0005] According to a first aspect, an elastic distributed message queue service system provided by an embodiment of the present invention includes a front-end service module, a back-end service module and a service factory, wherein:

[0006] The front-end service module is used to provide a visual interface for the message queue service product, so that the user can manage the message queue service product on the visual interface, generate corresponding operation instructions according to the user's management operation, and send the operation instructions to the back-end service module; wherein the management operation includes starting, stopping or expanding or shrinking the message queue service product;

[0007] The backend service module is used to perform backend settings on the relevant configuration information of the message queue service product according to the operation instruction, and send the operation instruction to the service factory;

[0008] The service factory is used for: if the received operation instruction is to activate, then create a virtual machine on the node of the k8s cluster, and create a RocketMQ5.0 service on the created virtual machine. The RocketMQ5.0 services on multiple virtual machines constitute a RocketMQ service cluster; if the received operation instruction is to expand or shrink, then increase or decrease the number of virtual machines to increase or decrease the scale of the RocketMQ service cluster; if the operation instruction is to stop, then destroy the virtual machine where the RocketMQ service cluster is located and the RocketMQ5.0 service created on the virtual machine to stop the RocketMQ service cluster.

[0009] In one embodiment, the back-end service module is also used to: if the operation instruction is to activate, generate order information for the message queue service product, send the order information to the base station subsystem, so that the base station subsystem calculates the fee according to the order information, and feeds back the calculation result to the back-end service module; the back-end service module is also used to: feed back the calculation result to the front-end service module, so that the user can confirm the calculation, and after the user confirms the calculation, send the activation operation instruction to the service factory.

[0010] In one embodiment, the backend service module is further used to: before generating the order information of the message queue service product, perform an authentication operation on the user, and execute the operation of generating the order information of the message queue service product after the authentication is passed.

[0011] In one embodiment, the front-end service module is also used to: provide a configuration interface for the message queue service product, so that the user can set the relevant configuration information of the message queue service product on the configuration interface, and send the configuration information set by the user to the back-end service module; wherein the relevant configuration information includes at least one of the activated instance, cluster scale, disk type, disk size, account password, bound user IP, alarm configuration information and monitoring configuration information; correspondingly, the back-end service module is also used to: execute the relevant configured business logic according to the relevant configuration information to realize the back-end configuration of the message queue service product.

[0012] In one embodiment, the RocketMQ5.0 service is implemented based on a first proxy component and a second proxy component. The first proxy component is responsible for implementing the computing logic of the message queue service product, and the second proxy component is responsible for the data storage of the message queue service product. The storage and computing separation is achieved through the first proxy component and the second proxy component.

[0013] In one embodiment, the RocketMQ5.0 service also manages metadata of the stored data in the second proxy component through a name server, wherein the metadata includes routing information.

[0014] In one embodiment, the RocketMQ5.0 service is specifically used to: when receiving a request sent by a client, establish a connection with the first proxy component to perform an authorization check on the request through the first proxy component, obtain the corresponding routing information from the name server after the authorization check passes, establish a connection with the corresponding second proxy component according to the routing information, and store the data in the request in the second proxy component to establish the connection to realize data storage.

[0015] In one embodiment, the second proxy component is further used to: perform data backup through other second proxy components having a master-slave relationship when storing data; and periodically send heartbeat messages to the name server to maintain connection with the name server.

[0016] In one embodiment, the virtual machine is used to store the running data in the timing database during the working process of the RocketMQ5.0 service; correspondingly, the back-end service module is also used to: when the user issues an instruction to view monitoring data through the front-end service module, query the monitoring data from the timing database, and return the monitoring data to the front-end service module for visual display.

[0017] In one embodiment, the RocketMQ5.0 service on the virtual machine is used to bind to the user's IP address and provide message queue services to the user after successful binding.

[0018] The elastic distributed message queue service system provided by the embodiment of the present invention is that the user performs management operations on the message queue service product on the visual interface of the front-end service module, generates corresponding operation instructions according to the user's management operations, and sends the operation instructions to the back-end service module. The back-end service module performs back-end settings on the relevant configuration information of the message queue service product according to the operation instructions, and sends the operation instructions to the service factory. If the operation instruction received by the service factory is to open, a virtual machine is created on the node of the k8s cluster, and a RocketMQ5.0 service is created on the created virtual machine. The RocketMQ5.0 services on multiple virtual machines constitute a RocketMQ service cluster; if the operation instruction received is to expand or shrink capacity, the number of virtual machines is increased or decreased to increase or decrease the scale of the RocketMQ service cluster; if the operation instruction is to stop, the virtual machine where the RocketMQ service cluster is located and the RocketMQ5.0 service created on the virtual machine are destroyed to achieve the stop of the RocketMQ service cluster. It can be seen that users can open, scale, and stop the message queue service product on the visual interface of the front-end module, and the back-end service module controls the service factory to create, scale, and destroy the RocketMQ5.0 service. Therefore, users can scale up and down at any time according to the use and load of the cluster, and the RocketMQ 5.0 service itself also has the ability to elastically scale. Therefore, the system provided by the embodiment of the present invention can flexibly scale up and down in a high-concurrency, high-traffic environment to meet the needs of the scene. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 The figure is a structural block diagram of a resilient distributed message queue service system in one embodiment of the present invention. DETAILED DESCRIPTION

[0020] In a first aspect, an embodiment of the present invention provides a resilient distributed message queue service system, see Figure 1 The system includes a front-end service module, a back-end service module and a service factory, wherein:

[0021] The front-end service module is used to provide a visual interface for the message queue service product, so that the user can manage the message queue service product on the visual interface, generate corresponding operation instructions according to the user's management operation, and send the operation instructions to the back-end service module; wherein the management operation includes starting, stopping or expanding or shrinking the message queue service product;

[0022] The backend service module is used to perform backend settings on the relevant configuration information of the message queue service product according to the operation instruction, and send the operation instruction to the service factory;

[0023] The service factory is used for: if the received operation instruction is to activate, then create a virtual machine on the node of the k8s cluster, and create a RocketMQ5.0 service on the created virtual machine. The RocketMQ5.0 services on multiple virtual machines constitute a RocketMQ service cluster; if the received operation instruction is to expand or shrink, then increase or decrease the number of virtual machines to increase or decrease the scale of the RocketMQ service cluster; if the operation instruction is to stop, then destroy the virtual machine where the RocketMQ service cluster is located and the RocketMQ5.0 service created on the virtual machine to stop the RocketMQ service cluster.

[0024] Among them, the front-end service module is RocketMQ-front. The front-end service module is mainly responsible for interacting with users and providing users with a visual interface and configuration interface for the product. Users can use the interface to perform management operations such as opening, closing, expanding, shrinking, and configuring information for message queue service products.

[0025] Among them, the backend service module, RocketMQ-service, implements the business logic of the entire message queue service product. The backend service module can perform relevant configuration operations according to the operation instructions to implement the backend configuration, and also send the operation instructions to the service factory. Of course, the backend service module also interacts with multiple other modules, for example, interacting with the base station subsystem, namely BSS, interacting with the service factory, interacting with IAM, interacting with LMA, etc.

[0026] Among them, when the received operation instruction is to open, the service factory will create a virtual machine on the node, and then create a RocketMQ5.0 service on the virtual machine, so that the RocketMQ5.0 services created on each virtual machine constitute a RocketMQ service cluster. If the received operation instruction is to expand capacity, virtual machines can be added, and RocketMQ5.0 services can be created on the newly added virtual machines, thereby expanding the scale of the RocketMQ service cluster. If the received operation instruction is to shrink capacity, virtual machines can be reduced, thereby reducing the scale of the RocketMQ service cluster. If the received operation instruction is to stop, the various virtual machines where the RocketMQ service cluster is located and the various RocketMQ5.0 services on the virtual machines can be destroyed to stop the RocketMQ service cluster and release node resources.

[0027] The service factory is the entity that actually creates, scales, shrinks, and destroys the RocketMQ service cluster. The service factory can conveniently manage the life cycle of the message queue service products purchased by users.

[0028] It can be seen that users can trigger various operation instructions on the front-end visual interface to achieve the creation, expansion, reduction and destruction of RocketMQ service clusters, thereby achieving the activation, expansion, reduction and stop of message queue service products.

[0029] Understandably, RocketMQ is a high-performance, distributed message queue system developed and open sourced by Alibaba. It is known for its high throughput, low latency, and high availability. It supports multiple message types such as normal messages, sequential messages, delayed messages, and transactional messages, and is suitable for complex enterprise-level applications. In order to better evolve towards cloud-native architecture and hyper-converged architecture, RocketMQ launched RocketMQ 5.0, which introduced a new stateless proxy mode, lightweight API, multi-language software development kit, and integration of event and stream processing scenarios.

[0030] From the deployment point of view, the deployment of RocketMQ5.0 service on virtual machines depends on the computing, storage, and network resources on the virtualized cloud platform. Among them, network resources include VPC and elastic IP for container private networks. Storage resources create system disks, cloud disks, etc. required for cloud servers, and support SSD and SATA storage resources. Computing resources mainly include virtual machine resources. RocketMQ5.0 service is deployed on multiple virtual machines to form a resilient distributed cluster. The creation of RocketMQ5.0 service requires the image repository to provide image information, so as to realize containerized deployment. Among them, VPC is a virtual private cloud.

[0031] Among them, the service factory is responsible for the scheduling of resources required for the activation of the message queue service product and the deployment of the cluster. The service factory manages computing, storage and network resources through Openstack, and interacts with Terraform components and Ansible components through its API interface. Among them, the Terraform component is an infrastructure-as-code management tool developed by HashiCorp. It uses configuration files to define and manage cloud resources and integrates OpenStack's API to automatically create and manage resources. Ansible is an open source automation tool for configuration management, application deployment and task automation. It describes automation tasks through simple YAML files and implements complex deployment tasks through the resource interfaces provided by OpenStack and Terraform components. It can be seen that Terraform components can be used to create virtual machines. Ansible can be used to create RocketMQ5.0 services on virtual machines.

[0032] In one embodiment, the back-end service module is also used to: if the operation instruction is to activate, generate order information for the message queue service product, send the order information to the base station subsystem, so that the base station subsystem calculates the fee according to the order information, and feeds back the calculation result to the back-end service module; the back-end service module is also used to: feed back the calculation result to the front-end service module, so that the user can confirm the calculation, and after the user confirms the calculation, send the activation operation instruction to the service factory.

[0033] Among them, RocketMQ5.0 service can provide message queue service, so the message queue service can be ordered as a product by users on the front-end visual interface.

[0034] That is to say, if the user wants to activate a message queue service product on the front-end visual interface, the back-end service module will generate order information and send the order information to the base station subsystem BSS, so that the BSS will process the order and obtain the calculation result, and return the calculation result to the back-end service module. The back-end service module informs the front-end service module of the calculation result, and the user sees the calculation result on the visual interface and confirms the calculation. After receiving the confirmation message, the back-end service module sends the activation operation instruction to the service factory.

[0035] Furthermore, the backend service module may also be used to: before generating the order information of the message queue service product, perform an authentication operation on the user, and after the authentication is passed, perform the operation of generating the order information of the message queue service product.

[0036] That is to say, the backend service module first authenticates the user, and only after the authentication is passed will the order information be generated and the subsequent steps will be carried out. If the authentication fails, the user will be reminded and the subsequent steps will not be carried out.

[0037] Among them, the backend service module can perform authentication operations on the IAM module. There are many ways of authentication. For example, the IAM module stores relevant information of system registered users. If the user is a system registered user, the authentication is passed, thereby ensuring the legitimacy of the order message queue service product.

[0038] In one embodiment, the front-end service module is also used to: provide a configuration interface for the message queue service product, so that the user can set the relevant configuration information of the message queue service product on the configuration interface, and send the configuration information set by the user to the back-end service module; wherein the relevant configuration information includes at least one of the activated instance, cluster scale, disk type, disk size, account password, bound user IP, alarm configuration information and monitoring configuration information; correspondingly, the back-end service module is also used to: execute the relevant configured business logic according to the relevant configuration information to realize the back-end configuration of the message queue service product.

[0039] In other words, users can make multiple configurations in the front-end configuration interface to achieve relevant configurations of the message queue service product. Among them, the configurable content includes at least one of the following: activation instance, cluster scale, disk type, disk size, account password, bound user IP, alarm configuration information, and monitoring configuration information. After the user configuration is completed, the back-end service module will configure the back-end according to the user's configuration operations to achieve the back-end configuration. When the service factory creates, scales, and destroys the RocketMQ service cluster, it will also perform related operations based on the relevant configuration information.

[0040] Among them, the front-end service module and the back-end service module can all be deployed in the k8s cluster in the form of chart packages. Chart packages usually refer to packages in Helm, which is a package management tool for k8s and is used to install, manage, and uninstall k8s applications. Chart packages contain the images, dependencies, and resource definitions required to run an application, and may also contain service definitions in the k8s cluster.

[0041] In one embodiment, the RocketMQ5.0 service is implemented based on a first proxy component and a second proxy component. The first proxy component is responsible for implementing the computing logic of the message queue service product, and the second proxy component is responsible for the data storage of the message queue service product. The storage and computing separation is achieved through the first proxy component and the second proxy component.

[0042] Among them, the first proxy component is the proxy component.

[0043] Among them, the second agent component is the Broker component.

[0044] Among them, the RocketMQ5.0 service realizes storage and computing separation through the proxy component. The proxy component is responsible for the computing logic such as client protocol adaptation, permission management, consumption management, etc. It is stateless and can be expanded at will, while the Broker component focuses on data storage in order to better adapt to the cloud native environment and realize elastic resource scheduling. Therefore, the embodiment of the present invention is based on the architecture design and deployment mode of the RocketMQ5.0 version, relying on the computing, storage, network resources on the cloud platform and the cloud native capabilities of the K8S platform, so that customers can quickly build a loosely coupled, distributed, and highly available business system.

[0045] Among them, the proxy component is mainly responsible for computing tasks, including access control, multi-protocol adaptation, general business capabilities, governance capabilities, and observability. The proxy components are stateless, so they can be horizontally expanded or reduced according to the traffic of users and clients, that is, the RocketMQ5.0 service itself has scalability. The Broker component is a storage module, which is mainly responsible for message storage, message indexing, message consistency multiple copies, multi-level storage, etc.

[0046] It is understandable that all existing traditional message queues are based on a storage-computing integrated structure design. This storage-computing integrated architecture is a stateful service. When encountering a scenario that requires expansion and contraction, due to the integration of storage and computing, a large amount of data needs to be migrated, and it is impossible to expand the capacity quickly and flexibly. In the embodiment of the present invention, the storage-computing separated architecture makes it unnecessary to perform a large amount of migration when expanding and contracting. Moreover, as the amount of data increases, a message queue cluster with elastic expansion and contraction capabilities can greatly reduce resource and labor costs.

[0047] In one embodiment, the RocketMQ5.0 service also manages metadata of the stored data in the second proxy component through a name server, wherein the metadata includes routing information.

[0048] The name server is NameServe. NameServer is responsible for managing metadata, including subject information, routing information, and Broker component information. NameServers are independent and stateless, and do not require a consistency protocol to meet strong consistency, ensuring that they are lightweight and simple enough.

[0049] In one embodiment, the RocketMQ5.0 service can be specifically used to: when receiving a request sent by a client, establish a connection with the first proxy component to perform an authorization check on the request through the first proxy component, obtain the corresponding routing information from the name server after the authorization check passes, establish a connection with the corresponding second proxy component according to the routing information, and store the data in the request in the second proxy component to which the connection is established to realize data storage.

[0050] That is to say, when the client sends a request, the RocketMQ5.0 service needs to establish a connection with the proxy component first. The proxy component will uniformly adapt to various protocols and perform permission verification on the incoming requests. After the verification is passed, it accesses the NameServer to obtain routing information, establishes a connection with the corresponding Broker component based on the routing information returned by the NameServer, and stores the data in the request in the Broker component.

[0051] In one embodiment, the second proxy component is further used to: perform data backup through other second proxy components having a master-slave relationship when storing data; and periodically send heartbeat messages to the name server to maintain connection with the name server.

[0052] That is to say, when the second proxy component is storing data, it can be responsible for the synchronous storage of data within the Broker. The Broker will also maintain a connection with the NameServer and send heartbeat information to the NameServer at regular intervals. Among them, the Broker Slave and Broker Master have a master-slave relationship.

[0053] In one embodiment, the virtual machine is used to store the running data in the timing database during the working process of the RocketMQ5.0 service; correspondingly, the back-end service module is also used to: when the user issues an instruction to view monitoring data through the front-end service module, query the monitoring data from the timing database, and return the monitoring data to the front-end service module for visual display.

[0054] Among them, time series databases, for example, InfluxDB. InfluxDB is an open source time series database developed by InfluxData, mainly used to store and analyze time series data.

[0055] Specifically, the running data of RocketMQ5.0 service in the working process is obtained through Telegraf, and the running data is stored in InfluxDB. Telegraf is an open source software agent written in Go language, which is mainly used to collect and send data from databases, systems and IoT sensors, including indicators, events, etc.

[0056] Among them, querying the monitoring data from the temporal database can be specifically implemented by the LMA module. The LMA module queries the monitoring data from the temporal database and returns the monitoring data to the front-end service module for visual display.

[0057] It can be seen that the BSS transaction side can be responsible for the configuration of message queue service products, including product prices and product permissions, which are divided into order center, product center, product configuration and quota configuration, etc. IAM is responsible for the management of users and user permissions. The LMA module is responsible for monitoring data queries, etc.

[0058] In one embodiment, the RocketMQ5.0 service on the virtual machine is used to bind to the user's IP address and provide message queue services to the user after successful binding.

[0059] That is to say, when creating a RocketMQ5.0 service on a virtual machine, the RocketMQ5.0 service needs to be bound to the user's IP. After binding, the user can enjoy the message queue service provided by the RocketMQ5.0 service. By binding the user's IP, the security of the service is provided.

[0060] The embodiment of the present invention is based on the capabilities of the cloud platform, and quickly provides the required computing, storage, and network resources through the cloud platform. At the same time, based on the capabilities of BSS, service factory, LMA, and IAM, users can quickly open and use message queue service products. At the same time, the deployment method adopts the architectural design of RocketMQ 5.0 version, and moves part of the capabilities of the client and Broker components to the proxy component, so that the proxy component can quickly expand and shrink, thereby giving the message queue service product a higher elastic scaling capability. Moreover, based on the RocketMQ5.0 service, the present invention designs and invents a resiliently distributed message queue service system based on the capabilities of the cloud platform and cloud native, so that users can expand and shrink at any time on the front-end page according to the use and load conditions of the cluster, reducing maintenance and use costs. That is, the embodiment of the present invention can make the message queue cluster more flexible, achieve rapid expansion and contraction, and reduce costs through the design of cloud-native message queues.

[0061] It can be seen that in the embodiment of the present invention, users can scale up or down at any time according to the use and load of the cluster. RocketMQ 5.0 service realizes storage and computing separation based on proxy components, and RocketMQ 5.0 service itself has elastic scaling capabilities. Therefore, the system provided by the embodiment of the present invention can flexibly scale up or down in a high-concurrency, high-traffic environment.

[0062] That is, the embodiment of the present invention is based on the cloud-native concept and realizes a high-performance, low-latency, loosely coupled cloud message queue service system to meet the needs of cloud message queues in the context of cloud computing, and solves the problem that traditional message queues cannot be flexibly expanded or reduced in high-concurrency and high-traffic environments.

[0063] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0064] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the present invention can be implemented by hardware, software, widgets, or any combination thereof. When implemented by software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0065] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solution of the present invention should be included in the scope of protection of the present invention.

Claims

1. A resilient distributed message queue service system, characterized in that: It includes front-end service module, back-end service module and service factory, among which: The front-end service module is used to provide a visual interface for the message queue service product, so that the user can manage the message queue service product on the visual interface, generate corresponding operation instructions according to the user's management operation, and send the operation instructions to the back-end service module; wherein the management operation includes starting, stopping or expanding or shrinking the message queue service product; The backend service module is used to perform backend settings on the relevant configuration information of the message queue service product according to the operation instruction, and send the operation instruction to the service factory; The service factory is used for: if the received operation instruction is to activate, then create a virtual machine on the node of the k8s cluster, and create a RocketMQ5.0 service on the created virtual machine. The RocketMQ5.0 services on multiple virtual machines constitute a RocketMQ service cluster; if the received operation instruction is to expand or shrink, then increase or decrease the number of virtual machines to increase or decrease the scale of the RocketMQ service cluster; if the operation instruction is to stop, then destroy the virtual machine where the RocketMQ service cluster is located and the RocketMQ5.0 service created on the virtual machine to stop the RocketMQ service cluster.

2. The system according to claim 1, characterized in that The back-end service module is also used to: if the operation instruction is to activate, generate order information for the message queue service product, send the order information to the base station subsystem, so that the base station subsystem calculates the fee according to the order information, and feeds back the calculation result to the back-end service module; the back-end service module is also used to: feed back the calculation result to the front-end service module, so that the user can confirm the fee, and after the user confirms the fee, send the activation operation instruction to the service factory.

3. The system according to claim 2, characterized in that The backend service module is also used to: before generating the order information of the message queue service product, perform an authentication operation on the user, and execute the operation of generating the order information of the message queue service product after the authentication is passed.

4. The system according to claim 2, characterized in that The front-end service module is also used to: provide a configuration interface for the message queue service product, so that the user can set the relevant configuration information of the message queue service product on the configuration interface, and send the configuration information set by the user to the back-end service module; wherein the relevant configuration information includes at least one of the activated instance, cluster scale, disk type, disk size, account password, bound user IP, alarm configuration information and monitoring configuration information; correspondingly, the back-end service module is also used to: execute the relevant configured business logic according to the relevant configuration information to realize the back-end configuration of the message queue service product.

5. The system according to claim 1, characterized in that The RocketMQ5.0 service is implemented based on a first proxy component and a second proxy component. The first proxy component is responsible for implementing the computing logic of the message queue service product, and the second proxy component is responsible for the data storage of the message queue service product. The storage and computing separation is achieved through the first proxy component and the second proxy component.

6. The system according to claim 5, characterized in that The RocketMQ5.0 service also manages metadata of the stored data in the second proxy component through a name server, wherein the metadata includes routing information.

7. The system according to claim 6, characterized in that The RocketMQ5.0 service is specifically used to: when receiving a request sent by a client, establish a connection with the first proxy component to perform an authority check on the request through the first proxy component, obtain corresponding routing information from the name server after the authority check passes, establish a connection with the corresponding second proxy component according to the routing information, and store the data in the request in the second proxy component to establish the connection to realize data storage.

8. The system according to claim 7, characterized in that The second proxy component is also used for: performing data backup through other second proxy components having a master-slave relationship when storing data; and regularly sending heartbeat messages to the name server to maintain the connection with the name server.

9. The system according to claim 1, characterized in that The virtual machine is used to store the running data in the timing database during the working process of the RocketMQ5.0 service; correspondingly, the back-end service module is also used to: when the user issues an instruction to view the monitoring data through the front-end service module, query the monitoring data from the timing database, and return the monitoring data to the front-end service module for visual display.

10. The system according to claim 1, characterized in that The RocketMQ5.0 service on the virtual machine is used to bind to the user's IP and provide message queue services to the user after successful binding.

Images