Service calling and providing method, device, electronic equipment, medium and program product

Abstract

This disclosure provides a service invocation method, service provision method, apparatus, electronic device, medium, and computer program product based on a modular architecture. The above method and apparatus can be used in the fields of distributed computing and financial technology. The service invocation method includes: submitting a service request, wherein the service request includes item information of a target service item; obtaining stub information of a service item corresponding to the target service item; parsing annotation information in the interface definition of the stub information to obtain attribute values ​​in the annotation information; loading a class corresponding to the attribute values ​​in the annotation information; executing a method of the class to obtain customer characteristic values; determining a modular module capable of providing the target service item based on the customer characteristic values; and initiating an invocation request to the modular module capable of providing the target service item.

Description

Technical Field

[0001] This disclosure relates to the fields of distributed computing and financial technology, and more specifically, to a service invocation method, service provision method, apparatus, electronic device, computer-readable storage medium, and computer program product based on a modular architecture. Background Technology

[0002] In a traditional distributed architecture, all provider nodes of a service are logically equal. When a consumer wants to call the service, it can choose any provider to initiate the call according to the load balancing strategy provided by the RPC framework, without having to consider anything else.

[0003] However, in a modular architecture, the situation changes. A service provider is divided into multiple units, each deploying a fully functional provider cluster and corresponding database resources. In this scenario, for a consumer within a unit to call the service, it must first calculate which unit's provider to call. This can result in two outcomes: either calling the provider within its own unit, in which case a direct RPC call can be initiated; or calling the provider from another unit, which requires a cross-unit call.

[0004] With the widespread adoption of microservices today, a centralized configuration center is a very natural choice. Service providers write the unitized characteristics of all the services they provide into the configuration center. Consumers retrieve the characteristics from the configuration center and cache them locally. At runtime, they directly read the key-value structured characteristic information to identify the target unit and then call the service provider within their own unit or other units. Summary of the Invention

[0005] In view of this, this disclosure provides a service invocation method, service provision method, device, electronic device, computer-readable storage medium, and computer program product based on a modular architecture, which has low dependency, low operation and maintenance and code maintenance costs, and low code maintenance difficulty.

[0006] One aspect of this disclosure provides a service invocation method based on a modular architecture, the modular architecture including multiple modular modules, in which service providers and service consumers are deployed. Each service provider provides a service item, and each service item has corresponding stub information, the stub information including the interface definition of the service item. The service invocation method is applied to the service consumer, and the method includes: submitting a service request, wherein the service request includes item information of a target service item; obtaining stub information of the service item corresponding to the target service item; parsing annotation information in the interface definition of the stub information to obtain attribute values ​​in the annotation information; loading a class corresponding to the attribute values ​​in the annotation information; executing a method of the class to obtain customer characteristic values; determining a modular module capable of providing the target service item based on the customer characteristic values; and initiating an invocation request to the modular module capable of providing the target service item.

[0007] According to the service invocation method based on a unitized architecture according to the embodiments of this disclosure, by parsing the annotation information in the interface definition of the stub information, the attribute values ​​defining how to parse customer characteristic values ​​from the item information of the target service item can be obtained. By executing the method of the class corresponding to the attribute value, the customer characteristic value can be parsed, thereby determining the unitized module that can provide the target service item based on the customer characteristic value. Compared with the prior art, the service consumer does not need to pull the configuration from the configuration center every time it starts, reducing or even eliminating the strong dependence of the service consumer on the configuration center. In addition, the architecture of this method is simple and no longer requires the introduction of third-party data synchronization tools, reducing operation and maintenance costs. Furthermore, developers no longer need to synchronously update the unitized features, reducing the difficulty and cost of code maintenance.

[0008] In some embodiments, the matter information includes request parameters; the method of executing the class to obtain customer characteristic values ​​includes: executing the method of the class to parse the customer characteristic values ​​from the request parameters.

[0009] In some embodiments, the customer characteristic value includes the user's address information in the request parameters.

[0010] In some embodiments, determining the unitized module capable of providing the target service item based on the address information includes: calculating the number of the unitized module corresponding to the address information; and determining the unitized module capable of providing the target service item based on the number.

[0011] Another aspect of this disclosure provides a service invocation apparatus based on a modular architecture. The modular architecture includes multiple modular modules, in which service providers and service consumers are deployed. Each service provider provides a service item, and each service item has corresponding stub information. The stub information includes the interface definition of the service item. The apparatus includes: a request module for submitting a service request, wherein the service request includes item information of a target service item; an acquisition module for acquiring the stub information of the service item corresponding to the target service item; a parsing module for parsing annotation information in the interface definition of the stub information to obtain attribute values ​​in the annotation information; a loading module for loading a class corresponding to the attribute values ​​in the annotation information; an execution module for executing a method of the class to obtain customer characteristic values; a determination module for determining, based on the customer characteristic values, a modular module capable of providing the target service item; and an invocation module for initiating an invocation request to the modular module capable of providing the target service item.

[0012] Another aspect of this disclosure provides a service provision method based on a modular architecture, the modular architecture including multiple modular modules, in which service providers and service consumers are deployed, each of the service providers providing service items, the service provision method being applied to the service providers, the method including: adding annotation information to the interface definition of the service item, wherein the annotation information includes attribute values; generating stub information based on the interface definition after adding annotation information; and publishing the stub information.

[0013] According to the service provision method based on a unitized architecture according to embodiments of this disclosure, annotation information is added to the interface definition of service items. The attribute values ​​of the annotation information can define how to parse customer feature values ​​from the item information of the target service item. Stub information is generated based on the interface definition after adding annotation information. After the stub information is published, the service consumer can obtain the stub information and parse the customer feature values, thereby facilitating the service consumer to determine the unitized module that can provide the target service item based on the customer feature values. The service consumer does not need to pull configuration from the configuration center every time it starts, reducing or even eliminating the strong dependence of the service consumer on the configuration center; in addition, the architecture of this method is simple, and there is no need to introduce third-party data synchronization tools, reducing operation and maintenance costs; furthermore, developers no longer need to synchronously update unitized features, reducing the difficulty and cost of code maintenance.

[0014] In some embodiments, publishing the stub information means publishing the stub information to a storage repository.

[0015] Another aspect of this disclosure provides a service provisioning apparatus based on a modular architecture, the modular architecture including multiple modular modules, in which service providers and service consumers are deployed, each of the service providers providing a service item. The apparatus includes: an adding module, configured to add annotation information to an interface definition of the service item, wherein the annotation information includes attribute values; a generating module, configured to generate stub information based on the interface definition after adding the annotation information; and a publishing module, configured to publish the stub information.

[0016] Another aspect of this disclosure provides an electronic device including one or more processors and one or more memories, wherein the memories are used to store executable instructions that, when executed by the processor, implement the method described above.

[0017] Another aspect of this disclosure provides a computer-readable storage medium storing computer-executable instructions that, when executed, are used to implement the method described above.

[0018] Another aspect of this disclosure provides a computer program product including a computer program comprising computer executable instructions that, when executed, are used to implement the method described above. Attached Figure Description

[0019] The above and other objects, features and advantages of this disclosure will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0020] Figure 1 This illustration schematically shows an exemplary system architecture to which methods and apparatus can be applied according to embodiments of the present disclosure;

[0021] Figure 2 A flowchart illustrating a service invocation method based on a unitized architecture according to an embodiment of the present disclosure is shown.

[0022] Figure 3 A flowchart illustrating a method of an execution class according to an embodiment of the present disclosure for obtaining customer characteristic values ​​is shown schematically.

[0023] Figure 4 A flowchart illustrating a modular module for determining the ability to provide target services based on customer characteristic values, according to an embodiment of the present disclosure, is shown.

[0024] Figure 5 This schematically illustrates a flowchart of a modular module that determines a target service item based on address information according to an embodiment of the present disclosure;

[0025] Figure 6 This schematically illustrates a structural block diagram of a service invocation apparatus based on a modular architecture according to an embodiment of the present disclosure;

[0026] Figure 7 A flowchart illustrating a service provision method based on a unitized architecture according to an embodiment of the present disclosure is shown schematically.

[0027] Figure 8 This illustration schematically shows a diagram of publishing stub information to a storage repository according to an embodiment of the present disclosure;

[0028] Figure 9 This schematically illustrates a structural block diagram of a service provisioning apparatus based on a modular architecture according to an embodiment of the present disclosure;

[0029] Figure 10 A schematic diagram illustrating the layout of a modular architecture according to an embodiment of the present disclosure is shown.

[0030] Figure 11 A block diagram of an electronic device according to an embodiment of the present disclosure is shown schematically. Detailed Implementation

[0031] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0032] In the technical solution disclosed herein, the acquisition, storage, and application of user personal information all comply with relevant laws and regulations, necessary confidentiality measures have been taken, and there is no violation of public order and good morals. In the technical solution disclosed herein, the acquisition, collection, storage, use, processing, transmission, provision, disclosure, and application of data all comply with relevant laws and regulations, necessary confidentiality measures have been taken, and there is no violation of public order and good morals.

[0033] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0034] When using expressions such as "at least one of A, B, or C," it should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (e.g., "a system having at least one of A, B, or C" should include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, features defined with "first" or "second" may explicitly or implicitly include one or more of the stated features.

[0035] In a traditional distributed architecture, all provider nodes of a service are logically equal. When a consumer wants to call the service, it can choose any provider to initiate the call according to the load balancing strategy provided by the RPC framework, without having to consider anything else.

[0036] However, in a modular architecture, the situation changes. A service provider is divided into multiple units, each deploying a fully functional provider cluster and corresponding database resources. In this scenario, for a consumer within a unit to call the service, it must first calculate which unit's provider to call. This can result in two outcomes: either calling the provider within its own unit, in which case a direct RPC call can be initiated; or calling the provider from another unit, which requires a cross-unit call.

[0037] With the widespread adoption of microservices today, a centralized configuration center is a very natural choice. Service providers write the unitized characteristics of all the services they provide into the configuration center. Consumers retrieve the characteristics from the configuration center and cache them locally. At runtime, they directly read the key-value structured characteristic information to identify the target unit and then call the service provider within their own unit or other units.

[0038] The main drawbacks of a centralized configuration center are as follows: First, the unitized features need to be pulled from the configuration center by the consumer every time it starts up, which is a strong dependency on the configuration center; second, the architecture is complex, and in order to solve the single point of failure of the configuration center, third-party data synchronization tools need to be introduced, resulting in high operation and maintenance costs; third, the unitized features of the service provider are physically isolated from the code, and after the service code is updated, developers are likely to forget to synchronize and update the unitized features, which increases the difficulty and cost of code maintenance.

[0039] This disclosure provides a service invocation method based on a modular architecture. The modular architecture includes multiple modular modules, in which service providers and service consumers are deployed. Each service provider provides a service item, and each service item has corresponding stub information, including the interface definition of the service item. The service invocation method is applied to the service consumer. The service invocation method based on the modular architecture includes: submitting a service request, wherein the service request includes item information of the target service item; obtaining the stub information of the service item corresponding to the target service item; parsing the annotation information in the interface definition of the stub information to obtain the attribute values ​​in the annotation information; loading the class corresponding to the attribute values ​​in the annotation information; executing the method of the class to obtain customer characteristic values; determining the modular module that can provide the target service item based on the customer characteristic values; and initiating an invocation request to the modular module that can provide the target service item.

[0040] It should be noted that the service invocation method, service provision method, device, electronic device, computer-readable storage medium and computer program product based on the unitized architecture disclosed herein can be used in the field of distributed computing technology, and can also be used in any field other than the field of distributed computing technology, such as the financial field. The field of this disclosure is not limited here.

[0041] Figure 1 This illustration schematically depicts an exemplary system architecture 100 applicable to service invocation methods, service provision methods, apparatuses, electronic devices, computer-readable storage media, and computer program products based on a modular architecture, according to embodiments of this disclosure. It should be noted that... Figure 1 The examples shown are merely examples of system architectures that can be applied to the embodiments of this disclosure, in order to help those skilled in the art understand the technical content of this disclosure, but do not mean that the embodiments of this disclosure cannot be used in other devices, systems, environments or scenarios.

[0042] like Figure 1 As shown, the system architecture 100 according to this embodiment may include terminal devices 101, 102, and 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the terminal devices 101, 102, and 103 and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0043] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0044] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0045] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using terminal devices 101, 102, and 103 (for example only). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0046] It should be noted that the service invocation method and service provision method based on the unitized architecture provided in this disclosure embodiment can generally be executed by server 105. Correspondingly, the service invocation device and service provision device based on the unitized architecture provided in this disclosure embodiment can generally be located in server 105. The service invocation method and service provision method based on the unitized architecture provided in this disclosure embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105. Correspondingly, the service invocation device and service provision device based on the unitized architecture provided in this disclosure embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105.

[0047] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0048] The following will be based on Figure 1 The described scene, through Figures 2-5 The service management method based on a modular architecture, according to embodiments of this disclosure, will be described in detail.

[0049] Figure 2 A flowchart illustrating a service invocation method based on a unitized architecture according to an embodiment of the present disclosure is shown.

[0050] According to the service invocation method based on a modular architecture according to the embodiments of this disclosure, it is applied to a service consumer. The modular architecture includes multiple modular modules, in which service providers and service consumers are deployed. Each service provider provides a service item, and each service item has corresponding stub information, which includes the interface definition of the service item.

[0051] It is understandable that multiple unitized modules in a modular architecture can be divided according to partitioning rules. These rules can be user attributes, which may include at least one of user ID, user type, number of users, and user level, but are not limited to these. Here, user ID can be understood as the user's account address; user type can be understood as a merchant, consumer, or regulator, etc. (These are just examples and should not be interpreted as restrictions on user types; user types can also be other categories); user level can be understood as the user's rank, such as one-star customer, two-star customer, three-star customer, etc. The higher the star rating, the higher the customer level, and the greater the customer benefits and privileges. (These are just examples and should not be interpreted as restrictions on user levels; user levels can also be other categories.)

[0052] Therefore, multiple modular units can be created based on at least one of user ID, user type, number of users, and user level, to store users according to the corresponding partitioning rules. The following detailed explanation uses partitioning multiple modular units based on user ID as an example.

[0053] Assume there are 100 users. User ID 1 is 00001, User ID 2 is 00002, User ID 3 is 00003, User ID 4 is 00004, User ID 5 is 00005, and so on, with User ID 100 being 00100. Based on these 100 users, the partitioning rule is as follows: users with the last three digits of their user IDs from 001 to 020 are grouped into one unit; users with the last three digits of their user IDs from 021 to 040 are grouped into another unit; users with the last three digits of their user IDs from 041 to 060 are grouped into another unit; users with the last three digits of their user IDs from 061 to 080 are grouped into another unit; and users with the last three digits of their user IDs from 081 to 100 are grouped into another unit.

[0054] Furthermore, by using at least one of the following user attributes—user ID, user type, number of users, and user level—multiple modular units can be divided in the modular architecture based on these user attributes. This allows for the division of modular units according to specific scenarios and needs, making the division of modular units more practical and flexible.

[0055] like Figure 2 As shown, the service invocation method based on the unitized architecture in this embodiment includes operations S210 to S270.

[0056] In operation S210, a service request is made, wherein the service request includes the item information of the target service item.

[0057] In operation S220, the stub information of the service item corresponding to the target service item is obtained. It can be understood that in multiple unitized modules, each unitized module can deploy a service provider to provide the same service item. When a service request is made, the corresponding service item can be matched according to the target service item of the service request, and then the stub information of the service item can be obtained.

[0058] In operation S230, the annotation information in the interface definition of the stub information is parsed to obtain the attribute values ​​in the annotation information. It should be noted that the attribute values ​​define how to parse customer characteristic values ​​from the item information of the target service item.

[0059] In operation S240, the class corresponding to the attribute values ​​in the annotation information is loaded. It should be noted that the class can be a Java programming language class.

[0060] In operation S250, a method of the class is executed to obtain customer characteristic values. It can be understood that since the attribute values ​​already define how to parse customer characteristic values ​​from the item information of the target service item, executing the method of the class corresponding to the attribute values ​​will retrieve the customer characteristic values.

[0061] As one possible approach, the request information could include request parameters. For example... Figure 3 As shown, operation S250 executes the class method to obtain customer characteristic values, including operation S251: executes the class method to parse customer characteristic values ​​from request parameters.

[0062] As one possible implementation, the customer characteristic value can include the user's address information from the request parameters. For example, the request parameters could be "User ID: 00043; User Password: 111", and after executing the method of the class, the customer characteristic value "User ID: 00043" can be obtained. By including the request parameters in the event information, including the user's address information in the request parameters in the customer characteristic value, and operation S251, it is easy to implement the method of the class to obtain the customer characteristic value.

[0063] In operation S260, based on customer characteristic values, the unitized modules capable of providing the target service items are determined. In some specific examples, such as... Figure 4 As shown, operation S260, which determines the unitized module that can provide the target service based on the customer characteristic value, can be understood as operation S261: determining the unitized module that can provide the target service based on the address information.

[0064] As one possible way to achieve this, such as Figure 5 As shown, operation S261 determines, based on the address information, the unitized modules that can provide the target service item, including operations S2611 and S2612.

[0065] In operation S2611, the number of the unitized module corresponding to the address information is calculated.

[0066] In operation S2612, the unitized module that can provide the target service item is determined based on the number.

[0067] Continuing with the example of the aforementioned 100 users, when dividing the 100 users into unit modules based on their user IDs, each unit module can be assigned a number. For example, users whose last three digits of their user IDs are 001-020 can be grouped into one unit module, and this unit module is numbered 1; users whose last three digits of their user IDs are 021-040 can be grouped into one unit module, and this unit module is numbered 2; users whose last three digits of their user IDs are 041-060 can be grouped into one unit module, and this unit module is numbered 3; users whose last three digits of their user IDs are 061-080 can be grouped into one unit module, and this unit module is numbered 4; and users whose last three digits of their user IDs are 081-100 can be grouped into one unit module, and this unit module is numbered 5.

[0068] Specifically, the calculation of the unitized module number corresponding to the address information can be based on the partitioning rules. That is, after obtaining the customer characteristic value "User ID: 00043", the last three digits of the user ID are 043. The unitized module number corresponding to the last three digits of the user ID 043 is 3. Therefore, based on the number 3, the unitized module capable of providing the target service can be determined. Operations S2611 and S2612 facilitate the determination of the unitized module capable of providing the target service based on the address information.

[0069] In operation S270, a call request is initiated to a unitized module that can provide the target service.

[0070] According to the service invocation method based on a unitized architecture according to the embodiments of this disclosure, by parsing the annotation information in the interface definition of the stub information, the attribute values ​​defining how to parse customer characteristic values ​​from the item information of the target service item can be obtained. By executing the method of the class corresponding to the attribute value, the customer characteristic value can be parsed, thereby determining the unitized module that can provide the target service item based on the customer characteristic value. Compared with the prior art, the service consumer does not need to pull the configuration from the configuration center every time it starts, reducing or even eliminating the strong dependence of the service consumer on the configuration center. In addition, the architecture of this method is simple and no longer requires the introduction of third-party data synchronization tools, reducing operation and maintenance costs. Furthermore, developers no longer need to synchronously update the unitized features, reducing the difficulty and cost of code maintenance.

[0071] Based on the above-described service invocation method using a modular architecture, this disclosure also provides a service invocation device 10 based on a modular architecture. The following will be combined with... Figure 6 A detailed description is provided of the service invocation device 10 based on a modular architecture.

[0072] Figure 6 The diagram schematically illustrates a structural block diagram of a service invocation apparatus 10 based on a modular architecture according to an embodiment of the present disclosure. The modular architecture includes multiple modular modules, in which service providers and service consumers are deployed. Each service provider provides a service item, and each service item has corresponding stub information, including the interface definition of the service item.

[0073] The service invocation device 10 based on a modular architecture includes a request module 1, an acquisition module 2, a parsing module 3, a loading module 4, an execution module 5, a determination module 6, and an invocation module 7.

[0074] Request module 1 is used to perform operation S210: submit a service request, wherein the service request includes the item information of the target service item.

[0075] Acquisition module 2 is used to perform operation S220: acquire the stub information of the service item corresponding to the target service item.

[0076] Parsing module 3 is used to perform operation S230: parse the annotation information in the interface definition of the stub information to obtain the attribute values ​​in the annotation information.

[0077] Loading module 4 is used to perform operation S240: loading the class corresponding to the attribute values ​​in the annotation information.

[0078] Execution module 5 is used to execute operation S250: the method of the execution class to obtain customer characteristic values.

[0079] Module 6 is used to perform operation S260: Based on customer characteristic values, determine the unitized modules that can provide the target service items.

[0080] Call module 7, which is used to perform operation S270: Initiate a call request to the unitized module that can provide the target service item.

[0081] Since the above-mentioned service invocation device 10 based on the unitized architecture is set up based on the service invocation method of the unitized architecture, the beneficial effects of the above-mentioned service invocation device 10 based on the unitized architecture are the same as those of the service invocation method based on the unitized architecture, and will not be repeated here.

[0082] Furthermore, according to embodiments of this disclosure, any and multiple modules among the request module 1, acquisition module 2, parsing module 3, loading module 4, execution module 5, determination module 6, and invocation module 7 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functionality of one or more of these modules can be combined with at least some of the functionality of other modules and implemented in one module.

[0083] According to embodiments of this disclosure, at least one of the request module 1, the acquisition module 2, the parsing module 3, the loading module 4, the execution module 5, the determination module 6, and the calling module 7 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of the three methods of software, hardware, and firmware, or in a suitable combination of any of these.

[0084] Alternatively, at least one of the following modules can be implemented, at least partially, as a computer program module that can perform the corresponding function when the computer program module is run.

[0085] The following will be based on Figure 1 The described scene, through Figure 7 and Figure 8 The service provision method based on a modular architecture according to embodiments of this disclosure will be described in detail.

[0086] Figure 7 A flowchart illustrating a service provision method based on a modular architecture according to an embodiment of this disclosure is shown schematically.

[0087] According to the service provision method based on a modular architecture according to embodiments of the present disclosure, the modular architecture includes multiple modular modules, in which service providers and service consumers are deployed, each service provider provides service items, and the service provision method is applied to the service providers.

[0088] like Figure 7 As shown, the service provision method based on the unitized architecture in this embodiment includes operations S310 to S330.

[0089] In operation S310, add annotation information to the interface definition of the service item. The annotation information includes attribute values, which can define how to parse customer feature values ​​from the item information of the target service item.

[0090] When operating S320, stub information is generated based on the interface definition after adding annotation information.

[0091] When operating S330, publish stub information.

[0092] According to the service provision method based on a unitized architecture according to embodiments of this disclosure, annotation information is added to the interface definition of service items. The attribute values ​​of the annotation information can define how to parse customer feature values ​​from the item information of the target service item. Stub information is generated based on the interface definition after adding annotation information. After the stub information is published, the service consumer can obtain the stub information and parse the customer feature values, thereby facilitating the service consumer to determine the unitized module that can provide the target service item based on the customer feature values. The service consumer does not need to pull configuration from the configuration center every time it starts, reducing or even eliminating the strong dependence of the service consumer on the configuration center; in addition, the architecture of this method is simple, and there is no need to introduce third-party data synchronization tools, reducing operation and maintenance costs; furthermore, developers no longer need to synchronously update unitized features, reducing the difficulty and cost of code maintenance.

[0093] In some embodiments of this disclosure, such as Figure 8 As shown, publishing stub information involves publishing the stub information to a storage repository. The storage repository can be a Mawen repository, which facilitates the publication of stub information. When a service consumer needs to call a service provider to provide a target service, it can pull the stub information from the Mawen repository, thereby enabling the parsing of annotation information in the interface definition of the stub information.

[0094] Based on the above-described service provision method using a modular architecture, this disclosure also provides a service provision apparatus 20 based on a modular architecture. The following will be combined with... Figure 9 A detailed description is provided of the service provisioning device 20 based on a modular architecture.

[0095] Figure 9 The diagram schematically illustrates a structural block diagram of a service providing apparatus 20 based on a modular architecture according to an embodiment of the present disclosure. The modular architecture includes multiple modular modules, in which service providers and service consumers are deployed, and each service provider provides service items.

[0096] The service provisioning device 20 based on a modular architecture includes an adding module 21, a generating module 22, and a publishing module 23.

[0097] Add module 21, which is used to perform operation S310: add annotation information to the interface definition of the service item, wherein the annotation information includes attribute values.

[0098] Generation module 22 is used to perform operation S320: generate stub information based on the interface definition after adding annotation information.

[0099] The publishing module 23 is used to perform operation S330: publishing stub information.

[0100] Since the above-mentioned service provisioning device 20 based on the modular architecture is set up based on the service provisioning method based on the modular architecture, the beneficial effects of the above-mentioned service provisioning device 20 based on the modular architecture are the same as those of the service provisioning method based on the modular architecture, and will not be repeated here.

[0101] Furthermore, according to embodiments of this disclosure, any multiple modules among the adding module 21, generating module 22, and publishing module 23 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functionality of one or more of these modules can be combined with at least some of the functionality of other modules and implemented in one module.

[0102] According to embodiments of this disclosure, at least one of the adding module 21, the generating module 22, and the publishing module 23 can be implemented at least partially as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging the circuitry, or as any one of the three implementation methods of software, hardware, and firmware, or as a suitable combination of any of them.

[0103] Alternatively, at least one of the add module 21, the generate module 22, and the publish module 23 may be implemented at least partially as a computer program module that can perform corresponding functions when the computer program module is run.

[0104] The following reference Figure 10 This disclosure provides a detailed description of a service provisioning method and a service invocation method based on a unitized architecture, according to embodiments of the present disclosure. It is important to understand that the following description is merely illustrative and not intended to limit the scope of this disclosure.

[0105] The methods for calculating the unit to which the provider belongs often differ depending on the service. Suppose we have a distributed system deployed with a unitized architecture, where the customer ID is used as the basis for unit segmentation. In this system, for a service that displays customer information, the service consumer needs to parse the customer ID from the service request, determine the unit number to which that customer ID belongs, and then call the provider for the corresponding unit. However, for a service that counts the total number of customers, the service consumer does not need to parse the customer ID (in fact, the service request will not contain the customer ID); it can directly call the provider for its own unit.

[0106] In the example above, which services need to calculate the target unit and which don't is determined by the service provider. For services that need to calculate the target unit, the method for parsing the customer ID from the request parameters varies depending on the service. This involves many details, which can be viewed as the unitized characteristics of the target service in a unitized scenario. These characteristics need to be communicated to the service consumer by the service provider in some way so that the service consumer can call the correct service provider at runtime.

[0107] This article describes how to manage the unitized features of services more elegantly, mainly including two aspects: how service providers define unitized features and how service consumers obtain the unitized features of services.

[0108] It is worth noting that this article has a basic premise: all services are distributed systems deployed based on a certain RPC framework. The modular architecture can be understood as a more advanced distributed system model.

[0109] The core idea of ​​this disclosure is that the service provider uses the annotation feature in Java to populate the unitized characteristics of the service into specific annotations, and then distributes them to the service consumer through service stubs. At runtime, the service consumer parses the specific annotations in the service stubs to obtain the content of the unitized characteristics, then calculates the target unit, and completes the service call.

[0110] We will now introduce this in two parts. The first part is how service providers configure unitized features for services based on annotations and distribute them to service consumers during the development phase, which is the service provision method based on unitized architecture. The second part is how service consumers parse annotations to obtain unitized features during the runtime phase, which is the service invocation method based on unitized architecture.

[0111] I. Development Phase

[0112] Suppose we have a business system that divides service providers into 5 units based on the last two digits of the customer ID. More specifically, one possible division scheme is that requests with the last two digits of the customer ID being 0-19 should call the provider in unit 1, requests with the last two digits being 20-39 should call the provider in unit 2, and so on, with requests with the last two digits being 80-99 calling the provider in unit 5. To achieve this runtime traffic allocation, the RPC framework, service providers, and service consumers all need to perform certain tasks. The following sections detail the tasks required by each role, following the specific implementation steps.

[0113] 1) The RPC framework defines unitized annotations based on the business scenario. In the example described above, the unitized annotation should specify "how to parse the customer ID from the request parameters". This annotation can be implemented as follows:

[0114] This annotation is used by the provider to identify its own services at the interface level.

[0115] @Target(ElementType.TYPE)

[0116] @Retention(RetentionPolicy.RUNTIME)

[0117] public @interface ZoneIdentify { / / Method to parse the user identifier cid from the parameter Class<? extends CidParser> cidParser() default CidParser.class;}

[0118] The RPC framework defines an annotation like the one above, named ZoneIdentify. The annotation contains only one attribute, cidParser, which tells the service consumer how to parse the user ID from the input parameters (both the consumer and the provider are developed based on the RPC framework, and this parsing action is actually done by the framework, but it is executed on the consumer side).

[0119] 2) Service providers use unitized annotations provided by the RPC framework to mark their published services, based on the specific characteristics of the service. In this example, the provider fills in the cidParser for different services in the annotation. Suppose there is now a provider that publishes two services, and the interfaces and corresponding annotations for these two services are shown in the following examples.

[0120] Code comments: This is a service to modify a user's login password. The first parameter of this interface is the user ID. The business logic of this interface is to change the password of the user specified by userId to the new password newPassword. In the annotation ZoneIdentify, cidParser is specified as a class, and its function, as its class name suggests, is to parse the first parameter.

[0121] Code comments: This interface provides a coupon distribution service to a specific user. The second parameter of this interface is the user ID. The business logic of this interface is to distribute coupons to the user specified by `userId` (where `couponId` is the coupon's internal ID). The `ZoneIdentify` annotation specifies `cidParser` as a class, whose purpose, as its name suggests, is to parse the second parameter. It must be noted that the `ParserFirstParam` and `ParserSecondParam` classes mentioned above must also be implemented by the service provider and sent to the consumer as part of the service stub along with the interface definition. For other complex interfaces of the provider, even more complex classes can be used to parse the user ID from the parameters. The specific implementation of these classes is purely a matter of Java programming skills and varies depending on the business scenario, so it will not be elaborated here.

[0122] The "sending service stubs to service consumers" mentioned above is generally translated into publishing service stubs to a Maven repository during actual development. This is a basic operation in modern distributed development, and the specific operational details will not be elaborated here.

[0123] 3) Service consumers update their service stubs. This is one of the basic operations in distributed development today, and it is common to pull them from the Maven repository. The specific operation details will not be elaborated here.

[0124] 4) When a service consumer initiates a request, the process of parsing annotations is handled by the RPC framework, with zero intrusion into the consumer's business code. For details on how the RPC framework parses annotations, please see the description of the runtime process below.

[0125] II. Operational Stage

[0126] Consumers do not need to make any adjustments to their calling methods; the parsing of unitized annotations is entirely handled silently by the RPC framework. Suppose the consumer wants to call the `modifyUserPassword` interface with the request parameters `userId = 10220826` and `newPassword = "123icbc*"`. After the business code submits the request to the RPC framework, the framework's processing flow is as follows.

[0127] 1) The framework obtains the stub of the target service from the request context. The stub contains the interface definition of the target service.

[0128] 2) The framework utilizes Java's reflection mechanism to obtain unitized annotations on the service interface. In the example above, the modifyUserPassword interface has a unitized annotation ZoneIdentify, which the framework will parse and read the value of the cidParser attribute in the annotation as ParserFirstParam.class.

[0129] 3) The framework finds and loads the ParserFirstParam class from the service stub, then executes the method of this class, and parses the user ID = 10220826 from the input parameters.

[0130] 4) The framework calculates the unit number of the provider based on the customer ID. In this example, the last two digits of the user ID are 26, so the request should be sent to the provider in unit number 2. This is a capability that an RPC framework under a unitized architecture needs to possess.

[0131] 5) The framework makes a call to the provider of the target unit. In this example, it makes a call to the provider of unit 2.

[0132] Figure 11 A block diagram schematically illustrates an electronic device suitable for implementing the above-described method according to an embodiment of the present disclosure.

[0133] like Figure 11 As shown, an electronic device 900 according to an embodiment of the present disclosure includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0134] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 902 and / or RAM 903. It should be noted that the programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0135] According to embodiments of this disclosure, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0136] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0137] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0138] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods of the embodiments of this disclosure.

[0139] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0140] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0141] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0142] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0143] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0144] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0145] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A service invocation method based on a modular architecture, wherein the modular architecture includes multiple modular modules, wherein service providers and service consumers are deployed in the multiple modular modules, each service provider provides a service item, each service item has corresponding stub information, the stub information including the interface definition of the service item, characterized in that, The service invocation method is applied to the service consumer, and the method includes: Submit a service request, wherein the service request includes the item information of the target service item; Obtain the stub information of the service item corresponding to the target service item; Parse the annotation information in the interface definition of the stub information to obtain the attribute values ​​in the annotation information; Load the class corresponding to the attribute values ​​in the annotation information; Execute the methods of the class to obtain customer characteristic values, which include the user's address information; Based on the customer characteristic values, determine the unitized modules capable of providing the target service; and Initiate a call request to the unitized module that can provide the target service. The step of determining the unitized module capable of providing the target service item based on the customer characteristic value includes: Calculate the unitized module number corresponding to the address information; and The modular module capable of providing the target service item is determined based on the number.

2. The method according to claim 1, characterized in that, The information includes request parameters; The method of executing the class to obtain customer feature values ​​includes: executing the method of the class to parse the customer feature values ​​from the request parameters.

3. A service invocation device based on a modular architecture, the modular architecture comprising multiple modular modules, wherein service providers and service consumers are deployed in the multiple modular modules, each service provider provides a service item, each service item has corresponding stub information, the stub information including the interface definition of the service item, characterized in that, The device includes: The request module is used to execute a service request, wherein the service request includes the item information of the target service item; The acquisition module is used to acquire the stub information of the service item corresponding to the target service item; A parsing module is used to parse the annotation information in the interface definition of the stub information to obtain the attribute values ​​in the annotation information; The loading module is used to load the class corresponding to the attribute values ​​in the annotation information; An execution module is used to execute methods of the class to obtain customer characteristic values, including user address information. The determining module is configured to execute a unitized module that determines, based on the customer characteristic values, the ability to provide the target service item; and The calling module is used to initiate a call request to a unitized module that can provide the target service. The step of determining the unitized module capable of providing the target service item based on the customer characteristic value includes: Calculate the unitized module number corresponding to the address information; and The modular module capable of providing the target service item is determined based on the number.

4. An electronic device, characterized in that, include: One or more processors; One or more memories are provided for storing executable instructions that, when executed by the processor, implement the method according to any one of claims 1 to 2.

5. A computer-readable storage medium, characterized in that, The storage medium stores executable instructions that, when executed by a processor, implement the method according to any one of claims 1 to 2.

6. A computer program product, characterized in that, The method includes a computer program comprising one or more executable instructions that, when executed by a processor, implement the method according to any one of claims 1 to 2.

Images