CN111158792B

CN111158792B - Service parameter verification processing system and method capable of realizing dynamic configuration under distributed architecture

Info

Publication number: CN111158792B
Application number: CN202010000420.5A
Authority: CN
Inventors: 刘相; 顾伟; 王葱权
Original assignee: Primeton Information Technology Co ltd
Current assignee: Primeton Information Technology Co ltd
Priority date: 2020-01-02
Filing date: 2020-01-02
Publication date: 2023-05-16
Anticipated expiration: 2040-01-02
Also published as: CN111158792A

Abstract

The invention relates to a service parameter verification processing system capable of realizing dynamic configuration under a distributed architecture, which comprises a service collection management module, a service verification processing module and a service verification processing module, wherein the service collection management module is used for collecting all service lists of the distributed architecture application system; the service parameter verification information definition module defines a service parameter verification rule model; the service parameter checking information management module is responsible for lasting service parameter checking rules and related operations; the service parameter verification information proxy module receives the change notification sent by the service parameter verification information definition module; the service parameter checking proxy module is used for checking rules according to specific service request data and corresponding service parameters. The invention also relates to a method for realizing the verification processing of the dynamic configurable service parameters under the distributed architecture. The service parameter verification processing system and the service parameter verification processing method which are dynamically configurable under the distributed architecture realize decoupling of the service parameter verification rule and the service code, reduce the complexity of the service code, improve the readability and have higher popularization value.

Description

Service parameter verification processing system and method capable of realizing dynamic configuration under distributed architecture

Technical Field

The invention relates to the field of computers, in particular to the field of distributed architecture, and specifically relates to a service parameter verification processing system and method capable of realizing dynamic configurability under a distributed architecture.

Background

With the demand of digital transformation, enterprise IT application architecture has been shifted from traditional single architecture to distributed architecture application, which is easier to support large-scale user requests due to natural expansibility, and meets the increasing demands of users. By breaking applications and services into smaller, loosely coupled components, they can be more easily upgraded and expanded, with different components being inter-invoked and accessed to implement a business scenario. In the process of distributed calling, in order to ensure the correctness and compliance of service logic, data verification is required to be carried out on distributed service parameters so as to ensure that the input data is semantically correct from the service; and with the development of the business, the verification rule of the service parameter is continuously changed, and the distributed architecture system is required to provide a capability of dynamically adjusting the verification rule of the service parameter so as to meet the requirements of the enterprise IT business change.

Aiming at parameter verification, the general method is realized on a Java bean object in a Java annotation mode; JSR 303 is defined for parameter validation in the Java hierarchy: the Bean Validation specification defines the corresponding metadata model and APIs for property Validation of javabeans. The property, the method parameter and the return value of the Java bean are supported to be verified, and Java comments are used as default metadata. The parameter check rule is defined, for example, by adding an annotation declaration @ NotNull to the properties or operations of the JavaBean to indicate that null @ Size (max=30) is not allowed (set to maximum); bean Validation is a data Validation framework at runtime, where the error information validated is returned immediately after Validation.

Defining that the attribute address 1 is not allowed to be null, and the maximum length is 30;

a maximum length of 30 is defined for attribute address 2;

the return value for the operation getCity () defines that the return value City is not allowed to be null, while the maximum length is 30;

according to the above example, verification of service parameters is achieved in terms of Java annotations.

The following analyzes the corresponding deficiencies for the above technical implementation:

less than 1: the coupling degree of the check rule and the service code is high: the check rule is directly encoded in the code in an annotating mode, so that the coupling degree of the check rule and the service code is high, and the check rule has strong invasiveness to the service code.

Less than 2: run-time cannot be dynamically configured and thermally updated: during service operation, if the check rule needs to be adjusted because of the adjustment of the service, the service code needs to be modified again, and the service system is shut down and released after being packed, compiled and deployed again.

Less than 3: the verification rules cannot be managed centrally: because the verification rules are distributed in different service codes, unified centralized management cannot be achieved, and maintenance is not facilitated.

Disclosure of Invention

The invention aims to overcome the defects of the prior art and provides a service parameter verification processing system and a service parameter verification processing method which can realize dynamic configurability under a distributed architecture with low complexity, high readability and simple and convenient operation.

In order to achieve the above object, the system and method for implementing dynamically configurable service parameter verification under a distributed architecture of the present invention are as follows:

the service parameter verification processing system realizing dynamic configurable under the distributed architecture is mainly characterized in that the system comprises:

the service collection management module is used for collecting all service lists of the distributed architecture application system;

the service parameter verification information definition module is connected with the service collection management module and is used for defining a service parameter verification rule model, managing the parameter verification rule definition of specific service and notifying a subsequent module to change the parameter verification rule;

The service parameter verification information management module is connected with the service parameter verification information definition module and is used for taking charge of lasting service parameter verification rules and related operations;

the service parameter verification proxy module is connected with the service parameter verification information management module and is used for dynamically verifying the validity of the service parameters through a proxy according to specific service request data and corresponding service parameter verification rules;

the service parameter verification information proxy module is connected with the service parameter verification information definition module, the service parameter verification information management module and the service parameter verification proxy module and is used for receiving the change notification sent by the service parameter verification information definition module.

Preferably, the service collection management module includes a query management interface for providing a list of applications to be managed and a list of services under the applications.

Preferably, the service parameter checking rule model of the service parameter checking information defining module includes a supported service parameter type and a supported checking rule.

Preferably, the operation provided by the service parameter checking information management module includes querying all service parameter checking rules under the application according to the application ID, querying service parameter checking rule detailed information, adding service parameter checking rules, updating service parameter checking rules and deleting service parameter checking rules according to the service ID.

The method for realizing the verification processing of the dynamic configurable service parameters under the distributed architecture based on the system is mainly characterized by comprising the following steps:

(1) The service collection management module collects all service lists of the distributed architecture application system;

(2) The service parameter verification information definition module manages the definition of the parameter verification rule of the specific service and notifies the service parameter verification information agent module of the change of the parameter verification rule;

(3) The service parameter checking information management module is responsible for lasting service parameter checking rules

(4) The service parameter verification information proxy module receives the change notification sent by the service parameter verification information definition module;

(5) The service parameter verification proxy module dynamically verifies the validity of the service parameters through proxy according to specific service request data and corresponding service parameter verification rules.

Preferably, the step (1) specifically includes the following steps:

(1.1) searching all application lists and basic information of the applications, or manually inputting the application information according to a provided management interface;

(1.2) searching all instance information under the application, or manually inputting the instance information of the application according to the provided management interface;

(1.3) scanning and collecting all service lists and service information under the application, or manually inputting the service information according to a provided management interface;

(1.4) persisting the collected information into a database or into a file system;

(1.5) providing a query API management interface for the persisted information in (1.4).

Preferably, the step (2) specifically includes the following steps:

(2.1) querying all collected applications from the service collection management module;

(2.2) designating the application to be checked from all the application lists of the query;

(2.3) querying all service listings under the application;

(2.4) selecting a specific service to be checked;

(2.5) defining a verification rule of the service input parameters according to the service parameter verification rule model;

(2.6) defining a verification rule of the service output parameter according to the service parameter verification rule model;

(2.7) persisting the defined parameter verification rule into the service parameter verification information management module;

(2.8) querying all online instance lists under the application from the service collection management module;

and (2.9) notifying the service parameter verification information proxy module of all the examples, and notifying the service parameter verification rule change.

Preferably, the step (4) specifically includes the following steps:

(4.1) pulling up the application according to the starting mode of the application;

(4.2) pulling up the service parameter verification information proxy module in the starting process;

(4.3) searching all service parameter verification rules under the application from the service parameter verification information management module;

(4.4) storing the searched service parameter checking rule by applying an internal local cache or a distributed cache, thereby improving the access efficiency;

(4.5) judging whether to monitor the receipt of the service parameter check rule change notification, if so, continuing to the step (4.6); otherwise, continuing the step (4.5);

(4.6) judging the type of the service parameter checking rule change, if the service parameter checking rule change is the new or modified type, continuing the step (4.7); if the deletion type is the deletion type, continuing the step (4.9);

(4.7) inquiring the changed service parameter verification rule from the service parameter verification information management module according to the changed service ID;

(4.8) updating the queried new service parameter checking rule to the cache of the step (4.4) according to the service ID;

(4.9) deleting the cache of step (4.4) according to the changed service ID.

Preferably, the step (5) specifically includes the following steps:

(5.1) pulling up the application according to the starting mode of the application;

(5.2) pulling up the service parameter verification proxy module in the starting process, and verifying according to all the loaded service parameter verification information;

(5.3) proxy all service instances;

(5.4) judging whether the service needs to be intercepted according to the loaded all service parameter checking rules, if so, continuing the step (5.5); otherwise, continuing the step (5.6);

(5.5) according to the called service ID, searching a corresponding service parameter checking rule from the loaded service parameter checking rule, checking the service input parameter, judging whether the check is passed or not, and if so, continuing the step (5.6); otherwise, continuing the step (5.9);

(5.6) continuing to execute the specific business logic of the service, and continuing the step (5.7) according to the judging result of the step (5.4), if the service needs interception, indicating that the output parameters need verification; if the service does not need interception, the output parameters are indicated to be not checked, and the step (5.8) is continued;

(5.7) checking the return value of the service logic as an output parameter, judging whether the check is passed or not, and if so, continuing the step (5.8); otherwise, continuing the step (5.9);

(5.8) returning the service output parameters to the caller;

And (5.9) returning the information which does not pass the verification to the calling party, and ending the service call.

The service parameter verification processing system and the service parameter verification processing method which are dynamically configurable under the distributed architecture realize the mechanism for separating service parameter verification configuration from service codes, and provide centralized dynamic configuration and hot updating capability, so that the decoupling of service parameter verification rules and the service codes is realized, the problem that the service parameter verification rules have strong invasiveness to the service codes is solved, the complexity of the service codes is reduced, and the readability is improved; meanwhile, the capability of dynamically adjusting the service parameter rule without stopping the service system is realized; in addition, a centralized management mode of the service parameter checking rules is provided, a global management view of the service parameter checking rules is provided for service management, and the method has high popularization value.

Drawings

FIG. 1 is a block diagram of a system for implementing dynamically configurable service parameter verification processing under a distributed architecture of the present invention.

FIG. 2 is a flow chart of the operation of the service collection management module implementing the method of dynamically configurable service parameter verification processing under a distributed architecture of the present invention.

Fig. 3 is a flowchart illustrating the operation of the service parameter verification information definition module of the method for implementing the dynamic configurable service parameter verification processing under the distributed architecture of the present invention.

Fig. 4 is a flowchart of the service parameter verification information proxy module operation of the method for implementing the dynamic configurable service parameter verification processing under the distributed architecture of the present invention.

Fig. 5 is a flowchart of the service parameter verification proxy module operation of the method for implementing the dynamic configurable service parameter verification process under the distributed architecture of the present invention.

Detailed Description

In order to more clearly describe the technical contents of the present invention, a further description will be made below in connection with specific embodiments.

The invention discloses a service parameter verification processing system capable of being configured dynamically under the distributed architecture, which comprises the following steps:

As a preferred embodiment of the present invention, the service collection management module includes a query management interface for providing a list of applications to be managed and a list of services under the applications.

As a preferred embodiment of the present invention, the service parameter checking rule model of the service parameter checking information definition module includes a supported service parameter type and a supported checking rule.

As a preferred embodiment of the present invention, the operation provided by the service parameter checking information management module includes querying all service parameter checking rules under the application according to the application ID, querying service parameter checking rule detailed information, adding service parameter checking rules, updating service parameter checking rules and deleting service parameter checking rules according to the service ID.

The method for realizing the verification processing of the dynamic configurable service parameters under the distributed architecture by utilizing the system comprises the following steps:

(1.5) providing a query API management interface for the persisted information of (1.4);

(2.3) querying all service listings under the application;

(2.4) selecting a specific service to be checked;

(2.9) notifying the service parameter verification information proxy module of all the examples, and notifying the service parameter verification rule change;

(4.9) deleting the cache of step (4.4) according to the changed service ID;

(5) The service parameter verification proxy module dynamically verifies the validity of the service parameters through proxy according to specific service request data and corresponding service parameter verification rules;

(5.3) proxy all service instances;

(5.8) returning the service output parameters to the caller;

In particular embodiments, the present invention relates to a system and method for dynamic configurable service parameter verification in a distributed architecture. The system comprises a service collection management module, a service management module and a service management module, wherein the service collection management module is responsible for collecting all service lists of the distributed architecture application system; the service parameter verification information definition module is used for managing the definition of the parameter verification rule of the specific service and notifying the service parameter verification information agent module of the change of the parameter verification rule; the service parameter checking information management module is responsible for lasting service parameter checking rules; the service parameter verification information agent module loads all service parameter verification rules under the current application system from the service parameter verification information management module, caches the service parameter verification rules and supports full-load and local loading; and the service parameter verification proxy module dynamically judges the validity of the service parameters according to specific service request data and corresponding service parameter verification rules, and the verification is carried out continuously by continuing to execute the service and is not carried out continuously by rejecting the service. The system and the method for verifying the service parameters of the distributed architecture with the structure, which are dynamically configurable, realize the dynamic configuration, the thermal updating and the centralized management of the service parameters, have strong adaptability to the parameter verification change caused by the service rule change, improve the development, the operation and the maintenance efficiency of the distributed architecture for applying the service parameter verification, and have wide application range in the field of the distributed architecture.

As shown in FIG. 1, the invention is divided into a service collection management module, a service parameter verification information definition module, a service parameter verification information management module, a service parameter verification information proxy module and a service parameter verification proxy module.

The service collection management module is responsible for collecting all service lists of the distributed architecture application system; the service parameter verification information definition module is used for managing the definition of the parameter verification rule of the specific service and notifying the service parameter verification information agent module of the change of the parameter verification rule; the service parameter checking information management module is responsible for lasting service parameter checking rules; the service parameter verification information agent module receives the change notification sent by the service parameter verification information definition module, loads all service parameter verification rules under the current application system from the service parameter verification information management module, caches the service parameter verification rules and supports full load and local load; and the service parameter checking proxy module dynamically judges the validity of the service parameter through proxy according to specific service request data and corresponding service parameter checking rules, and checks to continue to execute the service through continuing to execute the service without rejecting the service.

The service collection management module, the service parameter verification information definition module, the service parameter verification information management module, the service parameter verification information proxy module, and the service parameter verification proxy module will be described in detail below.

1. Service collection management module:

the service collection management module is used for collecting information of applications and application instances which need to be subjected to service parameter configuration management and collecting all service lists which need to be subjected to service parameter configuration management under each application; and the service parameter verification information definition module queries an application list to be managed and a service list under the application based on the interface. The steps of the service collection management module operation are shown in fig. 2.

The steps are as follows:

step 1: collecting application information: searching all application lists and basic information of the applications from a registry, or manually inputting the application information according to a provided management interface; the collected application information includes metadata: application ID, application name, application description, application registration time;

step 2: collecting instance information of an application: searching all instance information under the application from a registry, or manually inputting the instance information of the application according to a provided management interface; the instance information of the application includes metadata: application instance ID, IP address, application port, instance state, application instance registration time, etc.;

Step 3: collecting service information under an application: scanning and collecting all service lists and service information under the application according to annotation @ servicevalidateanounce for automatic discovery on the service statement, or manually inputting the service information according to a provided management interface; the service information includes metadata of: service ID (globally unique within the same application), service name, service full path, method name, parameter list information, return value information; wherein the parameter list information comprises parameter names and parameter types; the return value information comprises a return value name and a return value type;

step 4: persisting the collected information: persistence of the information collected in the step 1, the step 2 and the step 3; such as persisted to a database or into a file system;

step 5: providing a query class API management interface: providing a query API management interface for the persistent information in the step 4, which mainly comprises the following steps:

querying an application list interface;

inquiring an application information detail interface according to the application ID;

inquiring an instance information interface of the application according to the application ID;

inquiring a service information list interface according to the application ID;

and inquiring the service information detail interface according to the service ID.

2. Service parameter verification information definition module:

the service parameter verification information definition module mainly provides the capabilities including: defining a service parameter checking rule model comprising checking rules for specific parameters; defining specific service parameter verification rules for the application and service list collected in the service collection management module; after the definition of the service parameter verification rule is finished, notifying a service parameter verification information proxy module in an application instance of an application where the service is located, and dynamically refreshing the service parameter verification rule;

the service parameter checking rule model mainly comprises the following steps:

1. supported service parameter types

Basic type parameters: support basic types String, int, long, double, boolean, char in Java, etc.;

JavaBean type parameter: supporting parameters of the JavaBean types, expanding the JavaBean parameters when parameter rules are actually configured, checking the attribute of each basic type of JavaBean, and continuing expanding the corresponding attribute for checking if the attribute is still of the JavaBean type;

2. supported validation rules

And (5) checking: judging whether the current parameters need to be filled;

and (3) length verification: the maximum length of the verification parameter;

And (3) fixed length checking: judging whether the current parameter is negative length, and checking the given fixed length;

and (3) checking the range: judging whether the current parameter value is in a given range (range);

custom checking rules: the customized check rule is realized through an expansion mode;

as shown in fig. 3, the steps are described:

step 1: querying all application lists: querying all collected applications from a service collection management module;

step 2: selecting an application to be checked: the user designates the application to be checked from all the application lists queried in the step 1;

step 3: querying all service lists under the application: inquiring all service lists from a service collection management module according to the application appointed in the step 2;

step 4: selecting a service needing to be checked: selecting a specific service to be checked from the service list searched in the step 3;

step 5: setting a verification rule of input parameters: defining a verification rule of the service input parameters according to the service parameter verification rule model;

step 6: setting a verification rule of output parameters: defining a verification rule of the service output parameters according to the service parameter verification rule model;

Step 7: calling a service parameter verification information management module, and lasting verification rules: the parameter verification rules defined in the step 5 and the step 6 are persisted into a service parameter verification information management module;

step 8: querying all online instance lists under the application: inquiring all application instance lists under the application from a service collection management module according to the application designated in the step 2;

step 9: notifying the service parameter check information agent module of all the examples, and notifying the service parameter check rule change: and (3) notifying all application examples queried in the step (8), wherein the service parameter verification rule under the application is changed, and the service parameter verification information proxy module reloads the changed service parameter verification rule from the service parameter verification information management module.

3. Service parameter checking information management module:

the service parameter check information management module is responsible for lasting the service parameter check rule defined in the service parameter check information definition module and providing a service parameter check rule management type API interface, and mainly provides the following operations:

1) Inquiring all service parameter check rules under the application according to the application ID;

2) Inquiring detailed information of a service parameter check rule according to the service ID;

3) Newly adding a service parameter checking rule;

4) Updating a service parameter checking rule;

5) Deleting the service parameter checking rule.

4. Service parameter checking information agent module:

the service parameter checking information agent module is used as a part of the application and provides service outwards along with the starting of the application, and the module is stopped when the application is stopped; when the application is started, the module loads all service parameter verification rules under the current application from a service parameter verification information management module, and caches the service parameter verification rules in the application for improving the access efficiency; meanwhile, after a user newly adds, modifies or deletes a service parameter checking rule through the service parameter checking information definition module, the module receives a service parameter change notification sent by the service parameter checking information definition module, reloads the changed service parameter checking rule from the service parameter checking information management module, and adopts a local loading mode in the mode for improving the operation efficiency.

As shown in fig. 4, the steps are described:

step 1: starting an application: pulling up the application according to the starting mode of the application;

Step 2: starting a service parameter verification information agent module: pulling up the service parameter verification information proxy module in the starting process of the step 1;

step 3: searching all service parameter check rules under the application: searching all service parameter verification rules under the application from a service parameter verification information management module;

step 4: caching the service parameter checking rule searched in the step 3: storing the service parameter verification rule searched in the step 3 by applying the internal local cache or the distributed cache, thereby improving the access efficiency;

step 5: monitoring whether a service parameter check rule change notification is received or not: the module monitors whether the service parameter check rule change sent by the service parameter check information definition module is received or not, if the service parameter check rule change is received, the step 6 is executed, and if the service parameter check rule change is not received, the monitoring is continued;

step 6: judging the type of service parameter check rule change: if the service parameter checking rule changes in the new or modified type, executing the step 7; if the type is the deletion type, executing the step 9;

step 7: querying a changed service parameter checking rule: inquiring a changed service parameter check rule from a service parameter check information management module according to the changed service ID;

Step 8: updating the cache in step 4 according to the changed service ID: adding the new service parameter check rule inquired in the step 7 into a cache according to the service ID;

step 9: and deleting the cache in the step 4 according to the changed service ID.

5. Service parameter checking agent module:

the service parameter checking proxy module is used as a part of the application and provides service outwards along with the starting of the application, and the module is stopped when the application is stopped; the module intercepts all service requests according to a dynamic proxy technology, and judges whether the current service needs to be checked according to all service parameter check rules loaded in a service parameter check information proxy module; if the service is required to be checked, checking the input parameters and the output parameters of the service according to defined check rules, if the service passes the check, continuing the execution of the subsequent service logic, and if the service fails the check, returning check failure information, and refusing the execution of the subsequent service logic; if the verification is not needed, directly executing specific business logic; transparent call to the service API is realized through proxy technology.

As shown in fig. 5, the steps are described:

Step 2: starting a service parameter verification proxy module: pulling up the service parameter verification proxy module in the starting process of the step 1, and verifying according to all service parameter verification information loaded in the service parameter verification information proxy module;

step 3: proxy all service instances: all accesses to the service are intercepted by the service agent through the dynamic agent, and the call to the client is completely transparent;

step 4: judging whether the service needs to be intercepted: step 5, according to all the service parameter checking rules loaded in the step 2, if the called service ID has the definition of the service parameter checking rule, executing the step 5; otherwise, the called service ID does not have the definition of the service parameter check rule, and the step 6 is executed;

step 5: checking service input parameters: according to the called service ID, a corresponding service parameter checking rule is searched from the service parameter checking rules loaded in the step 2, the service input parameters are checked, the check is carried out by executing the step 6, and the check is not carried out by executing the step 9;

step 6: executing service logic: after the service input parameters pass the verification, continuing to execute the specific business logic of the service; according to the judgment of the step 4, if the service needs to be intercepted, the output parameters need to be checked, and the step 7 is executed; if the service does not need interception, indicating that the output parameters do not need verification, executing the step 8;

Step 7: checking the service output parameters: checking the return value of the service logic in the step 6 as an output parameter, wherein the check passes the step 8, and the step 9 is executed if the check does not pass the step;

step 8: returning service output parameters: returning the return value executed in the step 6 to the calling party as an output parameter;

step 9: and returning check error information: and returning the information which does not pass the verification to the calling party, and ending the service call.

The invention uses the order application of the micro-service architecture as a specific embodiment:

order application OrderAPP of the micro-service architecture provides management functions for orders. Mainly the following 2 interfaces are provided, and annotation @ servicevalidicateAnnuance is added, indicating that automatic scan discovery can be applied for subsequent service parameter check rule definition:

1) My order list query interface;

2) The product is added into a shopping cart interface;

two examples of external interfaces are shown below:

/**

* My order list query

*@param userID

*@return

*/

@ServiceValidateAnnounce

public List<Order>queryMyOrder(String userID)；

/**

* Shopping cart for adding products

*@param orderItemList

*@return

*/

@ServiceValidateAnnounce

public boolean addShoppingCar(List<OrderItem>orderItemtList)；

Order application OrderApp deploys three instances for providing services to the outside and registers with the service registry, respectively:

example 1: orderInstance1: the externally provided access address is 192.168.1.1:8080;

Example 2: orderInstance2: the externally provided access address is 192.168.1.2:8080

Example 3 OrderInstance2: the externally provided access address is 192.168.1.3:8080;

scene: order application service 1) in OrderAPP: my order list query interface, service 2): the product is added into the shopping cart interface to be already online operated, a verification rule of the input parameters of the service is required to be dynamically set in the operation period, the output parameters of the service are not required to be verified and are applied to three instances of order application OrderApp, and the order application is not required to be stopped, so that the hot updating capability of the service parameter verification rule is realized;

next, according to the method of the present invention, the system and method for verifying the service parameters that are dynamically configurable are adopted to implement the service scenario defined above, so that the advantages of simplicity and convenience of the present invention will be obviously felt.

1. Service collection management module:

the module is responsible for collecting application information of order application OrderAPP, instance information of three order applications under the order application OrderAPP, and all service lists needing to be subjected to service parameter configuration management under the order application OrderAPP; and persisting the collected application information and application instance information and service list information under the application, wherein the application information and the application instance information are stored in a database mode, and a query management interface is provided, and the service parameter check information definition module queries an application list to be managed and a service list under the application based on the interface.

The specific implementation of the module is as follows:

1. collecting application information: collecting meta information such as application ID, application name, application description, application registration time and the like of order application OrderAPP, wherein the specific meta information is shown in the following table:

2. collecting instance information of an application: the module collects the meta information such as application instance ID, IP address, application port, instance state, application instance registration time and the like of all instances of order application OrderAPP through a service registry, three instances of order application OrderAPP set in the scene are registered in the registry, and the meta information of the application instance collected through the registry is shown in the following table:

application instance meta-information	Example 1	Example 2	Example 3
				Application instance ID	OrderInstance1	OrderInstance2	OrderInstance3
IP address	192.168.1.1	192.168.1.2	192.168.1.3
				Application port	8080	8080	8080
Example State	Online (Online)	online (Online)	Online (Online)
				Application instance registration time	2019-11-17 13:00:00	2019-11-17 14:00:00	2019-11-17 15:00:00

3. Collecting service information under an application: the module obtains all service lists by automatically scanning annotation @ ServiceValidateAnnunce under order application OrderAPP, and the service information comprises metadata: service ID (globally unique within the same application), service name, service full path, method name, parameter list information, return value information; wherein the parameter list information comprises parameter names and parameter types; the return value information comprises a return value name and a return value type; 2 interfaces are defined in the scene, and the following table is used for collecting service information under order application OrderApp:

Wherein in the parameter list information "; "concatenated as separator into a complete string.

4. Persisting the collected information: and (3) persisting the order application collected in the step (1), the step (2) and the step (3) into a database, wherein the database is implemented by using a schematic script as follows, wherein the 2 services to be checked in the order application are as follows:

information for applications with/persistence

insert into [ application table name ] (application ID, application name, application description, application registration time) value ('orderlapp', 'order application', 'application for order management', '2019-11-17:00:00');

perform 3 pieces of application instance information

insert into [ application instance table name ] (application ID, application instance ID, IP address, application port, instance state, application instance registration time) value ('orderlapp', 'OrderInstance1', '192.1.1', '8080', 'online', '2019-11-17:00:00');

insert into [ application instance table name ] (application ID, application instance ID, IP address, application port, instance state, application instance registration time) value ('ordenapp', 'OrderInstance2', '192.168.1.2', '8080', 'online', '2019-11-17:00:00');

insert into [ application instance table name ] (application ID, application instance ID, IP address, application port, instance state, application instance registration time) value ('ordenapp', 'OrderInstance3', '192.168.1.3', '8080', 'online', '2019-11-17:00:00');

Information of 2 services of// persistence

insert into [ service table name ] (service ID, service name, service full path, method name, parameter list information, return value information) ('com. Primet. Iorder. QueryMyOrder (String)', 'my order list query interface', com. Primet. Iorder. QueryMyOrder, 'userID: java. Land. String', 'java. Util. List < com. Primet >');

insert intoj (service ID, service name, service full path, method name, parameter List information, return value information) value ('com. Primeon. Iorder. Addshofpinkcer (List < OrderItem >)', 'product added shopping cart interface', com. Primeon. Iorder. Addshoppacar, 'orderItemList: java. Util. List < com. Primeon. Orderitem >', 'bootean');

5. providing a query class API management interface: the module provides a query API management interface, and the provided query API management interface is as follows:

application list for// query

public List<AppInfo>queryAllApps()；

Query application information details based on application ID

public AppInfo queryAppDetail(String appID)；

Querying instance information of an application based on an application ID

public List<AppInstance>queryAllInstances(String appID)；

Querying a list of service information based on application ID

public List<Services>queryAllService(String appID)；

Querying service information details based on service ID

public Services queryServiceDetail(String serviceID)；

And II: service parameter checking information definition module

Aiming at the scene, the module is mainly responsible for defining parameter checking rules of 2 specific services (service 1: my order list query interface; service 2: product joining shopping cart interface). The specific functions include:

Defining a service parameter checking rule model comprising checking rules for specific parameters;

defining parameter verification rules of 2 specific services, and notifying three application examples that the service parameter verification rules are changed, so that the application examples dynamically refresh the parameter verification rules;

the service parameter verification rule model is defined as follows:

1. supported service parameter types

Defining basic type parameters of support: string, int, long, double, boolean, char in supporting Java, etc.;

defining supporting JavaBean type parameters: when the parameter rules are actually configured, the Java bean parameters are unfolded, the attributes of each basic type of the Java bean are checked, and if the attributes are still of the Java bean type, the corresponding attributes are unfolded continuously to be checked;

2. defining supported validation rules

Four verification rules are defined and supported in the module, namely filling verification, length verification, fixed length verification and range verification. Specific verification rules and implementation are shown in the following table:

the check rules of the my order list query interface are defined as follows:

the requirement for the parameter userID is: userID is necessary to be filled, and the maximum length is not more than 128;

specific parameter verification rules are described in the following table:

Parameters (parameters)	Checking of filling in	Length check	Fixed length check
				userID	Is that	128	-

The check rules for the product joining the shopping cart interface are defined as follows:

the requirement for the parameter orderItemList is satisfied: orderItemList is mandatory;

meanwhile, since the orderItemList is a JavaBean type, rules continue to be defined for the internal OrderItem object as follows:

the property product ID (product ID) of the JavaBean object OrderItem needs to satisfy: filling is needed, and the fixed length is 64 bits;

the property num (number of products) of the JavaBean object OrderItem needs to satisfy: filling 4 bits with maximum length;

specific parameter verification rules are described in the following table:

the steps of the service parameter checking rule and notification operation are as follows:

1. querying all application lists: from the "service collection management Module" according to the provided management APIs: public List < AppInfo > queryAllApps (), all collected applications are queried, and the queried applications in this example are: orderAPP;

2. selecting an application to be checked: the user designates the application needing verification as OrderAPP application;

3. querying all service lists under the application: according to the management API provided in the "service collection management module": public List < Services > queryAllService (String appID), querying all service lists under OrderAPP application, this example would query two Services, the specific service IDs are as follows:

ID of service 1: com.primeon.iorder.queryMyOrder (String)

ID of service 2: com.primet.iorder.addshoppangcar (List < OrderItem >)

4. Selecting a service needing to be checked: in this example, parameter verification rule setting needs to be performed on both services, and two service IDs need to be selected successively;

5. setting a verification rule of input parameters: the present example stores defined check rules in a database manner, and sets the input parameter check rules of the service 1 and the service 2 according to the parameter check rules defined in the above scenario as follows:

service 1: the parameter checking rules of com.

Service 2: the parameter checking rule of com, primeon, iorder, addshoppangcar (List < OrderItem >) is as follows:

6. setting a verification rule of output parameters: the present example does not require setting a check rule for the output parameters;

7. calling a service parameter verification information management module, and lasting verification rules: in the present example, the parameter verification rule defined in the parameters defined in step 5 and step 6 is persisted into the "service parameter verification information management module";

in step 5, service 1, the corresponding database save statement is as follows:

/('Y, Y128, N' specification: the first segment Y represents the necessary filling check, the second segment Y128 represents the need of length check and the maximum length is 128, and the third segment N represents the need of fixed length check;

insert into [ parameter check rule table name ] (sequence number, service ID, parameter, check rule) value (1, 'com. Primeton. Iorder. Querymyorder (String)', 'userID', 'Y, Y128, N');

service 2 in step 5, the corresponding database save statement is referred to in the following table:

/('Y, N, N' specification: the first section Y represents the necessary filling check, the second section N represents the unnecessary length check, and the third section N represents the unnecessary fixed length check;

insert into [ parameter check rule table name ] (sequence number, service ID, parameter, check rule) value (2, 'com. Primeton. Iorder. Addshoping car (List < orderetem >)', 'orderemlist', 'Y, N');

/('Y, N, Y64') description: the first section Y represents the necessary filling check, the second section N represents the unnecessary length check, the third section Y64 represents the fixed length check and the fixed length 64 bits;

insert into [ parameter check rule table name ] (sequence number, service ID, parameter, check rule) value (3, 'com. Primeton. Iorder. Addshofpingcar (List < ordereitem >)', 'orderemlist/ordereitem/product ID', 'Y, N, Y64');

/('Y, Y4, N' specification: the first section Y represents necessary filling verification, the second section Y4 represents that the length verification is required and is not more than 4, and the third section N represents that the fixed length verification is not required;

insert into [ parameter check rule table name ] (sequence number, service ID, parameter, check rule) value (4, 'com. Primeton. Iorder. Addshofpingcar (List < ordereitem >)', 'orderemlist/ordereitem/num', 'Y, Y4, N');

8. querying all online instance lists under the application: according to the management API provided by the service collection management Module: public List < AppInstance > queryAllInstances (String appID) queries all application instance lists under the application orderepp, and all online instances of the application orderepp according to the order queried by the API are as follows:

OrderInstance1

OrderInstance2

OrderInstance3

9. notifying the service parameter check information agent module of all the examples, and notifying the service parameter check rule change: notifying the 3 application instances OrderInstance1, orderInstance2, orderInstance3 queried in step 8; and notifying three examples by using the IP address and the application port corresponding to each example, wherein the service parameter check rule under the application example changes, and the service parameter check information proxy module reloads the changed service parameter check rule (the parameter check rules of the service 1 and the service 2 are changed) from the service parameter check information management module.

Thirdly,: service parameter checking information management module

In this example, the service parameter verification information is stored in a database manner, and is responsible for persisting the service parameter verification rule defined in the service parameter verification information definition module, and providing a service parameter verification rule management class API interface.

The management class API interface provided by the service parameter checking information management module is implemented as follows:

according to application ID, inquiring all service parameter check rules under the application

public List<ParamRule>queryAllRules(String appID)；

According to service parameter ID, inquiring service parameter check rule detailed information

public ParamRule queryParamRule(String serviceId)；

Check rule of new added service parameter

public int insertParamRule(ParamRule rule)；

Check rule for/(and update service parameters)

public int updateParamRule(ParamRule rule)；

Rules for checking/deleting service parameters

public int deleteParmaRule(ParamRule rule)；

Fourth, the method comprises the following steps: service parameter checking information proxy module

In this example, the service parameter verification information proxy module starts and provides services as part of the order application Orderapp (added to the order application in jar); when order application OrderAPP is started, the module loads service parameter verification rules of all services under the order application OrderAPP from a service parameter verification information management module, and caches (a local cache mode is adopted in the example) inside the order application OrderAPP to improve access efficiency; meanwhile, monitoring a service parameter change notification sent in a service parameter check information definition module, reloading a changed service parameter check rule from a service parameter check information management module, and refreshing a local cache;

The service parameter checking information agent module comprises the following steps:

1. starting an application: three application instances of order application OrderApp are launched: orderInstance1, orderInstance2, orderInstance3; in the scene, the order application is defined as a micro-service architecture, and is directly started in a java-jar mode, and the starting command is as follows:

nohup java-jar OrderApp-1.0.0.0.jar&

2. starting a service parameter verification information agent module: when three order application instances are started in step 1, the service parameter verification information proxy module is automatically loaded as a jar, and the service is pulled up through the static block. Defining an entry class of a service parameter verification information proxy module: the corresponding function is pulled up by the start () method, and the start example code is as follows:

3. searching all service parameter check rules under the application: the management API provided by the order application OrderAPP from the service parameter verification information management Module is started: public List < ParamRule > queryAllRules (String appID), find all service parameter check rules under this application, according to the scene definition above, inquire out 4 check rules altogether, inquire out the result as follows:

1,'com.primeton.IOrder.queryMyOrder(String)','userID','Y,Y128,N'

2,'com.primeton.IOrder.addShoppingCar(List<OrderItem>)','orderItemList','Y,N,N'

3,'com.primeton.IOrder.addShoppingCar(List<OrderItem>)','orderItemList/OrderItem/productID','Y,N,Y64'

4,'com.primeton.IOrder.addShoppingCar(List<OrderItem>)','orderItemList/OrderItem/num','Y,Y4,N'

4. caching the service parameter checking rule searched in the step 3: storing the 4 service parameter verification rules searched in the step 3 through a local cache in an order application OrderAPP application, thereby improving the access efficiency;

5. Monitoring whether a service parameter check rule change notification is received or not: the module monitors whether the service parameter check rule change sent by the service parameter check information definition module is received or not, if the service parameter check rule change is received, the step 6 is executed, and if the service parameter check rule change is not received, the monitoring is continued;

6. judging the type of service parameter check rule change: the fourth rule is updated again through the service parameter verification information definition module, the length of num is modified to be 5 bits, and the modified parameter verification rule is as follows:

4,'com.primeton.IOrder.addShoppingCar(List<OrderItem>)','orderItemList/OrderItem/num','Y,Y5,N'

the module receives that the change of the service parameter orderItemList/OrderItem/num check rule is modification, and then step 7 is executed;

7. querying a changed service parameter checking rule: according to the changed service ID: "com. Primeon. Iorder. Addshofpingcar (List < OrderItem >)", a changed service parameter check rule is queried from the "service parameter check information management module";

8. updating the cache in step 4 according to the changed service ID: according to the service ID: "com. Printer. AddShoppingCar (List < OrderItem >)", adding the new service parameter check rule queried in step 7 to the local cache;

9. deleting the cache in step 4 according to the changed service ID: no deletion is made in this example, so this operation is not performed;

Fifth step: service parameter checking proxy module

In this example, the service parameter verification proxy module starts and provides services as part of the order application Orderapp (added to the order application in jar); the module dynamically proxies all service requests outside, and judges whether the current service needs to be checked according to all service parameter check rules loaded in the service parameter check information proxy module; if the service is required to be checked, checking the input parameters and the output parameters of the service according to defined check rules, if the service passes the check, continuing the execution of the subsequent service logic, and if the service fails the check, returning check failure information, and refusing the execution of the subsequent service logic; if the verification is not needed, directly executing specific business logic; transparent call to the service API is realized through proxy technology.

The steps of the service parameter checking agent module operation are as follows:

1. starting an application: three application instances of order application OrderApp are launched: orderInstance1, orderInstance2, orderInstance3; in the scene, an order application is defined as a micro-service architecture, and is directly started in a java-jar mode, and a starting command is shown in the following table:

nohup java-jar OrderApp-1.0.0.0.jar&

2. Starting a service parameter verification proxy module: when three order application instances are started in step 1, the service parameter check proxy module is automatically loaded as a jar and pulls up the service through the static block. Defining an entry class of a service parameter verification proxy module: the corresponding function is pulled up by the start () method by the serivevalidateexecutroxymodule, and the starting example code is as follows:

3. proxy all service instances: when all external service objects of the order application OrderApp are obtained, returning an object which is dynamically proxied by a service parameter verification proxy module, automatically creating the object by a static method createAPIProxy, wherein the proxy class is ValidateApiProxyHandler;

the agent obtaining method and agent class are as follows:

4. judging whether the service needs to be intercepted: when a user accesses an interface 'My order list query interface', the input parameter value is 'testUserID', and as the service parameter check rule of the interface is defined before, interception and calling are required to be carried out on the interface, and step 5 is executed;

5. checking service input parameters: according to the called service ID: com.primeon.iorder.querymyorder (String), searching the corresponding service parameter check rule from the service parameter check rules loaded in step 2, wherein the searched service parameter check rule is as follows:

'com.primeton.IOrder.queryMyOrder(String)','userID','Y,Y128,N'

Input parameters to the service: checking the testuserID, wherein the length is 10 and is smaller than the maximum length 128, checking the testuserID passes, and continuing to execute the step 6;

6. executing service logic: continuing to execute the actual logic operation of the interface 'My order list query interface'; step 8 is directly executed as verification is not needed for the output parameters;

7. checking the service output parameters: through the judgment in the step 6, the verification of the service output parameters is not needed;

8. returning service output parameters: returning the return value executed in the step 6 to the calling party as an output parameter;

9. and returning check error information: the present example has no checking errors, so it is not done to this step;

according to the steps, dynamic definition and management of the verification rule of the service parameters under the order application are flexibly completed according to the service requirements, and a developer only needs to simply configure the verification rule of the service parameters according to the rule. The service parameter verification rule is decoupled from the service code, so that the problem of strong invasiveness of the service parameter verification rule to the service code is solved, the complexity of the service code is reduced, and the readability is improved; meanwhile, the capability of dynamically adjusting the service parameter rule without stopping the service system is realized; in addition, a centralized management mode of the service parameter checking rules is provided, a global management view of the service parameter checking rules is provided for service management, and the method has high popularization value.

The invention aims at a system and a method for verifying a service parameter which are dynamically configurable in a distributed architecture, and the service parameter verification rule is decoupled from the service code by providing a mechanism for separating service parameter verification configuration from the service code, so that the problem that the service parameter verification rule is strong in invasiveness to the service code is solved, and meanwhile, the complexity of the service code is reduced and the readability is improved. The service parameter verification method and the service parameter verification system provide the dynamic configuration and thermal updating capability of the service parameters, support the real-time configuration of the service parameter verification rules and enable the thermal updating to be effective in the running period of the service system, and do not need to stop the service system to realize the dynamic adjustment of the service parameter rules. The method for centrally managing the service and the service parameter checking rules is provided, so that the service parameter checking rules are centrally managed, and the global service view of the service and the service parameter checking rules is provided.

In this specification, the invention has been described with reference to specific embodiments thereof. It will be apparent, however, that various modifications and changes may be made without departing from the spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A system for implementing dynamically configurable service parameter verification processing under a distributed architecture, said system comprising:

2. The system for implementing dynamically configurable service parameter verification processing under a distributed architecture according to claim 1, wherein said service collection management module comprises a query management interface for providing a list of applications to be managed and a list of services under the applications.

3. The system according to claim 1, wherein the service parameter verification rule model of the service parameter verification information definition module includes supported service parameter types and supported verification rules.

4. The system according to claim 1, wherein the service parameter verification information management module provides operations including querying all service parameter verification rules under the application according to the application ID, querying service parameter verification rule detailed information, adding service parameter verification rules, updating service parameter verification rules, and deleting service parameter verification rules according to the service ID.

5. A method for implementing a dynamically configurable service parameter verification process in a distributed architecture based on the system of claim 1, said method comprising the steps of:

6. The method for implementing the verification process of the dynamic configurable service parameters under the distributed architecture according to claim 5, wherein the step (1) specifically comprises the following steps:

7. The method for implementing the verification process of the dynamic configurable service parameters under the distributed architecture according to claim 5, wherein the step (2) specifically comprises the following steps:

(2.3) querying all service listings under the application;

(2.4) selecting a specific service to be checked;

8. The method for implementing the verification process of the dynamic configurable service parameters under the distributed architecture according to claim 5, wherein the step (4) specifically comprises the following steps:

(4.9) deleting the cache of step (4.4) according to the changed service ID.

9. The method for implementing the dynamically configurable service parameter verification process under the distributed architecture according to claim 5, wherein said step (5) specifically comprises the steps of:

(5.3) proxy all service instances;

(5.8) returning the service output parameters to the caller;