A method and system for unifying topological data structures and operations across services in a network range

Abstract

The present invention discloses a method and system for unifying topological data structures and operations across services in a network range. The present invention constructs service maintenance through a topological network and publishes a topological data SDK and a topological standard operation algorithm SDK to a central warehouse. Each business service registers its own service identifier and remote method call address with a registration center and pulls all registered service information. Each business service independently stores part of the topological data related to its own business. When specific topological data needs to be operated, the corresponding processing function in the topological standard operation algorithm SDK pulled from the central warehouse is used to operate the topological data. The topological standard operation algorithm can support automatic routing to realize cross-service operation of topological data. The present invention realizes the decoupling of topological data of different services in the network range platform. Different services independently perform additional internal business operations on the part of the topological data belonging to the service through a unified operation algorithm, thereby improving the maintainability of the network range platform.

Description

Technical Field

[0001] The present invention relates to a method and system for unifying topological data structure and operation across services in a network range, and belongs to the technical fields of computer software and network security. Background Art

[0002] In the implementation of a large-scale network range, the range platform is broken down into numerous microservices, such as a cloud platform service that provides virtualized resource management capabilities, a topology network construction service that provides topology instance construction capabilities, a collection service that provides data collection capabilities, and a visualization service that provides topology information visualization capabilities. Each microservice needs to perform its own business operations based on the current topology instance data. For example, the visualization service needs to query topology instance information to display it on the interface, and the collection service needs to query topology instance information to obtain configuration collection information. These services will parse the topology instance data obtained from the open interface of the topology network construction service based on their internal understanding of the topology instance; or they will require the platform topology network construction service to customize the corresponding topology data interface according to the data format required by other services.

[0003] The current solution has the following issues: 1. The topology network construction service requires customizing different interfaces for different services, which is labor-intensive and time-consuming. 2. If the topology network construction service is unable to customize interfaces for different services, other services will need to redefine the topology data format and operation algorithms within the service, which is labor-intensive and time-consuming. 3. If numerous business interfaces are customized for different services within the topology network construction service, the topology network construction service will be coupled with a large number of other services' operations on topology data. The business meaning of these operations is unclear to the platform topology network construction service, making maintenance difficult. Summary of the Invention

[0004] Purpose of the invention: In response to the problems existing in the above-mentioned prior art, the purpose of the present invention is to provide a method and system for unifying topological data structures and operations across services in a network target range, to achieve the unification of topological data formats and topological standard operation algorithms, and to improve the maintainability of the network target range platform.

[0005] Technical solution: To achieve the above-mentioned purpose, the present invention adopts the following technical solution:

[0006] A method for unifying topology data structures and operations across services in a network range includes the following steps:

[0007] The topology network construction service maintains and publishes the topology data SDK and topology standard operation algorithm SDK to the central warehouse;

[0008] Each business service on the range platform registers its own service identifier and remote method call address with the registration center, and pulls all registered service information;

[0009] Each business service independently stores part of the topology data related to its own business. When specific topology data needs to be operated, the corresponding processing function in the topology standard operation algorithm SDK pulled from the central warehouse is used to operate the topology data. The processing function only relies on the abstract topology operation interface and implements remote method calls based on the mapping agent. When actually processing topology data, if the data table corresponding to the data class is stored in the local database of the business service, the generated local database implementation class instance is used. Otherwise, the database operation will be performed on the corresponding service based on the json remote method call according to the predefined data class affiliation service and the service information obtained from the registration center.

[0010] Preferably, the topology data SDK is composed of data classes that describe the entire topology data structure, including topology global information data classes, topology node data classes, topology node port data classes, topology connection data classes, cloud platform service-related data classes, and acquisition service-related data classes; each data class corresponds to a table in the database, and each data class has its unique belonging service; the topology standard operation algorithm SDK includes unified query, traversal, creation and update algorithms for topology data.

[0011] Preferably, the topology standard operation algorithm only relies on the abstract topology operation interface when it is implemented. The locally stored data in the topology data is processed by the local database interface implemented by this business service. The local database interface is generated by the mybatis framework using JDK dynamic proxy technology to generate a mapping proxy instance that actually performs database operations, and is registered in the Spring container for use by the topology standard operation algorithm; non-locally stored data is processed by the non-local database interface, and the non-local database interface mapping proxy instance will be registered in the Spring container through the Spring Config configuration class declaration for use by the topology standard operation algorithm.

[0012] Preferably, when the implementation class of the topology standard operation algorithm is initialized, a specific instance of the dependent abstract topology operation interface is obtained from the Spring container.

[0013] Preferably, remote method calls are implemented based on mapping proxies, including: defining an abstract topology operation interface class to describe the basic add, delete, modify and query capabilities related to database interaction provided by the mapping proxy, and defining a remote proxy interface to describe the cross-service call operation capabilities provided by the mapping proxy; implementing the remote proxy interface through the service proxy abstract class, providing basic JSON-based remote method call assembly parameters and call initiation template implementation; the basic mapping proxy abstract class inherits the service proxy abstract class and implements the abstract topology operation interface at the same time, providing the ability to perform database interaction operations across services; the mapping proxy of the specific business service operation table only needs to inherit the basic mapping proxy abstract class, and define its own affiliated service name and the corresponding class identifier in the affiliated service.

[0014] Preferably, when a remote method call is made based on json, the fields of the request parameter object constructed by the remote method call client include the corresponding business bean name in the Spring container, the calling method name, and the json string array converted from the parameter values ​​of the calling method and the corresponding parameter type array; the remote method call server parses the request parameter object, implements the method call based on the JDK reflection library, obtains the method execution return value, and returns the return value of the local method call and the method parameters after the local method call is completed to the remote method call client to handle the method side effects.

[0015] Furthermore, distributed transaction components are used to implement cross-service transaction management. The transaction management service maintains the status of global transactions and business service transactions, and notifies business services to commit or rollback global transactions.

[0016] Based on the same inventive concept, the present invention provides a system for unifying topological data structures and operations across services in a network range, including:

[0017] Topology network construction service module, used to maintain and publish topology data SDK and topology standard operation algorithm SDK to the central warehouse;

[0018] The service registration module is used by each business service of the range platform to register its own service identifier and remote method call address with the registration center, and pull all registered service information;

[0019] And multiple business service modules, each business service module independently stores part of the topology data related to its own business. When specific topology data needs to be operated, the corresponding processing function in the topology standard operation algorithm SDK pulled from the central warehouse is used to operate the topology data. The processing function only relies on the abstract topology operation interface and implements remote method calls based on the mapping agent. When actually processing topology data, if the data table corresponding to the data class is stored in the business service local database, the generated local database implementation class instance is used. Otherwise, the corresponding service will be called based on the json remote method to perform database operations according to the predefined data class affiliation service and the service information obtained from the registration center.

[0020] Furthermore, the system also includes: a transaction management service module for implementing cross-service transaction management using distributed transaction components. The transaction management service module maintains the status of global transactions and business service transactions, and notifies business services to commit or rollback global transactions.

[0021] The present invention also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the method for unifying topological data structures and operations across services in a network range.

[0022] Beneficial effects: The present invention realizes the unification of topology data format and topology standard operation algorithm by opening standard topology standard operation algorithm SDK and topology data SDK among multiple microservices. At the same time, cross-service storage of topology data is realized in this process, and different services independently store part of the topology data related to their own services. The topology standard operation algorithm supports automatic routing to realize cross-service operation of topology data. The present invention ultimately realizes the decoupling of topology data of different services of the network target range platform. Different services independently perform additional internal business operations on part of the topology data belonging to the service through a unified operation algorithm, thereby improving the maintainability of the network target range platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 Schematic diagram of the architecture design of an embodiment of the present invention.

[0024] Figure 2 The diagram is a schematic diagram of the architecture and flow of a shooting range platform including visualization services and acquisition services as exemplified in an embodiment of the present invention.

[0025] Figure 3 This is a detailed flowchart of the business service operation topology data in an embodiment of the present invention.

[0026] Figure 4 A class diagram is designed for a general remote method call based on MapperProxy in an embodiment of the present invention. DETAILED DESCRIPTION

[0027] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings and specific embodiments.

[0028] like Figure 1 As shown, an embodiment of the present invention discloses a method for unifying topological data structure and operation across services in a network target range, mainly including: topological network construction service maintenance and publishing topological data SDK and topological standard operation algorithm SDK to the central warehouse; each business service of the target range platform registers its own service identifier and remote method call address to the registration center, and pulls all registered service information; each business service independently stores part of the topological data related to its own business, and when specific topological data needs to be operated, the corresponding processing function in the topological standard operation algorithm SDK pulled from the central warehouse is used to operate the topological data. The processing function only relies on the abstract topological operation interface and implements remote method calls based on the mapping agent. When actually processing topological data, if the data table corresponding to the data class is stored in the local database of the business service, the generated local database implementation class instance is used. Otherwise, the corresponding service will be called based on the json remote method to perform database operations according to the predefined data class affiliation service and the service information obtained from the registration center.

[0029] The topology data SDK consists of data classes that describe the entire topology data structure. Each data class corresponds to a table in the database, and each data class has its own unique service.

[0030] The topology standard operation algorithm SDK includes unified query, traversal, creation, and update algorithms for topology data. The specific topology standard operation algorithm only relies on the abstract topology operation interface when it is implemented. The locally stored data in the topology data is processed by the local database interface implemented by this business service, and the non-locally stored data is processed by the non-local database interface. In specific implementation, the local database interface can be generated by the mybatis framework using JDK dynamic proxy technology to generate a mapping proxy instance that actually performs database operations and is registered with the Spring container for use by the topology standard operation algorithm; the non-local database interface mapping proxy instance can be registered with the Spring container through the Spring Config configuration class declaration for use by the topology standard operation algorithm. When the implementation class of the topology standard operation algorithm is initialized, the specific instance of the dependent abstract topology operation interface is obtained from the Spring container.

[0031] In one embodiment, remote method calls are implemented based on mapping proxies, and the specific implementation includes: first, defining an abstract topology operation interface class to describe the basic add, delete, modify, and query capabilities related to database interaction provided by the mapping proxy, and defining a remote proxy interface to describe the cross-service call operation capabilities provided by the mapping proxy; then, implementing the remote proxy interface through the service proxy abstract class, providing basic JSON-based remote method call assembly parameters and a template implementation for initiating calls; then, inheriting the service proxy abstract class through the basic mapping proxy abstract class and implementing the abstract topology operation interface at the same time, providing the ability to perform database interaction operations across services; finally, the mapping proxy of the specific business service operation table only needs to inherit the basic mapping proxy abstract class, and define its own affiliated service name and the identifier of the corresponding class in the affiliated service.

[0032] In one embodiment, when a remote method call is made based on JSON, the fields of the request parameter object constructed by the remote method call client include the corresponding business bean name in the Spring container, the call method name, and the JSON string array converted from the parameter values ​​of the call method and the corresponding parameter type array; the remote method call server parses the request parameter object, implements the method call based on the JDK reflection library, obtains the method execution return value, and returns the return value of the local method call and the method parameters after the local method call is completed to the remote method call client to handle method side effects.

[0033] In one embodiment, a distributed transaction component is further used to implement cross-service transaction management. The transaction management service maintains the status of global transactions and business service transactions, and notifies the business service to commit or rollback the global transaction.

[0034] Figure 2 The following example illustrates the architecture and specific business implementation process of the network range platform including topology network construction service, visualization service and collection service. Figure 2 Describes in detail the implementation details of the method for unifying topology data structures and operations across services in the Cyber ​​Range.

[0035] like Figure 2 As shown, this embodiment discloses a method for unifying topology data structures and operations across services in a network range, including the following steps:

[0036] Step S101: The topology network construction service updates and maintains the topology data SDK and the topology standard operation algorithm SDK and uploads them to the nexus repository. Other business services such as the visualization service and the collection service pull the topology data SDK and the topology standard operation algorithm SDK from the nexus repository.

[0037] The Topology Data SDK defines the data structure of the topology. The Topology Standard Operation Algorithm SDK defines the algorithms for operating on the topology data structure. The Topology Data SDK consists of data classes that describe the entire topology data structure. Each data class corresponds to a table in the database, and each data class has its own uniquely assigned microservice, that is, the microservice where the corresponding database table is stored. In this embodiment, for the names and meanings of the detailed data classes, refer to Table 1.

[0038] Table 1 Example of Data Classes

[0039]

[0040] It should be noted that the above Topology Data SDK only lists the topology data classes related to the cloud platform and the acquisition service. There can be additional topology data classes related to other services that can be added separately.

[0041] In this embodiment, gradle is used as the build tool. Add the following content to the build.gradle file in the Topology Data SDK module, and execute the gradle publish operation to publish the current module to the maven repository of the project.

[0042] publishing {

[0043] publications {

[0044] maven(MavenPublication){

[0045] from components.java

[0046] }

[0047] }

[0048] repositories {

[0049] maven {

[0050] name ='remote'

[0051] allowInsecureProtocol = true

[0052] url 'http: / / <netxus service IP> / repository / <directory address> / '

[0053] credentials {

[0054] username =<netxus account>

[0055] password = <netxus password>

[0056] }

[0057] }

[0058] }

[0059] }

[0060] Step S102: When all microservices on the range platform start and every minute after startup, they register their service identifiers and remote method call addresses with the registration center, and pull all the registered information.

[0061] The registration format example is as follows:

[0062] {

[0063] "app_code": "topo_constructor",

[0064] "rpc_host": "http: / / 172.0.0.1:8081 / proxy / call / service"

[0065] }

[0066] Step S103: When a certain user views the details of a certain topology in the visualization service interface, a specific topology instance id is passed in.

[0067] Step S104: The visualization service receives the requested parameter, that is, the topology instance id.

[0068] Step S105: The visualization service directly uses the SceneHandler constructor in the topology standard operation algorithm SDK obtained from the nexus repository to load the topology data.

[0069] The topology standard operation algorithm refers to the unified query, traversal, creation, and update algorithms for topology data. The example code snippet is as follows:

[0070] / / Obtain an instance of the implementation class of the BaseMapperInterface abstract class registered in the current Spring container. SceneHandler only depends on the BaseMapperInterface abstract class interface and does not depend on a specific instance.

[0071] @Override

[0072] public BaseMapperInterface <scenemodel>getSceneMapper() {

[0073] return (BaseMapperInterface <scenemodel>) BeanCommon.getBean(SceneSdkMapperConstant.SCENE_MAPPER);

[0074] }

[0075] @Override

[0076] public BaseMapperInterface <sceneareamodel>getSceneAreaMapper() {

[0077] return (BaseMapperInterface <sceneareamodel>) BeanCommon.getBean(SceneSdkMapperConstant.SCENE_AREA_MAPPER);

[0078] }

[0079] @Override

[0080] public BaseMapperInterface <sceneelementmodel>getSceneElementMapper(){

[0081] return (BaseMapperInterface <sceneelementmodel>) BeanCommon.getBean(SceneSdkMapperConstant.SCENE_ELEMENT_MAPPER);

[0082] }

[0083] public SceneHandler(String sceneId, String areaId, SceneContextBOcontext) {

[0084] init(sceneId, areaId, false, context);

[0085] }

[0086] public void save() {

[0087] boolean isCreate = StringUtils.isEmpty(sceneId);

[0088] saveScene();

[0089] Map<String, A0>existAreaMap = isCreate ? new HashMap<>() :readAreas().stream()

[0090] .collect(Collectors.toMap(BaseSceneAreaModel::getNodeId, x->x));

[0091] var filterAreaIds = new String[0];

[0092] if (isAreaMode) {

[0093] String currentAreaId = areaId == null ? StringUtils.EMPTY :areaId;

[0094] filterAreaIds = ArrayUtils.addAll(existAreaMap.values().stream().filter(BaseSceneAreaModel::getOpen)

[0095] .map(BaseSceneAreaModel::getNodeId).toArray(String[]::new), currentAreaId);

[0096] }

[0097] ... / / Specific business-related saving logic is not described in detail. Here we only illustrate how to call the implementation class instance of the abstract class.}

[0098] private boolean saveScene() {

[0099] / / Code to save SceneModel data class

[0100] S0 sceneObj = scene.toModel();

[0101] var result = getSceneMapper().save(sceneObj);

[0102] sceneId = sceneObj.getId();

[0103] scene.fromModel(sceneObj);

[0104] plugins.forEach(plugin ->plugin.setSourceSceneId(sceneId));

[0105] return result;

[0106] }

[0107] The code examples above are part of two functions. One is the SceneHandler constructor, which implements a unified query algorithm for topology data. The other is the save method, which implements a unified update algorithm for topology data. By importing the Topology Standard Algorithm SDK JAR package, each business service can directly use the various topology operation algorithms defined in the JAR package to operate on topology data across services.

[0108] Step S106: When actually loading topology data, the current business service (visualization service) performs different operations depending on the injected database query interface class instance (i.e., MapperProxy, described below). For data tables actually stored in the current business service, the injected instance is a local database query class instance generated by MyBatis based on the JDK dynamic proxy. For data tables not stored in the current business service, the injected instance is a database query interface class instance registered within the current business service through a custom configuration class. The current business service uses the getService method in each database query interface class instance to obtain the corresponding microservice, as well as the service identifier and remote call information obtained from the registration center, to request the corresponding service address. The actual database operation is then executed within other business services using JSON-based remote method calls. Seata is used in this process to implement cross-service transactions and ensure the consistency of topology data across services.

[0109] The specific execution process is as follows Figure 3 As shown, specifically including:

[0110] Step S1061: The topology standard operation algorithm only relies on the abstract topology query interface BaseMapperInterface when it is implemented. The locally stored data in the topology data is processed by the Mapper managed by the mybatis framework of this business service; the non-locally stored data is processed by the custom MapperProxy.

[0111] Step S1062: When the system starts, the MyBatis framework uses JDK dynamic proxy technology to generate a MapperProxy instance for the local database interface Mapper that actually performs database operations. This instance is then registered with the Spring container for use by the topology standard operation algorithm. Predefined non-local database interface MapperProxy instances are registered with the Spring container through a Spring Config configuration class declaration for use by the topology standard operation algorithm.

[0112] The following is a simple display of the configuration class code:

[0113] @Configuration

[0114] public class MapperProxyBeanConfig {

[0115] / **

[0116] * Get the scene MapperProxy

[0117] *

[0118] * @return scene MapperProxy

[0119] * /

[0120] @Bean("sceneMapper")

[0121] public SceneMapperProxy getSceneMapperProxy() {

[0122] return new SceneMapperProxy();

[0123] }

[0124] / **

[0125] * Get the scene node MapperProxy

[0126] *

[0127] * @return scene node MapperProxy

[0128] * /

[0129] @Bean("sceneElementMapper")

[0130] public SceneElementMapperProxy getSceneElementMapperProxy() {

[0131] return new SceneElementMapperProxy();

[0132] }

[0133] / **

[0134] * Get the scene node port MapperProxy

[0135] *

[0136] * @return scene node port MapperProxy

[0137] * /

[0138] @Bean("sceneElementPortMapper")

[0139] public SceneElementPortMapperProxy getSceneElementPortMapperProxy(){

[0140] return new SceneElementPortMapperProxy();

[0141] }

[0142] } ...There will be many MapperProxy instances registered with the Spring container through the current configuration class.

[0143] Step S1063: When the system is running, the implementation class SceneHandler of the topology standard operation algorithm creates an instance of the class. When the class is initialized, the specific instance of the dependent BaseMapperInterface abstract class is obtained from the Spring container.

[0144] Step S1064: When the system is running, when operating the local storage data of the current business service, the MapperProxy instance is dynamically generated by mybatis to connect to the local database for operation; when operating non-local storage data, the pre-defined MapperProxy is used to call the json-based remote method call client, and the service address corresponding to the storage of the current data class is called to the remote method call server of the corresponding service address. Finally, the mybatis inside other services dynamically generates a MapperProxy instance to perform data operation.

[0145] Step S1065: When actually operating the topology data, a business service for the topology operation is initiated, and a global transaction is initiated to the transaction manager service TC of seata.

[0146] Since the actual topology data operation is cross-service, the local database transaction of each service can only guarantee the validity, consistency and integrity of the part of the topology data stored by its own service, but cannot guarantee the validity, consistency and integrity of the topology data stored across services.

[0147] Therefore, this embodiment uses the Seata distributed transaction component to support the system's distributed transaction capabilities. The Transaction Manager Service (TC) is a centralized transaction management service provided by Seata. It maintains the status of global transactions and transactions for each service and notifies each service to commit or rollback global transactions. Each business service registers with the TC to report the execution status and results of its global transactions and to commit or rollback global transactions. The following steps describe in more detail the interaction between each business service and the Transaction Manager Service (TC).

[0148] Step S1066: All business services obtain the global lock of the current topology operation from the transaction manager service TC.

[0149] Step S1607: Each business service submits the internal undoLog related to the topology operation and the rollback to the local database in the form of a local transaction.

[0150] Step S1068: Each business service reports the execution status of the local transaction to the transaction manager service TC.

[0151] Step S1069: After the transaction manager service TC obtains the successful execution status of all local transactions reported by the business services, it sends a global transaction execution success instruction to each business service. After receiving the global transaction success instruction, each business service releases the global lock and deletes the undoLog generated for rollback in step S1067.

[0152] Step S107: The visualization service obtains the topology data parsed by the topology standard operation algorithm SDK in the topology data SDK format, and displays it to the user on the interface.

[0153] In step S1064, the json-based remote method call mainly includes the general remote method call logic of MapperProxy as well as the client implementation and server implementation.

[0154] In this embodiment, the template method design pattern is used to implement the general remote method call logic of MapperProxy, which is specifically implemented as follows: Figure 4 The implementation steps include:

[0155] Step S201: Define the BaseMapperInterface interface class to describe the basic add, delete, modify, and query capabilities related to database interaction provided by MapperProxy. Define the IProxy interface to describe the cross-service call operation capabilities provided by MapperProxy.

[0156] Step S202: Define the ServiceProxy abstract class to implement the IProxy interface, providing a basic JSON-based template implementation for assembling parameters and initiating remote method calls. Define the BaseMapperProxy abstract class to inherit the ServiceProxy abstract class and implement the BaseMapperInterface interface, providing the ability to perform database interactions across services.

[0157] Step S203: The data table MapperProxy related to the specific business service only needs to inherit the BaseMapperProxy abstract class and define its own affiliated service name (getService() method) and the identifier of the corresponding class in the affiliated service (getClass() method), so that it can easily provide the upper-level business with the ability to interact with the cross-service database.

[0158] In this embodiment, the JSON-based remote method call client implementation mainly includes constructing a request parameter object and retaining the value and type information of the request parameter. The request parameter object structure is shown in Table 2.

[0159] Table 2 Request parameter object structure

[0160]

[0161] As shown in Table 2, the request parameter object contains four fields. The clazz field is the name of the corresponding business bean in the Spring container and is a fixed property of each MapperProxy. The method field is the name of the calling method, which is determined by the currently called method. The params field is a JSON string array converted from the parameter values ​​of the currently called method. The paramsType field is the parameter type of the corresponding parameter. Because parameter values ​​are transmitted only as strings during network transmission, their type is lost. Therefore, the server cannot recover the actual parameter information based solely on the parameter value.

[0162] The following details a Java method that uses strings to fully retain parameter type information. The specific steps include:

[0163] Step S301: Initialize and use the typeName variable to record the current parameter type information. The variable value is initially an empty string.

[0164] Step S302: Start to determine the input parameter type information.

[0165] Step S303: If the parameter type is Class, directly use Class.getName() to obtain the parameter type name, recorded as className, typeName = typeName + className.

[0166] Step S304: If the parameter type is not Class, then the parameter type is a parameterized type class (ParameterizedType). This includes:

[0167] Step S3041: Get the original type of the current parameterized type (ParameterizedType.getRawType), and recursively execute step S302 and subsequent steps using the original type as a parameter.

[0168] Step S3042: Get the generic parameter array of the current parameterized type (ParameterizedType.getActualTypeArguments). This includes:

[0169] Step S30421: typeName = typeName + "<".

[0170] Step S30422: If the generic parameter array is not empty, for each generic parameter element, execute: recursively execute step S302 and subsequent steps using the generic parameter as a parameter; typeName = typeName + ",".

[0171] Step S30423: typeName = typeName + ">".

[0172] When the execution is finally completed, typeName records the parameter type information.

[0173] The JSON-based remote method call server implementation mainly includes:

[0174] Step S401: Parse the request parameter object and restore the value information and type information of the request parameter.

[0175] Parsing a request parameter object primarily involves converting string elements in the params array of the request object into corresponding Java objects based on their type information. The type information, described in string form, can be retrieved from the corresponding position in the paramTypes array.

[0176] The following describes in detail how to parse the actual Java type information from the type information string.

[0177] Step S4011: record the input type information character string as S, whose length is L, and the terminator set E includes the characters '<', ',', ' ', and '>'.

[0178] Step S4012: Start acquiring the original type information and use raw to record the original type information string. The specific process includes:

[0179] Step S40121: For index a, increment by 1 from 0 to L-1. S.charAt(a) is the character at the corresponding index position, recorded as char_a. If E contains char_a, return the substring raw = S.subString(0,a).

[0180] Step S40122: For the substring raw, the class represented by the raw string can be obtained through Class.forName provided by JDK reflection and recorded as rawClass.

[0181] Step S4013: Start obtaining parameter type information, traverse each character in the string S, start with the index value of raw.length, and use the array Arg[] to record the parameter type information string. The specific process includes:

[0182] Step S40131: If raw.length is equal to S.length, then directly return the empty Arg[] array.

[0183] Step S40132: Determine whether S.charAt(raw.length) is equal to '<'. If not, it means that the format of S is abnormal, and an exception is directly thrown to terminate the current parsing.

[0184] Step S40133: Use greaterMarkCout to record the number of '<' symbols currently to be processed, initially 0, and use startIndex to record the starting index of the currently obtained parameter type information, initially raw.length+1.

[0185] Step S40134: traverse each character in string S, starting with the index value raw.length+1, incrementing by 1 each time, up to a maximum of S.length-1, and recording the current index value as index_a. The specific process includes:

[0186] Step S401341: Record the character in S.chartAt(index_a) as c.

[0187] Step S401342: If the character c is equal to '<', then greaterMarkCout = greaterMarkCout + 1.

[0188] Step S401343: If the character c is equal to '>', then greaterMarkCout = greaterMarkCout - 1; if greaterMarkCout is less than 0, then add the element S.subString(staertIndex, index_a) to Arg[], terminate the current traversal, and jump to step S4015.

[0189] Step S401344: If the character c is equal to ',' and if greaterMarkCout is equal to 0, then add the element S.subString(startIndex, index_a) to Arg[]. startIndex = index_a + 1.

[0190] Step S4014: Determine whether the Arg[] array is empty. If it is empty, return rawClass.

[0191] Step S4015: If the Arg[] array is not empty, recursively execute steps S4011 to S4015 for each element in the Arg[] array, using a type array type[] to record the execution result of each element. The resulting parameterized type is ParameterizedType, whose raw type is rawClass and whose generic parameter type is type[].

[0192] Step S402: Implement method call based on JDK reflection library and obtain method execution return value.

[0193] Specifically, after step S401, the request parameter object is parsed to obtain the class of the method to be executed, the name of the method to be executed, and the parameters passed by the executed method. The getMethod method of the Class class in the JDK reflection library is used to obtain the method object, and the invoke method is used to execute the method and obtain the return value of the method execution.

[0194] Step S403: Process the method side effects and construct the return object.

[0195] Specifically, the execution of a method call typically produces more than just a return value; it also affects the call parameters, generating side effects. For example, when saving data, the primary key ID generated after saving is typically backfilled into the saved data object parameters. If a remote method call only results in a return value, it cannot effectively simulate a local method call. Therefore, in this embodiment, in addition to the return value of the local method call, the method parameters after the local method call is completed are returned to the remote method call client.

[0196] When the remote method call client obtains the return value of the method call, it also needs to replace its own method call parameter value with the method call parameter value returned by the server to simulate the method side effect.

[0197] Based on the same inventive concept, an embodiment of the present invention also discloses a system for unifying topological data structures and operations across services in a network target range, including: a topological network construction service module, used to maintain and publish topological data SDKs and topological standard operation algorithm SDKs to a central warehouse; a service registration module, used for each business service of the target range platform to register its own service identifier and remote method call address to the registration center, and pull all registered service information; and multiple business service modules, each business service module independently stores part of the topological data related to its own business. When specific topological data needs to be operated, the corresponding processing function in the topological standard operation algorithm SDK pulled from the central warehouse is used to operate the topological data. The processing function only relies on the abstract topological operation interface and implements remote method calls based on a mapping agent. When actually processing topological data, if the data table corresponding to the data class is stored in the local database of the business service, the generated local database implementation class instance is used. Otherwise, the corresponding service will be called based on the json remote method to perform database operations according to the predefined data class affiliation service and the service information obtained from the registration center.

[0198] Furthermore, the system also includes: a transaction management service module for implementing cross-service transaction management using distributed transaction components. The transaction management service module maintains the status of global transactions and business service transactions, and notifies business services to commit or rollback global transactions.

[0199] The specific implementation details of each module can be found in the above method embodiment and will not be repeated here.

[0200] An embodiment of the present invention also discloses a computer program product, including a computer program, which, when executed by a processor, implements the steps of the method for unifying topology data structure and operation across services in a network target range.

[0201] The program code for implementing the inventive method can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that the program code, when executed by the processor or controller, causes the steps of the inventive method to be implemented. The program code can be executed entirely on the machine, partially on the machine, partially on the machine as an independent software package and partially on a remote machine, or completely on a remote machine or server. The present invention is not described in detail herein, and all of these are known techniques to those skilled in the art.< / sceneelementmodel> < / sceneelementmodel> < / sceneareamodel> < / sceneareamodel> < / scenemodel> < / scenemodel>

Claims

1. A method for unifying topology data structures and operations across services in a network range, characterized in that: The steps include: The topology network construction service maintains and publishes the topology data SDK and topology standard operation algorithm SDK to the central warehouse; Each business service on the range platform registers its own service identifier and remote method call address with the registration center, and pulls all registered service information; Each business service independently stores part of the topology data related to its own business. When it needs to operate specific topology data, it uses the corresponding processing function in the topology standard operation algorithm SDK pulled from the central warehouse to operate the topology data. The processing function only relies on the abstract topology operation interface and implements remote method calls based on the mapping agent. When actually processing topology data, if the data table corresponding to the data class is stored in the local database of the business service, the generated local database implementation class instance is used. Otherwise, the database operation is performed on the corresponding service based on the remote method call of JSON according to the predefined data class belonging service and the service information obtained from the registration center; The topology data SDK is composed of data classes that describe the entire topology data structure, including topology global information data class, topology node data class, topology node port data class, topology connection data class, cloud platform service-related data class, and collection service-related data class; each data class corresponds to a table in the database, and each data class has its own unique service; the topology standard operation algorithm SDK includes unified query, traversal, creation and update algorithms for topology data; the topology standard operation algorithm only relies on the abstract topology operation interface when implemented. The local storage data in the topology data is processed by the local database interface implemented by this business service. The local database interface is generated by the mybatis framework using JDK dynamic proxy technology to generate a mapping proxy instance that actually performs database operations, and is registered in the Spring container for use by the topology standard operation algorithm; non-locally stored data is processed by the non-local database interface, and the non-local database interface mapping proxy instance will be registered in the Spring container through the Spring Config configuration class declaration for use by the topology standard operation algorithm.

2. The method for unifying topology data structures and operations across services in a network range according to claim 1, characterized in that: When the implementation class of the topology standard operation algorithm is initialized, the specific instance of the dependent abstract topology operation interface is obtained from the Spring container.

3. The method for unifying topology data structures and operations across services in a network range according to claim 1, characterized in that: Implementing remote method calls based on mapping proxies includes: defining an abstract topology operation interface class to describe the basic add, delete, modify, and query capabilities related to database interaction provided by the mapping proxy, defining a remote proxy interface to describe the cross-service call operation capabilities provided by the mapping proxy; implementing the remote proxy interface through the service proxy abstract class, providing basic json-based remote method call assembly parameters and call initiation template implementation; the basic mapping proxy abstract class inherits the service proxy abstract class and implements the abstract topology operation interface at the same time, providing the ability to perform database interaction operations across services; the mapping proxy of the specific business service operation table only needs to inherit the basic mapping proxy abstract class, and define its own affiliated service name and the corresponding class identifier in the affiliated service.

4. The method for unifying topology data structures and operations across services in a network range according to claim 1, characterized in that: When a JSON-based remote method call is made, the fields of the request parameter object constructed by the remote method call client include the corresponding business bean name in the Spring container, the calling method name, and the JSON string array converted from the parameter values ​​of the calling method and the corresponding parameter type array; the remote method call server parses the request parameter object, implements the method call based on the JDK reflection library, obtains the method execution return value, and returns the return value of the local method call and the method parameters after the local method call is completed to the remote method call client to handle the method side effects.

5. The method for unifying topology data structures and operations across services in a network range according to claim 1, characterized in that: Distributed transaction components are used to implement cross-service transaction management. The transaction management service maintains the status of global transactions and business service transactions, and notifies business services to commit or rollback global transactions.

6. A system for unifying topological data structures and operations across services in a network range, characterized by: include: Topology network construction service module, used to maintain and publish topology data SDK and topology standard operation algorithm SDK to the central warehouse; The service registration module is used by each business service of the range platform to register its own service identifier and remote method call address with the registration center, and pull all registered service information; And multiple business service modules, each business service module independently stores part of the topology data related to its own business. When it is necessary to operate specific topology data, the corresponding processing function in the topology standard operation algorithm SDK pulled from the central warehouse is used to operate the topology data. The processing function only relies on the abstract topology operation interface and implements remote method calls based on the mapping agent. When actually processing topology data, if the data table corresponding to the data class is stored in the local database of the business service, the generated local database implementation class instance is used. Otherwise, the database operation is performed on the corresponding service based on the remote method call of json according to the predefined data class belonging service and the service information obtained from the registration center; The topology data SDK is composed of data classes that describe the entire topology data structure, including topology global information data class, topology node data class, topology node port data class, topology connection data class, cloud platform service-related data class, and collection service-related data class; each data class corresponds to a table in the database, and each data class has its own unique service; the topology standard operation algorithm SDK includes unified query, traversal, creation and update algorithms for topology data; the topology standard operation algorithm only relies on the abstract topology operation interface when implemented. The local storage data in the topology data is processed by the local database interface implemented by this business service. The local database interface is generated by the mybatis framework using JDK dynamic proxy technology to generate a mapping proxy instance that actually performs database operations, and is registered in the Spring container for use by the topology standard operation algorithm; non-locally stored data is processed by the non-local database interface, and the non-local database interface mapping proxy instance will be registered in the Spring container through the Spring Config configuration class declaration for use by the topology standard operation algorithm.

7. The system for unifying topological data structures and operations across services in a network range according to claim 6, characterized in that: Also includes: The transaction management service module is used to implement cross-service transaction management using distributed transaction components. The transaction management service module maintains the status of global transactions and business service transactions, and notifies business services to commit or rollback global transactions.

8. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method for unifying topology data structure and operation across services in a network range according to any one of claims 1 to 5 are implemented.

Images