In order to facilitate those skilled in the art to understand the technical content of the present invention, the content of the present invention will be further explained below in conjunction with the accompanying drawings.
 Using the TCP communication method, the gateway and the execution node are separated, allowing multiple nodes to process the same function, thereby reducing the pressure on the server, regardless of the development language, and realizing the iterative mixed development requirements of the system.
 In the design, the gateway service serves as a unified entrance and exit, dispatching client application requests to the back-end execution nodes for processing according to certain rules, and responding to the client with data after receiving the processing results, thus forming a reverse proxy mechanism . At this time, the source of the request (the requesting client) is clear, but it is not clear which server the request is processed by. The client is not aware of the existence of the proxy, and the reverse proxy is transparent to the outside world, and the visitor does not I don't know that I am visiting a proxy. Because the client can access without any configuration.
 like figure 1 As shown, the system of the present invention includes: a gateway service and an execution node, data transmission is performed through TCP, and the gateway service provides calling functions in the form of RESTFUL.
 like figure 2 As shown, the gateway service design is composed of API registration service, API buffer pool, and API caller. SpringBoot is used as the underlying container to provide a unified RESTFUL call interface.
 The gateway service listens to the registration port after startup, and the execution node registers the provided functions with the gateway in TCP mode after startup to form an API list; other applications request the registered API functions through the RESTFUL interface.
 SpringBoot framework: The gateway service provides a RESTFUL unified request interface, so SpringBoot is used as the underlying container, and the standard POST request function is used as the only transparent interface. Its prototype is:
 @RequestMapping(path="/getResult", method=RequestMethod.POST)
 public ResultModel getResult(
 @RequestBody Argument invokeArgs,
 HttpServletRequest request)
 Among them, invokeArgs is used as a request input parameter, and its data type is JSON, including the requested IP address, function name, function version number, and parameters received by the function or other parameter information. Its definition is as follows:
 The return value (response) data model includes: the requested function name, the version number of the function, the function access return code, and the function response return value. In order to better adapt to various parameter transfers, the return value type is wrapped in Object, and its data type Rely on datatype for definition, including: String, int, double, bool, JsonArray, JsonObject, etc., which are defined as follows
 API registration service: monitor the function registration port in TCPServer mode, receive the function registration from the execution node, and save the execution node information and the called function to the API buffer pool.
 API cache pool: In order to quickly find calling functions and nodes, all registered functions are saved to the cache pool. In order to ensure the collaborative development of multiple users and the accuracy of breakpoint debugging, a development group is introduced into the design. When the execution node registers the API, it also submits the development group information to which it belongs, forms a development list on the API registration service, and forms an API cache pool. The function prototype of the development group is as follows:
 Interface functions are registered in the development group of the API cache pool, such as image 3 As shown, the development team defines the function mapping relationship and node mapping relationship in the form of HashMap. Among them, the function mapping relationship is determined by the IP port ( image 3 IP:PORT in ) as key, function list ( image 3 Func1, Func2, ..., Funcn) in the value to form a correspondence; the node mapping is based on the function name ( image 3 Func in ) is the key, call node ( image 3 Node1, Node2, ..., Noden in ) form correspondences for values.
API caller: When performing function search, obtain the corresponding development group from the group parameter of the requested Url address, obtain the API list of the development group, and then obtain the execution node list in the function mapping relationship through the method parameter, and pass the configured The load balancing algorithm obtains the corresponding nodes, executes function calculations, and returns data. The logic process is as follows Figure 4 shown.
 The execution node is composed of API collector, node service and executor.
 API Collector: A set of function annotations is defined on the execution node to mark function information. When developers write interface functions, they need to annotate classes and interface functions through annotations. The annotation process is similar to that of SpringBoot interface functions.
 When the execution node starts, the API collector traverses and reflects the loaded classes, obtains class instances through annotations, extracts function annotation information, and forms a function list to register with the gateway service. The function list exists in the form of JSON, including the full name, description, parameters, return value and other information of the function.
 Node service: In the execution node, it listens to the called port as a TCPServer, and connects to the gateway service as a TcpClient to register the API function.
 Executor: When the node service receives a request from the gateway service, it calls the executor to execute the specified function logic. The executor analyzes the received function description, performs function reflection according to the complete path name, forms a function instance, calls the local function in a reflection manner, and transmits the return value to the gateway service.
 Working principle of the present invention is:
 like Figure 5 As shown, the overall working process of the system operation is divided into the registration phase and the calling phase. The registration phase is mainly the startup and initialization of each service, and the execution node registers the local function with the gateway service; the call phase is to receive the request through the gateway service, dispatch it to the execution node, realize the function operation and respond to the caller process.
 The system is initially started, and the gateway service monitors the gateway port, waiting for node registration and interface calls.
 When the execution node is started, it first monitors the adjusted port according to the configuration, and then forms an API list by collecting local API interface functions, and registers the node information with the gateway service. The node information includes: node IP, adjusted port number, API function list; gateway After receiving the registration information, the service caches the "interface function-execution node list" of the API list in the form of key-value pairs, forming a mapping relationship between interface functions and multiple execution nodes.
 When the application calls the API, such as Image 6 As shown, the call function will be requested to the gateway service, and the gateway service will filter according to the list of execution nodes corresponding to the call function, and determine and select the execution node through the load balancing algorithm (mainly including: round robin, random, task optimal), and the gateway service Actively connect to the adjusted port of the execution node through TCP, and pass the call information as a parameter to the execution node. The execution node forms a class instance in the form of reflection by calling the full interface path (package name + class name + function name) in the information, executes the function, and outputs the execution result to the gateway service through TCP. After the gateway service receives the data, it forms a response stream in the form of a restful interface and outputs the data to the calling program, and finally the calling program displays the result through the interface.
 Those skilled in the art will appreciate that the embodiments described here are to help readers understand the principles of the present invention, and it should be understood that the protection scope of the present invention is not limited to such specific statements and embodiments. Various modifications and variations of the present invention will occur to those skilled in the art. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the scope of the claims of the present invention.