A communication service management apparatus and system based on a unified framework

Abstract

The application provides a communication service management device and system based on a unified framework, and belongs to the field of communication networks. The communication service management device comprises a service gateway module, a registration center module, a service monitoring module, a configuration management module, a package management module and a service running module. The distributed communication service management system comprises the communication service management devices based on the unified framework arranged on multiple communication devices. The application provides a unified service management framework, adopts a unified interface, defines a standard service calling process, and performs service whole life cycle management, and can be widely applied to scenes requiring service management.

Description

Technical Field

[0001] This invention belongs to the field of communication networks, and specifically refers to a communication service management device and system based on a unified framework, applicable to any scenario requiring service management. Background Technology

[0002] With the continuous development of service-oriented technologies, various communication capabilities are increasingly being provided to applications in the form of service encapsulation. The traditional service management approach involves first building a service pool, and then the application directly calls the corresponding service based on the interface provided by the service. This approach is relatively convenient when the number of services is small, but as the number of services increases, the direct calling method leads to application development complexity. Every change in a service requires the application to make corresponding changes, and there is a lack of state management for services, making it difficult to meet the management needs of a large number of services. Summary of the Invention

[0003] This invention addresses the problems of traditional service management methods, such as limited functionality, difficult invocation, and inability to manage on a large scale. It proposes a communication service management device and system based on a unified framework. This invention provides a unified service management framework, uses a unified interface, sets a standard service invocation process, and performs full service lifecycle management. It can be widely applied to communication systems requiring service management.

[0004] The technical problem to be solved by this invention is achieved by the following technical solution:

[0005] A communication service management device based on a unified framework includes a service gateway module, a registration center module, a service monitoring module, a configuration management module, a packet management module, and a service operation module, wherein:

[0006] The service gateway module provides a unified external interface. When an application sends a service call request to the service gateway module, the service gateway module obtains the required service information from the registry module based on the content of the call request, and starts the service instance through the service runtime module.

[0007] The registry module is responsible for service registration and discovery. When a service instance starts, the registry module receives the service instance's registration request, stores service information, and forms a list of available services.

[0008] The service monitoring module monitors the running status of service instances in real time. The monitoring content includes the CPU utilization, memory usage, and response time of the service. The monitoring content is logged. When an abnormal status is detected, the service running module is notified to handle the abnormal service.

[0009] The configuration management module manages service configuration information. When a service instance is running, it dynamically obtains and updates configuration information from the configuration management module. When deployed in a distributed manner on multiple devices, the configuration management module automatically discovers the configuration management modules on other nodes and synchronizes information when data or configuration information changes.

[0010] The package management module is responsible for managing service installation packages, providing information query, installation, update, uninstallation, and package information storage for installation packages;

[0011] The service runtime module is responsible for the full lifecycle management of the service. When a service call request is received, the service runtime module creates a service instance and starts the service. When a service stop request is received, the service instance is terminated.

[0012] A distributed communication service management system includes a communication service management device based on a unified framework deployed on multiple communication devices;

[0013] When registering a communication service, the local registration center module receives the local communication service registration request and records the service information. The local registration center module sends the service information to the local configuration center module. The local configuration center module and the remote configuration center module synchronize the service information and push the synchronized information to the local or remote registration center module.

[0014] When an application calls a local communication service, the local service gateway module receives the application's service call request, analyzes the application's requirements, and determines the communication service to be called. The local service gateway module queries the local registry module for the address of the communication service, and then instructs the local service runtime module to create and run an instance of the communication service.

[0015] When an application calls a remote communication service, the local service gateway module receives the application's service call request, analyzes the application's requirements, and determines the communication service to be called. The local service network module queries the local registry center module for the address of the communication service, and then instructs the service runtime module to create and run an instance of the communication service. The communication service instance returns result information indicating that a remote service needs to be called. The local service gateway then initiates a service call request to the remote service gateway. The remote service gateway queries the remote registry center module for the address of the remote communication service, and then instructs the remote service runtime module to create and run an instance of the remote communication service.

[0016] Compared with the prior art, the present invention has the following advantages:

[0017] 1. Provide a unified service call interface. Existing technologies require applications to interact with each service, and the interface format and calling method of each service may differ, causing applications to need to be designed specifically for each service. This invention standardizes the application interface, allowing applications to interact only with the service gateway. The calling parameter is as simple as providing the service name, thereby greatly simplifying application development.

[0018] 2. Unified management of services. Existing technologies rely on services for self-management. This invention constrains services within a unified management framework, requiring service registration, acceptance of control by the service operation system and configuration center, and monitoring of service status. This unified management mechanism can meet the management needs of large-scale services.

[0019] 3. Cross-device service invocation is possible. Existing technologies only allow services to be invoked by their own applications. This invention designs an information synchronization mechanism between configuration management centers, allowing each device's configuration management center to monitor the service status of other devices. This enables the services of all devices to be built into a unified service pool for scheduling. In addition, a unified service invocation process is adopted, allowing each device to invoke the services of other devices, thus achieving inter-device collaboration. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the communication service management device in an embodiment of the present invention.

[0021] Figure 2 This is a flowchart of service registration and information synchronization in an embodiment of the present invention.

[0022] Figure 3 This is a flowchart of local service invocation in an embodiment of the present invention.

[0023] Figure 4 This is a flowchart of cross-device service calls in an embodiment of the present invention.

[0024] Figure 2-4 The numbers on the middle arrows are used to indicate the sequence of processes and are not part of the attached diagram. Detailed Implementation

[0025] The present invention will now be further described with reference to the accompanying drawings.

[0026] A communication service management device based on a unified framework, such as Figure 1 As shown, it includes a service gateway module, a registration center module, a service monitoring module, a configuration management module, a package management module, and a service operation module, among which:

[0027] The service gateway module provides a unified external interface. When an application sends a service call request to the service gateway module, the service gateway module obtains the required service information from the registry module based on the content of the call request, and starts the service instance through the service runtime module.

[0028] The registry module is responsible for service registration and discovery. When a service instance starts, the registry module receives the service instance's registration request, stores service information (such as IP address, port number, service name, etc.), and forms a list of available services.

[0029] The service monitoring module monitors the running status of service instances in real time. Monitoring data includes CPU utilization, memory usage, response time, and other data, which is then logged. When an anomaly is detected, the service execution module is notified to handle the abnormal service.

[0030] The configuration management module manages service configuration information. During service instance runtime, it dynamically retrieves and updates configuration information from the configuration management module. When deployed in a distributed manner across multiple devices, the configuration management module automatically discovers other nodes' configuration management modules and synchronizes information when data or configuration information changes.

[0031] The package management module is responsible for managing service installation packages. It provides capabilities such as querying installation package information, installing, updating, uninstalling, and storing package information.

[0032] The service runtime module is responsible for the entire lifecycle management of the service. When a service call request is received, the service runtime module creates a service instance and starts the service; when a service stop request is received, it terminates the service instance.

[0033] A distributed communication service management system includes a communication service management device based on a unified framework deployed on multiple communication devices.

[0034] When registering a communication service, the local registration center module receives the local communication service registration request and records the service information. The local registration center module then sends the service information to the local configuration center module. The local configuration center module and the remote configuration center module synchronize the service information and push the synchronized information to the local or remote registration center module.

[0035] When an application calls a local communication service, the local service gateway module receives the application's service call request, analyzes the application's requirements, and determines the communication service to be called. The local service gateway module queries the local registry module for the address of the communication service, and then instructs the local service runtime module to create and run an instance of the communication service.

[0036] When an application invokes a remote communication service, the local service gateway module receives the application's service invocation request, analyzes the application's requirements, and determines the communication service to be invoked. The local service gateway module queries the local registry module for the address of the communication service, and then instructs the service runtime module to create and run an instance of the communication service. The communication service instance returns a result indicating that a remote service is being invoked. The local service gateway then initiates a service invocation request to the remote service gateway, which in turn queries the remote registry module for the address of the remote communication service, and then instructs the remote service runtime module to create and run an instance of the remote communication service.

[0037] Figure 2 The service registration and information synchronization process is described, including the following steps:

[0038] (101) Service A and Service B send a registration request to Registration Center 1. Registration Center 1 records the information of Service A and Service B. Service C sends a registration request to Registration Center 2. Registration Center 2 records the information of Service C.

[0039] (102) Registration Center 1 sends service information to Configuration Center 1, and Registration Center 2 sends service information to Configuration Center 2.

[0040] (103) The configuration center pre-plans its own level, and the configuration centers synchronize data according to the level. If the configuration center 1 and configuration center 2 are at the same level, the configuration centers will synchronize information equally. If the configuration center 1 is at a higher level than the configuration center 2, the configuration center 1 will only synchronize information related to it to the configuration center 2, and the configuration center 2 will synchronize all information to the configuration center 1.

[0041] (104) Configuration Center 1 obtains the information of Registration Center 2 synchronized by Configuration Center 2 and sends the information to Registration Center 1. Configuration Center 2 obtains the information of Registration Center 1 synchronized by Configuration Center 1 and sends the information to Registration Center 2.

[0042] (105) Registration center 1 returns a registration success result to service A and service B, and registration center 2 returns a registration success result to service C. After synchronization, registration center 1 and registration center 2 both store information about service A, service B and service C, and can provide query services for local services.

[0043] Figure 3 The process of local service invocation is described, including the following steps:

[0044] (201) An external application initiates a service call request to the service gateway. The service gateway analyzes the application requirements and decides to call service A.

[0045] (202) The service gateway sends a service discovery request to the registry center, which carries the service name of service A.

[0046] (203) The registration center returns the address of the service running system to which service A belongs to the service gateway.

[0047] (204) The service gateway instructs the service to run system calls service A.

[0048] (205) The service runtime system creates an instance of service A and runs the instance to provide services to external applications.

[0049] (206) The instance of service A returns a successful call response to the service runtime system. The service runtime system manages its lifecycle and returns a successful service call response to the service gateway.

[0050] (207) The service gateway returns a successful call response to the external application.

[0051] Figure 4 The process of cross-device service scheduling is described, including the following steps:

[0052] (301) An external application initiates a service call request to service gateway 1. Service gateway 1 analyzes the application requirements and decides to call service A.

[0053] (302) Service gateway 1 sends a service discovery request to registry center 1, which carries the service name of service A.

[0054] (303) Registration Center 1 returns the address of Service Operation System 1 to which Service A belongs to Service Gateway 1.

[0055] (304) Service gateway 1 instructs service runtime system 1 to call service A. Service runtime system 1 creates an instance of service A and runs the instance.

[0056] (305) Service A returns a successful call result. In the returned result, Service A indicates that Service Gateway 1 needs to call Service C.

[0057] (306) Service gateway 1 learns from the synchronization information that service C is located in service gateway 2, and service gateway 1 initiates a service call request to service gateway 2.

[0058] (307) Service gateway 2 sends a service discovery request to registry center 2, which carries the service name of service C.

[0059] (308) Registration Center 2 returns the address of Service Operation System 2 to which Service C belongs to Service Gateway 2.

[0060] (309) Service gateway 2 instructs service runtime system 2 to call service C, service runtime system 2 creates an instance of service C and runs the instance.

[0061] (310) Service C returns a successful call result to Service Gateway 2, Service Gateway 2 returns a successful call result to Service Gateway 1, and Service Gateway 1 returns a successful call result to the external application.

[0062] In summary, this invention provides a unified service management framework, adopts a unified interface, defines a standardized service call process, and manages the entire service lifecycle, which can be widely applied in scenarios requiring service management.

Claims

1. A communication service management device based on a unified framework, characterized in that, It includes a service gateway module, a registration center module, a service monitoring module, a configuration management module, a package management module, and a service operation module, among which: The service gateway module provides a unified external interface. When an application sends a service call request to the service gateway module, the service gateway module obtains the required service information from the registry module based on the content of the call request, and starts the service instance through the service runtime module. The registry module is responsible for service registration and discovery. When a service instance starts, the registry module receives the service instance's registration request, stores service information, and forms a list of available services. The service monitoring module monitors the running status of service instances in real time. The monitoring content includes the CPU utilization, memory usage, and response time of the service. The monitoring content is logged. When an abnormal status is detected, the service running module is notified to handle the abnormal service. The configuration management module manages service configuration information. When a service instance is running, it dynamically obtains and updates configuration information from the configuration management module. When deployed in a distributed manner on multiple devices, the configuration management module automatically discovers the configuration management modules on other nodes and synchronizes information when data or configuration information changes. The package management module is responsible for managing service installation packages, providing information query, installation, update, uninstallation, and package information storage for installation packages; The service runtime module is responsible for the full lifecycle management of the service. When a service call request is received, the service runtime module creates a service instance and starts the service. When a service stop request is received, the service instance is terminated.

2. A distributed communication service management system, characterized in that, The communication service management device based on a unified framework as described in claim 1, which is deployed on multiple communication devices; When registering a communication service, the local registration center module receives the local communication service registration request and records the service information. The local registration center module sends the service information to the local configuration center module. The local configuration center module and the remote configuration center module synchronize the service information and push the synchronized information to the local or remote registration center module. When an application calls a local communication service, the local service gateway module receives the application's service call request, analyzes the application's requirements, and determines the communication service to be called. The local service gateway module queries the local registry module for the address of the communication service, and then instructs the local service runtime module to create and run an instance of the communication service; When an application calls a remote communication service, the local service gateway module receives the application's service call request, analyzes the application's requirements, and determines the communication service to be called; the local service network module queries the local registry center module for the address of the communication service, and then instructs the service runtime module to create and run an instance of the communication service; The communication service instance returns result information indicating that a remote service needs to be called. The local service gateway initiates a service call request to the remote service gateway. The remote service gateway queries the remote registration center module for the address of the remote communication service, and then instructs the remote service runtime module to create and run an instance of the remote communication service.

Images