Gateway identification injection-based micro-service unified access and global governance method

Abstract

The application discloses a kind of gateway identification injection-based microservice unified access and global governance method, the method includes: gateway layer receives client request and is forwarded to target microservice, and injects environment identification to return response;Client extracts environment identification to determine gateway mode or direct connection mode, calls preset interface to obtain service port number and gateway prefix, and dynamically generates the request access address matched with current access mode;After successful access, client and target microservice are based on target context path Session connection and hierarchical cache are established, wherein session identification path and target context path are forcedly bound, and cache namespace is consistent with target context path.The application realizes seamless dynamic adaptation in multiple environments, completely eliminates address hard coding, and simultaneously solves session conflict and cache coverage problems under the deployment of multiple services in the same domain.

Description

Technical Field

[0001] This invention relates to the fields of microservice architecture management, API gateway traffic scheduling, and cloud-native service governance, specifically to a method for unified access and global governance of microservices based on gateway identifier injection. Background Technology

[0002] Currently, microservice architecture has become the mainstream architecture for enterprise-level business system development and deployment. Enterprise business is typically broken down into multiple independent front-end applications and back-end microservices, such as business services, algorithm services, data services, and file services. Each service needs to provide external access capabilities to achieve business collaboration. In the traditional deployment model, each microservice needs to be allocated an independent network port, and clients directly call the service interface through IP address plus port number or scattered subpaths. When the number of services is small, this model can meet basic needs, but as business continues to iterate and the number of services continues to increase, problems such as chaotic port management, complex access paths, and expanded security attack surfaces become increasingly prominent.

[0003] As a core component of traffic entry points in microservice architectures, API gateways are gradually becoming a key technical means to solve the aforementioned service access problems. Among numerous gateway products, APISIX, with its high-performance processing capabilities based on OpenResty, pluggable extension mechanism, lightweight deployment method, and dynamic routing features, has become a preferred gateway solution for cloud-native microservice architectures. However, current industry applications of APISIX mainly focus on basic traffic forwarding or single-dimensional gateway construction. Although some solutions have achieved visual configuration and construction of gateways, reducing the technical threshold for gateway deployment to some extent, these solutions have not formed an integrated and standardized implementation solution for the full-link requirements of enterprise-level microservice architectures in areas such as unified access, cross-service isolation, multi-environment adaptation, and comprehensive traffic governance. This has resulted in the core governance capabilities of APISIX not being fully utilized, and the management costs and security risks of multi-service architectures remaining high.

[0004] Based on the existing publicly available technical solutions, they can be roughly categorized into the following three types.

[0005] The first type is the multi-port direct access solution. In this solution, each microservice is deployed independently and listens on different public network ports. Clients directly call the corresponding service interface via IP address and port number. There is no gateway layer in the entire system for traffic forwarding and management. Although this solution eliminates the need for any gateway configuration costs, it is essentially a gateway-less mode. In actual operation, it exposes many problems such as limited port resources, complex client configuration, and a large security attack surface. It is usually only suitable for small systems with a very small number of services.

[0006] The second type is the simple gateway proxy forwarding solution. This solution introduces gateway components such as APISIX and Nginx as a unified traffic entry point, and implements gateway-layer forwarding for multiple services by configuring basic path matching rules or port routing rules. However, this solution does not isolate session information, browser caching, and login status for each service, nor does it integrate necessary governance capabilities such as traffic control and log monitoring. When multiple services share the same gateway entry point, problems such as cross-service pollution, difficulty in fault location, and lack of effective traffic control are highly likely to occur.

[0007] The third category is the visual configuration gateway construction solution. This solution obtains gateway parameters through a pre-designed configuration webpage, completing the configuration of the etcd storage module, API communication module, and Nginx coordination module. This enables rapid gateway construction and dynamic route updates, lowering the technical threshold for gateway setup to some extent. However, this solution only focuses on the deployment and basic forwarding functions of the gateway components themselves, without addressing core enterprise-level requirements such as isolation mechanisms for multi-service access, multi-environment adaptation strategies, and service governance. Therefore, it cannot effectively solve the end-to-end management problem under a multi-microservice architecture.

[0008] In summary, the three solutions mentioned above only address a single dimension of the problem in microservice access or gateway construction. None of them form a complete solution that covers the entire process from unified access to security isolation, environment adaptation, and ultimately, comprehensive governance. Therefore, they cannot meet the actual needs of enterprise-level microservice architectures in terms of standardized, regulated, and intelligent operation.

[0009] Further analysis of existing technical solutions reveals the following main shortcomings in their implementation.

[0010] Regarding service access, existing solutions lack a unified standard. In the multi-port direct connection mode, front-end applications need to configure different API base addresses and port numbers for different back-end services, resulting in numerous configuration items and high maintenance costs. Once the port of a service changes, the relevant configurations of all calling clients need to be modified synchronously. In practice, it is very easy to miss or make incorrect modifications, which can lead to service call failures.

[0011] Regarding cross-service isolation, existing solutions suffer from severe deficiencies in isolation mechanisms, directly impacting system stability. In simple gateway proxy schemes, multiple services share the same gateway entry point, but there is no isolation design for Session Cookies and frontend local storage. This easily leads to cross-service session pollution, such as a user's login state from service A being incorrectly reused by service B, and the mutual overwriting of cached data, such as different services using the same storage key name leading to accidental data modification, ultimately causing service malfunctions and harming the user experience.

[0012] In terms of multi-environment adaptation, existing solutions lack flexibility, leading to low development and testing efficiency. Currently, no solution can dynamically adapt between direct connection mode in development and testing environments and gateway mode in production environments. Service access addresses are typically hard-coded in the project code. When an environment switch is required, developers must manually modify the address constants in the code and recompile and deploy the entire application. This approach not only severely reduces development and testing efficiency but also easily leads to distorted test results due to incorrect environment configuration parameters.

[0013] In terms of security protection, existing solutions are relatively weak, and the attack surface continues to expand. A large number of backend service ports are directly exposed outside of public firewalls, making them easy targets for port scanning, brute-force attacks, and malicious requests. Due to the lack of a unified traffic control entry point, it is impossible to centrally identify and block malicious requests, and the openness of multiple ports further increases the vulnerability risks in network management.

[0014] Regarding gateway functionality, existing solutions generally offer limited features and lack comprehensive service governance capabilities. Most existing APISIX application solutions remain at the basic traffic forwarding level, failing to integrate core governance capabilities such as authentication and authorization, traffic limiting, circuit breaking and degradation, and log monitoring. When a service malfunctions, operations personnel struggle to quickly pinpoint the root cause, and in the event of sudden traffic surges, the system is prone to service avalanche due to the lack of protection mechanisms, severely impacting overall stability.

[0015] In terms of operation and maintenance management, existing solutions are costly and have unsatisfactory resource utilization. Whenever a new service needs to be added, operations personnel must sequentially complete a series of operations, including port application, firewall rule opening, network configuration adjustments, and client adaptation, which undoubtedly increases the workload of operations and development personnel. At the same time, multiple ports listening independently consume significant server network resources, while ports for some low-traffic services remain idle for extended periods, resulting in substantial resource waste.

[0016] In terms of architectural scalability, the existing solution is inadequate, resulting in low efficiency in integrating new services. Due to the lack of a unified service integration standard, adding new services requires customized configurations for the gateway, front-end application, and back-end service. Different developers often use different configuration methods, leading to a gradually chaotic overall architecture. Furthermore, the gateway layer lacks standardized extension interfaces, necessitating large-scale modifications to the existing configuration when integrating new governance capabilities, impacting the system's normal operation.

[0017] In terms of front-end and back-end collaboration, existing solutions are difficult to adapt and have high cross-team communication costs. Due to the lack of standardized front-end and back-end request path specifications, front-end and back-end developers need to repeatedly confirm addresses and path prefixes when interface integration, a time-consuming and laborious process. At the same time, front-end caching and session management also lack unified operating standards. These factors combined lead to low efficiency in front-end and back-end collaborative development and are prone to functional failures due to adaptation issues.

[0018] In summary, existing technical solutions for unified access and governance of microservice architectures fail to simultaneously address the issues of session and cache isolation between multiple services, as well as dynamic adaptation across multiple environments. When multiple services coexist under a single gateway entry point, cross-service session pollution and cache data overwriting frequently occur. Furthermore, switching between development, testing, and production environments still relies on manual code modifications, which is inefficient and prone to errors. Therefore, there is an urgent need in this field for a unified access and global governance method for microservices that can drive clients to adaptively complete environment identification and request address concatenation through dynamic identifier injection at the gateway layer, while simultaneously implementing strict isolation of sessions and caches across multiple services. Summary of the Invention

[0019] The purpose of this invention is to provide a unified access and global governance method for microservices based on gateway identifier injection. This addresses the problems of cross-service session pollution and data overwriting caused by the lack of session and cache isolation mechanisms when multiple microservices share the same gateway entry point. It also resolves the issues of inefficiency and error-proneness caused by hard-coded service access addresses, which necessitate manual code modification for multi-environment switching. Furthermore, it eliminates the technical shortcomings of traditional methods, such as chaotic port management and expanded security attack surfaces. This invention dynamically injects environment identifier information into the client response at the gateway layer, driving the client to adaptively identify the current operating environment and dynamically concatenate the request address. Simultaneously, by implementing path binding and independent naming for the session identifiers of each microservice and namespace-based hierarchical isolation for the front-end cache, it achieves unified standardized access for multiple microservices, cross-service secure isolation, and seamless dynamic adaptation to multiple environments without modifying the business code. This aims to comprehensively improve the operational efficiency and system stability of enterprise-level distributed microservice architectures.

[0020] To achieve the above objectives, this invention provides a method for unified access and global governance of microservices based on gateway identifier injection, the method comprising: The gateway layer receives access requests for a target microservice initiated by a client and forwards the access requests to the corresponding target microservice according to preset routing rules. The gateway layer intercepts the response returned by the target microservice to the client and dynamically injects an environment identifier into the response header. The client intercepts the response and extracts the environment identifier, and determines the current access mode as gateway mode or direct connection mode based on the environment identifier; The client obtains the service port number and gateway prefix of the target microservice by calling a preset interface, and dynamically generates a request access address that matches the current access mode according to the determined access mode. Specifically, when the gateway mode is confirmed, the request access address is generated by concatenating the obtained gateway prefix; when the direct connection mode is confirmed, the request access address is generated by concatenating the obtained service port number. After the access is executed, the client and the target microservice establish independent session connections and hierarchically isolated local data caches based on the target context path, wherein the target context path is consistent with the gateway prefix when the gateway layer routes the target microservice.

[0021] Furthermore, the preset routing rules adopt either path prefix routing based on Uniform Resource Locators or wildcard domain name resolution routing. Specifically, a strictly corresponding standard mapping relationship is established among the base address of the client initiating the request, the gateway prefix of the gateway layer, and the target context path of the target microservice backend.

[0022] Furthermore, the requested access address is a single sign-on redirect address; The client dynamically generates a request access address that matches the current access mode. Specifically, when the access mode is confirmed to be the gateway mode, the client generates the single sign-on redirect address by concatenating the obtained gateway prefix and performs redirection; when the access mode is confirmed to be the direct connection mode, the client generates the single sign-on redirect address by concatenating the obtained service port number and performs redirection.

[0023] Furthermore, establishing independent session connections between the client and the target microservice based on the target context path includes: The path attribute of the session cookie of the target microservice is forcibly bound to the target context path, so that the browser carries the corresponding session cookie only when the target context path is matched; Furthermore, a unique string containing microservice name information is used to configure an independent cookie name for the session cookie to prevent session conflicts when multiple services are deployed in the same domain.

[0024] Furthermore, establish a hierarchical and isolated local data cache, including: When establishing the hierarchical isolated local data cache in the client's local storage, a concatenated character structure containing namespace identifiers and key identifiers is used to manage the cached data hierarchically. Each microservice's dedicated namespace identifier is strictly consistent with the target context path corresponding to that microservice, in order to achieve physical isolation of dedicated data.

[0025] Furthermore, the method also includes performing nested isolation on the interface paths of the target microservice: Configure a three-level nested interface path for the target microservice. The three-level nested interface path includes, in sequence, the service prefix as the first level, the interface module as the second level, and the interface name as the third level. The service prefix, which serves as the first level, is the same as the target context path.

[0026] Furthermore, the method also includes global governance based on a gateway plug-in mechanism: The gateway layer invokes a preset set of governance plugins, which includes at least runtime plugins for security protection, traffic control, circuit breaking and degradation, and log monitoring. Based on a layered configuration system with three granularities—global, service, and interface—dynamic parameter distribution and lifecycle management are implemented for the plugins in the governance plugin set.

[0027] Furthermore, the service port number, target context path, and independent cookie name of the target microservice are all dynamically configured through environment variables to decouple the configuration information from the microservice business code.

[0028] Furthermore, in addition to being injected into the response header, the environment identifier is also transmitted via a Uniform Resource Locator parameter or a client-side cookie to adapt to third-party client call scenarios where custom response headers cannot be parsed.

[0029] Furthermore, the method also includes alternative routing and rewriting mechanisms: When using request header matching for routing, the gateway layer parses the service name identifier carried in the client request header and routes it to the corresponding target microservice. When the target microservice is unable to configure the target context path itself, the path rewriting mechanism of the gateway layer rewrites the original path in the client request into a path format that the target microservice can recognize.

[0030] Compared with the prior art, the present invention has the following significant advantages: This invention dynamically injects an environment identifier into the gateway layer response header, driving the client to automatically extract the identifier and determine the current access mode. Then, combined with the gateway prefix or service port number obtained through a preset interface, it dynamically constructs a request access address that matches the current environment. This mechanism effectively overcomes the shortcomings of traditional microservice architectures, which heavily rely on manual hard-coding of access addresses. Switching between development, testing, and production environments requires no modification or recompilation of any business code, greatly avoiding test distortion or production incidents caused by incorrect manual address modifications, and significantly improving the efficiency of multi-environment collaborative deployment and test integration.

[0031] This invention establishes a strict mapping relationship between the base address of the client request, the gateway prefix, and the context path of the target microservice backend. This specification not only enables standardized access for each microservice through a unified gateway entry point, effectively eliminating the cumbersome multi-port management of the traditional model and significantly reducing the costs of port application, firewall configuration, and network management at the operation and maintenance level, but also effectively reduces the number of network ports directly exposed to the public network by backend services, thereby significantly reducing the area of ​​microservice clusters susceptible to malicious scanning and attacks and improving the overall security level.

[0032] To address the pain points of state pollution and data overwriting that easily occur when deploying multiple microservices in the same domain, this invention establishes a three-dimensional security isolation system integrating sessions, caches, and interfaces. At the session level, the path attribute of the session cookie is forcibly bound to the target context path, and an independent cookie name is configured based on the service name, thus providing double protection to prevent the possibility of misuse of cross-service states. At the cache level, a hierarchical character structure is constructed, and it is ensured that the namespace identifier is strictly consistent with the target context path. At the interface level, nested physical isolation is implemented with the target context path as the first-level prefix. This multi-dimensional and strict constraint effectively avoids cross-service session pollution, cache data overwriting, and interface call conflicts, greatly reducing the risk of business failures caused by conflicts in storage and calls within the same domain.

[0033] This invention integrates core governance capabilities such as security protection, traffic control, circuit breaking and degradation, and log monitoring into the gateway layer as a set of plugins, supplemented by a layered configuration system with three granularities: global, service, and interface levels. This mechanism enables the system to implement precise interception, rate limiting, or degradation responses from top to bottom when facing unauthorized access, traffic surges, or internal node anomalies, effectively preventing service cascading failures and ensuring high system availability. Simultaneously, the entire governance process exhibits completely zero-intrusion characteristics on the underlying microservice business code, requiring no code modification of the microservices, ensuring the smooth evolution and sustainable expansion of the original system architecture. Attached Figure Description

[0034] Figure 1This is a flowchart of the microservice unified access and global governance method of the present invention; Figure 2 This is a flowchart illustrating the dynamic adaptation and redirection of single sign-on in this invention. Detailed Implementation

[0035] Example 1 like Figure 1 As shown, this embodiment provides a method for unified access and global governance of microservices based on gateway identifier injection. The method includes: The gateway layer receives access requests for a target microservice initiated by a client and forwards the access requests to the corresponding target microservice according to preset routing rules. The gateway layer intercepts the response returned by the target microservice to the client and dynamically injects an environment identifier into the response header. The client intercepts the response and extracts the environment identifier, and determines the current access mode as gateway mode or direct connection mode based on the environment identifier; The client obtains the service port number and gateway prefix of the target microservice by calling a preset interface, and dynamically generates a request access address that matches the current access mode according to the determined access mode. Specifically, when the gateway mode is confirmed, the request access address is generated by concatenating the obtained gateway prefix; when the direct connection mode is confirmed, the request access address is generated by concatenating the obtained service port number. After the access is executed, the client and the target microservice establish independent session connections and hierarchically isolated local data caches based on the target context path, wherein the target context path is consistent with the gateway prefix when the gateway layer routes the target microservice.

[0036] The steps of the above method will be explained one by one below.

[0037] In this embodiment, the gateway layer, serving as the unified traffic entry point for the entire microservice architecture, is deployed on an isolated node between the public and internal networks. The gateway layer only exposes a limited number of standard ports to the outside world, such as standard ports for HTTP and HTTPS, while all backend microservices only listen on internal network ports and are not directly exposed externally. Any access request initiated by a client targeting a specific microservice first reaches the unified port of the gateway layer. The gateway layer maintains a set of preset routing rules to map the prefix paths of different services to the corresponding backend microservice instances. When the gateway layer receives a request, it matches the path prefix in the request URL with the corresponding routing rules and forwards the request to the corresponding target microservice on the internal network. Therefore, the client does not need to be aware of the actual IP address and port number of the backend microservice; all access is completed through the unified gateway entry point, completely eliminating the cumbersome operation of multi-port management.

[0038] After the request is forwarded to the target microservice and a response is received, the gateway layer does not directly return the original response to the client. Instead, it intercepts and processes the response. The gateway layer utilizes its response rewriting mechanism to dynamically inject an environment identifier field into the HTTP response header. As a specific implementation, this environment identifier field can be set to `X-API-Gateway:true`, explicitly indicating to the client that the current request was forwarded via the gateway proxy. This injection process is completely transparent to the target microservice; the microservice itself is unaware of the identifier's existence, and all processing is completed at the gateway layer. When the client receives a response with the environment identifier, it can determine its current access environment, providing a basis for subsequent dynamic address generation.

[0039] After receiving the response from the gateway layer, the client intercepts and parses the response headers to extract the environment identification information. If the `X-API-Gateway:true` flag is detected, the client determines that it is currently in gateway mode, i.e., the current access method is for a production environment. If this flag is not detected, it determines that it is currently in direct connection mode, i.e., the current access method is for a development or testing environment. Through this simple flag detection mechanism, the client can dynamically perceive the current access mode at runtime without relying on any hard-coded environment variables or configuration files.

[0040] Before or simultaneously with determining the access mode, the client also needs to obtain the connection parameters of the target microservice. For this purpose, each backend microservice provides a standardized pre-defined interface, such as the ` / api / getServicePort` interface. The client calls this interface to query the target microservice for its service port number and gateway prefix information. Upon receiving the query request, the target microservice returns its actual listening port number within the internal network and the routing prefix configured at the gateway layer. The client temporarily stores the obtained port number and gateway prefix information as the basis for dynamically constructing the access address for subsequent requests.

[0041] After obtaining the parameters, the client dynamically generates a request access address that matches the current environment based on the previously determined access mode. The specific address generation logic is as follows: When the gateway mode is confirmed, the client uses the address of the server where the gateway layer resides and appends the obtained gateway prefix to generate the complete request access address; when the direct connection mode is confirmed, the client uses the IP address of the internal network server where the target microservice resides and appends the obtained service port number to generate the complete request access address. Through this mechanism, the client's address generation in different environments is fully automated. Developers do not need to manually maintain multiple sets of address configurations for different environments, completely eliminating the risk of configuration errors caused by hard-coded addresses and the inefficiency of repeated compilation and deployment.

[0042] After the requested access address is generated and the access is successfully executed, the client and the target microservice enter the session establishment and data caching phase. This invention introduces a complete isolation mechanism based on the target context path at this stage to ensure that multiple services do not interfere with each other when coexisting. The target context path is an independent path prefix pre-configured for each microservice during deployment, and this path strictly matches the gateway prefix used by the gateway layer when routing the microservice. By using the target context path as the core anchor point for isolation, this invention establishes a strict isolation system from two dimensions: session connection and local caching. The specific implementation will be described in detail below.

[0043] As one implementation method, the preset routing rules in this embodiment adopt a path prefix routing method based on Uniform Resource Locators or a wildcard domain name resolution routing method; wherein, a strict corresponding standard mapping relationship is established among the base address of the client initiating the request, the gateway prefix of the gateway layer, and the target context path of the target microservice backend.

[0044] The specific implementation of the routing rules will be explained in detail below.

[0045] In path prefix routing, the gateway layer configures independent path prefix routing rules for each microservice. For example, the path prefix is ​​configured as ` / ins` for the `ins` service and ` / bserver` for the `bserver` service. When a user initiates a request for "gateway address / ins / api / login", the gateway layer matches the ` / ins` prefix and forwards the request to the internal network address corresponding to the `ins` service. In wildcard domain name routing, the gateway layer configures wildcard domain name resolution, such as `*.example.com`, and adopts a hybrid routing strategy: for combined services on a shared platform, routing is done using the "main domain name plus path prefix", such as "web.example.com / bservice"; for independently deployed or externally exposed services, routing is done directly using the subdomain, such as "ins.example.com". Both routing methods can be flexibly selected; path prefix routing is enabled by default, while wildcard domain name routing is an optional extension.

[0046] Regardless of the routing method used, this invention requires establishing a strictly corresponding and standardized mapping relationship among the three elements. Specifically, the base address used by the client when initiating a request (e.g., the unified entry address of the gateway layer or the production environment domain name), the gateway prefix configured by the gateway layer for the service (e.g., / ins), and the target context path configured by the target microservice backend (also / ins) must maintain a one-to-one correspondence. This standardized mapping relationship ensures that after a request is sent from the client, it can be accurately identified by the gateway layer and routed to the correct target microservice, while the target microservice can also correctly parse and process the request modified by the context path. This standard fundamentally solves the problems of repeated confirmation of addresses and prefixes and high cross-team communication costs during front-end and back-end interface integration in existing technologies. It also allows the integration of new services to be completed quickly by simply configuring according to the standard, without any customization of the existing system.

[0047] In one implementation, the requested access address in this embodiment is a single sign-on redirect address; the client dynamically generates a requested access address that matches the current access mode, specifically: when it is confirmed to be the gateway mode, the client generates the single sign-on redirect address by concatenating the obtained gateway prefix and performs redirection; when it is confirmed to be the direct connection mode, the client generates the single sign-on redirect address by concatenating the obtained service port number and performs redirection.

[0048] The following section will elaborate on the implementation of dynamic redirection in a single sign-on scenario.

[0049] In enterprise-level microservice architectures, single sign-on (SSO) is a core authentication scenario for users accessing multiple microservices. In traditional solutions, the SSO redirect address is typically hard-coded in the front-end configuration file, and address differences across different environments rely on manual maintenance. This embodiment solves this problem by applying the aforementioned environment identifier injection mechanism and dynamic address generation mechanism to the SSO scenario. Specifically, each backend microservice, during its standardization transformation, adds two interfaces: one is the ` / api / getServicePort` interface, which returns the service's port number and gateway prefix; the other is the ` / {servicePrefix} / sso / login` interface, which receives and verifies the token transmitted by the SSO system, and creates an independent session locally upon successful verification.

[0050] Before initiating a single sign-on redirect, the client first calls the ` / api / getServicePort` interface to obtain the service port number and gateway prefix information of the target microservice. Then, it concatenates the address according to the currently identified access mode. In gateway mode, the client concatenates the server address of the gateway layer with the gateway prefix to generate a redirect address like "gateway address / itc / sso / login?token=xxx" and executes the redirect. In direct connection mode, the client directly concatenates the IP address of the internal network server where the target microservice resides with the service port number to generate a redirect address like "internal IP address:service port number / itc / sso / login?token=xxx" and executes the redirect. Through this mechanism, the single sign-on redirect address achieves environment adaptability. Whether developers are debugging locally via direct connection or accessing through a gateway in a production environment, the redirect address can automatically adapt without manual code modification.

[0051] As one implementation method, this embodiment establishes a session connection between the client and the target microservice that is independent of each other based on the target context path, including: forcibly binding the path attribute of the session cookie of the target microservice to the target context path, so that the browser carries the corresponding session cookie only when matching the target context path; and configuring an independent cookie name for the session cookie using a unique string containing microservice name information, so as to prevent session conflicts of multiple services deployed in the same domain.

[0052] The specific implementation of session isolation will be explained in detail below.

[0053] Session isolation is one of the most critical isolation dimensions when deploying multiple services within the same domain. When multiple microservices share the same domain and port, the browser's cookie management mechanism by default places all cookies under the same scope, which can lead to session information from different services being carried over and overwritten. This invention establishes a session isolation mechanism on two levels.

[0054] The first layer involves the mandatory binding of the cookie path to the target context path. Each backend microservice, during standardized configuration, sets the Path attribute of the session cookie to the value of its target context path. For example, the ins service might be configured with server.servlet.session.cookie.path= / ins, and the web service with server.servlet.session.cookie.path= / bserver. When a user accesses the ins service and successfully logs in, the server returns a Set-Cookie response header containing the Path= / ins attribute. According to the HTTP specification, the browser will only carry this cookie when making a request with a path starting with / ins. When the user subsequently accesses the web service (path / bserver), the browser will not carry the ins service's session cookie because the path does not match, thus achieving physical isolation between the two service sessions.

[0055] The second layer involves the independent naming of session cookies. To further enhance the reliability of isolation, each service is configured with a unique cookie name containing its own service name information. For example, the INS service is configured with SESSION_COOKIE_NAME=JSESSIONID_INS, and the web service is configured with SESSION_COOKIE_NAME=JSESSIONID_BSERVER. This naming strategy ensures that even if the path binding mechanism fails to fully function under certain abnormal circumstances, the browser can still distinguish between multiple cookies by their different names, preventing cookies with the same name from overwriting each other. Through the dual protection of "path binding plus independent naming," this invention completely solves the problem of cross-service session pollution.

[0056] As one implementation method, this embodiment establishes a hierarchical isolated local data cache, including: when establishing the hierarchical isolated local data cache in the client's local storage, using a concatenated character structure containing namespace identifiers and key identifiers to manage the cached data hierarchically; wherein, the exclusive namespace identifier of each microservice is strictly consistent with the target context path corresponding to the microservice, so as to achieve physical isolation of exclusive data.

[0057] The specific implementation of cache isolation will be explained in detail below.

[0058] In a browser environment, the scope of localStorage and sessionStorage is determined by the protocol, domain name, and port, and does not distinguish between URL paths. When multiple front-end projects are deployed under the same domain, they share the same local storage space. If different projects use the same storage key name, data can easily be overwritten. This invention solves this cache conflict problem by establishing a namespace hierarchical management mechanism at the application layer.

[0059] In terms of implementation, developers encapsulate a unified storage utility class that accepts a namespace parameter during construction. During each storage operation, the utility class automatically appends the namespace identifier to the user-specified key name, forming a complete storage key in the format "namespace:key name," and then stores it in localStorage. When retrieving data, the utility class similarly appends the namespace identifier to the key name, achieving strict isolation between data from different projects.

[0060] The namespace values ​​strictly adhere to the specification of matching the backend target context path. For example, the INS frontend project uses the namespace INS, while the bserver frontend project uses the namespace bserver. Taking the INS project storing user information as an example, after calling insStorage.set('user', {id:1, name:'admin'}), the actual stored full key name is ins:user. If the web service's frontend project also attempts to store data with 'user' as the key name, the actual stored key name is bserver:user. The two key names are completely different, eliminating the possibility of data overwriting from the outset.

[0061] In addition, for public data that needs to be shared among multiple microservices, such as global theme settings and language preferences, this embodiment sets up a separate public namespace (e.g., common). All projects can read and write data through keys such as common:theme and common:language, thus achieving orderly management of shared data.

[0062] As one implementation, the method in this embodiment further includes performing nested isolation on the interface path of the target microservice: configuring a three-level nested interface path for the target microservice, wherein the three-level nested interface path sequentially includes a service prefix as the first level, an interface module as the second level, and an interface name as the third level; wherein the service prefix as the first level is the same as the target context path.

[0063] The specific implementation of interface path isolation will be explained in detail below.

[0064] Interface path isolation is the third dimension in the three-dimensional isolation system. This invention establishes a unified nested path specification for the API interfaces of all microservices, adopting a three-level hierarchical structure: the first level is the service prefix, which is the target context path of the microservice, such as / ins; the second level is the interface module, used to distinguish different business modules and access permission levels within the same service, such as / api for public interfaces, / admin for management interfaces, and / open for externally exposed interfaces; the third level is the specific interface name, usually named using camelCase, such as login and getDataList.

[0065] Taking the `ins` service as an example, its user login interface has a full path of ` / ins / api / login`; the `bserver` service has a full path of ` / bserver / admin / getDataList`; and the `label` service has a full path of ` / label / open / getLabelInfo`. By using the service prefix as the first level of the interface path, the interfaces of different microservices are naturally distinguished by different path prefixes. Even if two services have interfaces with the same name (e.g., both designed with the ` / api / login` path), in a nested structure, the actual exposed full paths are ` / ins / api / login` and ` / bserver / api / login`, respectively. The gateway layer can accurately route requests to the corresponding target microservice based on this, avoiding interface name conflicts from the source.

[0066] As one implementation method, the method described in this embodiment also includes global governance based on a gateway plug-in mechanism: a preset governance plug-in set is invoked at the gateway layer, the governance plug-in set including at least running plug-ins for security protection, traffic control, circuit breaking and degradation, and log monitoring; based on a layered configuration system with three granularities—global level, service level, and interface level—dynamic parameter distribution and lifecycle management are performed on the plug-ins in the governance plug-in set.

[0067] The following section will elaborate on the specific implementation of gateway plug-in governance.

[0068] The gateway layer itself has pluggable extensibility. This invention fully leverages this feature to integrate various governance functions required in a microservice architecture into the gateway layer as a set of plug-ins, achieving unified and granular management of traffic. All governance capabilities are processed at the gateway layer for requests and responses, without requiring any modification to the business code of the backend microservices.

[0069] In terms of security, the gateway layer integrates an authentication plugin to verify the identity token in the request, an IP blacklist / whitelist plugin to filter the source IP, and a request validation plugin to check the legality of the format and content of the request parameters, thereby effectively preventing unauthorized access and malicious requests at the traffic entry point. Regarding traffic management, the gateway layer uses a rate-limiting plugin to control the number of requests per unit time, preventing excessive calls from individual clients from exhausting system resources. Simultaneously, it utilizes the gateway layer's native load balancing capabilities to distribute requests to multiple instances of the target microservice according to strategies such as round-robin or weighted round-robin, ensuring high service availability. For circuit breaking and degradation, the gateway layer integrates a circuit breaker plugin to monitor the error rate of upstream services in real time. When the error rate exceeds a preset threshold, a circuit breaker is automatically triggered, and subsequent requests will be directly rejected or forwarded to a pre-configured backup upstream service, preventing cascading failures caused by individual service failures. In terms of log monitoring, the gateway layer pushes request logs, response logs, and exception logs to the centralized log analysis system in real time through the log push plugin. At the same time, it exposes the operational indicator data to the monitoring and alarm system through the indicator exposure plugin, enabling operation and maintenance personnel to grasp the system's operating status in real time and quickly locate problems when faults occur.

[0070] The aforementioned governance plugins do not have a uniform global effect; instead, they support layered configuration at three granularities: global, service-level, and interface-level. Global-level configurations apply to all requests passing through the gateway layer; service-level configurations only apply to routing rules for specific services; and interface-level configurations only apply to routing rules for specific interfaces. Through this layered configuration system, operations personnel can implement differentiated governance strategies for different services and interfaces based on actual business needs, achieving granular traffic control.

[0071] As one implementation method, in this embodiment, the service port number of the target microservice, the target context path, and the independent cookie name are all dynamically configured through environment variables to decouple the configuration information from the microservice business code.

[0072] The following section will elaborate on the specific implementation of environment variable configuration.

[0073] In a microservice architecture with multiple technology stacks and deployment modes, different services use different development languages, runtime frameworks, and deployment environments. To ensure that the standardized configuration of this invention can be uniformly implemented in heterogeneous environments, this embodiment uses environment variable injection to decouple configuration from code. For microservices using the Java technology stack, environment variables are referenced in the configuration file using placeholders such as ${SERVICE_PORT}, ${SERVICE_CONTEXT_PATH}, and ${SESSION_COOKIE_NAME}. The actual values ​​are injected by the container or deployment script when the service starts. For services using non-Java technology stacks such as Go, Python, and Node.js, the above configuration parameters are obtained by reading system environment variables.

[0074] This design allows the same service code to be deployed in different environments simply by modifying environment variable values, without requiring any changes to the business logic. For example, for a public service that needs to deploy multiple instances, different SERVICE_CONTEXT_PATH environment variable values ​​can be configured for different instances to achieve path-isolated deployment of the same code package across multiple instances.

[0075] As one implementation method, in this embodiment, in addition to injecting the environment identifier into the response header, it is also transmitted through a Uniform Resource Locator parameter or a client cookie to adapt to third-party client call scenarios that cannot parse custom response headers.

[0076] The following section will elaborate on alternative methods for conveying environmental labeling.

[0077] In certain special client-side scenarios, such as when a third-party system initiates a request through an embedded browser control or a restricted HTTP client library, the client may be unable to parse or access the custom response header injected by the gateway layer. To adapt to such scenarios, this embodiment provides two alternative methods for passing the environment identifier. The first method is through URL parameters, that is, appending the `gateway=true` parameter to the query string of the request address. The client can determine whether it is currently in gateway mode by parsing the URL parameter. The second method is through client-side cookies, that is, the gateway layer sets an independent identifier cookie in the response, and the client determines the access mode by checking whether this cookie exists. By providing multiple alternative passing methods, this invention can flexibly adapt to different client types and calling scenarios, ensuring the universality and reliability of the environment identifier injection mechanism in various heterogeneous environments.

[0078] As one implementation method, the method in this embodiment also includes an alternative routing and rewriting mechanism: when using request header matching for routing forwarding, the gateway layer parses the service name identifier carried in the client request header and routes it to the corresponding target microservice; when the target microservice cannot configure the target context path itself, the path rewriting mechanism of the gateway layer rewrites the original path in the client request into a path format that the target microservice can recognize.

[0079] The following section will elaborate on the specific implementation of the alternative routing and rewriting mechanism.

[0080] In certain special scenarios, the system may not be able to use URL path prefixes for routing differentiation. For example, the interface paths of some legacy systems are fixed, making it impossible to add service prefixes to the paths; or in some scenarios, it is inconvenient for clients to modify the request path. For such scenarios where path prefixes are restricted, this embodiment provides an alternative solution of request header matching routing. When the client initiates a request, it carries a service name identifier field in the request header, such as X-Service-Name:ins. After receiving the request, the gateway layer parses this field in the request header and routes the request to the corresponding target microservice according to the preset request header matching routing rules.

[0081] Furthermore, for legacy microservices already running in production environments, it may be impossible to modify their code to configure the target context path for stability reasons. To address this, this embodiment provides a gateway-layer path rewriting mechanism as an adaptation solution. The gateway layer, through a proxy rewriting plugin, rewrites the request path before forwarding the request to the microservice. For example, when a client requests ` / label / api / getLabelInfo`, the gateway layer rewrites the path to ` / api / getLabelInfo` before forwarding it to the label service. This mechanism allows seamless integration into the unified access and global governance system of this invention, even if the backend service does not support context path configuration, through a single layer of adaptation at the gateway layer, significantly reducing the transformation cost and access threshold of existing systems.

[0082] Example 2

[0083] Based on the method and steps described in Example 1, this embodiment further provides a more detailed explanation of the technical solution from multiple dimensions, including system architecture layering, standardized configuration specifications, specific implementation details of the three-dimensional isolation system, dynamic adaptation to multiple environments and single sign-on optimization process, and the construction of a gateway plug-in governance system.

[0084] The system used in this embodiment adopts a five-layer distributed architecture, consisting of a user / client layer, a gateway global governance layer, a microservice standardized access layer, a data storage layer, and an operation and maintenance management layer, from top to bottom. Each layer communicates with the others via standardized network protocols and interfaces such as HTTP / HTTPS and TCP / IP. The layers are decoupled, allowing for independent deployment and expansion.

[0085] The user / client layer serves as the final access point for the service, responsible for initiating service requests and displaying the business processing results. This layer must adhere to the front-end adaptation standardization specifications defined in this embodiment, implementing functions such as dynamic address concatenation across multiple environments and cache namespace management.

[0086] The gateway global governance layer is the core implementation layer in this embodiment, deployed on an isolated node between the public and internal networks. This layer is responsible for unified traffic entry, intelligent routing and forwarding, environment identifier injection, cross-service isolation control, global traffic governance, and plugin lifecycle management. Internally, the gateway layer includes a dynamic storage module to store core data such as routing rules, governance configurations, and plugin parameters, and supports dynamic updates. Gateway cluster deployment ensures high availability; all user-facing services are forwarded through the unified gateway entry point. Application services no longer directly provide HTTPS services; the gateway layer handles HTTPS offloading and forwarding centrally.

[0087] The standardized microservice access layer includes all backend microservices for enterprise-level business operations, supporting development using multiple technology stacks such as Java, Go, Python, and Node.js. All services adhere to the standardized backend configuration specifications outlined in this embodiment, each with its own independent context path, listening only on internal network ports, and receiving requests forwarded from the gateway layer; they are not directly exposed to the outside world.

[0088] The data storage layer provides basic support services such as data storage, caching, and file management for the microservice layer, while also providing storage services for logs, monitoring metrics, and other data for the gateway's global governance layer. This layer supports distributed deployment, ensuring high availability and reliability of data.

[0089] The operations and maintenance management layer provides the entire system with unified configuration management, operational status monitoring, centralized log analysis, anomaly alerts, and operations and maintenance capabilities, enabling visualized operations and maintenance of gateways and microservices, reducing operational complexity, and improving operational efficiency.

[0090] This embodiment constructs a single traffic entry point through the gateway layer, establishes standardized configuration specifications for the interaction of the gateway, backend, and frontend, and achieves unified access for all microservices, completely eliminating multi-port management. The core of this implementation consists of three parts: standardized gateway routing configuration, standardized backend service configuration, and standardized frontend request adaptation. These three parts strictly correspond one-to-one, ensuring the accuracy and consistency of request routing.

[0091] Regarding standardized gateway routing configuration, gateway routing is the core of unified access. This embodiment supports two access methods. Method 1 is URL path prefix routing, which is enabled by default. Its core logic is to add the service name as a path prefix after the unified gateway port. The gateway layer routes requests to the corresponding backend microservices based on the prefix, eliminating the need to consider port differences and significantly reducing the number of port requests. In terms of gateway infrastructure deployment, the gateway cluster is deployed on accessible isolated nodes, with only a limited number of standard ports exposed and all irrelevant ports closed. A configuration storage cluster is deployed as the storage carrier for routing rules and configurations, and data consistency is ensured through a consistency algorithm. In terms of routing rule design, an independent path prefix routing rule is configured for each microservice. The route name follows the naming convention of "service name-route," the matching mode uses path prefix matching, and the route priority is set according to the service prefix length from longest to shortest to avoid shorter path prefixes incorrectly covering longer ones. The upstream address is configured with the corresponding microservice's internal IP address and internal port. Upstream health checks are enabled, and the check interval and timeout can be set as needed. Once an abnormal node is detected, it is automatically removed from the upstream list. For dynamic route updates, a timer mechanism at the gateway layer periodically queries the routing rules in the configuration storage, while a listener function monitors rule changes in real time, enabling dynamic updates of routing rules within seconds. The entire process does not require restarting the gateway. For example, if a user initiates a request for "gateway address / bserver / login", the gateway layer matches the path prefix "bserver" and forwards the request to the port corresponding to the bserver service on the internal network. The bserver service then handles the specific path " / bserver / login".

[0092] Method two is wildcard DNS routing, an optional extension method that is disabled by default. Its core logic involves configuring wildcard DNS for a domain and employing a hybrid routing strategy: for shared platforms or combined services, routing is done using the "main domain plus path prefix" method; for independently deployed or publicly exposed services, routing is done directly using subdomains. The advantages of this method are that it supports service isolation and domain name reuse, complies with public network service deployment standards, facilitates centralized management of HTTPS wildcard certificates, and is suitable for scenarios providing standardized service interfaces.

[0093] Regarding standardized backend service configuration, all backend microservices adhere to the core principle of context path standardization, configuring context paths through default configurations or dynamic injection of environment variables. This path maintains complete consistency with the gateway routing prefix, while also standardizing cookie paths and session configurations, laying the foundation for resolving browser-side session conflicts and frontend-backend collaboration issues. Based on actual business service requirements, each microservice has a clearly defined correspondence between its port number and context path. For example, the backend service context path for the web service is configured as " / bserver"; the ins service as " / ins"; the itc service as " / itc"; and the label service as " / label". Specifically, for the same service requiring multiple instances, different context path environment variable values ​​can be configured for different instances to achieve path isolation across multiple instances of the same service.

[0094] For services using the Java technology stack, configuration information can be dynamically configured by referencing environment variables in the configuration file, including port number, context path, path attribute of session cookies, HTTP Only attribute, Secure attribute, and session cookie name. For example, the path attribute of the session cookie can be set to the same value as the context path, and the cookie name can be configured as a unique string containing service name information, in the format "fixed prefix_service name".

[0095] For services using non-Java technology stacks such as Go, Python, and Node.js, this embodiment provides two adaptation schemes. The first is a service-based configuration scheme, which sets the context path through the framework's native routing group or middleware configuration functions to ensure consistency with the gateway route prefix. The second is a gateway plugin adaptation scheme, where if the service itself cannot configure the context path, a path rewriting plugin at the gateway layer rewrites the original path in the client request into a prefix-free path format that the backend service can directly recognize.

[0096] Regarding standardized adaptation of frontend requests, all frontend applications adhere to the principle of standardized request base addresses, setting the base request address of the HTTP request client to the context path of the corresponding service to ensure that requests can be correctly routed by the gateway. For base address configuration, the gateway base address is configured through environment configuration files for different environments, maintaining consistency across environments by modifying only the gateway base address's pointer. For example, in the development environment, the gateway base address is configured as an internal network test address, while in the production environment, it is configured as the official production domain name. At the HTTP client encapsulation level, when creating a request instance, the frontend application automatically concatenates the gateway base address with the context path of the corresponding service, eliminating the need to manually write the complete address in each API call. For example, the API request base path for the ins frontend project is set to " / ins", and the API request base path for the oms frontend project is set to " / omsservice".

[0097] To address core issues such as session conflicts, cache conflicts, and interface name conflicts in multi-service deployments within the same domain, this embodiment constructs a three-dimensional, integrated, full-domain security isolation system from three dimensions: session isolation, cache isolation, and interface path isolation.

[0098] At the session isolation level, a three-pronged approach—cookie path binding, independent cookie naming, and physical isolation of context paths—completely resolves the cross-service session pollution problem. Regarding the mandatory binding of cookie paths and context paths, leveraging the native features of the web container, the path attribute of the session cookie is bound to the service's context path, ensuring that the browser only carries the corresponding session cookie when making requests to services matching that path. For example, the cookie path for the INS service is " / ins", and the cookie path for the web service is " / bserver," making them independent. Regarding independent naming of session cookies, each service configures a unique cookie name through an independent session cookie name configuration item. Even if the path binding mechanism fails in extreme abnormal situations, the browser can still distinguish the session information of different services through different cookie names. For example, the cookie name for the INS service is "JSESSIONID_INS", and the cookie name for the web service is "JSESSIONID_BSERVER". Regarding physical isolation of context paths, different services configure different independent context paths, naturally isolating session scopes and fundamentally avoiding session conflicts. For example, the Set-Cookie header returned after logging in to the ins service explicitly contains the "Path= / ins" attribute. When the web service accesses the " / bserver" path, it will not carry this cookie, thus completely resolving the session conflict issue between the two services.

[0099] At the cache isolation level, since the scope of browser local storage is determined by the protocol, domain name, and port, and does not distinguish between URL paths, multiple front-end projects deployed in the same domain will share the same storage space, which can easily lead to problems such as authentication information confusion and business data overwriting. This embodiment achieves strict isolation through layered namespaces. Regarding the unified naming convention for storage keys, a two-layer format of "namespace identifier:key identifier" is adopted. Private data specific to a project is strictly isolated using the project's dedicated namespace, while public data shared by all projects is stored using a common namespace. Each front-end project's dedicated namespace is consistent with the context path of the corresponding back-end service to ensure the consistency of the front-end and back-end naming systems. For example, the ins front-end project uses the namespace "ins," and its complete storage key for storing user information is "ins:user"; the storage key used for common theme configuration is "common:theme." At the front-end storage utility class encapsulation level, a unified storage utility class is developed. It receives namespace parameters during construction and automatically completes the concatenation of namespace and key name during read and write operations, thereby achieving physical isolation of data from different projects at the application layer and avoiding the risk of key name conflicts that may arise from manual operations.

[0100] At the interface path isolation level, all service API interfaces adopt a nested hierarchical structure of " / service prefix / interface module / interface name" to achieve physical isolation. The first level is the service prefix, which is the context path of the service; the second level is the interface module, used to distinguish different business modules and access permission levels within the same service; and the third level is the specific interface name. For example, the full path of the login interface of the ins service is " / ins / api / login", the full path of the data query interface of the bserver service is " / bserver / admin / getDataList", and the full path of the open interface of the label service is " / label / open / getLabelInfo". By using the service prefix as the first level of the interface path, even if different services have interfaces with the same name, the gateway layer can accurately route requests to the corresponding target microservices through different path prefixes, avoiding interface name conflicts from the source.

[0101] This embodiment achieves seamless adaptation between the direct connection mode of the development and testing environment and the gateway mode of the production environment by injecting environment identifiers through gateway plugins, dynamically concatenating addresses on the front end, and standardizing backend interfaces. At the same time, it optimizes the single sign-on redirection process.

[0102] Figure 2 This demonstrates the complete process of dynamic adaptation and redirection for single sign-on, specifically including the following steps: This embodiment achieves seamless adaptation between the direct connection mode of the development and testing environment and the gateway mode of the production environment by injecting environment identifiers through gateway plugins, dynamically concatenating addresses on the front end, and standardizing backend interfaces. At the same time, it optimizes the single sign-on (SSO) redirection process. Figure 2 This demonstrates the complete process of dynamic adaptation and redirection for single sign-on, specifically including the following steps: Step S1 (Start): The front end initiates an access request to the target microservice; Step S2: The front end calls the service port acquisition interface provided by the back end to query the service port number and gateway prefix information of the target microservice, and the back end returns the corresponding service information. Step S3 (Judgment): The front end intercepts the response header returned by the gateway layer and determines whether there is an environment identifier field in the response header; Step S4 (Gateway Mode): If the environment identifier field is detected, it is determined that the current mode is gateway mode. The front end generates a single sign-on (SSO) redirect address by concatenating the obtained gateway prefix information. Step S4' (Direct Connection Mode): If no environment identifier field is detected, it is determined that the current mode is direct connection mode. The front end generates a single sign-on (SSO) redirect address by concatenating the obtained service port number. Step S5: The page is redirected to the Single Sign-On (SSO) redirect address dynamically generated in step S4 or S4', and the user enters the Single Sign-On authentication page. Step S6: The Single Sign-On (SSO) authentication center verifies the validity of the token carried in the request; After step S7 (creating a session) and token verification, the target microservice creates an independent session locally, and the session identifier path attribute of this session is forcibly bound to the context path of the target microservice. Step S8 (End): After authentication is completed, you will be redirected to the business page of the target microservice to complete the entire Single Sign-On (SSO) process.

[0103] Regarding the specific implementation of gateway environment identifier injection, an identifier field is injected into the HTTP response header of all HTTP responses returned via the gateway proxy by configuring the gateway's response rewriting plugin. After receiving the response, the frontend application can determine whether the current access is in gateway mode via the gateway proxy or direct connection mode directly connecting to the backend service by checking whether the field exists in the response header.

[0104] Regarding the standardization of backend Single Sign-On (SSO) interfaces, each backend microservice adds a service port acquisition interface. This interface receives the service name as a parameter and returns the corresponding service's port number and gateway prefix information. Simultaneously, the standardized SSO login interface path is formatted as " / service prefix / sso / login". This interface is responsible for receiving and verifying the token transmitted by the SSO system. Upon successful verification, it creates an independent session locally.

[0105] Regarding the specific implementation of gateway environment identifier injection, an identifier field is injected into the HTTP response header of all HTTP responses returned via the gateway proxy by configuring the gateway's response rewriting plugin. After receiving the response, the frontend application can determine whether the current access is in gateway mode via the gateway proxy or direct connection mode directly connecting to the backend service by checking whether the field and its corresponding value exist in the response header.

[0106] Regarding the standardization of backend SSO interfaces, each backend microservice adds a service port acquisition interface. This interface receives the service name as a parameter and returns the corresponding service's port number and gateway prefix information. Simultaneously, the login interface path for standardized single sign-on is standardized, in the format " / service prefix / sso / login". This interface is responsible for receiving and verifying the token transmitted by the single sign-on system, and creating an independent session locally upon successful verification.

[0107] Based on the pluggable nature of the gateway layer, this embodiment designs a layered configuration system with three granularities: global level, service level, and interface level. It integrates five core governance capabilities, all of which are implemented at the gateway layer without requiring modification of the front-end and back-end business code.

[0108] In terms of security protection and governance, the gateway layer integrates an authentication plugin to verify the identity token in the request, an IP blacklist / whitelist plugin to filter the access source, and a request validation plugin to check the legality of the format and content of the request parameters, effectively preventing unauthorized access and malicious requests at the traffic entry point. For traffic control and governance, a rate-limiting plugin controls the number of requests per unit time, while leveraging the gateway layer's native load balancing capabilities to distribute requests to multiple instances of the target microservice according to preset round-robin or weighted round-robin strategies. For some legacy services, a path rewriting plugin can be used for adaptation. Regarding circuit breaker and degradation governance, a circuit breaker plugin monitors the error rate of upstream services in real time. When the error rate exceeds a preset threshold, a circuit breaker state is automatically triggered, and the interface will directly return a degraded response or forward the request to a pre-configured backup upstream service, preventing cascading failures caused by individual service failures. In terms of log monitoring and governance, a log push plugin pushes request logs, response logs, and exception logs to a centralized log analysis system in real time. Simultaneously, a metric exposure plugin exposes operational metric data to external monitoring and alerting systems, enabling operations personnel to monitor system status in real time. Regarding metric statistics and governance, a statistics plugin performs multi-dimensional statistics on traffic data, providing data support for system optimization and resource expansion.

[0109] To meet the personalized governance needs of enterprises, this embodiment also supports the development of custom plugins based on the Lua language. Custom plugins follow the plugin development framework of the gateway layer and can implement hook function logic at various stages, such as request rewriting and access control. Plugin configurations are stored through a dynamic storage module, supporting dynamic updates, and can be integrated and activated at the global, service, or interface level configuration granularity.

[0110] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for unified access and global governance of microservices based on gateway identifier injection, characterized in that, The method includes: The gateway layer receives the initial access request for the target microservice initiated by the client and forwards the initial access request to the corresponding target microservice according to the preset routing rules. The gateway layer intercepts the response returned by the target microservice to the client and dynamically injects an environment identifier into the response header. The client intercepts the response and extracts the environment identifier, and determines the current access mode as gateway mode or direct connection mode based on the environment identifier; The client obtains the service port number and gateway prefix of the target microservice by calling the service port acquisition interface provided in advance by the target microservice; The client dynamically generates a request access address that matches the current access mode as a single sign-on redirect address and performs redirection based on the determined access mode. Specifically, when the gateway mode is confirmed, the single sign-on redirect address is generated by concatenating the obtained gateway prefix and the redirection is performed. When the direct connection mode is confirmed, the single sign-on redirect address is generated by concatenating the obtained service port number and the redirection is performed. After the redirection is executed, the client and the target microservice establish independent session connections and hierarchically isolated local data caches based on the target context path. The target context path is consistent with the gateway prefix used by the gateway layer when routing the target microservice.

2. The method according to claim 1, characterized in that, The preset routing rules adopt either path prefix routing based on Uniform Resource Locators or wildcard domain name resolution routing. The gateway prefix and the target context path use the same path string prefix, so that a one-to-one path mapping relationship is established between the base address of the client request, the gateway prefix of the gateway layer, and the target context path of the target microservice backend.

3. The method according to claim 1, characterized in that, Establishing independent session connections between the client and the target microservice based on the target context path includes: The path attribute of the session cookie of the target microservice is forcibly bound to the target context path, so that the browser carries the corresponding session cookie only when the target context path is matched; Furthermore, a unique string containing microservice name information is used to configure an independent cookie name for the session cookie to prevent session conflicts when multiple services are deployed in the same domain.

4. The method according to claim 1, characterized in that, Establish a hierarchical and isolated local data cache, including: When establishing the hierarchical isolated local data cache in the client's local storage, a concatenated character structure containing namespace identifiers and key identifiers is used to manage the cached data hierarchically. Each microservice's dedicated namespace identifier is strictly consistent with the target context path corresponding to that microservice, in order to achieve hierarchical isolation of dedicated data namespaces.

5. The method according to claim 1, characterized in that, The method also includes performing nested isolation on the interface paths of the target microservice: Configure a three-level nested interface path for the target microservice. The three-level nested interface path includes, in sequence, a service prefix as the first level, an interface module as the second level, and an interface name as the third level. The service prefix, which serves as the first level, is the same as the target context path.

6. The method according to claim 1, characterized in that, The method also includes global governance based on a gateway plug-in mechanism: The gateway layer invokes a preset set of governance plugins, which includes at least runtime plugins for security protection, traffic control, circuit breaking and degradation, and log monitoring. Based on a layered configuration system with three granularities—global, service, and interface—dynamic parameter distribution and lifecycle management are implemented for the plugins in the governance plugin set.

7. The method according to claim 3, characterized in that, The service port number, target context path, and independent cookie name of the target microservice are all dynamically configured through environment variables to decouple the configuration information from the microservice business code.

8. The method according to claim 1, characterized in that, In addition to being injected into the response header, the environment identifier is also transmitted via a Uniform Resource Locator (URL) parameter or a client-side cookie to adapt to third-party client call scenarios where custom response headers cannot be parsed.

9. The method according to any one of claims 1 to 8, characterized in that, The method also includes alternative routing and rewriting mechanisms: When using request header matching for routing, the gateway layer parses the service name identifier carried in the client request header and routes it to the corresponding target microservice. When the target microservice is unable to configure the target context path itself, the path rewriting mechanism of the gateway layer rewrites the original path in the client request into a path format that the target microservice can recognize.

Images