A business processing method, apparatus, system, device, and storage medium

Abstract

This invention discloses a business processing method, apparatus, system, device, and storage medium. The method includes: when a page entry operation for a business to be processed is received, determining the user's processing permission for the business to be processed based on the business identifier of the business to be processed; if the user has processing permission, redirecting to the page for the business to be processed and determining user information based on a session identifier obtained from the main site, wherein the session identifier is generated by the main site when the user logs in; and processing the business to be processed based on the user information. Using this method, when developing and deploying a system using a microservice architecture, branch sites can obtain user permissions by calling the main site from the front end through the business identifier, effectively reducing the number of requests and optimizing server performance by bypassing the back end. Furthermore, when permissions are granted, customer information can be obtained through the session identifier, reducing the coupling between the main and branch sites while ensuring data consistency and communication security.

Description

Technical Field

[0001] This invention relates to the field of Web application technology, and in particular to a business processing method, apparatus, system, device, and storage medium. Background Technology

[0002] In recent years, with the continuous innovation and development of Internet technology and the diversification of user needs, only systems with rich functionality can win users' favor in the highly competitive Internet environment. As system business increases, the amount of code continues to grow, and applications gradually become bloated with high coupling between functions, limiting system performance and maintenance costs, and restricting the system's ability to add new business. Microservice architecture, as a distributed architecture solution, has emerged to address this need.

[0003] In existing technologies, a master-slave site model is used in microservice architectures. The master site stores login session information in a Redis server for session management. Session sharing is implemented between the master and slave sites, allowing all slave site microservices to access the server and retrieve session information. However, using Redis to manage meeting information requires allowing other slave site microservices to access the master site's Redis, resulting in high coupling between microservices, increased operational costs, and a failure to truly achieve master-slave site deployment. Furthermore, for access control, slave site backends frequently need to call the menu permission query interface provided by the master site to check if customers have menu permissions for slave sites. Frequent data interaction between the master and slave sites increases server load, significantly impacting performance and increasing slave site dependency on the master site, leading to high coupling between business modules. Summary of the Invention

[0004] This invention provides a business processing method, apparatus, system, device, and storage medium that reduces the coupling between main and branch stations while ensuring communication security, while maintaining data consistency.

[0005] Firstly, this embodiment provides a business processing method applied to a sub-site in a microservice architecture, the method comprising:

[0006] When a page entry operation for a pending service is received, the user's processing authority for the pending service is determined based on the service identifier of the pending service.

[0007] If the user has processing permissions, the user is redirected to the page for the pending business and the user information is determined based on the session identifier obtained from the main site. The session identifier is generated by the main site when the user logs in.

[0008] The pending service is processed based on the user information.

[0009] Secondly, this embodiment provides a business processing device configured in a sub-site under a microservice architecture, the device comprising:

[0010] The permission determination module is used to determine the user's processing permission for the pending business based on the business identifier of the pending business when a page entry operation for the pending business is received.

[0011] The information determination module is used to redirect to the page of the business to be processed if the user has processing permissions, and determine the user information based on the session identifier obtained from the main site. The session identifier is generated by the main site when the user logs in.

[0012] The processing module is used to process the pending service based on the user information.

[0013] Thirdly, embodiments of the present invention also provide a microservice system, the system including a main site and at least one sub-site;

[0014] The main site is used to receive user login operations, generate a session identifier after the user logs in, and store the user's associated permission storage table.

[0015] The sub-site includes: an access control module, an information verification module, and a processing module; wherein...

[0016] The permission determination module is used to determine the user's processing permission for the pending business based on the business identifier of the pending business when a page entry operation for the pending business is received.

[0017] The information determination module is used to redirect to the page of the business to be processed if the user has processing permissions, and determine the user information based on the session identifier obtained from the main site. The session identifier is generated by the main site when the user logs in.

[0018] The processing module is used to process the pending service based on the user information.

[0019] Fourthly, embodiments of the present invention also provide an electronic device as a subsite in a microservice architecture, comprising:

[0020] One or more processors;

[0021] Storage device for storing one or more programs;

[0022] The one or more programs are executed by the one or more processors, such that the one or more processors are used to perform the business processing method as described in the first aspect embodiment.

[0023] Fifthly, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the business processing method as described in the first aspect embodiment.

[0024] This invention discloses a business processing method, apparatus, system, device, and storage medium. The method includes: when receiving a page entry operation for a business to be processed, determining the user's processing permission for the business to be processed based on the business identifier of the business to be processed; if the user has processing permission, redirecting to the page of the business to be processed and determining user information based on a session identifier obtained from the main site, wherein the session identifier is generated by the main site when the user logs in; and processing the business to be processed based on the user information. This technical solution, when developing and deploying a system using a microservice architecture, allows branch sites to obtain user permissions by calling the main site's interface at the front end through the business identifier, bypassing the backend. This effectively reduces the number of requests, optimizes server performance, and obtains customer information through the session identifier when permissions are granted. While maintaining data consistency, this reduces the coupling between the main and branch sites, reduces data interaction between the backends of the main and branch sites, alleviates the server burden, ensures communication security, and facilitates the expansion of system business functions.

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

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

[0027] Figure 1 This is a flowchart illustrating a business processing method provided in Embodiment 1 of the present invention;

[0028] Figure 2 This is a flowchart illustrating a business processing method provided in Embodiment 2 of the present invention;

[0029] Figure 3 This is an example diagram of a certain scenario business processing step provided in Embodiment 2 of the present invention;

[0030] Figure 4 This is a schematic diagram of the structure of a business processing device provided in Embodiment 3 of the present invention;

[0031] Figure 5This is a schematic diagram of the structure of a microservice system provided in Embodiment 4 of the present invention;

[0032] Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 5 of the present invention. Detailed Implementation

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

[0034] It should be noted that the terms "target," "original," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] Microservice architecture categorizes business functions and packages them into highly cohesive, loosely coupled modular units. Different functional modules are deployed on different servers, business data is stored in their respective databases, and each microservice is managed by a different business team, achieving team independence, technical independence, data independence, and deployment independence. However, the issue of data communication between microservices also arises. How to achieve more secure and efficient data communication between microservices, ensuring consistency between business and user data, has become a research focus for system developers.

[0036] In a microservices architecture, different teams are responsible for different functional modules of the same system. To facilitate development and maintenance, the system is divided into a main site and sub-sites for development. The main site and sub-sites are deployed independently. The main site is responsible for developing basic functions such as user login, menu control, and permission verification, while the sub-sites are responsible for specific business functions. In the main-sub-site model, the main site and sub-sites are two independent site systems. The main site provides menu entry points for the sub-sites, and customers can only access the sub-sites through the main site; they cannot provide services to customers independently.

[0037] In existing technologies, the methods for obtaining user permissions and information between main and branch sites are as follows: 1. The main site stores the session information generated during login in a Redis server for session management. 2. Session sharing is implemented between the main and branch sites, allowing all branch site microservices to access the Redis server and retrieve sessions. 3. The branch site determines the user's login status based on the session. If the user is logged in, subsequent request logic is executed. 4. The branch site's backend uses the customer information as a request parameter to call the main site's menu permission query interface. If the main site returns permission for the menu item, subsequent business logic requests from the branch site continue to be executed. 5. If the main site's menu permission query interface returns no permission, an error message is returned to the frontend, and the branch site's frontend prompts the customer that they do not have permission for the function.

[0038] Considering the use of Redis for session management, it's necessary to allow other branch site microservices to access the main site's Redis. This results in high coupling between microservices, increasing operational costs and preventing a true master-branch site deployment. Furthermore, for access control, the branch site backend needs to frequently call the menu permission query interface provided by the main site to check if customers have menu permissions for the branch site. This frequent data interaction between the main and branch sites increases the server load, significantly impacting performance and increasing the branch sites' dependence on the main site, leading to high coupling between business modules.

[0039] Example 1

[0040] Figure 1 This is a flowchart illustrating a business processing method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where data consistency between main and branch sites is achieved and the coupling between main and branch sites is reduced under a microservice architecture. The method can be executed by a business processing device, which can be implemented by hardware and / or software and is generally integrated in the branch site.

[0041] like Figure 1 As shown, the business processing method provided in this embodiment may specifically include the following steps:

[0042] S110. When a page entry operation for a pending business is received, the user's processing authority for the pending business is determined based on the business identifier of the pending business.

[0043] To more clearly describe the embodiments of the present invention, the relevant terms mentioned in this embodiment will be explained first. Microservices: Microservices are an architectural style where a large, complex software application consists of one or more microservices. Each microservice in the system can be deployed independently, and the microservices are loosely coupled, with each microservice focusing on completing only one task. Master-Subsite Pattern: In a microservice architecture, different teams are responsible for different functional modules of the same system. To facilitate development and maintenance, the system is divided into a master site and subsites for development. The master and subsites are deployed independently. The master site is responsible for developing basic functions such as user login, menu control, and permission verification, while the subsites are responsible for specific business functions. In the master-subsite pattern, the master site and subsites are two independent site systems. The master site provides menu entry points for the subsites, and customers can only access the subsites through the master site and cannot provide services independently. Session: In computers, especially in network applications, this is called "session control." A session object stores the attributes and configuration information required for a specific user session. Thus, when a user navigates between WorldWideWeb (Web) pages of the application, the variables stored in the session object will not be lost but will persist throughout the entire user session. When a user requests a web page from the application, the web server automatically creates a session object if the user does not already have one. The server terminates the session when it expires or is discarded. Axios: A promise-based network request library that wraps the native XHR request (a type of browser request) and can be used in browsers and the Node.js runtime environment. JSAPI: A set of predefined JavaScript functions designed to provide applications and developers with the ability to access a set of programs based on certain software or hardware without needing to access the source code or understand the internal workings. The JSAPIs mentioned in this solution are encapsulated in the client-side app by the main site. When the sub-sites run within the main site app, they can access these JSAPIs.

[0044] It's important to understand that the microservice architecture described in this embodiment can be implemented using devices such as mobile phones and computers. In this embodiment, the main site is the application (APP) client, serving as the entry point for all sub-site microservices and responsible for basic functions such as user login, menu control, and permission verification. Sub-sites are business applications, such as H5 (HTML5 is a language for building web content) applications. Sub-sites run on the main site client and perform specific business functions. The application scenario of this embodiment can be understood as follows: when a user has business processing needs, the user needs to log in through the main site client first; if the user wants to perform specific business processing, they need to click the corresponding business menu to jump to the sub-site page to perform the specific business operation. For example, users can log in using an account and password or a mobile phone verification code; no specific restrictions are made here.

[0045] In this context, the page entry operation can be understood as a user clicking with a touch object to access a specific service within a sub-site. The sub-site is the executing entity of the service processing method provided in this embodiment. When it receives a page entry operation for a service to be processed, the sub-site needs to determine the user's processing permissions for the service based on its service identifier, thus determining whether the user has permission to access the sub-site page for service processing. The service identifier is a unique identifier for each type of functional service. The sub-site and the main site agree on a unique service identifier for each functional service; this can also be understood as the service identifier for each type of functional service being determined and known during service construction.

[0046] In the existing technology, the backend of the sub-site needs to frequently call the menu permission query interface provided by the main site to query whether the customer has menu permissions for the sub-site. The frequent data interaction between the main and sub-sites increases the server load, significantly affects the performance of the main and sub-sites, and increases the sub-site's dependence on the main site, resulting in high coupling between business modules.

[0047] In this embodiment, the sub-site frontend calls the main site's interface to obtain the user's corresponding business permissions. It's important to understand that when a user logs in on the main site, the main site stores the user's permissions for all function menus across the entire system in a key-value pair format in the main site's client cache. For example, assuming the business identifier is `buscode`, having permission can be recorded as `buscode-true`, and not having permission can be recorded as `buscode-false`.

[0048] Specifically, when a user clicks on a sub-site menu (i.e., when a page entry operation is received), the sub-site frontend calls the first interface provided by the main site, namely the JSAPI1 function, to obtain the user's permissions for the pending business. For example, determining whether a user has permission to process a pending business could be done as follows: the sub-site frontend calls the main site's first interface to obtain the permission storage table stored by the main site; the permission storage table is queried to determine the key-value pair corresponding to the business identifier; based on the key-value pair, the user's processing permissions for the pending business are determined. For example, if the pending business identifier is "buscode" and the key-value pair "buscode-true" is found, then the user has permission to process the pending business. Conversely, if the pending business identifier is "buscode" and the key-value pair "buscode-false" is found, then the user does not have permission to process the pending business.

[0049] S120. If the user has processing permissions, redirect to the page for the pending business and determine the user information based on the session identifier obtained from the main site.

[0050] The session identifier is generated by the main site when a user logs in. The main site generates a session identifier, which is a randomly generated string used to identify the customer, and it changes every 2 minutes.

[0051] In this embodiment, if it is determined that the user has processing permissions, access to the page corresponding to the sub-site is permitted. To perform business processing, user information needs to be obtained. In this embodiment, user information is obtained through a session identifier. A filter is used in the sub-site backend to uniformly filter requests from users who are not logged in. For logged-in requests, the main site's information query interface is called to obtain customer information, which is then stored in the session information. This ensures that request parameters do not involve sensitive user information, reduces the risk of data tampering, and guarantees more secure and reliable request transmission. For users who are already logged in and make business requests again, user information can be directly obtained from the sub-site's session information.

[0052] In this embodiment, when a customer logs in and enters the sub-site page for the first time, triggering an initialization request, the sub-site frontend calls the main site's interface to obtain the session identifier. After obtaining the session identifier, the session identifier and request parameters are transmitted to the sub-site backend via a business request. The sub-site backend defines a filter to filter out unlogged-in users. The session identifier is used to call the login customer information query interface exposed by the main site to the sub-site to obtain the current customer information, which is then stored in the sub-site for subsequent transactions. In this embodiment, when the customer logs in again and enters the sub-site page, user information can be directly obtained from the session information.

[0053] The filter is a Java class that implements the special interface Filter. It filters requested resources (JSP, servlet, HTML), performs some processing, and then hands them over to a small service program or service connector servlet for further processing. It is commonly used for login permission verification, filtering sensitive characters, etc. Through the filter, business requests arriving at the server are processed uniformly, and requests from unauthenticated users are filtered out.

[0054] The Filter class defines three methods: `init()`: This method is called when the container starts and initializes the filter. `doFilter()`: This method is called for every request made within the container. `destroy()`: This method is called when the container destroys the filter instance. This embodiment primarily uses the `doFilter()` method. It's important to note that in this embodiment, the filter is replaced by a Java interceptor, which intercepts requests before the controller is executed, determining login status and retrieving customer information.

[0055] Specifically, when a customer enters the subsite page for the first time after logging in and triggers an initialization request, the frontend obtains the session identifier through the user session acquisition interface and sends it to the subsite backend through a business request. The subsite backend uses the filter interface and overrides the doFilter() method to filter requests from customers who are not logged in by using the session identifier. For requests from customers who are logged in, it calls the query customer information interface provided by the main site and stores the customer information in the subsite session information for use by the subsite in subsequent business processing.

[0056] S130. Process the pending business based on the user information.

[0057] Specifically, based on user information, the pending business is processed, such as querying data from the past month.

[0058] This invention discloses a business processing method, apparatus, system, device, and storage medium. The method includes: when a page entry operation for a business to be processed is received, determining the user's processing permission for the business to be processed based on the business identifier of the business to be processed; if the user has processing permission, redirecting to the page for the business to be processed and determining user information based on a session identifier obtained from the main site, the session identifier being generated by the main site when the user logs in; and processing the business to be processed based on the user information. Using this method, when developing and deploying a system using a microservice architecture, branch sites can obtain user permissions by calling the main site's interface from the front end through the business identifier, bypassing the backend. This effectively reduces the number of requests, optimizes server performance, and, when permissions are granted, obtains customer information through the session identifier, ensuring that request parameters do not involve sensitive user information, reducing the risk of data tampering, and ensuring more secure and reliable request transmission. While achieving data consistency, it reduces the coupling between the main and branch sites, reduces data interaction between the backends of the main and branch sites, lightens the server load, ensures communication security, and facilitates the expansion of system business functions.

[0059] As an optional embodiment of the present invention, based on the above embodiments, the method is further limited to: if the user does not have processing permission, then no page redirection is performed and a permission-unauthorized prompt message is generated.

[0060] Specifically, if it is determined that a user lacks the necessary permissions to process the requested service, the user cannot be redirected to the corresponding page on the subsite. In this case, a permission denied message is generated to inform the logged-in user that they lack the necessary permissions to process the requested service. For example, the logic for obtaining user permissions can be represented as follows:

[0061] Letauth = awaitgetAuthMenu(buscode); / / Call the main site's JSAPI to obtain menu permissions

[0062] If (auth){

[0063] this.$router.push({path:' / path1'});

[0064] }else{

[0065] this.$toast("Permission denied");

[0066] }

[0067] In this optional embodiment, the sub-site frontend calls the main site's encapsulated interface for obtaining customer permissions via a business identifier. This retrieves the user's permissions for the sub-site menu, preventing unauthorized users from accessing the sub-site's business pages and generating a permission denied message. Sub-site customer permissions are obtained directly from the frontend interface via the permission identifier, bypassing the backend, effectively reducing the number of requests, optimizing server performance, and decreasing the coupling between the main and sub-sites.

[0068] Example 2

[0069] Figure 2 This is a flowchart illustrating a business processing method according to Embodiment 2 of the present invention. This embodiment is a further optimization of the above embodiment. In this embodiment, when a page entry operation for a business to be processed is received, determining the user's processing permission for the business to be processed based on the business identifier of the business to be processed is further specified as follows: When a page entry operation for a business to be processed is received, the first interface of the main site is called through the sub-site front-end to obtain the permission storage table, wherein the permission storage table contains the binding relationship between the user and various business processing permissions, and the permission storage table is stored by the main site when the user logs in on the main site; the permission storage table is queried to determine the key value corresponding to the business identifier; and the user's processing permission for the business to be processed is determined based on the key value.

[0070] Furthermore, the process of obtaining user information based on the session identifier obtained from the main site is further specified as follows: The session identifier is obtained by calling the second interface of the main site through the sub-site frontend; a business request is generated and sent to the sub-site backend based on the session identifier and request parameters; the business request is parsed through the filter of the sub-site backend to obtain the session identifier; if the session identifier is empty, the user information is determined based on the login identifier in the sub-site's session information; if the session identifier is not empty, the user information is obtained by calling the third interface of the main site through the sub-site backend.

[0071] like Figure 2 As shown, this second embodiment provides a business processing method, which specifically includes the following steps:

[0072] S210. When a page entry operation for a pending business is received, the permission storage table is obtained by calling the first interface of the main site through the sub-site front-end.

[0073] The permission storage table contains the binding relationships between users and various business processing permissions. This table is stored by the main site when a user logs in. In this embodiment, the sub-site frontend calls the main site's interface to obtain the user's corresponding business permissions. It's important to understand that when a user logs in to the main site, the main site stores the user's permissions for all function menus across the entire system in a key-value pair format in the main site's client cache. For example, assuming the business identifier is `buscode`, having permission can be recorded as `buscode-true`, and not having permission can be recorded as `buscode-false`.

[0074] Specifically, when a user clicks on a sub-site menu, i.e. when a page entry operation is received, the sub-site front-end calls the first interface provided by the main site, namely the JSAPI1 function, to obtain the permission storage table.

[0075] S220. Query the permission storage table to determine the key value corresponding to the business identifier.

[0076] Specifically, query the permission storage table to determine the key value corresponding to the business identifier.

[0077] S230. Determine the user's processing permissions for the pending business based on the key value.

[0078] For example, if the identifier of the service to be processed is buscode, and the key-value pair found is buscode-true, then it is determined that the user has the permission to process the service to be processed. If the identifier of the service to be processed is buscode, and the key-value pair found is buscode-false, then it is determined that the user does not have the permission to process the service to be processed.

[0079] S240. If the user has processing permissions, the user will be redirected to the page for the pending business and the session identifier will be obtained by calling the second interface of the main site through the sub-site front-end.

[0080] When a user logs in, the main site generates a session identifier, which is a randomly generated string used to identify the customer. This identifier changes at set time intervals, such as every 2 minutes. If the user has processing permissions, they can be redirected to the corresponding page on the sub-site, i.e., the page for the business to be processed. The sub-site frontend obtains the logged-in user's session identifier by calling a second interface provided by the main site client. This second interface can be represented as JSAPI2.

[0081] S250: Generate a business request based on the session identifier and request parameters and send it to the backend of the sub-site.

[0082] Specifically, subsites can configure information related to business requests, such as request timeout, backend address, and message type. The parameters of the business request include not only the subsite's own request parameters but also a session identifier. The generated business request is then sent to the subsite's backend. The subsite frontend initiates requests to the backend via axios (a web data interaction method) and receives data returned from the backend.

[0083] For example, the logic for setting business request parameters can be represented as follows:

[0084] Constservice = axios.create({

[0085] timeout: 30000, / / Request timeout period

[0086] withCredentials:true, / / The frontend request message carries cookies

[0087] baseURL:'10.10.10.10 / itsmb', / / Request path

[0088] headers:{

[0089] "Content-Type":"application / json",

[0090] }

[0091] }).

[0092] For example, a business request is sent to the backend of a subsite, where the request parameters include the parameters of the subsite's business request and the session identifier. The logic can be expressed as follows:

[0093]

[0094] S260. The business requests are parsed through the filters in the backend of the sub-site to obtain the session identifier.

[0095] Specifically, a filter is defined in the backend of the subsite. All requests initiated by the frontend will pass through this filter. The instance constructor's `init` method can be overridden to retrieve configuration parameters. The `doFilter` method is also overridden to parse lightweight data exchange format (JavaScriptObjectNotation, JSON) data and obtain the session identifier to determine the login status. For example, the logic for parsing business requests through the subsite backend filter can be represented as follows:

[0096]

[0097] S270. If the session identifier is empty, the user information is determined based on the login identifier in the session information of the sub-site.

[0098] Specifically, if the session identifier is empty, it means that this is not the user's first request for subsite data after logging in. For example, if the user performs business processing and then performs a data query after logging in, the business processing can be understood as the first request for subsite data, and the data query can be understood as a second request for subsite data. If the session identifier is empty, the user information needs to be further determined based on the login identifier in the subsite's session information.

[0099] Furthermore, the steps to determine user information based on the login identifier in the session information of the sub-site can be described as follows:

[0100] a1. Obtain the login identifier from the session information of the sub-site.

[0101] Specifically, if the session identifier is empty, the user's login identifier is stored in the session information, and the login identifier is retrieved from the session information. For example, assume the session identifier is denoted as ssi and the login identifier is denoted as isLogin.

[0102] b1. Determine if the login identifier is true.

[0103] Specifically, it checks if the login identifier is true. Continuing with the example above, this means either isLogin equal to true or isLogin equal to null.

[0104] c1. If true, then retrieve user information from the session information.

[0105] Specifically, if the login identifier is true, it means the user has completed logging in, and the user information is retrieved from the session information of the subsite. For example, continuing from the above example, if ssi is empty and isLogin equals true, it means the user has completed logging in, and the user information is retrieved from the session.

[0106] d1. Otherwise, confirm that the user is not logged in and return a "not logged in" message.

[0107] Specifically, if the login identifier is false, it means that the user is not logged in, which can also be understood as the login information being invalid. In this case, the filter on the backend of the subsite will filter out this part of the request and directly return an error message.

[0108] Furthermore, after obtaining user information by calling the third interface of the main site through the backend of the sub-site, the process also includes: storing the user information in the session information of the sub-site, and setting the login identifier in the session information to true.

[0109] Specifically, when a user accesses subsite data for the first time, after retrieving user information through the subsite's backend calling the main site's third-party interface, the user information is stored in the subsite's session information. This allows the user to directly retrieve their information from the subsite's session information for subsequent business operations, avoiding frequent requests to the main site and improving server performance. Additionally, the login flag in the session information is set to true, indicating that the user has successfully logged in.

[0110] For example, the logic for obtaining user information based on the session identifier can be represented as follows:

[0111]

[0112] S280. If the session identifier is not empty, the user information is obtained by calling the third interface of the main site through the backend of the sub-site.

[0113] Specifically, if the session identifier has a non-empty value, it indicates that this is the user's first request for data from a sub-site after logging in. In this case, the sub-site calls the interface provided by the main site to obtain the logged-in user's information. In this embodiment, for ease of distinction, the interface for obtaining user information is referred to as the third interface.

[0114] S290. Process the pending business based on the user information.

[0115] This embodiment details the steps for determining a user's processing authority for a pending business based on its business identifier, and for obtaining user information based on a session identifier obtained from the main site. When a system is developed and deployed using a microservice architecture, user permissions at different sites are obtained by calling interface functions on the front end using the business identifier, bypassing the backend. This effectively reduces the number of requests, optimizes server performance, and reduces the coupling between the main and branch sites. User login information is obtained through a session identifier. A filter is used on the backend of each branch site to uniformly filter out requests from unlogged-in users. For logged-in requests, the user information is stored in the session information after calling the main site's information query interface. This ensures that request parameters do not involve sensitive user information, reduces the risk of data tampering, and guarantees greater security and reliability during request transmission. By using business identifiers and session identifiers, while maintaining data consistency between the main and branch sites in the microservice architecture, data interaction between the backends of the main and branch sites is reduced, alleviating server load, reducing coupling, and facilitating system expansion of business functions.

[0116] To more clearly illustrate the business processing method provided in the embodiments of the present invention, by way of example, Figure 3 This is an example diagram of a certain scenario business processing steps provided in Embodiment 2 of the present invention.

[0117] S1. When a page entry operation for a pending business is received, the first interface of the main site is called through the sub-site front-end to obtain the permission storage table. The permission storage table contains the binding relationship between the user and various business processing permissions. The permission storage table is stored by the main site when the user logs in.

[0118] S2. Query the permission storage table to determine the key value corresponding to the business identifier.

[0119] S3. Determine the user's processing permissions for the business to be processed based on the key value. If the user does not have processing permissions, proceed to step S4. If the user has processing permissions, proceed to step S5.

[0120] S4. If the user does not have permission to process the request, the page will not be redirected and a permission-invalid message will be generated.

[0121] S5. If the user has processing permissions, redirect to the page of the business to be processed and obtain the session identifier by calling the second interface of the main site through the sub-site front-end.

[0122] S6. Generate a business request based on the session identifier and request parameters and send it to the backend of the subsite.

[0123] S7. Parse the business request through the filter of the subsite backend to obtain the session identifier. If the session identifier is empty, proceed to step S8. If the session identifier is not empty, proceed to step S12.

[0124] S8. If the session identifier is empty, obtain the login identifier from the session information of the sub-site.

[0125] S9. Determine if the login identifier is true. If it is true, proceed to step S10; otherwise, proceed to step S11.

[0126] S10. If true, then obtain user information from the session information.

[0127] S11. Otherwise, confirm that the user is not logged in and return a "not logged in" message.

[0128] S12. If the session identifier is not empty, the user information is obtained by calling the third interface of the main site through the backend of the sub-site.

[0129] S13. Store user information in the session information of the sub-site and set the login identifier in the session information to true.

[0130] S14. Process the pending business based on the user information.

[0131] Example 3

[0132] Figure 4This is a schematic diagram of a business processing device provided in Embodiment 3 of the present invention. It is applicable to situations where data consistency between primary and secondary sites in a microservice architecture is achieved while reducing coupling between them. This device can be implemented in hardware and / or software. Figure 4 As shown, the device includes: an authorization determination module 31, an information determination module 32, and a processing module 33, wherein...

[0133] The permission determination module 31 is used to determine the user's processing permission for the pending business based on the business identifier of the pending business when a page entry operation for the pending business is received.

[0134] The information determination module 32 is used to redirect to the page of the business to be processed if the user has processing permissions and determine the user information based on the session identifier obtained from the main site. The session identifier is generated by the main site when the user logs in.

[0135] Processing module 33 is used to process the business to be processed based on user information.

[0136] Optionally, the device also includes a prompting module for:

[0137] If the user does not have permission to process the request, the page will not redirect and a permission denied message will be generated.

[0138] Optionally, the permission determination module 31 is used for:

[0139] When a page entry operation for pending business is received, the first interface of the main site is called through the sub-site front-end to obtain the permission storage table. The permission storage table contains the binding relationship between users and various business processing permissions. The permission storage table is stored by the main site when the user logs in.

[0140] Query the permission storage table to determine the key value corresponding to the business identifier;

[0141] Based on the key value, determine the user's processing permissions for the pending business.

[0142] Optionally, the information determination module 32 includes:

[0143] The identifier acquisition unit is used to obtain the session identifier by calling the second interface of the main site through the sub-site front-end;

[0144] The request sending unit is used to generate a business request based on the session identifier and request parameters and send it to the backend of the sub-site.

[0145] The parsing unit is used to parse business requests through the filters in the backend of the sub-site to obtain the session identifier;

[0146] The first determining unit is used to determine user information based on the login identifier in the session information of the sub-site if the session identifier is empty.

[0147] The second determining unit is used to obtain user information by calling the third interface of the main site through the backend of the sub-site if the session identifier is not empty.

[0148] Optionally, the first determining unit is specifically used for:

[0149] Obtain the login identifier from the session information of the sub-site;

[0150] Determine if the login identifier is true;

[0151] If true, then retrieve user information from the session information;

[0152] Otherwise, determine that the user is not logged in and return a "not logged in" message.

[0153] Optionally, the device further includes a storage module for:

[0154] Store user information in the session information of the sub-site, and set the login identifier in the session information to true.

[0155] The business processing apparatus provided in the embodiments of the present invention can execute the business processing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0156] Example 4

[0157] Figure 5 This is a schematic diagram of the structure of a microservice system provided in Embodiment 4 of the present invention, as shown below. Figure 5 As shown, the system includes a main site 1 and at least one branch site 2;

[0158] The main site 1 is used to receive user login operations, generate a session identifier after the user logs in, and store the user's associated permission storage table;

[0159] Subsite 2 includes: an access control module 31, an information determination module 32, and a processing module 33; among which...

[0160] The permission determination module 31 is used to determine the user's processing permission for the business to be processed based on the business identifier of the business to be processed when a page entry operation for the business to be processed is received.

[0161] The information determination module 32 is used to redirect to the page of the business to be processed if the user has processing permissions and determine the user information based on the session identifier obtained from the main site. The session identifier is generated by the main site when the user logs in.

[0162] Processing module 33 is used to process the business to be processed based on user information.

[0163] The microservice system provided in the embodiments of the present invention can execute the business processing methods provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the methods.

[0164] Example 5

[0165] Figure 6 This is a schematic diagram of an electronic device provided in Embodiment 5 of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0166] like Figure 6 As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 or a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded into the RAM 43 from storage unit 48. The RAM 43 may also store various programs and data required for the operation of the electronic device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0167] Multiple components in electronic device 40 are connected to I / O interface 45, including: input unit 746, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0168] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as business processing methods.

[0169] In some embodiments, the business processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the business processing method described above may be performed. Alternatively, in other embodiments, processor 41 may be configured to perform the business processing method by any other suitable means (e.g., by means of firmware).

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

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

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

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

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

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

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

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

Claims

1. A service processing method characterized by, The method applied to a sub-site under a micro-service architecture comprises: When a page entering operation of a to-be-processed business is received, a processing authority of the to-be-processed business of a user is determined according to a business identifier of the to-be-processed business; If the user has the processing authority, the user information is determined according to a session identifier obtained from a main site, the session identifier being generated by the main site when the user logs in the main site, and the page of the to-be-processed business is jumped to; The to-be-processed business is processed according to the user information; The user information is obtained according to the session identifier obtained from the main site, comprising: The session identifier is obtained by calling a second interface of the main site through a front end of the sub-site; A business request is generated and sent to a back end of the sub-site according to the session identifier and a request parameter; The session identifier is obtained by analyzing the business request through a filter of the back end of the sub-site; If the session identifier is empty, the user information is determined according to a login identifier in session information of the sub-site; If the session identifier is not empty, the user information is obtained by calling a third interface of the main site through the back end of the sub-site; The user information is determined according to the login identifier in the session information of the sub-site, comprising: The login identifier is obtained from the session information of the sub-site; It is judged whether the login identifier is true or not; If true, the user information is obtained from the session information; Otherwise, it is determined that the user is not logged in and a not logged in prompt is returned.

2. The method of claim 1, wherein, Further comprising: If the user has no processing authority, no page jump is performed and a no authority prompt information is generated.

3. The method of claim 1, wherein, When the page entering operation of the to-be-processed business is received, the processing authority of the to-be-processed business of the user is determined according to the business identifier of the to-be-processed business, comprising: When the page entering operation of the to-be-processed business is received, a permission storage table is obtained by calling a first interface of the main site through a front end of the sub-site, wherein the permission storage table contains a binding relationship between the user and each type of business processing authority, and the permission storage table is stored by the main site when the user logs in the main site; The permission storage table is queried to determine a key value corresponding to the business identifier; The processing authority of the to-be-processed business of the user is determined according to the key value.

4. The method of claim 1, wherein, After the user information is obtained by calling the third interface of the main site through the back end of the sub-site, further comprising: The user information is stored in the session information of the sub-site, and a login identifier in the session information is set to true.

5. A service processing apparatus characterized by comprising: The device is configured in a sub-site under a micro-service architecture, comprising: A permission determination module is configured to determine a processing authority of a to-be-processed business of a user according to a business identifier of the to-be-processed business when a page entering operation of the to-be-processed business is received; An information determination module is configured to jump to the page of the to-be-processed business and determine user information according to a session identifier obtained from a main site if the user has the processing authority, the session identifier being generated by the main site when the user logs in the main site; A processing module is configured to process the to-be-processed business according to the user information; The information determination module comprises: An identifier obtaining unit is configured to obtain a session identifier by calling a second interface of the main site through a front end of the sub-site; A request sending unit is configured to generate a service request according to the session identifier and request parameters and send the service request to a back end of the sub-site; An analysis unit is configured to analyze the service request by a filter of the back end of the sub-site to obtain a session identifier; A first determination unit is configured to determine user information according to a login identifier in session information of the sub-site if the session identifier is empty; A second determination unit is configured to obtain user information by calling a third interface of the main site through the back end of the sub-site if the session identifier is not empty; The first determination unit is specifically configured to: obtain a login identifier from the session information of the sub-site; determine whether the login identifier is true; if the login identifier is true, obtain user information from the session information; otherwise, determine that the user is not logged in and return a not logged in prompt.

6. A microservice system, characterized by The system comprises a main site and at least one sub-site; The main site is configured to receive a login operation of a user, generate a session identifier after the user logs in, and store a permission storage table associated with the user; The sub-site comprises a permission determination module, an information determination module, and a processing module; wherein The permission determination module is configured to determine a processing permission of a user for a to-be-processed service according to a service identifier of the to-be-processed service when receiving a page entering operation of the to-be-processed service; The information determination module is configured to jump to a page of the to-be-processed service and determine user information according to a session identifier obtained from the main site if the user has the processing permission, the session identifier being generated by the main site when the user logs in the main site; The processing module is configured to process the to-be-processed service according to the user information; The information determination module comprises: An identifier obtaining unit is configured to obtain a session identifier by calling a second interface of the main site through a front end of the sub-site; A request sending unit is configured to generate a service request according to the session identifier and request parameters and send the service request to a back end of the sub-site; An analysis unit is configured to analyze the service request by a filter of the back end of the sub-site to obtain a session identifier; A first determination unit is configured to determine user information according to a login identifier in session information of the sub-site if the session identifier is empty; A second determination unit is configured to obtain user information by calling a third interface of the main site through the back end of the sub-site if the session identifier is not empty; The first determination unit is specifically configured to: obtain a login identifier from the session information of the sub-site; determine whether the login identifier is true; if the login identifier is true, obtain user information from the session information; otherwise, determine that the user is not logged in and return a not logged in prompt.

7. An electronic device, comprising: As a sub-site under a micro-service architecture, comprising: one or more processors; a storage device configured to store one or more programs; The one or more programs are executed by the one or more processors, so that the one or more processors are configured to execute the service processing method of any one of claims 1-4.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to realize the service processing method of any one of claims 1-4.

Images