Intranet microservice management method and device

Abstract

The application relates to an intranet microservice management method and device. The method comprises the following steps: a domain division step; a gateway routing strategy configuration step; an API gateway building step; an API publishing step; a routing component design step; and a gray verification step. The application establishes a domain and application mapping relationship, realizes direct access in the same domain, realizes a routing strategy of an API gateway across domains, and realizes a non-intrusive dynamic routing addressing scheme in combination with a client routing component, so that an efficient intranet microservice management scheme is provided.

Description

Intranet microservice governance methods and devices Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for governing intranet microservices. Background Technology

[0002] Currently, most internet companies use the mainstream microservice architecture development model. As companies grow, the number of applications increases rapidly, reaching hundreds or even thousands, and the number of APIs can even reach tens of thousands (API overload). This makes the call relationships between internal microservices extremely complex, posing new challenges to service governance.

[0003] Because processing between internal microservices increases complexity and risk, most companies only manage API gateways for requests from the external network. A few companies build multiple API gateway clusters on the internal network to manage application API interfaces for different businesses / platforms, but for cross-business / platform requests, the corresponding gateway domain name must be requested. These traditional solutions are more suitable for initially agreeing on a standard, where all new scenarios requiring gateway requests can be initiated directly by specifying the gateway domain name or through gateway application service discovery. However, the request path may need to specify namespaces and API group directory prefixes. Given the extensive use of FeignClient, this requires significant modifications. Later, when gateways are taken offline or deprecated and replaced with direct connection solutions, it will lead to another round of modifications. Currently, a simple and efficient internal network microservice gateway governance solution is lacking. Summary of the Invention

[0004] Based on this, this paper proposes an intranet microservice governance method and device to solve the above problems. By establishing a mapping relationship between domains and applications, it enables direct access within the same domain and a routing strategy of using the API gateway for cross-domain access. Combined with a client-side routing component, it implements a non-intrusive dynamic routing solution.

[0005] According to a first aspect of the present invention, an intranet microservice governance method is provided, comprising the following steps:

[0006] The domain partitioning process involves dividing applications by domain and establishing a mapping relationship between applications and domains.

[0007] The gateway routing policy configuration steps are as follows: configure the routing policy, save the routing policy in the configuration center, and distribute it to each application;

[0008] API gateway setup steps, including setting up an API gateway cluster;

[0009] The API publishing steps involve publishing the list of APIs that request cross-domain requests to the API gateway whitelist.

[0010] The routing component design steps involve obtaining the routing policy from the configuration center and sending it to the routing component. The routing component then performs access permission verification for incoming requests and routes and forwards outgoing requests according to the routing policy.

[0011] The gray-scale verification step involves performing gray-scale verification on the newly launched API gateway.

[0012] In some embodiments, the routing policy includes: switch control, domain list, domain application relationship list, public application whitelist, and public API whitelist;

[0013] Switch control includes multi-level switch control of main switch, area switch, and application switch;

[0014] Storing routing policies in the configuration center and distributing them to various applications includes storing routing policies in the configuration center and having the configuration center distribute them to the routing components of each application in real time.

[0015] In some embodiments, building an API gateway cluster includes: building an API gateway cluster based on Apisix; treating the API gateway as a microservice, with the instance automatically registered to the service registry after startup; and configuring an elastic scaling strategy for the API gateway cluster in the Kubernetes cluster.

[0016] In some embodiments, the API list can be obtained by: cleaning and outputting the API list by analyzing the mapping relationship between call chain data and application domain; or by obtaining it through log statistical analysis.

[0017] In some embodiments, the routing component performs access permission verification on inbound requests and routing forwarding on outbound requests according to a routing policy, including:

[0018] a) When the application starts, it asynchronously retrieves routing policy information from the client side of the configuration center and caches it locally;

[0019] b) When the routing policy changes, the configuration center issues the changes in real time;

[0020] c) When the application receives an HTTP request, it determines whether a direct connection is allowed based on the routing policy;

[0021] d) When an application sends a request to a downstream application, it determines whether to connect directly or to the API gateway, and performs corresponding service discovery and load balancing operations based on the determination result.

[0022] In some embodiments, a gray-scale verification is performed on the newly launched API gateway, including:

[0023] The system monitors logs or uses Promethues metrics to alert users to determine if there are any anomalies. If an anomaly is found, the corresponding switch in the switch control is turned off.

[0024] In some embodiments, a traffic management step is further included, which involves obtaining the processor utilization rate in the previous time period, limiting the read speed to 90% of the previous time period when the utilization rate exceeds a set upper limit threshold, and limiting the read speed to 110% of the previous time period when the utilization rate exceeds a set lower limit threshold. The previous time period is preferably a period of 15 seconds from now to the past.

[0025] According to a second aspect of the present invention, an intranet microservice governance device is provided, comprising:

[0026] The domain segmentation module is used to segment applications by domain and establish a mapping relationship between applications and domains;

[0027] The gateway routing policy configuration module is used to configure routing policies, store the routing policies in the configuration center, and distribute them to various applications.

[0028] The API gateway setup module is used to build an API gateway cluster.

[0029] The API publishing module is used to publish a list of APIs for cross-domain requests to the API gateway whitelist.

[0030] The routing component design module is used to obtain routing policies from the configuration center and send them to the routing component. The routing component performs access permission verification for inbound requests and routing forwarding of outbound requests according to the routing policies.

[0031] The gray-scale verification module is used to perform gray-scale verification on newly launched API gateways.

[0032] According to a third aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of any of the methods described above.

[0033] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the methods of any of the above embodiments.

[0034] By implementing the above-described solution of the present invention, the following beneficial effects can be obtained:

[0035] 1. By using a routing component that requires no code intrusion, dynamic addressing logic control is achieved for direct connection or gateway access, without requiring any changes to the existing FeignClient service call method.

[0036] 2. A variety of gray-scale verification solutions and fallback strategies reduce the risk of accidents.

[0037] 3. Organize and categorize applications from a domain perspective, clearly defining the main responsibilities and externally exposed capabilities of each domain. Requests within the same domain can be made directly, while cross-domain requests must go through a domain gateway, reducing the complexity of inter-service calls. Only one internal API gateway needs to be built and shared, and with elastic scaling strategies, there's no need to allocate a separate gateway for each domain. Hierarchical API management allows focus to be placed on the governance of critical APIs, and cross-domain API requests provide data analysis support for this management.

[0038] 4. By controlling the flow rate, the read speed is cyclically reduced / increased, thereby controlling the processor utilization and reducing the risk of system failures. Attached Figure Description

[0039] Figure 1 is a flowchart of some embodiments of the intranet microservice governance method of the present invention;

[0040] Figure 2 is a schematic diagram of the framework of some embodiments of the intranet microservice governance method of the present invention;

[0041] Figure 3 is a schematic diagram of permission verification for inbound requests in some embodiments of the intranet microservice governance method of the present invention;

[0042] Figure 4 is a schematic diagram of outgoing request routing judgment in some embodiments of the intranet microservice governance method of the present invention;

[0043] Figure 5 is a structural schematic diagram of some embodiments of the intranet microservice governance device of the present invention;

[0044] Figure 6 is an internal structural diagram of a computer device used to implement some embodiments of the present invention. Detailed Implementation

[0045] Embodiments of the invention will now be described more fully with reference to the accompanying drawings, in which embodiments of the invention are illustrated. However, the invention may be practiced in many different forms, and should not be construed as limited to the embodiments set forth herein.

[0046] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “this” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that, when used herein, the term “comprising” specifies the presence of the stated features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0047] Unless otherwise defined, the terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. Terms used herein shall be interpreted as having the same meaning as they have in the context of this specification and in the relevant field, and shall not be interpreted in an idealized or overly formal sense, unless specifically defined herein.

[0048] Before describing the specific details of this application, the meanings of the terms used in this application will be briefly explained.

[0049] Kubernetes (k8s) is a container cluster management system. It is an open-source platform that enables automated deployment, automatic scaling, and maintenance of container clusters. The original name of k8s was Kubernetes.

[0050] Apisix is ​​a dynamic, real-time, high-performance API gateway that provides rich traffic management features such as load balancing, dynamic upstream support, canary deployments, service circuit breaking, authentication, and observability. Built on the foundation of nginx and ngx_lua, Apisix fully leverages the powerful performance of LuaJIT and implements a cloud-native, high-performance, and scalable microservice API gateway based on openresty and etcd.

[0051] Promethues is an open-source monitoring solution for collecting and aggregating metrics as time-series data. Simply put, each item in the Promethues store is a metric event with a timestamp of when it occurred.

[0052] Figure 1 shows a flowchart of some embodiments of the intranet microservice governance method of the present invention.

[0053] As shown in Figure 1, the method includes:

[0054] Domain partitioning step S102: Partition applications by domain and establish a mapping relationship between applications and domains;

[0055] Domain rules (such as domain name and number of domains) are generally set up according to different parts of the company, and applications handled by the same department belong to the same domain.

[0056] Gateway routing policy configuration step S104: Configure the routing policy, save the routing policy in the configuration center, and distribute it to each application;

[0057] The routing policy includes information such as switch control, domain list, domain application relationship list, public application whitelist, and public API whitelist. For switch control, a multi-level switch policy is supported, encompassing master switch, domain switch, and application switch, allowing control over the enabling / disabling of the routing policy at different levels such as domain and application. For scenarios involving direct connections to some public services or public APIs, whitelist configuration is provided. The routing policy is stored in the configuration center and distributed to the routing components of each application in real time. The application whitelist and API whitelist are stored as JSON arrays in the configuration center.

[0058] API gateway setup step S106: Set up the API gateway cluster;

[0059] Build an API gateway cluster based on high-performance Apisix; treat the API gateway as a microservice, and automatically register it to the service registry after the instance starts (an instance can be regarded as a pod); configure an elastic scaling strategy for the API gateway cluster in the Kubernetes cluster; the API gateway cluster serves all domains, and only one cluster needs to be built, without the need to build separate clusters according to domain dimensions.

[0060] The intranet API gateway is only responsible for the request and forwarding between intranet microservices. The verification logic is simple, only performing whitelist authentication. If the verification is successful, the request is forwarded; otherwise, the request is rejected.

[0061] API publishing step S108 involves publishing the list of APIs for cross-domain requests to the API gateway whitelist.

[0062] How to obtain the API list:

[0063] 1) Clean the output API list and related information on the number of calls by analyzing the mapping relationship between the data and the application domain through call chain analysis;

[0064] 2) Statistical analysis through logs.

[0065] In the routing component design step S110, the routing policy is obtained from the configuration center and sent to the routing component. The routing component then performs access permission verification on inbound requests and forwards outbound requests according to the routing policy. The specific steps are as follows:

[0066] a) When the application starts, it automatically retrieves routing policy information asynchronously through the configuration center client component and caches it locally;

[0067] b) When the routing policy changes, the configuration center issues the changes in real time;

[0068] c) When the application receives an HTTP request, it will determine whether direct connection is allowed based on the routing policy;

[0069] d) When the application sends a request to the downstream, it will determine whether to use a direct connection or the API gateway, and perform corresponding service discovery and load balancing operations based on the determination result;

[0070] e) When it is necessary to disable the routing function, configure the off switch.

[0071] Step S112, gray-scale verification, is performed on the newly launched API gateway.

[0072] In the initial stage of the intranet API gateway's deployment, cross-domain requests will incur an additional hop. If the target application's API is not published to the gateway, the request will fail. Therefore, a phase of gradual rollout and verification is required. The specific steps are as follows:

[0073] a. The application manager reviews and confirms whether APIs that may be requested across domains have been published to the API gateway.

[0074] b. After the application is published to the API gateway, enable or disable the application through the UI interface or configuration center.

[0075] c. Monitor the log system or use the Promethues indicator to alert for any anomalies. If an anomaly could lead to an accident, shut down the switch and conduct a thorough investigation to identify and address any issues.

[0076] Figure 2 shows a schematic diagram of the framework of some embodiments of the intranet microservice governance method of the present invention.

[0077] As shown in Figure 2, management staff control the domain rules and send changes to the domain rules to the routing component. Applications 1 and 2, and application 4 and application 5 within the domain are directly connected. Applications 3 and 4 in different domains are connected via the API gateway. Applications in the public service (application whitelist) are directly connected to applications in domain A and domain B.

[0078] Figure 3 illustrates a schematic diagram of permission verification for inbound requests in some embodiments of the intranet microservice governance method of the present invention.

[0079] As shown in Figure 3: The application accepts an HTTP request; the routing component (i.e., the agent component) intercepts the request; it determines whether the request originates from the API gateway; if so, it passes the request through; otherwise, it proceeds to the next step; it determines whether the API gateway is healthy; if not, it passes the request through; if so, it proceeds to the next step; it determines whether the switch is enabled; if not, it passes the request through; if so, it proceeds to the next step; it determines whether the application is on the app's whitelist; if so, it passes the request through; otherwise, it proceeds to the next step; it determines whether the application is in the same domain; if so, it passes the request through; otherwise, it proceeds to the next step; it determines whether the application is on the API whitelist; if so, it passes the request through; otherwise, it rejects the request.

[0080] Figure 4 shows a schematic diagram of outgoing request routing judgment in some embodiments of the intranet microservice governance method of the present invention.

[0081] As shown in Figure 4: The application receives an HTTP request; the routing component (i.e., the agent component) intercepts the request; it checks if the API gateway is healthy; if not, it selects the direct connection method; if yes, it proceeds to the next step; it checks if the downstream switch is enabled; if not, it selects the direct connection method; if yes, it proceeds to the next step; it checks if the app is whitelisted; if yes, it selects the direct connection method; otherwise, it proceeds to the next step; it checks if the app is in the same domain; if yes, it selects the direct connection method; otherwise, it proceeds to the next step; it checks if the API is whitelisted; if yes, it selects the direct connection method; otherwise, it uses the gateway method. Direct connection method: Direct connection to application service discovery → request to downstream application; Gateway method: Gateway application service discovery → forwarding the request to the API gateway → API gateway forwarding the request.

[0082] In summary, this invention provides a method for governing microservices within an intranet. It includes: dividing applications by domain and defining access control rules for applications within and between domains; routing policies are integrated with a configuration center, which then distributes them uniformly to client proxy components; the client routing component receives the routing policies, monitors for changes, and caches them locally; to reduce cached data, the routing component only caches policy information indicating whether a policy is enabled or disabled; the client routing component verifies incoming HTTP requests based on the routing policies and dynamically determines the addressing of outgoing HTTP requests, i.e., whether to directly connect to the target application's service discovery or the API gateway application's service discovery; when the API gateway is unhealthy or unavailable, the routing component automatically identifies the direct connection fallback logic and triggers an alarm. By establishing a domain-application mapping relationship, it achieves direct access within the same domain and routing through the API gateway across domains, and combines this with the client routing component to implement a non-intrusive dynamic routing solution.

[0083] Figure 5 shows a schematic diagram of the structure of some embodiments of the intranet microservice governance device of the present invention.

[0084] As shown in Figure 5, the intranet microservice governance device in this embodiment includes:

[0085] Domain partitioning module 100 is used to partition applications by domain and establish a mapping relationship between applications and domains;

[0086] The gateway routing policy configuration module 200 is used to configure routing policies, store the routing policies in the configuration center, and distribute them to various applications.

[0087] API Gateway Setup Module 300 is used to build an API Gateway cluster.

[0088] API publishing module 400 is used to publish a list of APIs for cross-domain requests to the API gateway whitelist;

[0089] The routing component design module 500 is used to obtain routing policies from the configuration center and send them to the routing component. The routing component performs access permission verification on inbound requests and routing forwarding on outbound requests according to the routing policies.

[0090] The gray-scale verification module 600 is used to perform gray-scale verification on newly launched API gateways.

[0091] For specific limitations regarding an intranet microservice governance device, please refer to the limitations of an intranet microservice governance method described above, which will not be repeated here. Each module in the aforementioned intranet microservice governance device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0092] This invention also provides a computer device, which can be a terminal, and its internal structure is shown in Figure 6. The computer device includes a processor, memory, network interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the aforementioned intranet microservice governance method. The display screen can be a liquid crystal display (LCD) or an e-ink display. The input device can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse. Those skilled in the art will understand that the structure shown in FIG6 is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0093] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described intranet microservice governance method.

[0094] Those skilled in the art will understand that implementing all or part of the processes in the above method embodiments can be accomplished by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus (RAMbus), direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0095] The embodiments of the present invention have now been described in detail. To avoid obscuring the concept of the invention, some details known in the art have not been described. Those skilled in the art will fully understand how to implement the technical solutions disclosed herein based on the above description.

[0096] While specific embodiments of the present invention have been described in detail by way of examples, those skilled in the art should understand that the above examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should understand that modifications can be made to the above embodiments or equivalent substitutions can be made to some technical features without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A method for governing intranet microservices, characterized in that, The process includes the following steps: Domain segmentation, dividing applications by domain and establishing a mapping relationship between applications and domains; Gateway routing policy configuration, configuring routing policies, storing the routing policies in the configuration center, and distributing them to each application; API gateway setup, building an API gateway cluster; API publishing, publishing the list of APIs for cross-domain requests to the API gateway whitelist; Routing component design, obtaining routing policies from the configuration center to the routing component, which then performs access permission verification for incoming requests and routing forwarding of outgoing requests according to the routing policies; and Canary release verification, performing canary release verification on the newly launched API gateway. The routing component's performance of access permission verification for incoming requests and routing forwarding of outgoing requests according to the routing policies includes: a) When the application starts, configuring... The configuration center asynchronously pulls routing policy information and caches it locally; b) when the routing policy changes, the configuration center issues the changes in real time; c) when an application receives an HTTP request, it determines whether a direct connection is allowed based on the routing policy; d) when an application sends a request to the downstream, it determines whether to connect directly or enter the API gateway, and performs corresponding service discovery and load balancing operations based on the determination result; the routing policy includes: switch control, domain list, domain application relationship list, public application whitelist, and public API whitelist; the switch control includes multi-level switch control of master switch, domain switch, and application switch; the step of storing the routing policy in the configuration center and issuing it to each application includes: storing the routing policy in the configuration center and issuing it to the routing components of each application in real time.

2. The intranet microservice governance method according to claim 1, characterized in that, The process of building the API gateway cluster includes: building an API gateway cluster based on Apisix; treating the API gateway as a microservice, with the instance automatically registered to the service registry after startup; and configuring an elastic scaling strategy for the API gateway cluster in the Kubernetes cluster.

3. The intranet microservice governance method according to claim 1, characterized in that, The API list can be obtained in the following ways: by analyzing the mapping relationship between call chain data and application domains to clean and output the API list; or by obtaining it through log statistical analysis.

4. The intranet microservice governance method according to claim 1, characterized in that, The gray-scale verification of the newly launched API gateway includes: judging whether there is an anomaly by monitoring the log system or using the promethues metric alarm; if an anomaly is found, the corresponding switch in the switch control is turned off.

5. The intranet microservice governance method according to claim 1, characterized in that, It also includes a traffic management step, which obtains the processor utilization rate of the previous time period. When the utilization rate exceeds the set upper limit threshold, the read speed is limited to 90% of the previous time period. When the utilization rate exceeds the set lower limit threshold, the read speed is limited to 110% of the previous time period.

6. An intranet microservice governance device, comprising: The domain segmentation module is used to segment applications by domain and establish a mapping relationship between applications and domains; The gateway routing policy configuration module is used to configure routing policies, store the routing policies in the configuration center, and distribute them to various applications. The API gateway setup module is used to build an API gateway cluster. The API publishing module is used to publish a list of APIs for cross-domain requests to the API gateway whitelist; the routing component design module is used to obtain routing policies from the configuration center and send them to the routing component, which then performs access permission verification for incoming requests and routes and forwards outgoing requests according to the routing policies. The gray-scale verification module is used to perform gray-scale verification on newly launched API gateways; The routing component performs access permission verification for incoming requests and routing forwarding for outgoing requests according to the routing policy, including: a) when the application starts, asynchronously pulling routing policy information through the client of the configuration center and caching it locally; b) when the routing policy changes, the configuration center issues the changes in real time; c) when the application receives an HTTP request, it determines whether direct connection is allowed according to the routing policy; d) when the application sends a request to the downstream, it determines whether to connect directly or enter the API gateway, and performs corresponding service discovery and load balancing operations based on the determination result; the routing policy includes: switch control, domain list, domain application relationship list, public application whitelist, and public API whitelist; the switch control includes multi-level switch control of master switch, domain switch, and application switch; the step of storing the routing policy in the configuration center and issuing it to each application includes: storing the routing policy in the configuration center and issuing it to the routing components of each application in real time.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images