Public service logic execution range configuration method and device, electronic equipment and storage medium

Abstract

The invention discloses a public service logic execution range configuration method and device, electronic equipment and a storage medium. The method comprises the following steps: in response to a transaction request, obtaining a packet path keyword corresponding to the transaction request; querying in a rule list based on a packet path keyword corresponding to the transaction request, and if the packet path keyword corresponding to the transaction request exists in the rule list, obtaining a level offset corresponding to the packet path keyword; if the verification of the level offset corresponding to the packet path keyword is passed, obtaining a forward identifier corresponding to the packet path keyword; and if the forward identifier corresponding to the packet path keyword is a forward identifier, incorporating a transaction corresponding to the transaction request into a public service logic execution range. According to the technical scheme, the packet path keyword is used as key data for judging whether the packet path keyword is included in the public service logic execution range or not, and dynamic configuration of the public service logic execution range is achieved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for configuring the execution scope of public service logic. Background Technology

[0002] With the rapid development of fintech, banking systems face core challenges such as high-concurrency transaction processing, data consistency assurance, and security risk control. Traditional monolithic architectures suffer from severe coupling between business logic and cross-cutting concerns such as logging, transaction management, and access control, leading to bloated code and high maintenance costs. Spring AOP decouples cross-cutting logic from business logic through dynamic proxy mechanisms, abstracting common functionalities like logging, transactions, and permissions into aspects. This avoids code duplication, unifies the management of cross-cutting logic, facilitates feature expansion and anomaly detection, and enables banking systems to achieve "lightweight core business operations and intelligent operation and maintenance management," serving as a crucial technological foundation for fintech innovation.

[0003] Aspects can precisely control the scope of functionality through pointcut expressions. For example, `execution(*com.bank.service.*.*(..))` means that all methods in all code classes under the `com.bank.service` directory in the application are included. The implementation principle of aspects dictates that the system must determine whether to weave join points into the target class based on the methods at runtime. Pointcut expressions should not be too complex, otherwise performance will be affected. Therefore, aspects are mostly suitable for enhancing common public logic at the overall system level, and are not suitable for weaving common public logic into different business categories in complex business scenarios.

[0004] In real-world banking systems, various transaction products are diverse and complex. A broad product category can be further divided into several subcategories. For example, a bank's online banking handles deposits, transfers, investments, and foreign exchange. Investment products include funds, wealth management products, insurance, and bonds. Bonds are further divided into savings bonds and bond market products, representing a layered product architecture. Correspondingly, the project engineering structure also establishes layered program code directories according to different business and product categories. In practical applications, different product categories may require different common processing logic. If aspects are directly used to limit the processing scope, it can lead to an excessive number of aspects or overly complex pointcut expressions. This results in the system needing to traverse more potential join points for matching, increasing the number of matching rule checks, introducing unnecessary system overhead, and lowering overall system performance.

[0005] Furthermore, in real-world production applications, the enhanced logic within aspects may require switching or adjustments to its execution scope. Conventional pointcut expressions are hard-coded into the application and cannot be changed during system runtime, lacking the ability to be hot-updated and thus failing to meet the aforementioned dynamic adjustment needs. Summary of the Invention

[0006] This invention provides a method, apparatus, electronic device, and storage medium for configuring the execution scope of public service logic, so as to realize the dynamic configuration of the execution scope of public service logic.

[0007] According to one aspect of the present invention, a method for configuring the execution scope of public service logic is provided, comprising:

[0008] In response to a transaction request, obtain the packet path keyword corresponding to the transaction request;

[0009] Based on the packet path keyword corresponding to the transaction request, the rule list is queried. If the packet path keyword corresponding to the transaction request exists in the rule list, the hierarchical offset corresponding to the packet path keyword is obtained. If the hierarchical offset corresponding to the packet path keyword passes the verification, the positive identifier corresponding to the packet path keyword is obtained. If the positive identifier corresponding to the packet path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic.

[0010] According to another aspect of the present invention, a public service logic execution scope configuration apparatus is provided, comprising:

[0011] The package path keyword acquisition module is used to acquire the package path keyword corresponding to the transaction request in response to the transaction request.

[0012] The rule verification module is used to query the rule list based on the packet path keyword corresponding to the transaction request. If the packet path keyword corresponding to the transaction request exists in the rule list, the layer offset corresponding to the packet path keyword is obtained. If the layer offset corresponding to the packet path keyword passes the verification, the positive identifier corresponding to the packet path keyword is obtained. If the positive identifier corresponding to the packet path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0014] At least one processor;

[0015] and a memory communicatively connected to the at least one processor;

[0016] The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to execute the public service logic execution scope configuration method according to any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the public service logic execution scope configuration method according to any embodiment of the present invention.

[0018] The technical solution of this invention, in response to a transaction request, obtains the packet path keyword corresponding to the transaction request, and then queries the rule list based on the packet path keyword. If the packet path keyword exists in the rule list, the hierarchical offset corresponding to the packet path keyword is obtained; if the hierarchical offset corresponding to the packet path keyword passes the verification, the positive identifier corresponding to the packet path keyword is obtained; if the positive identifier corresponding to the packet path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic. This technical solution uses the packet path keyword as key data to determine whether to include the transaction in the execution scope of the public service logic, thus achieving dynamic configuration of the execution scope of the public service logic.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a diagram illustrating the dynamic pointcut management method provided by the Spring framework based on a configuration center in existing technologies.

[0022] Figure 2 This is a flowchart of a public service logic execution scope configuration method provided in Embodiment 1 of the present invention;

[0023] Figure 3 This is a flowchart of a public service logic execution scope control method provided by an embodiment of the present invention;

[0024] Figure 4This is a flowchart of a public service logic execution scope configuration method provided in Embodiment 2 of the present invention;

[0025] Figure 5 This is a flowchart of a method for dynamically adjusting a rule list according to an embodiment of the present invention;

[0026] Figure 6 This is a flowchart of a public service logic execution scope configuration method provided in Embodiment 3 of the present invention;

[0027] Figure 7 This is a schematic diagram of the structure of a public service logic execution scope configuration device according to Embodiment 4 of the present invention;

[0028] Figure 8 This is a schematic diagram of the structure of an electronic device that implements the public service logic execution scope configuration method of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be used interchangeably where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices. The acquisition, storage, use, and processing of data in the technical solutions of this application all comply with the relevant provisions of national laws and regulations.

[0031] Before introducing specific embodiments, we will describe in detail the technical solution in the prior art that is closest to the present invention. Figure 1 This is a diagram illustrating the dynamic pointcut management method based on a configuration center provided by the Spring framework in existing technologies. For example... Figure 1As shown, the configuration center server is responsible for the centralized storage and management of pointcut rules. The application service cluster interacts with the configuration center through the configuration client SDK to dynamically obtain pointcut configurations. The AOP aspect execution engine implements dynamic proxies based on Spring AOP, intercepting method calls and executing enhanced logic according to the pointcut rules in the configuration center.

[0032] In existing technologies, when banks implement a business risk awareness system, they need to collect and analyze online channel transaction messages to identify abnormal behavior. When piloting the integration of this system into online banking, transactions will simultaneously send messages to the system during execution. The plan is to initially test it on a small scale with single intra-bank transfer transactions, then expand it to various transfer transactions such as single inter-bank transfers, batch transfers, and scheduled transfers. After a period of time, transactions under deposit and foreign exchange businesses will be included in the trial scope, ultimately integrating all online banking transactions into the business risk awareness system. This is a typical scenario requiring dynamic adjustment of the execution scope of public service logic. The previous method of controlling the access scope involved identifying all transaction interfaces for various products and placing the processing logic for sending messages to the business risk awareness system within an aspect. This aspect can match every interface request. An interface whitelist is created within the aspect, pre-writing all interfaces that need to be included in the scope to the whitelist. Transactions matching the whitelist execute the subsequent message sending logic within the aspect. This approach can only control at the finest transaction level, and cannot manage the business as a whole at different levels. The process of sorting out and configuring is quite complicated and prone to omissions and misconfigurations.

[0033] Regarding the above application scenarios, the existing technology has the following drawbacks:

[0034] 1. The existing dynamic pointcut management method based on configuration center to dynamically adjust the execution scope of public service logic essentially modifies the pointcut expression. In complex multi-level classification business scenarios, if you want to achieve flexible adjustment of the execution scope of public service logic through a single pointcut, you rely entirely on the stacking of complex pointcut expressions, which cannot avoid the performance overhead caused by complex pointcut expressions.

[0035] 2. Rewriting pointcut expressions online is a high-risk operation, equivalent to modifying the application's underlying logic, and offers considerable freedom. Improper operation can easily lead to system failures, and in principle, it should be tested before deployment. Exposing the entry point for modifying pointcut expressions in a production environment poses significant security risks.

[0036] This invention provides a method, apparatus, electronic device, and storage medium for configuring the execution scope of public service logic in the above-mentioned scenarios. It can simplify the configuration process, reduce complexity, support dynamic configuration during application operation, and does not introduce security risks.

[0037] Example 1

[0038] Figure 2 This is a flowchart illustrating a method for configuring the execution scope of public service logic according to Embodiment 1 of the present invention. This embodiment is applicable to situations where the execution scope of public service logic in an application is dynamically configured. This method can be executed by a public service logic execution scope configuration device, which can be implemented in hardware and / or software and can be configured in electronic devices such as servers. Figure 2 As shown, the method includes:

[0039] S110. In response to the transaction request, obtain the packet path keyword corresponding to the transaction request.

[0040] S120. Based on the packet path keyword corresponding to the transaction request, query the rule list. If the packet path keyword corresponding to the transaction request exists in the rule list, obtain the hierarchical offset corresponding to the packet path keyword. If the hierarchical offset corresponding to the packet path keyword passes the verification, obtain the positive identifier corresponding to the packet path keyword. If the positive identifier corresponding to the packet path keyword is positive, include the transaction corresponding to the transaction request in the public service logic execution scope.

[0041] In this embodiment of the invention, the transaction request can be a transaction request initiated by a customer through an application. The application can be an application used by a bank or other financial institution. For example, the application's engineering structure can be as follows:

[0042]

[0043] Here, com.bank.onlinebank is the root path of the entire application, and these three layers are fixed values. common represents common business logic, service represents service, businesstype represents business type, product represents product, and trade represents transaction. As shown in the project structure example, the transaction code at the product level is all under the service path, so this layer is also fixed for the product. There are a total of four fixed layers.

[0044] If the transaction request for trade1 is being executed, the application's package path is determined to be com.bank.onlinebank.service.businesstype1.product3.trade1, which has 7 layers. This indicates that the transaction belongs to the product 3 and the business type 1. Similarly, if any transaction in business type 3 is being executed, the first 5 layers of the application's package path are determined to be com.bank.onlinebank.service.businesstype3.

[0045] In this embodiment of the invention, the package path keyword is a part of the application's full package name. For example, service, businesstype1, product3, or trade1 in com.bank.onlinebank.service.businesstype1.product3.trade1 can all be used as package path keywords.

[0046] In some optional embodiments, obtaining the package path keyword corresponding to the transaction request includes: obtaining the package name of the application where the transaction request is located; and using the name of a preset level in the package name of the application where the transaction request is located as the package path keyword corresponding to the transaction request.

[0047] Here, the application's package name refers to the application's fully qualified package name. For example, in com.bank.onlinebank.service.businesstype1.product3.trade1, if the default level is 5, then the package path keyword is businesstype1.

[0048] In this embodiment of the invention, the rule list may include multiple rules, each rule including a package path keyword, the hierarchical offset corresponding to the package path keyword, and a positive identifier. The rule list is used for execution scope verification to determine whether to include the transaction within the execution scope of the public service logic.

[0049] In this context, package path keywords can be represented by `keywords` in the application. `keywords` stores keywords at a specific level within the package path, such as `product1` or `businesstype2`. Hierarchical offsets can be represented by `offset` in the application. `offset` stores the hierarchical offset corresponding to the package path keyword and can be identified using integers greater than or equal to 0, such as 0, 1, or 2. If the hierarchical offset corresponding to the package path keyword in the rule is set to 0, it means that all transactions under the entire business or product category corresponding to that package path keyword are included in the execution scope, without requiring finer-grained identification and verification. If the hierarchical offset of the package path keyword in the rule is set to 1 or 2, it means that some transactions under the business or product category corresponding to that package path keyword are included in the execution scope and require further identification. It is important to note that when a package path keyword with a non-zero hierarchical offset is configured, finer-grained package path keywords and hierarchical offsets must be configured simultaneously for further identification. Only when a package path keyword with a hierarchical offset of 0 is finally obtained can it be successfully included in the execution scope. In an application, a positive flag can be used to indicate whether the rule is used for positive or negative judgment. 1 is a whitelist and 0 is a blacklist.

[0050] It should be noted that the package path keyword is used in subsequent execution scope checks; the deeper the level, the finer the granularity of the execution scope check.

[0051] In some embodiments, the rule list can be stored in a relational database. The bank system can preload and cache the rule list via hashing upon startup. The rule list supports hot refresh, and its data structure is shown below:

[0052]

[0053]

[0054] For example, the rules in the rule list can be as shown in Table 1.

[0055] Table 1

[0056]

[0057] As shown in Table 1, the first rule indicates that all transactions under business type 3 are included in the scope of public service logic execution. The second rule indicates that only the transaction trade2 under business type 1 is included in the scope of public service logic execution. The third rule indicates that all transactions under product4 under business type 2 are included in the scope of public service logic execution.

[0058] In some optional embodiments, after querying the rule list based on the packet path keyword corresponding to the transaction request, the method further includes: if the packet path keyword corresponding to the transaction request does not exist in the rule list, then the transaction corresponding to the transaction request will not be included in the execution scope of the public service logic.

[0059] In some optional embodiments, after obtaining the layer offset corresponding to the packet path keyword, the method further includes: if the layer offset corresponding to the packet path keyword fails the verification, determining the next verification layer based on the layer offset corresponding to the packet path keyword and the current verification layer; if the layer value of the next verification layer is less than the packet path length, obtaining the packet path keyword of the next verification layer, and verifying the packet path keyword of the next verification layer based on the rule list.

[0060] In some optional embodiments, after obtaining the positive identifier corresponding to the packet path keyword, the method further includes: if the positive identifier corresponding to the packet path keyword is negative, then the transaction corresponding to the transaction request will not be included in the execution scope of the public service logic.

[0061] For example, Figure 3 This is a flowchart of a public service logic execution scope control method according to an embodiment of the present invention. The steps of the public service logic execution scope control method include:

[0062] 1. Obtain the business category package path keyword and initial validation level.

[0063] Specifically, based on the engineering structure example, it can be determined that the package path of the business category (business type) is at level 5. The level 5 of the package path is set as the package path keyword used for initial verification (such as businesstype1, businesstype2, or businesstype3 in the engineering structure example), and the current verification level is set to 5.

[0064] 2. Perform rule validation step 1 on the package path keyword.

[0065] Specifically, the rule list in the server cache is queried to determine whether the currently obtained packet path keyword exists in the rule list. If it exists, step 1 verification passes; otherwise, step 1 verification fails, it is determined that the transaction is outside the whitelist, and the public service logic is not executed, that is, the transaction corresponding to the transaction request is not included in the execution scope of the public service logic.

[0066] 3. Perform rule verification step 2.

[0067] If the verification in step 1 passes, the system queries the rule list for the current package path keyword to obtain the hierarchical offset corresponding to the package path keyword. If the offset is 0, the verification in step 2 passes; if the offset is greater than 0, the verification fails.

[0068] If the verification in step 2 passes, the system determines whether the transaction is on the blacklist or the whitelist based on the positive flag. If it is on the blacklist, the transaction is outside the whitelist and the common service logic is not executed; if it is on the whitelist, the transaction is within the whitelist and the common service logic is executed. If the verification in step 2 fails, proceed to step 4.

[0069] 4. Based on the verification results in step 2 and the current verification level, obtain the package path keywords of the next lower level.

[0070] Specifically, the layer offset obtained in rule verification step 2 is added to the current verification layer to obtain the layer value of the next verification layer. If the layer value of the next verification layer is less than or equal to the packet path length, the packet path keyword of the next verification layer is successfully obtained, and the packet path keyword of the next verification layer is verified based on the rule list. If the layer value of the next verification layer is greater than the packet path length, the retrieval fails, the transaction is determined to be outside the whitelist, and the public service logic is not executed.

[0071] It should be noted that during the execution of the public service logic execution scope control method, the relatively complex operation involves only two rule verification steps, both of which involve querying the rule list in the cache. Since rules can be stored using hashes, the performance overhead of each query is negligible. With a correctly designed rule list, the entire execution process loops at most twice (the first loop uses the initial package path keyword for identification and verification, and the second loop uses the package path keyword with added hierarchical offsets). Therefore, the performance overhead of the public service logic execution scope control method can be kept low and will not increase with the expansion of project scale or the increased flexibility and complexity of the control scope. Furthermore, the data reading operations introduced by this embodiment during transaction execution can all be read from the server cache, avoiding the performance overhead of directly reading the database.

[0072] The technical solution of this invention, in response to a transaction request, obtains the packet path keyword corresponding to the transaction request, and then queries the rule list based on the packet path keyword. If the packet path keyword exists in the rule list, the hierarchical offset corresponding to the packet path keyword is obtained; if the hierarchical offset corresponding to the packet path keyword passes the verification, the positive identifier corresponding to the packet path keyword is obtained; if the positive identifier corresponding to the packet path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic. This technical solution uses the packet path keyword as key data to determine whether to include the transaction in the execution scope of the public service logic, thus achieving dynamic configuration of the execution scope of the public service logic.

[0073] Example 2

[0074] Figure 4 This is a flowchart of a public service logic execution scope configuration method provided in Embodiment 2 of the present invention. The method of this embodiment can be combined with various optional schemes in the public service logic execution scope configuration method provided in the above embodiments. The public service logic execution scope configuration method provided in this embodiment has been further optimized. Optionally, after responding to a transaction request, the method further includes: reading a hot-load identifier in the server cache; if the hot-load identifier in the server cache is the same as the hot-load identifier in the server's local memory, then reading the rule list in the server cache; if the hot-load identifier in the server cache is different from the hot-load identifier in the server's local memory, then updating and reading the rule list in the server cache.

[0075] like Figure 4 As shown, the method includes:

[0076] S210. In response to the transaction request, obtain the packet path keyword corresponding to the transaction request.

[0077] S220. Read the hot-reload identifier in the server cache. If the hot-reload identifier in the server cache is the same as the hot-reload identifier in the server's local memory, then read the rule list in the server cache. If the hot-reload identifier in the server cache is different from the hot-reload identifier in the server's local memory, then update and read the rule list in the server cache.

[0078] S230. Based on the packet path keyword corresponding to the transaction request, query the rule list. If the packet path keyword corresponding to the transaction request exists in the rule list, obtain the hierarchical offset corresponding to the packet path keyword. If the hierarchical offset corresponding to the packet path keyword passes the verification, obtain the positive identifier corresponding to the packet path keyword. If the positive identifier corresponding to the packet path keyword is positive, include the transaction corresponding to the transaction request in the public service logic execution scope.

[0079] In this embodiment of the invention, the hot-load flag is used to dynamically refresh the rule list.

[0080] For example, Figure 5 This is a flowchart of a method for dynamically adjusting a rule list according to an embodiment of the present invention. Figure 5 As shown, the rule setting steps include:

[0081] a. Internal administrators can configure rules through the management interface.

[0082] b. Internal administrators can perform operations such as adding, deleting, and modifying the rule list in the database.

[0083] c. Modify the hot-reload flag in the database while modifying the rule list.

[0084] d. Read the hot reload flag from the database every 5 minutes, and refresh the hot reload flag in the server cache at the same time.

[0085] The transaction execution process includes:

[0086] 1. The customer initiates a transaction request.

[0087] 2. The public service logic execution scope controller reads the hot reload flag in the server cache and compares it with the local hot reload flag in the server's local memory. If they are the same, it means that the rule list in the current server cache is up-to-date, and proceed to step 3; if they are different, it means that the rule list in the current server cache needs to be updated, and proceed to step 4, while updating the local hot reload flag.

[0088] Among them, the public service logic execution scope controller is a virtual controller used to control or adjust the execution scope of public service logic.

[0089] 3. Read the rule list from the server cache and perform rule validation.

[0090] 4. Read the latest rule list from the database and update the server cache with the latest rule list to refresh the rule list cache.

[0091] It should be noted that this embodiment of the invention relies on updating the rule list to control the execution scope of the public service logic. The dynamic adjustment process involves database addition, deletion, and modification operations, without exposing the modification entry point of the pointcut expression. Furthermore, the rule list is only read by this method and participates in the identification and verification of package path keywords. The use case has strict scope limitations and is isolated from underlying logic such as aspect weaving. If an invalid package path keyword is configured, it will be directly ignored by the system and will not cause system-level anomalies. If an incorrect layer offset value is configured, it will cause the failure to obtain the lower-level package path keyword in the execution flow, but deadlock will not occur. Therefore, the introduction of this public service logic execution scope configuration method does not add additional system risks and is secure.

[0092] The technical solution of this invention relies on the setting of a rule list for controlling the execution scope of public service logic. The rule list is stored in a relational database, and it is loaded into a cache during application initialization. Subsequent transaction execution reads the cached rule list for relevant control. This invention supports dynamic refreshing of the rule list. Internal administrators can access the database through the management terminal to add, delete, and modify the rule list, updating it in the server cache to achieve dynamic rule adjustment.

[0093] Example 3

[0094] Figure 6 This is a flowchart of a public service logic execution scope configuration method provided in Embodiment 3 of the present invention. The method in this embodiment is a preferred embodiment of the above embodiments.

[0095] like Figure 6 As shown, the method includes:

[0096] Step 1: The customer initiates a transaction request.

[0097] Step 2: The public service logic execution scope controller in the transaction application server obtains the packet path keyword corresponding to the transaction request based on the transaction request and reads the rule list from the rule list database. Further, it queries the rule list based on the packet path keyword corresponding to the transaction request. If the rule list contains the packet path keyword corresponding to the transaction request, it obtains the hierarchical offset corresponding to the packet path keyword. If the hierarchical offset corresponding to the packet path keyword passes the verification, it obtains the positive identifier corresponding to the packet path keyword. If the positive identifier corresponding to the packet path keyword is positive, the transaction corresponding to the transaction request is included in the public service logic execution scope.

[0098] Step 3: Perform public service logic processing and transaction processing (i.e., transaction execution), and the transaction is processed in the back-end business system (i.e., the back-end system).

[0099] In the above technical solution, internal management personnel can also configure rules through the management terminal to configure rules in the rule list database.

[0100] The technical solution of this invention uses package path keywords as key data to determine whether a service logic execution scope is included, thereby realizing dynamic configuration of the service logic execution scope.

[0101] Example 4

[0102] Figure 7 This is a schematic diagram of a public service logic execution scope configuration device provided in Embodiment 4 of the present invention. Figure 7 As shown, the device includes:

[0103] The packet path keyword acquisition module 410 is used to acquire the packet path keyword corresponding to the transaction request in response to the transaction request;

[0104] The rule verification module 420 is used to query the rule list based on the packet path keyword corresponding to the transaction request. If the packet path keyword corresponding to the transaction request exists in the rule list, the layer offset corresponding to the packet path keyword is obtained. If the layer offset corresponding to the packet path keyword passes the verification, the positive identifier corresponding to the packet path keyword is obtained. If the positive identifier corresponding to the packet path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic.

[0105] The technical solution of this invention, in response to a transaction request, obtains the packet path keyword corresponding to the transaction request, and then queries the rule list based on the packet path keyword. If the packet path keyword exists in the rule list, the hierarchical offset corresponding to the packet path keyword is obtained; if the hierarchical offset corresponding to the packet path keyword passes the verification, the positive identifier corresponding to the packet path keyword is obtained; if the positive identifier corresponding to the packet path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic. This technical solution uses the packet path keyword as key data to determine whether to include the transaction in the execution scope of the public service logic, thus achieving dynamic configuration of the execution scope of the public service logic.

[0106] In some optional implementations, the package path keyword acquisition module 410 is specifically used for:

[0107] Get the package name of the application that made the transaction request;

[0108] The name of the preset level in the package name of the application where the transaction request is located is used as the package path keyword corresponding to the transaction request.

[0109] In some optional implementations, the rule list includes a package path keyword, the hierarchical offset corresponding to the package path keyword, and a positive identifier.

[0110] In some optional implementations, the rule validation module 420 is further configured to:

[0111] If the package path keyword corresponding to the transaction request does not exist in the rule list, then the transaction corresponding to the transaction request will not be included in the execution scope of the public service logic.

[0112] In some optional implementations, the rule validation module 420 is further configured to:

[0113] If the layer offset corresponding to the packet path keyword fails the verification, the next verification layer is determined based on the layer offset corresponding to the packet path keyword and the current verification layer.

[0114] If the level value of the next verification level is less than the packet path length, the packet path keyword of the next verification level is obtained, and the packet path keyword of the next verification level is verified based on the rule list.

[0115] In some optional implementations, the rule validation module 420 is further configured to:

[0116] If the forward identifier corresponding to the package path keyword is reversed, then the transaction corresponding to the transaction request will not be included in the execution scope of the public service logic.

[0117] In some optional implementations, the public service logic execution scope configuration apparatus further includes:

[0118] The rule list acquisition module is used to read the hot-reload identifier in the server cache. If the hot-reload identifier in the server cache is the same as the hot-reload identifier in the server's local memory, then the rule list in the server cache is read; if the hot-reload identifier in the server cache is different from the hot-reload identifier in the server's local memory, then the rule list in the server cache is updated and read.

[0119] The public service logic execution scope configuration device provided in the embodiments of the present invention can execute the public service logic execution scope configuration method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0120] Example 5

[0121] Figure 8A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0122] like Figure 8 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An I / O interface 15 is also connected to the bus 14.

[0123] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0124] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 executes the various methods and processes described above, such as a public service logic execution scope configuration method, which includes:

[0125] In response to a transaction request, obtain the packet path keyword corresponding to the transaction request;

[0126] Based on the packet path keyword corresponding to the transaction request, the rule list is queried. If the packet path keyword corresponding to the transaction request exists in the rule list, the hierarchical offset corresponding to the packet path keyword is obtained. If the hierarchical offset corresponding to the packet path keyword passes the verification, the positive identifier corresponding to the packet path keyword is obtained. If the positive identifier corresponding to the packet path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic.

[0127] In some embodiments, the public service logic execution scope configuration method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the public service logic execution scope configuration method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the public service logic execution scope configuration method by any other suitable means (e.g., by means of firmware).

[0128] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0129] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0130] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0131] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0132] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0133] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0134] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0135] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for configuring the execution scope of a public service logic, characterized in that, include: In response to a transaction request, obtain the packet path keyword corresponding to the transaction request; Based on the packet path keyword corresponding to the transaction request, the rule list is queried. If the packet path keyword corresponding to the transaction request exists in the rule list, the hierarchical offset corresponding to the packet path keyword is obtained. If the layer offset corresponding to the package path keyword passes the verification, the positive identifier corresponding to the package path keyword is obtained; if the positive identifier corresponding to the package path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic.

2. The method according to claim 1, characterized in that, The step of obtaining the packet path keyword corresponding to the transaction request includes: Get the package name of the application that made the transaction request; The name of the preset level in the package name of the application where the transaction request is located is used as the package path keyword corresponding to the transaction request.

3. The method according to claim 1, characterized in that, The rule list includes package path keywords, the hierarchical offsets corresponding to the package path keywords, and positive identifiers.

4. The method according to claim 1, characterized in that, After querying the rule list based on the packet path keyword corresponding to the transaction request, the process also includes: If the package path keyword corresponding to the transaction request does not exist in the rule list, then the transaction corresponding to the transaction request will not be included in the execution scope of the public service logic.

5. The method according to claim 1, characterized in that, After obtaining the hierarchical offset corresponding to the package path keyword, the method further includes: If the layer offset corresponding to the packet path keyword fails the verification, the next verification layer is determined based on the layer offset corresponding to the packet path keyword and the current verification layer. If the level value of the next verification level is less than the packet path length, the packet path keyword of the next verification level is obtained, and the packet path keyword of the next verification level is verified based on the rule list.

6. The method according to claim 1, characterized in that, After obtaining the positive identifier corresponding to the package path keyword, the method further includes: If the forward identifier corresponding to the package path keyword is reversed, then the transaction corresponding to the transaction request will not be included in the execution scope of the public service logic.

7. The method according to claim 1, characterized in that, Following the response to the transaction request, it also includes: Read the hot reload flag in the server cache. If the hot reload flag in the server cache is the same as the hot reload flag in the server's local memory, then read the rule list in the server cache. If the hot-reload flag in the server cache is different from the hot-reload flag in the server's local memory, then update and read the rule list in the server cache.

8. A public service logic execution scope configuration device, characterized in that, include: The package path keyword acquisition module is used to acquire the package path keyword corresponding to the transaction request in response to the transaction request. The rule verification module is used to query the rule list based on the packet path keyword corresponding to the transaction request. If the packet path keyword corresponding to the transaction request exists in the rule list, the layer offset corresponding to the packet path keyword is obtained. If the layer offset corresponding to the package path keyword passes the verification, the positive identifier corresponding to the package path keyword is obtained; if the positive identifier corresponding to the package path keyword is positive, the transaction corresponding to the transaction request is included in the execution scope of the public service logic.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the public service logic execution scope configuration method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the public service logic execution scope configuration method according to any one of claims 1-7.

Images