Method and system for cross-service unified topological data structure and operation in network target range

Abstract

The invention discloses a cross-service unified topological data structure and operation method and system in a network target range. According to the method, service maintenance is constructed through a topological network, and topological data SDK and a topological standard operation algorithm SDK are published to a central warehouse; each business service registers an own service identifier and a remote method calling address to the registration center, and pulls all registered service information; each business service independently stores part of topological data related to own business, when specific topological data needs to be operated, the topological data is operated by using a corresponding processing function in a topological standard operation algorithm SDK pulled from a central warehouse, and the topological standard operation algorithm can support automatic routing to realize cross-service operation of the topological data. According to the invention, decoupling of the topological data of different services of the network target range platform is realized, the different services independently carry out additional internal business operation on part of the topological data belonging to the services through a unified operation algorithm, and the maintainability of the network target range platform is improved.

Description

Technical Field

[0001] The present invention relates to a method and system for unified topology data structure and operation across services in a network range, belonging 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 split into many microservices, such as a cloud platform service providing virtualization resource management capabilities, a topology network construction service providing topology instance construction capabilities, a collection service providing collection capabilities, a visualization service providing topology information visualization capabilities, etc. Each microservice needs to execute its own business operations according to the current topology instance data. For example, the visualization service needs to query topology instance information for presenting topology information on the interface, and the collection service needs to query topology instance information for obtaining configured collection information, etc. These services will parse the topology instance data obtained from the interfaces opened by the topology network construction service according to their internal understanding of the topology instance; or require the platform topology network construction service to customize corresponding topology data interfaces according to the data formats required inside other services.

[0003] The current solutions have the following problems: 1. The topology network construction service needs to separately customize different interfaces for different services, with a large workload and a long docking time. 2. If the topology network construction service lacks the ability to customize corresponding interfaces for different services, other services need to redefine and implement the format and operation algorithms of topology data inside the service, with a large workload and a long docking time. 3. If a large number of business interfaces are customized for different services inside the topology network construction service, the topology network construction service will couple a large number of operations of other services on topology data, and the business meanings of these operations are not clear to the platform topology network construction service, making maintenance very difficult. Summary of the Invention

[0004] Object of the Invention: Aiming at the problems existing in the above-mentioned prior art, the object of the present invention is to provide a method and system for unified topology data structure and operation across services in a network range, realizing the unification of topology data formats and the unification of topology standard operation algorithms, and improving the maintainability of the network range platform.

[0005] Technical Solution: To achieve the above object of the invention, the present invention adopts the following technical solutions: A method for unified topology data structure and operation across services in a network range, comprising the following steps: The topology network construction service maintains and publishes a topology data SDK and a topology standard operation algorithm SDK to a central repository; Each business service of the range platform registers its own service identifier and remote method call address with a registration center, and pulls all the registered service information; Each business service stores its own business-related partial topology data independently. 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 depends on the abstract topology operation interface and implements remote method invocation based on the mapping proxy. 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, according to the predefined data class attribution service and the service information obtained from the registry center, the database operation is performed by remotely invoking the corresponding service based on json.

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

[0007] Preferably, when the topology standard operation algorithm is implemented, it only depends on the abstract topology operation interface. The local storage data in the topology data is processed by the local database interface implemented by this business service. The local database interface uses the JDK dynamic proxy technology of the mybatis framework to generate a mapping proxy instance that actually executes database operations and registers it in the Spring container for the topology standard operation algorithm to use; the non-local storage data is processed by the non-local database interface, and the mapping proxy instance of the non-local database interface will be declared and registered in the Spring container through the Spring Config configuration class for the topology standard operation algorithm to use.

[0008] Preferably, when the implementation class of the topology standard operation algorithm is initialized, the specific instance of the abstract topology operation interface on which it depends is obtained from the Spring container.

[0009] Preferably, remote method invocation is implemented based on the mapping proxy, including: defining an abstract topology operation interface class to describe the basic and database interaction-related capabilities of adding, deleting, modifying, and querying 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 a service proxy abstract class to provide a template implementation for assembling parameters and initiating calls for basic json-based remote method invocation; the basic mapping proxy abstract class inherits the service proxy abstract class and at the same time implements the abstract topology operation interface to provide the ability to perform database interaction operations across services; the mapping proxy for the specific business service operation table only needs to inherit the basic mapping proxy abstract class and define its own attribution service name and the corresponding class identifier in the attributed service.

[0010] Preferably, when making a remote method call 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 method name to be called, as well as an array of JSON strings obtained by converting the parameter values of the method to be called and an array of corresponding parameter types; the remote method call server parses the request parameter object, implements the method call based on the JDK reflection library, obtains the return value of the method execution, and returns the return value of the local method call and the method parameters after the completion of the local method call to the remote method call client to handle method side effects.

[0011] Furthermore, a distributed transaction component is adopted to implement cross-service transaction management. The transaction management service maintains the states of the global transaction and the transactions of business services, and notifies the business services to commit or roll back the global transaction.

[0012] Based on the same inventive concept, the present invention provides a system for cross-service unified topology data structure and operation in a network range, including: A topology network construction service module, configured to maintain and publish a topology data SDK and a topology standard operation algorithm SDK to a central repository; A service registration module, configured to register the service identifiers and remote method call addresses of each business service in the range platform with a registration center, and pull all the registered service information; And a plurality of business service modules. Each business service module independently stores a 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 repository is used to operate the topology data. The processing function only depends on the abstract topology operation interface, and a remote method call is implemented based on a mapping proxy. When actually processing the topology data, if the data table corresponding to the data class is stored in the local database of the business service, an instance of the generated local database implementation class is used; otherwise, according to the predefined data class attribution service and the service information obtained from the registration center, a database operation is performed on the corresponding service by means of a remote method call based on JSON.

[0013] Furthermore, the system further includes: a transaction management service module, configured to implement cross-service transaction management by using a distributed transaction component. The transaction management service module maintains the states of the global transaction and the transactions of business services, and notifies the business services to commit or roll back the global transaction.

[0014] The present invention also provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of the method for cross-service unified topology data structure and operation in the network range are implemented.

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

[0016] Figure 1 It is a schematic diagram of the architecture design of an embodiment of the present invention.

[0017] Figure 2 It is a schematic diagram of the architecture and process of a range platform including a visualization service and a collection service as an example in an embodiment of the present invention.

[0018] Figure 3 It is a detailed process schematic diagram of a business service operating topology data in an embodiment of the present invention.

[0019] Figure 4 It is a general remote method call design class diagram based on MapperProxy in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0020] Next, the technical solutions of the present invention will be clearly and completely described in conjunction with the accompanying drawings and specific embodiments.

[0021] As Figure 1 shown, an embodiment of the present invention discloses a method for cross-service unified topology data structure and operation in a network range, mainly including: the topology network construction service maintains and publishes the topology data SDK and the topology standard operation algorithm SDK to the central warehouse; each business service in the range platform registers its own service identifier and the remote method call address with the registration center, and pulls all the registered service information; each business service independently stores part of the topology data related to its own business. When specifically operating on the topology data, the corresponding processing function in the topology standard operation algorithm SDK pulled from the central warehouse is used to operate on the topology data. The processing function only depends on the abstract topology operation interface, and realizes remote method call based on the mapping proxy. When actually processing the 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, according to the predefined service to which the data class belongs and the service information obtained from the registration center, a remote method call based on json is used to execute database operations on the corresponding service.

[0022] Among them, 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 affiliated service.

[0023] The topology standard operation algorithm SDK includes unified query, traversal, creation, and update algorithms for topology data. When implementing the specific topology standard operation algorithms, they only depend on the abstract topology operation interface. The local storage data in the topology data is processed by the local database interface implemented by this business service, and the non-local storage data is processed by the non-local database interface. When specifically implementing, the local database interface can use the JDK dynamic proxy technology by the mybatis framework to generate a mapping proxy instance that actually executes database operations, and register it into the Spring container for the topology standard operation algorithms to use; the non-local database interface mapping proxy instance can be declared and registered into the Spring container through the Spring Config configuration class for the topology standard operation algorithms to use. When initializing the implementation class of the topology standard operation algorithm, the specific instance of the abstract topology operation interface on which it depends is obtained from the Spring container.

[0024] In one embodiment, remote method invocation is implemented based on the mapping proxy. The specific implementation includes: First, define an abstract topology operation interface class to describe the basic capabilities related to database interaction provided by the mapping proxy, and define a remote proxy interface to describe the cross-service call operation capabilities provided by the mapping proxy; then implement the remote proxy interface through a service proxy abstract class, providing a template implementation for assembling parameters and initiating calls for basic json-based remote method invocations; then inherit the service proxy abstract class through the basic mapping proxy abstract class and implement the abstract topology operation interface at the same time, providing the ability to perform database interaction operations across services; finally, the mapping proxy for 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.

[0025] In one embodiment, when making a json-based remote method invocation, the fields of the request parameter object constructed by the remote method invocation client include the corresponding business Bean name in the Spring container, the method name to be invoked, as well as an array of json strings obtained by converting the parameter values of the method to be invoked and an array of corresponding parameter types; the remote method invocation server parses the request parameter object, implements the method invocation based on the JDK reflection library, obtains the return value of the method execution, and returns the return value of the local method invocation and the method parameters after the local method invocation is completed to the remote method invocation client to handle method side effects.

[0026] In one embodiment, a distributed transaction component is further adopted to implement cross-service transaction management. The transaction management service maintains the states of the global transaction and the transactions of the business services, and notifies the business services to commit or roll back the global transaction.

[0027] Figure 2 illustrates the architecture of a network range platform including a topology network construction service, a visualization service, and a collection service, as well as the implementation process of specific services. The following combines Figure 2 Details of the implementation of a method for cross-service unified topology data structure and operations in a network range are described in detail.

[0028] As Figure 2 shown, a method for cross-service unified topology data structure and operations in a network range disclosed in this embodiment includes the following steps: 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.

[0029] The topology data SDK defines the data structure of the topology, and 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, the names and meanings of the detailed data classes are shown in Table 1.

[0030] Table 1 Example of data classes

[0031] It should be noted that the above topology data SDK only lists the topology data classes related to the cloud platform and the collection service, and more topology data classes related to other services can be added additionally.

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

[0033] publishing { publications { maven(MavenPublication){ from components.java } } repositories { maven { name ='remote' allowInsecureProtocol = true url 'http: / / <netxus service IP> / repository / <directory address> / ' credentials { username =<netxus account> password =<netxus password> } } } } Step S102: When all microservices of 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.

[0034] The registration format example is as follows: { "app_code": "topo_constructor", "rpc_host": "http: / / 172.0.0.1:8081 / proxy / call / service" } 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.

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

[0036] 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.

[0037] 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: / / Obtain the implementation class instance 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.

[0038] @Override public BaseMapperInterface <scenemodel>getSceneMapper() { return (BaseMapperInterface <scenemodel>) BeanCommon.getBean(SceneSdkMapperConstant.SCENE_MAPPER); } @Override public BaseMapperInterface <sceneareamodel>getSceneAreaMapper() { return (BaseMapperInterface <sceneareamodel>) BeanCommon.getBean(SceneSdkMapperConstant.SCENE_AREA_MAPPER); } @Override public BaseMapperInterface <sceneelementmodel>getSceneElementMapper(){ return (BaseMapperInterface <sceneelementmodel>) BeanCommon.getBean(SceneSdkMapperConstant.SCENE_ELEMENT_MAPPER); } public SceneHandler(String sceneId, String areaId, SceneContextBO context) { init(sceneId, areaId, false, context); } public void save() { boolean isCreate = StringUtils.isEmpty(sceneId); saveScene(); Map<String, A0> existAreaMap = isCreate? new HashMap<>() : readAreas().stream() .collect(Collectors.toMap(BaseSceneAreaModel::getNodeId, x -> x)); var filterAreaIds = new String[0]; if (isAreaMode) { String currentAreaId = areaId == null? StringUtils.EMPTY : areaId; filterAreaIds = ArrayUtils.addAll(existAreaMap.values().stream().filter(BaseSceneAreaModel::getOpen) .map(BaseSceneAreaModel::getNodeId).toArray(String[]::new), currentAreaId); } ... / / The specific business - related saving logic is not detailed here. Only the calling method of the implementation class of the abstract class is demonstrated here} private boolean saveScene() { / / Code for saving the SceneModel data class S0 sceneObj = scene.toModel(); var result = getSceneMapper().save(sceneObj); sceneId = sceneObj.getId(); scene.fromModel(sceneObj); plugins.forEach(plugin ->plugin.setSourceSceneId(sceneId)); return result; } The code shown above is part of two functions. One is the SceneHandler constructor, which is the implementation of the unified query algorithm for topological data. The other is the save method, which is part of the implementation of the unified update algorithm for topological data. By introducing the topological standard algorithm SDK jar package, each business service can directly use various topological operation algorithms defined in the topological standard algorithm SDK jar package to operate on topological data across services.

[0039] Step S106: When actually loading topological data, the current business service (visualization service) will perform different operations according to different instances of the injected database query interface class (i.e., the MapperProxy described below). For data tables actually stored in the current business service, the injected instance is the local database query class generated by mybatis based on JDK dynamic proxy; for data tables not stored in the current business service, the injected instance is the instance of the database query interface class registered through a custom configuration class within the current business service. The current business service obtains the microservice to which it belongs, the service identifier, and the remote call information obtained from the registration center through the getService method in each database query interface class instance, and requests the corresponding service address. The actual database operation is executed within other business services through JSON-based remote method calls. In this process, seata is used to implement cross-service transactions to ensure the consistency of cross-service topological data.

[0040] The specific execution process is as Figure 3 shown, specifically including: Step S1061: When implementing the topology standard operation algorithm, it only depends on the abstract topology query interface BaseMapperInterface. The local storage data in the topology data is processed by the Mapper implemented and managed by the mybatis framework of this business service; the non-local storage data is processed by the custom MapperProxy.

[0041] Step S1062: When the system starts, the local database interface Mapper will generate an actual MapperProxy instance that executes database operations by using the JDK dynamic proxy technology by the mybatis framework, and register it into the Spring container for the topology standard operation algorithm to use. The predefined non-local database interface MapperProxy instance will be declared and registered into the Spring container through the Spring Config configuration class for the topology standard operation algorithm to use.

[0042] The following is a simple display of the configuration class code: @Configuration public class MapperProxyBeanConfig { / ** * Get the scene MapperProxy * * @return the scene MapperProxy * / @Bean("sceneMapper") public SceneMapperProxy getSceneMapperProxy() { return new SceneMapperProxy(); } / ** * Get the scene node MapperProxy * * @return the scene node MapperProxy * / @Bean("sceneElementMapper") public SceneElementMapperProxy getSceneElementMapperProxy() { return new SceneElementMapperProxy(); } / ** * Obtain the scene node port MapperProxy * * @return The scene node port MapperProxy * / @Bean("sceneElementPortMapper") public SceneElementPortMapperProxy getSceneElementPortMapperProxy() { return new SceneElementPortMapperProxy(); } }...... There are many other MapperProxy instances registered in the Spring container through the current configuration class later.

[0043] Step S1063: When the system is running, an instance of the class is created by the implementation class SceneHandler of the topology standard operation algorithm. When initializing the class, a specific instance of the abstract class BaseMapperInterface on which it depends will be obtained from the Spring container.

[0044] Step S1064: When the system is running, when operating on the local storage data of the current business service, directly connect to the local database through the MapperProxy instance dynamically generated by mybatis for operation; when operating on non-local storage data, call the JSON-based remote method call client through the pre-defined MapperProxy, and call the remote method call server at the corresponding service address through the service address stored corresponding to the current data class. Finally, the MapperProxy instance is dynamically generated by mybatis inside other services for data operation.

[0045] Step S1065: When actually operating on the topology data, the business service that initiates the topology operation initiates a global transaction to the seata transaction manager service TC.

[0046] Since the actual topology data operation is cross-service, the local database transaction of each service can only ensure the validity, consistency, and integrity of the partial topology data stored in its own service, but cannot ensure the validity, consistency, and integrity of the completed cross-service stored topology data.

[0047] Therefore, in this embodiment, the Seata distributed transaction component is adopted to support the distributed transaction capability of the system. The Transaction Manager Service TC is a centralized transaction management service provided by Seata, which maintains the states of global transactions and transactions of each service, and notifies each service to commit or roll back the global transaction. Each business service registers / reports the execution status and results of the global transaction of this business service with TC, and executes the commit or rollback of the global transaction. The subsequent steps describe in more detail the interaction process between each business service and the Transaction Manager Service TC.

[0048] Step S1066: All business services obtain the global lock for the current topology operation from the Transaction Manager Service TC.

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

[0050] Step S1068: Each business service reports the execution status of the local transaction to the Transaction Manager Service TC.

[0051] Step S1069: After the Transaction Manager Service TC obtains that the execution status of the local transactions reported by all business services is successful, it sends an instruction indicating the successful execution of the global transaction to each business service. After receiving the global transaction success instruction, each business service releases the global lock and deletes the undoLog generated in Step S1067 for rollback.

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

[0053] In Step S1064, the JSON-based remote method invocation mainly includes the general remote method invocation logic of MapperProxy and the client implementation and server implementation.

[0054] In this embodiment, the template method design pattern is adopted to implement the general remote method invocation logic of MapperProxy, and the specific implementation is as Figure 4 shown. The implementation steps include: Step S201: Define the BaseMapperInterface interface class to describe the basic capabilities of MapperProxy related to database interaction for addition, deletion, modification, and query. Define the IProxy interface to describe the cross-service call operation capabilities provided by MapperProxy.

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

[0056] For the MapperProxy of the data table related to the specific business service, it only needs to inherit from the BaseMapperProxy abstract class and define the identification of its own belonging service name (getService() method) and the corresponding class (getClass() method) in the belonging service, then it can conveniently provide the ability of cross-service database interaction operations for the upper-layer business.

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

[0058] Table 2 Structure of the request parameter object

[0059] 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, which is a fixed attribute of each MapperProxy. The method field is the name of the called method, which is determined by the currently called method. The params field is an array of JSON strings converted from the parameter values of the currently called method. The paramsType is the parameter type of the corresponding parameter. Because only strings are used to pass parameter values during network transmission, the type of the parameter value will be lost, so the server cannot restore the actual parameter information only based on the parameter value.

[0060] The following details a method in Java that can completely retain parameter type information using strings. The specific steps are as follows: Step S301: Initialize the use of the typeName variable to record the current parameter type information, and the initial value of the variable is an empty string.

[0061] Step S302: Start to judge the input parameter type information.

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

[0063] Step S304: If the parameter type is not the Class class, then the parameter type is the parameterized type class (ParameterizedType). It includes: Step S3041: Obtain the raw type of the current parameterized type (ParameterizedType.getRawType), and recursively execute Step S302 and its subsequent steps with the raw type as the parameter.

[0064] Step S3042: Obtain the generic parameter array of the current parameterized type (ParameterizedType.getActualTypeArguments). It includes: Step S30421: typeName = typeName + "<".

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

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

[0067] After the execution of typeName is finally completed, it records the parameter type information.

[0068] The server - side implementation of the remote method call based on json mainly includes: Step S401: Parse the request parameter object to restore the value information and type information of the request parameters.

[0069] Parsing the request parameter object mainly converts the string elements in the params array in the request object into corresponding java objects according to their type information. The type information described in string form can be obtained from the corresponding positions in the paramTypes array.

[0070] The following details how to parse the actual java type information from the type information string.

[0071] Step S4011: Record the input type information string as S, its length as L, and the termination character set E contains characters '<', ',', ' ', '>'.

[0072] Step S4012: Start to obtain the raw type information, and use raw to record the raw type information string. The specific process includes: Step S40121: For the index a, increment it by 1 each time starting from 0 until L - 1. S.charAt(a) is the character at the corresponding index position, recorded as char_a. If E contains char_a, then return the substring raw = S.subString(0, a).

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

[0074] Step S4013: Start to obtain parameter type information. Traverse each character in the string S, with the starting index value being raw.length, and use the array Arg[] to record the parameter type information string. The specific process includes: Step S40131: If raw.length is equal to S.length, then directly return an empty Arg[] array.

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

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

[0077] Step S40134: Traverse each character in the string S, with the starting index value being raw.length + 1, incrementing by 1 each time, and the maximum being S.length - 1. Record the current index value as index_a. The specific process includes: Step S401341: Record the character S.chartAt(index_a) as c.

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

[0079] 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[], abort the current traversal, and jump to Step S4015.

[0080] Step S401344: If the c character 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.

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

[0082] Step S4015: If the Arg[] array is not empty, then recursively execute steps S4011 to S4015 for each element in the Arg[] array, and use an array of types type[] to record the execution results of each element. Finally, obtain the parameterized type ParameterizedType, whose raw type is rawClass and the generic parameter type is type[].

[0083] Step S402: Implement method invocation based on the JDK reflection library and obtain the return value of the method execution.

[0084] Specifically, after step S401, by parsing the request parameter object, the class to which the method to be executed belongs, the name of the method to be executed, and the parameters passed to the execution method can be obtained. The method object can be obtained using the getMethod method of the Class class in the JDK reflection library, and the method invocation can be executed using the invoke method to obtain the return value of the method execution.

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

[0086] Specifically, generally, the execution of a method invocation will not only obtain the return value, but also affect the invocation parameters, that is, generate method invocation side effects. For example, when saving data, usually the primary key id generated after saving is filled back into the parameter of the data object to be saved. If the result of a remote method invocation only has the return value, then it cannot well simulate a local method invocation. Therefore, in this embodiment, in addition to the return value of the local method invocation, the method parameters after the completion of the local method invocation are also returned to the remote method invocation client.

[0087] When the remote method invocation client obtains the return value of the method invocation, it also needs to replace the method invocation parameter value of itself with the method invocation parameter value returned by the server to simulate the method side effects.

[0088] Based on the same inventive concept, an embodiment of the present invention also discloses a system for unified topology data structure and operation across services in a network range, including: a topology network construction service module for maintaining and publishing a topology data SDK and a topology standard operation algorithm SDK to a central repository; a service registration module for each business service of the range platform to register its own service identifier and remote method call address with a registration center and pull all registered service information; and a plurality of business service modules, each business service module independently stores part of the topology data related to its own business, and when specific topology data needs to be operated, uses the corresponding processing function in the topology standard operation algorithm SDK pulled from the central repository to operate the topology data. The processing function only depends on an abstract topology operation interface and implements remote method calls based on a mapping proxy. When actually processing topology data, if the data table corresponding to the data class is stored in the local database of the business service, a generated local database implementation class instance is used, otherwise, according to the predefined data class attribution service and the service information obtained from the registration center, a remote method call based on json is made to the corresponding service to execute database operations.

[0089] Further, the system further includes: a transaction management service module for implementing cross-service transaction management using a distributed transaction component. The transaction management service module maintains the states of global transactions and business service transactions and notifies the business service to commit or roll back the global transaction.

[0090] Details of the implementation of each specific module can be referred to the above method embodiment and will not be elaborated here.

[0091] An embodiment of the present invention also discloses a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of the method for unified topology data structure and operation across services in the network range are implemented.

[0092] The program code for implementing the method of the present invention 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 devices, so that when the program codes are executed by the processor or controller, the steps of the method of the present invention are implemented. The program codes can be executed entirely on the machine, partially on the machine, executed as an independent software package partially on the machine and partially on a remote machine, or executed entirely on a remote machine or server. Details not described in the present invention are all well-known technologies in the art.< / sceneelementmodel> < / sceneelementmodel> < / sceneareamodel> < / sceneareamodel> < / scenemodel> < / scenemodel>

Claims

1. A method for cross-service unified topology data structure and operation in a network range, characterized in that It includes the following steps: The topology network construction service maintains and publishes the topology data SDK and the topology standard operation algorithm SDK to the central repository; Each business service on the range platform registers its own service identifier and the remote method call address with the registry center, and pulls all the registered service information; Each business service independently stores the part of the topology data related to its own business. When it is necessary to operate specific topology data, it uses the corresponding processing function in the topology standard operation algorithm SDK pulled from the central repository to operate the topology data. The processing function only depends on the abstract topology operation interface and implements remote method calls based on the mapping proxy. When actually processing topology data, if the data table corresponding to the data class is stored in the local database of the business service, it uses the generated local database implementation class instance. Otherwise, according to the predefined service to which the data class belongs and the service information obtained from the registry center, it performs database operations by making a remote method call to the corresponding service based on json.

2. The method for cross-service unified topology data structure and operation in a network range, as claimed in claim 1, wherein The topology data SDK consists 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, data classes related to cloud platform services, and data classes related to acquisition services; 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.

3. The method for cross-service unified topology data structure and operation in a network range, as claimed in claim 1, wherein When implementing the topology standard operation algorithm, it only depends on the abstract topology operation interface. The local storage data in the topology data is processed by the local database interface implemented by this business service. The local database interface uses the JDK dynamic proxy technology of the mybatis framework to generate a mapping proxy instance that actually executes database operations and registers it in the Spring container for the topology standard operation algorithm to use; the non-local storage data is processed by the non-local database interface, and the mapping proxy instance of the non-local database interface will be declared and registered in the Spring container through the Spring Config configuration class for the topology standard operation algorithm to use.

4. The method for cross-service unified topology data structure and operation in a network range, characterized in that, When initializing the implementation class of the topology standard operation algorithm, it obtains the specific instance of the dependent abstract topology operation interface from the Spring container.

5. The method for cross-service unified topology data structure and operation in a network range, as claimed in claim 1, wherein Implementing remote method calls based on the mapping proxy includes: defining an abstract topology operation interface class to describe the basic and database interaction-related capabilities of adding, deleting, modifying, and querying 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 to provide a template implementation for assembling parameters and initiating calls for basic json-based remote method calls; the basic mapping proxy abstract class inherits the service proxy abstract class and implements the abstract topology operation interface at the same time to provide the ability to perform database interaction operations across services; the mapping proxy for the specific business service operation table only needs to inherit the basic mapping proxy abstract class and define its own belonging service name and the corresponding class identifier in the belonging service.

6. The method for cross-service unified topology data structure and operation in a network range, as claimed in claim 1, is characterized in that When making a remote method call 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 method name to be called, as well as an array of JSON strings obtained by converting the parameter values of the method to be called and an array of corresponding parameter types; the remote method call server parses the request parameter object, implements the method call based on the JDK reflection library, obtains the return value of the method execution, and returns the return value of the local method call and the method parameters after the local method call is completed to handle method side effects.

7. The method for cross-service unified topology data structure and operation in a network range, as claimed in claim 1, wherein A distributed transaction component is used to implement cross-service transaction management. The transaction management service maintains the states of the global transaction and the transactions of business services, and notifies the business services to commit or roll back the global transaction.

8. A system for unified topology data structure and operation across services in a network range, characterized in that, It includes: A topology network construction service module, which is used to maintain and publish the topology data SDK and the topology standard operation algorithm SDK to the central repository; A service registration module, which is used for each business service of the range platform to register its own service identifier and the remote method call address with the registration center, and pull all the 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 specific topology data needs to be operated, the corresponding processing function in the topology standard operation algorithm SDK pulled from the central repository is used to operate the topology data. The processing function only depends on the abstract topology operation interface and implements remote method call based on the mapping proxy. When actually processing the 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, according to the predefined data class belonging service and the service information obtained from the registration center, a remote method call based on JSON is made to the corresponding service to execute database operations.

9. The system for cross-service unified topology data structure and operation in the network range, as claimed in claim 8, wherein It also includes: A transaction management service module, which is used to implement cross-service transaction management by using a distributed transaction component. The transaction management service module maintains the states of the global transaction and the transactions of business services, and notifies the business services to commit or roll back the global transaction.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it realizes the steps of the method for unified topology data structure and operation across services in the network range according to any one of claims 1-7.

Images