CN111158792A

CN111158792A - System and method for realizing dynamic configurable service parameter verification processing under distributed architecture

Info

Publication number: CN111158792A
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: 2020-05-15
Anticipated expiration: 2040-01-02
Also published as: CN111158792B

Abstract

The invention relates to a service parameter verification processing system for realizing dynamic configuration under a distributed architecture, which comprises a service collection management module, a service parameter verification processing module and a service parameter verification processing module, wherein the service collection management module is used for collecting all service lists of a distributed architecture application system; the service parameter verification information definition module defines a service parameter verification rule model; the service parameter verification information management module is responsible for persisting service parameter verification rules and related operations; the service parameter check information agent module receives a change notice sent by the service parameter check information definition module; the service parameter checking agent 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. By adopting the system and the method for realizing the dynamically configurable service parameter verification processing under the distributed architecture, the decoupling of the service parameter verification rule and the service code is realized, the complexity of the service code is reduced, the readability is improved, and the system and the method have strong popularization value.

Description

System and method for realizing dynamic configurable service parameter verification processing under distributed architecture

Technical Field

The invention relates to the field of computers, in particular to the field of distributed architectures, and specifically relates to a system and a method for realizing dynamically configurable service parameter verification processing under the distributed architectures.

Background

With the requirement of digital transformation, the enterprise IT application architecture is converted from the traditional monomer architecture to the application of a distributed architecture, and the application of the distributed architecture is easier to support large-scale user requests due to natural expansibility, so that the increasing demands of users are met. Applications and services can be upgraded and extended more easily by breaking them down into smaller, loosely coupled components, with different components calling, accessing each other to implement a business scenario. In the process of distributed calling, in order to guarantee the correctness and the compliance of business logic, data verification needs to be carried out on distributed service parameters to ensure that input data are correct in business semantics; with the development of business, the check rule for the service parameter is continuously changed, and a distributed architecture system is required to provide the capability of dynamically adjusting the check rule for the service parameter so as to meet the requirement of the IT business change of an enterprise.

Aiming at parameter verification, the general method is realized on a JavaBean object by a Java annotation mode; JSR 303 is defined for parameter validation in the Java architecture: the Bean Validation specification defines the corresponding metadata model and API for property Validation of javabeans. The verification of attributes, method parameters and return values of JavaBean is supported, and the default metadata uses Java exceptions (Java Annotations). Parameter checking rules are defined, for example, by adding the annotation statement @ NotNull to the attributes or operations of the JavaBean, indicating that no null, @ Size (max ═ 30) is allowed (set maximum); the Bean validity is a data verification framework in runtime, and an error message verified immediately after verification is returned.

It is defined for the attribute addressline1 that it is not allowed to be empty, while the maximum length is 30;

the maximum length is 30 for the attribute addressline 2;

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

according to the above example, the checking of the service parameters is implemented in a Java annotated way.

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 coded in the code in an annotation mode, so that the coupling degree of the check rule and the business code is high, and the business code has strong intrusiveness.

And less than 2: no dynamic configuration and hot-update at runtime: during the service operation period, if the check rule needs to be adjusted due to the adjustment of the service, the service code needs to be modified again, and repackaged, compiled and deployed, which causes the service system to be stopped and released.

Less than 3: the verification rules cannot be managed in a centralized way: since the check 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 system and a method for realizing the verification processing of the dynamically configurable service parameters under the distributed architecture which has low complexity, high readability and simple and convenient operation.

In order to achieve the above purpose, the system and the method for verifying and processing the dynamically configurable service parameters under the distributed architecture of the present invention are as follows:

the system for realizing the verification processing of the dynamically configurable service parameters under the distributed architecture is mainly characterized by comprising the following components:

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 informing a subsequent module of changing 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 the persistent service parameter verification rule and related operations;

the service parameter checking agent module is connected with the service parameter checking information management module and is used for dynamically checking the validity of the service parameters through an agent according to specific service request data and corresponding service parameter checking rules;

and the service parameter checking information agent module is connected with the service parameter checking information definition module, the service parameter checking information management module and the service parameter checking agent module and is used for receiving a change notice sent by the service parameter checking information definition module.

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

Preferably, the service parameter verification rule model of the service parameter verification information definition module includes supported service parameter types and supported verification rules.

Preferably, the operation provided by the service parameter verification information management module includes querying all service parameter verification rules under the application according to the application ID, querying detailed information of the service parameter verification rules, adding new service parameter verification rules, updating the service parameter verification rules, and deleting the service parameter verification 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 informs the service parameter verification information agent module of the change of the parameter verification rule;

(3) the service parameter verification information management module is responsible for persisting service parameter verification rules

(4) The service parameter check information agent module receives a change notice sent by the service parameter check information definition module;

(5) the service parameter checking agent module dynamically checks the validity of the service parameters through an agent according to specific service request data and corresponding service parameter checking rules.

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

(1.1) searching all application lists and basic information of the applications, or manually inputting 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 application, or manually inputting the service information according to a provided management interface;

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

and (1.5) providing a query API management interface for the information which is persistent in the step (1.4).

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

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

(2.2) specifying an application requiring verification from the list of all applications queried;

(2.3) inquiring all service lists under the application;

(2.4) selecting specific services needing to be checked;

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

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

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

(2.8) inquiring all online instance lists under all the applications from the service collection management module;

and (2.9) notifying the service parameter checking information agent modules of all the instances of the service parameter checking information agent modules of the service parameter checking rules to 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 check information agent module in the starting process;

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

(4.4) storing the searched service parameter check rule by applying an internal local cache or a distributed cache, so that the access efficiency is improved;

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

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

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

(4.8) updating the inquired new service parameter check rule to the cache in 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 comprises the following steps:

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

(5.2) pulling up the service parameter check agent module in the starting process, and checking according to all the loaded service parameter check information;

(5.3) proxying all service instances;

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

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

(5.6) continuing to execute the specific service logic of the service, if the service needs to be intercepted according to the judgment result of the step (5.4), indicating that the output parameter needs to be checked, and continuing to the step (5.7); if the service does not need interception, the output parameter does not need to be 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, and if so, continuing to the step (5.8); otherwise, continuing the step (5.9);

(5.8) returning the service output parameter to the calling party;

and 5.9, returning the information which is not verified to pass to the calling party, and ending the service calling.

By adopting the system and the method for realizing the service parameter verification processing with dynamic configuration under the distributed architecture, the mechanism of separating the service parameter verification configuration from the service code is realized, and the centralized dynamic configuration and hot updating capability are provided, so that the service parameter verification rule and the service code are decoupled, the problem of strong invasion 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 rules without stopping the service system is realized; in addition, a centralized management mode of the service parameter verification rules is provided, a global management view of the service parameter verification rules is provided for service management, and the method has high popularization value.

Drawings

Fig. 1 is a structural diagram of a system for implementing dynamically configurable service parameter verification processing under a distributed architecture according to the present invention.

Fig. 2 is a flowchart of the operation of the service collection management module of the method for verifying dynamically configurable service parameters in a distributed architecture according to the present invention.

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

Fig. 4 is a flowchart of the operation of the service parameter verification information agent module of the method for implementing the verification processing of the dynamically configurable service parameters under the distributed architecture according to the present invention.

Fig. 5 is a flowchart of the operation of the service parameter check agent module of the method for implementing the check processing of the dynamically configurable service parameters under the distributed architecture according to the present invention.

Detailed Description

In order to more clearly describe the technical contents of the present invention, the following further description is given in conjunction with specific embodiments.

The invention discloses a system for realizing verification processing of dynamically configurable service parameters under a distributed architecture, which comprises:

As a preferred embodiment of the present invention, the service collection management module includes a query management interface, which is used to provide a list of applications to be queried and a list of services under the applications.

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

As a preferred embodiment of the present invention, the operation provided by the service parameter verification information management module includes querying all service parameter verification rules under the application according to the application ID, querying detailed information of the service parameter verification rules, adding new service parameter verification rules, updating the service parameter verification rules, and deleting the service parameter verification 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.4) persisting the collected information to a database or to a file system;

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

(2.3) inquiring all service lists under the application;

(2.4) selecting specific services needing to be checked;

(2.9) notifying the service parameter checking information agent modules of all the instances of the service parameter checking information agent modules and notifying the service parameter checking rule change;

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

(5) the service parameter checking agent module dynamically checks the validity of the service parameters through an agent according to specific service request data and corresponding service parameter checking rules;

(5.3) proxying all service instances;

(5.8) returning the service output parameter to the calling party;

In the specific implementation mode of the invention, the invention relates to a system and a method for checking a dynamically configurable service parameter under 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 a distributed architecture application system; the service parameter verification information definition module manages the definition of the parameter verification rule of the specific service and informs the service parameter verification information agent module of the change of the parameter verification rule; the service parameter verification information management module is responsible for persisting the service parameter verification 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 loading and partial loading; and the service parameter checking agent module dynamically judges the validity of the service parameters according to the specific service request data and the corresponding service parameter checking rule, and the checking is continuously executed through the continuous execution service and is not continuously executed through the refused service. By adopting the system and the method for verifying the dynamically configurable service parameters under the distributed architecture, the dynamic configuration, the thermal update and the centralized management of the service parameters are realized, the adaptability to the parameter verification change caused by the change of the business rule is strong, the development, operation and maintenance efficiency of the verification of the service parameters applied to the distributed architecture is improved, and the system and the method have wide application range in the field of the distributed architecture.

As shown in fig. 1, the present 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 agent module, and a service parameter verification agent 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 manages the definition of the parameter verification rule of the specific service and informs the service parameter verification information agent module of the change of the parameter verification rule; the service parameter verification information management module is responsible for persisting the service parameter verification rules; the service parameter verification information agent module receives a change notice 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 loading and local loading; and the service parameter checking agent module dynamically judges the validity of the service parameters through an agent according to the specific service request data and the corresponding service parameter checking rule, and the checking is continuously executed through the continuous execution service and is not continuously executed through the refused service.

The following describes the service collection management module, the service parameter verification information definition module, the service parameter verification information management module, the service parameter verification information agent module, and the service parameter verification agent module in detail.

Firstly, a service collection management module:

the service collection management module is used for collecting the information of the 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; the collected information is persisted, and an inquiry management interface is provided, and a service parameter check information definition module inquires an application list needing 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 figure 2.

Description of the steps:

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

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

and step 3: collecting service information under application: scanning and collecting all service lists and service information under application according to the comment @ servicevalidateAnnounce declared on the service for automatic discovery, or manually inputting the service information according to a provided management interface; the service information includes metadata such as: service ID (globally unique in the same application), service name, full service path, method name, parameter list information and return value information; the parameter list information comprises parameter names and parameter types; the return value information comprises a return value name and a return value type;

and 4, step 4: persisting the collected information: the information collected in the steps 1, 2 and 3 is persisted; e.g., persisted to a database or persisted to a file system;

and 5: providing a query type API management interface: providing an API (application programming interface) management interface for the information which is persistent in the step 4, wherein the API management interface 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.

A service parameter verification information definition module:

the service parameter verification information definition module mainly provides the following capabilities: defining a service parameter check rule model, including check rules for specific parameters; specific service parameter checking rules are defined aiming at the applications and service lists collected in the service collection management module; after the definition of the service parameter verification rule is completed, notifying a service parameter verification information agent module in an application example of the application where the service is located to perform dynamic refreshing of the service parameter verification rule;

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

1. supported service parameter types

Basic type parameters: supporting basic types String, int, long, double, borolean, char and the like in Java;

JavaBean type parameter: supporting the parameter of the JavaBean type, expanding the JavaBean parameter when actually configuring the parameter rule, checking the attribute of each basic type of the JavaBean, and if the attribute is still the JavaBean type, continuously expanding the corresponding attribute for checking;

2. supported check rules

Mandatory checking: judging whether the current parameters need to be filled;

length checking: checking the maximum length of the parameter;

and (4) fixed length verification: judging whether the current parameter is fixed in length or not, and checking the given fixed length;

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

customizing a check rule: realizing a self-defined check rule through an expansion mode;

as shown in fig. 3, the steps illustrate:

step 1: query all application lists: inquiring all collected applications from the service collection management module;

step 2: selecting the application to be checked: the user specifies the application needing to be checked from all the application lists inquired in the step 1;

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

and 4, step 4: selecting the service needing to be checked: selecting specific services needing to be verified from the searched service list in the step 3;

and 5: setting a check rule of an input parameter: defining a check rule of the service input parameter according to the service parameter check rule model;

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

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

and 8: query all online instance lists under the application: according to the application specified in the step 2, inquiring all application instance lists under the application from the service collection management module;

and step 9: notifying all instances of a service parameter check information agent module, notifying a service parameter check rule change: notifying all the application instances inquired in the step 8 that the service parameter verification rule under the application changes, and the service parameter verification information agent module reloads the changed service parameter verification rule from the service parameter verification information management module.

Thirdly, a service parameter checking information management module:

the service parameter verification information management module is responsible for persisting the service parameter verification rules defined in the service parameter verification information definition module and providing a service parameter verification rule management 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 the service parameter verification rule according to the service ID;

3) newly adding a service parameter check rule;

4) updating a service parameter check rule;

5) and deleting the service parameter check rule.

Fourthly, the service parameter checking information agent module:

the service parameter checking information agent module is used as a part of the application and provides service to the outside along with the start of the application, and the module is stopped when the application stops; when the application is started, the module loads all service parameter verification rules under the current application from the 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 adds, modifies or deletes the 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, and reloads the changed service parameter checking rule from the service parameter checking information management module, wherein a local loading mode is adopted in the mode for improving the operation efficiency.

As shown in fig. 4, the steps illustrate:

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

step 2: the starting service parameter checking information agent module: pulling up a service parameter check information agent module in the starting process of the step 1;

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

and 4, step 4: caching the service parameter check rule searched in the step 3: storing the service parameter check rule searched in the step 3 by applying an internal local cache or a distributed cache, so that the access efficiency is improved;

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

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

and 7: inquiring the changed service parameter check rule: inquiring a changed service parameter verification rule from a service parameter verification information management module according to the changed service ID;

and 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 the cache according to the service ID;

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

Fifthly, the service parameter checking agent module:

the service parameter checking agent module is used as a part of the application and provides service to the outside along with the starting of the application, and the module is stopped when the application stops; the module intercepts all service requests according to a dynamic agent 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 agent module; if the verification is needed, verifying the input parameters and the output parameters of the service according to a defined verification rule, if the verification is passed, continuing the subsequent service logic execution, and if the verification is failed, returning verification failure information, and rejecting the subsequent service logic execution; if the verification is not needed, directly executing specific service logic; transparent calling of the service API is realized through the proxy technology.

As shown in fig. 5, the steps illustrate:

step 2: starting a service parameter checking agent module: pulling up the service parameter check agent module in the starting process of the step 1, and checking according to all service parameter check information loaded in the service parameter check information agent module;

and step 3: proxy all service instances: all the accesses to the service are subjected to dynamic proxy interception through a service proxy, and the calling to the client is completely transparent;

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

and 5: checking the service input parameters: according to the called service ID, searching the corresponding service parameter verification rule from the service parameter verification rules loaded in the step 2, verifying the service input parameter, wherein the verification passes the execution step 6, and the verification does not pass the execution step 9;

step 6: executing the service logic: after the service input parameter is verified, the specific service logic of the service is continuously executed; according to the judgment of the step 4, if the service needs to be intercepted and the output parameter needs to be checked, executing a step 7; if the service does not need interception, indicating that the output parameter does not need verification, executing step 8;

and 7: and (3) checking the service output parameters: checking the return value of the service logic in the step 6 as an output parameter, wherein the step 8 is executed if the check is passed, and the step 9 is executed if the check is not passed;

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

and step 9: and returning checking error information: and returning the information which fails to pass the verification to the calling party, and ending the service calling.

The invention takes order application to a micro-service architecture as a specific embodiment:

order of the microservice architecture applies OrderApp to provide the management function of the order externally. The following 2 interfaces are mainly provided, and an annotation @ servicevalidatestatement exception is added, which indicates that the following service parameter check rule definitions can be discovered by application automatic scanning:

1) a my order list query interface;

2) adding a product into a shopping cart interface;

two external interface examples are shown below:

/**

my order list query

*@param userID

*@return

*/

@ServiceValidateAnnounce

public List<Order>queryMyOrder(String userID)；

/**

Product adding shopping cart

*@param orderItemList

*@return

*/

@ServiceValidateAnnounce

public boolean addShoppingCar(List<OrderItem>orderItemtList)；

The order application OrderApp deploys three instances for out-of-office provisioning of services and registers with the service registry, respectively:

example 1: OrderInstance 1: the externally provided access address is 192.168.1.1: 8080, a step of;

example 2: OrderInstance 2: the externally provided access address is 192.168.1.2: 8080

Example 3 OrderInstance 2: the externally provided access address is 192.168.1.3: 8080, a step of;

scene: service 1 in order application OrderApp): my order list query interface, service 2): the product is added into a shopping cart interface and is operated online, a check rule of an input parameter of the service needs to be dynamically set in the operation period, the output parameter of the service does not need to be checked, the service is applied to three instances of order application OrderApp without stopping order application, and the hot updating capability of the service parameter check rule is realized;

next, according to the method of the present invention, the service scenario defined above is implemented by using a system and a method for dynamically configurable service parameter verification, which obviously feel the advantages of simplicity and convenience of the present invention.

Firstly, a service collection management module:

the module is responsible for collecting application information of the order application OrderApp, example information of three order applications under the order application OrderApp and all service lists needing service parameter configuration management under the order application OrderApp; the collected application information, application instance information and service list information under application are persisted, the embodiment adopts a database mode for storage, and provides a query management interface, and a service parameter verification information definition module queries an application list needing to be managed and a service list under application based on the interface.

The module is specifically realized as follows:

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

2. collecting instance information of the application: the module collects the application instance IDs, IP addresses, application ports, instance states, application instance registration time and other meta-information of all instances of the order application OrderApp through the service registration center, three instances in which the order application OrderApp is set in the scene are all registered in the registration center, and the collection of the application instance meta-information through the registration center 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 states	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 application: the module automatically scans the annotation @ servicevalidatestatement intersection under the order application OrderApp to acquire all service lists, wherein the service information comprises metadata as follows: service ID (globally unique in the same application), service name, full service path, method name, parameter list information and return value information; 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 service information under the order application OrderApp is collected and is shown in the following table:

among the parameter list information, if there are multiple parameters, use "; "as separator characters are concatenated into a complete character string.

4. Persisting the collected information: the order application collected in the steps 1, 2 and 3, the example of the order application and 2 services needing to be checked in the order application are persisted into a database, and the executed schematic script of the database is as follows:

// persisting application information

insert _ int [ application table name ] (application ID, application name, application description, application registration time) value ('OrderApp', 'order application', 'application for order management', '2019-11-1712: 00: 00');

// persisting 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 ('OrderApp', 'OrderInstance1', '192.168.1.1', '8080', 'online', '2019-11-1713: 00: 00');

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

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

// persisting information for 2 services

insert into [ service table name ] (service ID, service name, service full path, method name, parameter list information, return value information) value ('com.precision.iorder.querymyorder (String)', 'my order list query interface', com.precision.iorder.querymyorder ', queryMyOrder,' user ID: java.lang.string ',' java.util.list < com.priority.order >);

insert _ int [ service table name ] (service ID, service name, service full path, method name, parameter List information, return value information) value (' com.prime.iorder.addshoppencar (List < orderetm >) ', ' product joining shopping cart interface ', com.prime.iorder.adshoppencar ', addshoppencar, ' orderetmel ';

5. providing a query type API management interface: the module provides an inquiry API management interface, which is as follows:

// query application List

public List<AppInfo>queryAllApps()；

V/query for details of application information based on application ID

public AppInfo queryAppDetail(String appID)；

V/query instance information of an application according to application ID

public List<AppInstance>queryAllInstances(String appID)；

V/query service information List according to application ID

public List<Services>queryAllService(String appID)；

V/query for details of service information based on service ID

public Services queryServiceDetail(String serviceID)；

II, secondly: service parameter check information definition module

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

defining a service parameter check rule model, including check rules for specific parameters;

defining 2 parameter verification rules of specific services, and notifying three application examples that the service parameter verification rules change, so as to realize dynamic refreshing of the application examples on the parameter verification rules;

the service parameter check rule model is defined as follows:

1. supported service parameter types

Basic type parameters supported are defined: support String, int, long, double, borolean, char, etc. in Java;

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

2. defining supported check rules

Four kinds of check rules are defined and supported in the module, namely mandatory check, length check, fixed length check and range check. The specific verification rules and implementations are as follows:

the verification rules for the my order list query interface are defined as follows:

the requirement for the parameter userID is: userID is mandatory, maximum length no more than 128;

the specific parameter checking rule description is as follows:

parameter(s)	Mandatory check-up	Length check	Fixed length check
				userID	Is that	128	-

The check rule for adding the product into the shopping cart interface is defined as follows:

the parameter orderemlist needs to satisfy: orderemlist is mandatory;

meanwhile, as orderemlist is a JavaBean type, rules continue to be defined for the internal ordereltem object as follows:

the property productID (product ID) of the JavaBean object orderiem needs to satisfy: padding, fixed length 64 bits;

the property num (product quantity) of the JavaBean object orderiem needs to satisfy: must fill, maximum length 4 bits;

the specific parameter checking rule description is as follows:

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

1. query all application lists: from the "service collection management module", according to the provided management API: publicList < AppInfo > queryalapps (), and queries all collected applications, the applications queried in this example are: OrderApp;

2. selecting the application to be checked: the user specifies the application needing to be checked as an 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 > queryalservice (string appid), which queries all service lists under the OrderApp application, two Services are queried in this example, and specific service IDs are shown as follows:

ID of service 1: com, primeton, iorder, queryMyOrder (String)

ID of service 2: com, primeon, iorder, addShoppengCar (List < OrderItem >)

4. Selecting the 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 check rule of an input parameter: the present example stores defined check rules in a database manner, and sets the input parameter check rules of service 1 and service 2 according to the parameter check rules defined in the above scenario as follows:

service 1: the parameter checking rule for com, primeton, iorder, querymorder (String) is as follows:

Service 2: primeton iorder addshoppengcar (List < orderem >) has the following parameter check rule:

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

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

in step 5, serving 1, the corresponding database save statements are as follows:

/'Y, Y128, N' states: the first section Y represents the mandatory check, the second section Y128 represents the length check and the maximum length is 128, and the third section N represents that the fixed length check is not needed;

insert _ int [ parameter check rule table name ] (sequence number, service ID, parameter, check rule) value (1,' com.

In step 5, for service 2, the corresponding database save statements refer to the following table:

/'Y, N, N' states: the first section Y represents the mandatory check, the second section N represents that the length check is not needed, and the third section N represents that the fixed length check is not needed;

insert _ int [ parameter check rule table name ] (sequence number, service ID, parameter, check rule) value (2, 'com. prime. iorder. addshoppengcar (List < orderetmem >)', 'orderetmlist', 'Y, N');

/'Y, N, Y64' illustrates: the first section Y represents the mandatory check, the second section N represents that the length check is not needed, and the third section Y64 represents that the fixed length check is needed and the fixed length is 64 bits;

insert _ int [ parameter check rule table name ] (sequence number, service ID, parameter, check rule) value (3, 'com. prime. iorder. addshoppengcar (List < ordere >)', 'orderetlist/ordere/productID', 'Y, N, Y64');

/'Y, Y4, N' states: the first section Y represents the mandatory check, the second section Y4 represents that the length check is required and is not more than 4, and the third section N represents that the fixed length check is not required;

insert _ int [ parameter check rule table name ] (sequence number, service ID, parameter, check rule) value (4, 'com. prime. iorder. addshoppengcar (List < ordere >)', 'orderetlist/ordere/num', 'Y, Y4, N');

8. query all online instance lists under the application: according to the management API provided by the service collection management module: public List < appentity > queryallnstances (string appid) queries a List of all application instances under application OrderApp, all online instances of application OrderApp for the order queried according to the API are as follows:

OrderInstance1

OrderInstance2

OrderInstance3

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

Thirdly, the method comprises the following steps: service parameter check information management module

In this example, the service parameter verification information is stored in a database, 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 API interface.

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

v/according to application ID, inquiring all service parameter checking rules under the application

public List<ParamRule>queryAllRules(String appID)；

V/query service parameter verification rule details based on service parameter ID

public ParamRule queryParamRule(String serviceId)；

// newly added service parameter check rule

public int insertParamRule(ParamRule rule)；

// update service parameter check rules

public int updateParamRule(ParamRule rule)；

// delete service parameter check rules

public int deleteParmaRule(ParamRule rule)；

Fourthly, the method comprises the following steps: service parameter checking information agent module

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

the service parameter check information agent module operates as follows:

1. starting the application: three application instances of the order application OrderApp are launched: OrderInstance1, OrderInstance2, OrderInstance 3; in the scene, order application is defined as a micro-service architecture, the order application 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. the starting service parameter checking information agent module: when three order application instances are started in step 1, the service parameter check information agent module is automatically loaded as jar and pulls the service through the static block. Defining an entry class of the service parameter check information agent module: the SeriveValidatProxModule, pulling up the corresponding function by the start () method, starts the example code as follows:

3. finding all service parameter check rules under application: starting a management API provided by the order application OrderApp from the service parameter verification information management module: public List < ParamRule > queryalrules (stringappid), find all the service parameter check rules under the application, and according to the above scenario definition, query 4 check rules in total, with the query 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 check rule searched in the step 3: storing the 4 service parameter verification rules searched in the step 3 through a local cache in the order application OrderApp application, so that the access efficiency is improved;

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

6. judging the type of the 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 into 5 bits, and the modified parameter verification rule is as follows:

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

if the module receives that the service parameter orderemlist/orderetmem/num changes are modified, the module executes step 7;

7. inquiring the changed service parameter check rule: according to the changed service ID: "com.primeton.iorder.addshoppengcar (List < orderiem >)", inquiring the changed service parameter check rule 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, primeton, iorder, add shoppengcar (List < orderlitem >)", add the new service parameter check rule inquired out in step 7 to the local cache;

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

fifthly: service parameter checking agent module

In this example, the service parameter checking agent module starts and provides services as part of order application OrderApp (added to order application in jar); the module dynamically proxies all external service requests, and judges whether the current service needs to be verified according to all service parameter verification rules loaded in the service parameter verification information proxy module; if the verification is needed, verifying the input parameters and the output parameters of the service according to a defined verification rule, if the verification is passed, continuing the subsequent service logic execution, and if the verification is failed, returning verification failure information, and rejecting the subsequent service logic execution; if the verification is not needed, directly executing specific service logic; transparent calling of the service API is realized through the proxy technology.

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

1. starting the application: three application instances of the order application OrderApp are launched: OrderInstance1, OrderInstance2, OrderInstance 3; in the scene, order application is defined as a micro-service architecture, the order application is directly started in a java-jar mode, and the starting command refers to the following table:

nohup java-jar OrderApp-1.0.0.0.jar&

2. starting a service parameter checking agent module: when three order application instances are launched in step 1, the service parameter check agent module is automatically loaded as a jar and pulls the service through the static block. Defining an entry class of the service parameter check agent module: the SeriveValidateExecuteproxyModule pulls up the corresponding function through the start () method, and starts the example code as follows:

3. proxy all service instances: when the order is obtained by applying all external service objects of OrderApp, returning an object dynamically proxied by a service parameter checking proxy module, and automatically creating the object by a static method createAPIProxy, wherein the proxy class is ValidateApPrroxyHandler;

the method for obtaining the proxy and the proxy class are as follows:

4. judging whether the service needs to be intercepted: when a user accesses an interface, namely a My order list query interface, the transmitted parameter value is testUserID, and since the service parameter check rule of the interface is defined in the front, the interface needs to be intercepted and called, and the step 5 is executed;

5. checking the service input parameters: according to the called service ID: com, meter, consumer, queryme, strand, finding the corresponding service parameter check rule from the service parameter check rules loaded in step 2, wherein the service parameter check rules obtained by query are as follows:

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

inputting parameters for the service: checking the testUserID, wherein the length is 10 and is less than the maximum length of 128, and continuing to execute the step 6 after the checking is passed;

6. executing the service logic: continuing to execute the actual logic operation of the interface My order list query interface; step 8 is directly executed because the output parameters do not need to be checked;

7. and (3) checking the service output parameters: through the judgment in the step 6, the service output parameters do not need to be checked;

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

9. and returning checking error information: this example has no check error, so this step cannot be performed;

according to the steps, dynamic definition and management of the check rules of the service parameters under the application of the order are flexibly completed according to the business requirements, and developers only need to simply configure the check rules of the service parameters according to the rules. The mechanism of separating the service parameter verification configuration from the service code is realized, and centralized dynamic configuration and hot update capabilities are provided, so that the service parameter verification rule and the service code are decoupled, the problem that the service parameter verification rule has strong invasion 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 rules without stopping the service system is realized; in addition, a centralized management mode of the service parameter verification rules is provided, a global management view of the service parameter verification rules is provided for service management, and the method has high popularization value.

The invention provides a mechanism for separating service parameter verification configuration and service codes, and provides a service parameter verification rule and a service code, aiming at a system and a method for verifying dynamically configurable service parameters under a distributed architecture, so that the problem of strong service code invasion of the service parameter verification rule is solved, the complexity of the service code is reduced, and the readability is improved. The dynamic configuration and hot update capability of the service parameters are provided, the real-time configuration of the service parameter check rules is supported and the hot update is effective during the operation period of the service system, and the service system is not required to be stopped to realize the dynamic adjustment of the service parameter rules. The method provides a centralized management mode for the service and service parameter check rules, achieves centralized management of the service parameter check rules, and provides a global business view of the service and service parameter check rules.

In this specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader 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 is characterized in that the system comprises:

2. The system of claim 1, wherein the service collection management module comprises a query management interface for providing a list of applications to be queried and a list of services to be queried.

3. The system of claim 1, wherein the service parameter verification rule model of the service parameter verification information definition module includes a supported service parameter type and a supported verification rule.

4. The system of 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 details of the service parameter verification rules, adding new service parameter verification rules, updating the service parameter verification rules, and deleting the service parameter verification rules according to the service ID.

5. A method for implementing verification processing of dynamically configurable service parameters under a distributed architecture based on the system of claim 1, the method comprising the steps of:

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

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

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

(2.3) inquiring all service lists under the application;

(2.4) selecting specific services needing to be checked;

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

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

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

(5.3) proxying all service instances;

(5.8) returning the service output parameter to the calling party;