TWI839911B - System and method for invoking microservice - Google Patents

Abstract

A system and a method for invoking microservice are provided. The method includes: generating a security token by a trust-chain-element-module; and after a first microservice module runs a business logic, using the security token by the first microservice module to invoke a second microservice module via the trust-chain-element-module.

Description

System and method for invoking microservices

The present invention relates to a software system technology, and more particularly to a system and method for calling microservices.

In the Software as a Service (SaaS) environment, microservices need to face call requests from multiple users. These call requests may come from various types of users, such as web pages, mobile devices, other application services, etc. Therefore, authorization and permission authentication for the source of the call request becomes an inevitable issue.

There are many different scenarios for microservice calls. In particular, a microservice call may generate a chain operation of multiple microservices. If each microservice in the process is authorized and authenticated, there will be several times more microservice calls, resulting in performance degradation, additional resource consumption, and reduced user experience.

The present invention is directed to a system and method for calling microservices, which can reduce the number of microservice calls to improve system performance and user experience.

According to an embodiment of the present invention, the system for calling microservices of the present invention includes a storage device and a processor. The storage device stores multiple microservice modules and a trust chain component module, wherein the multiple microservice modules include a first microservice module and a second microservice module. The processor is coupled to the storage device, wherein the trust chain component module generates a security token; after the first microservice module runs the business logic, the first microservice module uses the security token to call the second microservice module via the trust chain component module.

According to an embodiment of the present invention, the method for calling a microservice of the present invention includes: generating a security token by a trust chain component module; and after the first microservice module runs the business logic, the first microservice module uses the security token to call the second microservice module via the trust chain component module.

Based on the above, the system and method for calling microservices of the present invention can use a security token to serially call subsequent microservice modules by a microservice module without the need for each microservice module to perform authorization authentication and permission authentication, thereby reducing the number of microservice calls and improving system performance and user experience.

In order to make the above features and advantages of the present invention more clearly understood, embodiments are specifically cited below and described in detail with reference to the accompanying drawings.

Reference will now be made in detail to exemplary embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numerals are used in the drawings and description to represent the same or similar parts.

FIG1 is a schematic diagram of a system 100 for invoking microservices according to an embodiment of the present invention. Referring to FIG1 , the system 100 includes a storage device 110 and a processor 120. The system 100 can be communicatively connected to a user electronic device 200. The processor 120 is coupled to the storage device 110.

In this embodiment, the storage device 110 may include a memory and/or a database, wherein the memory may be, for example, a non-volatile memory (NVM). The processor 120 may include a central processing unit (CPU), or other programmable general-purpose or special-purpose microprocessors, digital signal processors (DSP), application specific integrated circuits (ASIC), programmable logic devices (PLD), other similar processing circuits, or a combination of these devices. The storage device 110 can store relevant programs, modules, systems or algorithms useful for implementing various embodiments of the present invention, so that the processor 120 can access and execute to implement the relevant functions and operations described in various embodiments of the present invention. In this embodiment, the storage device 110 can store multiple microservice modules and a trust chain component module 112, wherein the multiple microservice modules include a first microservice module 111a, a second microservice module 111b, and a third microservice module 111c. In addition, the storage device 110 can store a service permission component module 113, a permission service module 114, and an authorization service module 115, and their functions will be described later. It should be noted that the number of microservice modules shown in Figure 1 is for illustration only, and the present invention is not limited thereto.

FIG2 is a flow chart of a method for calling microservices according to an embodiment of the present invention. Referring to FIG1 and FIG2 , the system 100 of FIG1 may execute the following steps S210 and S220. In step S210, the trust chain component module 112 may generate a security token. In step S220, after the first microservice module 111a runs the business logic, the first microservice module 111a may use the security token to call the second microservice module 111b via the trust chain component module 112. In other words, after the trust chain component module 112 generates the security token, each microservice module may use the same security token to (sequentially) call its subsequent microservice module in series. This will be further explained below.

FIG3 is a schematic diagram of a trust chain architecture of multiple microservice modules of an embodiment of the present invention. Refer to FIG1 and FIG3. In this embodiment, the first microservice module 111a can be operated based on the trust chain component module 112 and the service authority component module 113 (for example, the trust chain component module 112 and the service authority component module 113 can be implemented at the bottom layer of the first microservice module 111a), and the first microservice module 111a can include its business logic. Similarly, the second microservice module 111b may run based on the trust chain component module 112 and the service authority component module 113 (for example, the trust chain component module 112 and the service authority component module 113 may be implemented at the bottom layer of the second microservice module 111b), and the second microservice module 111b may include its business logic.

In this embodiment, the trust chain component module 112 can be used to generate and verify the security token. Specifically, after the trust chain component module 112 generates the security token, the first microservice module 111a can use the security token to (in series) call the second microservice module 111b. Subsequent microservice modules (such as the second microservice module 111b) can verify whether the security token is legitimate through the trust chain component module 112. On the other hand, the first microservice module 111a can call the permission service module 114 via the service permission component module 113, so that the permission service module 114 and the authorization service module 115 can determine whether the user electronic device 200 is legal (that is, the permission service module 114 performs user authentication, and the authorization service module 115 performs authorization authentication). After determining that the user electronic device 200 is legal, the permission service module 114 can generate a user token, and the first microservice module 111a can receive the user token from the permission service module 114 via the service permission component module 113.

FIG4 is a flow chart of the trust chain operation of multiple microservice modules of an embodiment of the present invention. Refer to FIG1, FIG3 and FIG4. In step S401, the user electronic device 200 can send a microservice call request (remote call) to the first microservice module 111a. In step S402, the first microservice module 111a can receive the microservice call request of the first microservice module 111a from the user electronic device 200, and confirm that there is no user token and no security token in the microservice call request. After the first microservice module 111a confirms that there is no user token and no security token in the microservice call request, in step S403, the first microservice module 111a can call the permission service module 114 (via the service permission component module 113) so that the permission service module 114 can determine whether the user electronic device 200 is legal (i.e., perform user authentication).

In step S404, the authorization service module 114 may perform user authentication. After the authorization service module 114 determines that the user authentication has been passed, in step S405, the authorization service module 114 may call the authorization service module 115, so that the authorization service module 115 determines whether the user electronic device 200 is legal (i.e., performs authorization authentication). In step S406, the authorization service module 115 may perform authorization authentication.

After the authorization service module 115 determines that the authorization authentication has passed, in step S407, the permission service module 114 can receive a notification of successful authorization authentication from the authorization service module 115 and generate a user token. In step S408, the first microservice module 111a can receive the user token from the permission service module 114 via the service permission component module 113, and generate a security token via the trust chain component module 112.

In step S409, the first microservice module 111a may run its business logic and transmit a call request including a security token to the second microservice module 111b to call the second microservice module 111b.

In step S410, the second microservice module 111b may receive the call request and determine/verify whether the security token is legitimate through the trust chain component module 112. After the second microservice module 111b confirms that the security token is legitimate through the trust chain component module 112, in step S411, the second microservice module 111b may run its business logic and transmit the call request including the security token to the third microservice module 111c to call the third microservice module 111c. In step S412, the third microservice module 111c may receive the call request and determine/verify whether the security token is legitimate through the trust chain component module 112. After the third microservice module 111c confirms that the security token is legitimate through the trust chain component module 112, in step S413, the third microservice module 111c can run its business logic.

In step S414, the second microservice module 111b may receive a call response message from the third microservice module 111c and continue to complete the business logic of the second microservice module 111b. In step S415, the first microservice module 111a may receive a call response message from the second microservice module 111b and continue to complete the business logic of the second microservice module 111b. In step S416, the first microservice module 111a may transmit the microservice call response to the user electronic device 200.

It should be noted that the number of microservice modules shown in FIG4 is for illustration only. In other words, each microservice module can use the security token to call its subsequent microservice modules in series (sequentially), and only the first microservice module 111a needs to perform authorization authentication and permission authentication with the permission service module 114 and the authorization service module 115.

FIG5 is a schematic diagram of a trust chain operation scenario of multiple microservice modules of an embodiment of the present invention. Referring to FIG1 and FIG5 . The trust chain component module 112 can generate a security token and verify the security token to allow each microservice module to complete the serial microservice call. On the other hand, the permission service module 114 can perform user authentication, and then the authorization service module 115 can perform authorization authentication to allow the first microservice module 111a to complete the necessary authentication call.

FIG6 is a flow chart of generating a user token in a trust chain operation scenario according to an embodiment of the present invention. Referring to FIG1 , FIG5 and FIG6 , in step S601 , the authorization service module 114 may receive user login information from the user electronic device 200 .

In this embodiment, the permission service module 114 can store the tenant information corresponding to the user login information. In addition, the authorization service module 115 can store (legitimate) tenant information. When the permission service module 114 determines that the user login information is legitimate, and the authorization service module 115 determines that the tenant information corresponding to the user login information is legitimate, the permission service module 114 can generate a user token.

Specifically, in step S602, the authorization service module 114 may determine whether the user login information is valid (perform user authentication). When the authorization service module 114 determines that the user login information is valid, the authorization service module 114 may obtain the tenant information corresponding to the user login information stored by the authorization service module 114.

In step S603, the authority service module 114 may transmit tenant information corresponding to the user login information to the authorization service module 115. In step S604, the authorization service module 115 may determine whether the tenant information is legal (i.e., determine whether the tenant is an authorized tenant). After the authorization service module 115 determines that the authorization authentication has passed, in step S605, the authorization service module 115 may transmit an authorization authentication success notification to the authority service module 114.

In step S606 , the authorization service module 114 may generate a user token. In step S607 , the authorization service module 114 may transmit the user token to the user electronic device 200 .

FIG7 is a schematic diagram of calling the first microservice module 111a in the trust chain operation scenario of an embodiment of the present invention. Refer to FIG1, FIG5 and FIG7. It is worth noting that the difference between FIG7 and FIG6 is that, in the embodiment of FIG6, since the user has not yet obtained the user token, the user must first perform permission verification and authorization verification on the permission service module 114 and the authorization service module 115 to obtain the user token. On the other hand, in the embodiment of FIG7, since the user already has the user token, the user can use the user token to call the first microservice module 111a.

In step S701, the first microservice module 111a may receive a microservice call request of the first microservice module 111a from the user electronic device 200, wherein the microservice call request includes a user token. In step S702, the first microservice module 111a may call the permission service module 114 via the service permission component module 113 to determine whether the user token is legal. In detail, the first microservice module 111a may transmit the user token to the permission service module 114 via the service permission component module 113.

In step S703, when the authorization service module 114 determines that the user token is legitimate, the authorization service module 114 may send a successful authentication notification to the service authorization component module 113. In step S704, the first microservice module 111a may generate a security token via the trust chain component module 112.

FIG8 is a flow chart of calling the second microservice module 111b and subsequent microservice modules in the trust chain operation scenario of an embodiment of the present invention. Refer to FIG1, FIG5 and FIG8. As described in the above embodiments, the first microservice module 111a can use the security token to call the second microservice module 111b via the trust chain component module 112. Then, when the second microservice module 111b determines that the security token is legitimate via the trust chain component module 112, the second microservice module 111b can run the business logic and use the security token to call the third microservice module 111c via the trust chain component module 112.

Specifically, in step S801, the first microservice module 111a may run its business logic. In step S802, the first microservice module 111a may transmit a call request including a security token to the second microservice module 111b to call the second microservice module 111b.

In step S803, the second microservice module 111b may receive the call request and determine whether the security token is legitimate through the trust chain component module 112. After the second microservice module 111b determines that the security token is legitimate through the trust chain component module 112, the second microservice module 111b may run its business logic. In step S804, the second microservice module 111b may transmit the call request including the security token to the third microservice module 111c.

In step S805, the third microservice module 111c may receive the call request and determine whether the security token is legitimate through the trust chain component module 112. After the third microservice module 111c determines that the security token is legitimate through the trust chain component module 112, the third microservice module 111c may run its business logic.

In step S806, the third microservice module 111c can complete the business logic of the third microservice module 111c and send a call response message to the second microservice module 111b. In step S807, the second microservice module 111b can complete the business logic of the second microservice module 111b and send a call response message to the first microservice module 111a.

In one embodiment, the security token may include a tenant identification, a user identification, and an expiration date. Table 1 is an example of a security token. After the trust chain component module 112 generates the security token, the trust chain component module 112 may encrypt the security token using a key. The key may correspond to an expiration date, for example, and the trust chain component module 112 may update the key after the expiration date has expired. Table 1 (an example of a security token) Tenant Identification User Identification expiry date tenant2 user1 Service1

It is worth noting that each microservice module in this embodiment may correspond to multiple applications. For example, the first microservice module 111a may belong to a first application, the second microservice module 111b may belong to a second application, and the third microservice module 111c may belong to a third application. Further, the first application, the second application, and the third application may be the same application. Alternatively, the first application, the second application, and the third application may be different applications.

In summary, the system and method for calling microservices of the present invention can be used by a microservice module to use a security token to (sequentially) call its subsequent microservice modules in series, without the need for each microservice module to perform authorization authentication and permission authentication. In particular, only the first microservice module in the serial microservice modules needs to perform authorization authentication and permission authentication, and the subsequent microservice modules can be ensured by the security token that the user who calls the first microservice module has passed the authorization authentication and permission authentication. On this basis, additional authorization authentication and permission authentication can be avoided, and there will be no situation in which a specific microservice module cannot be successfully called due to authentication failure when calling a serial microservice module, thereby improving system performance and user experience.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technical personnel in this field should understand that they can still modify the technical solutions described in the above embodiments, or replace part or all of the technical features therein with equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention.

100: System for calling microservices 110: Storage device 111a: First microservice module 111b: Second microservice module 111c: Third microservice module 112: Trust chain component module 113: Service authority component module 114: Authority service module 115: Authorization service module 120: Processor 200: User electronic device S210~S220, S401~S416, S601~S606, S701~S704, S801~S807: Steps

Figure 1 is a schematic diagram of a system for calling microservices in an embodiment of the present invention. Figure 2 is a flow chart of a method for calling microservices in an embodiment of the present invention. Figure 3 is a schematic diagram of a trust chain architecture of multiple microservice modules in an embodiment of the present invention. Figure 4 is a flow chart of the trust chain operation of multiple microservice modules in an embodiment of the present invention. Figure 5 is a schematic diagram of a trust chain operation scenario of multiple microservice modules in an embodiment of the present invention. Figure 6 is a flow chart of generating a user token in a trust chain operation scenario in an embodiment of the present invention. Figure 7 is a schematic diagram of calling a first microservice module in a trust chain operation scenario in an embodiment of the present invention. Figure 8 is a flow chart of calling the second microservice module and subsequent microservice modules in the trust chain operation scenario of an embodiment of the present invention.

S210, S220: Step

Claims (14)

A system for calling microservices includes: a storage device storing multiple microservice modules and a trust chain component module, wherein the multiple microservice modules include a first microservice module and a second microservice module; and a processor coupled to the storage device, wherein the trust chain component module generates a security token; after the first microservice module runs the business logic, the first microservice module uses the security token to call the second microservice module via the trust chain component module, wherein the multiple microservice modules further include a third microservice module, wherein when the second microservice module determines that the security token is legal via the trust chain component module, the second microservice module runs the business logic and uses the security token to call the third microservice module via the trust chain component module. The system as described in claim 1, wherein the storage device further stores a service permission component module and a permission service module, wherein the permission service module receives user login information from a user electronic device; when the permission service module determines that the user login information is legitimate, the permission service module transmits a user token to the user electronic device. A system as described in claim 2, wherein the storage device further stores an authorization service module, wherein When the permission service module determines that the user login information is legal, and the authorization service module determines that the tenant information corresponding to the user login information is legal, the permission service module generates the user token. A system as described in claim 3, wherein the permission service module stores the tenant information corresponding to the user login information, and when the permission service module determines that the user login information is legal, the permission service module transmits the tenant information corresponding to the user login information to the authorization service module. The system as described in claim 1, wherein the storage device further stores a service permission component module and a permission service module, wherein the first microservice module receives a microservice call request of the first microservice module from a user electronic device, wherein the microservice call request includes a user token; the first microservice module calls the permission service module via the service permission component module to determine whether the user token is legal; when the permission service module determines that the user token is legal, the first microservice module generates the security token via the trust chain component module. A system as described in claim 1, wherein the security token includes a tenant identification, a user identification, and an expiration date. A system as described in claim 1, wherein the first microservice module and the second microservice module correspond to a first application and a second application respectively, wherein the first application and the second application are the same, or the first application and the second application are different. A method for calling a microservice is applicable to a system storing multiple microservice modules and a trust chain component module, wherein the multiple microservice modules include a first microservice module and a second microservice module, wherein the method includes: generating a security token by the trust chain component module; and after the first microservice module runs the business logic, the first microservice module uses the security token to call the second microservice module via the trust chain component module, wherein the multiple microservice modules further include a third microservice module, wherein the method further includes: when the second microservice module determines that the security token is legitimate via the trust chain component module, the second microservice module runs the business logic and uses the security token to call the third microservice module via the trust chain component module. As described in claim 8, the system further stores a service permission component module and a permission service module, wherein the method further includes: the permission service module receives user login information from a user electronic device; when the permission service module determines that the user login information is legitimate, the permission service module transmits a user token to the user electronic device. As described in claim 9, the system further stores an authorization service module, wherein the method further includes: When the permission service module determines that the user login information is legal, and the authorization service module determines that the tenant information corresponding to the user login information is legal, the permission service module generates the user token. The method of claim 10, wherein the permission service module stores the tenant information corresponding to the user login information, wherein the method further comprises: when the permission service module determines that the user login information is legal, the permission service module transmits the tenant information corresponding to the user login information to the authorization service module. As described in claim 8, the system further stores a service permission component module and a permission service module, wherein the method further comprises: the first microservice module receives a microservice call request of the first microservice module from a user electronic device, wherein the microservice call request includes a user token; the first microservice module calls the permission service module via the service permission component module to determine whether the user token is legal; when the permission service module determines that the user token is legal, the first microservice module generates the security token via the trust chain component module. A method as claimed in claim 8, wherein the security token includes a tenant identification, a user identification, and an expiration date. The method of claim 8, wherein the first microservice module and the second microservice module correspond to a first application and a second application, respectively, wherein the first application and the second application are the same, or the first application and the second application are different.

Images