A unified service scheduling method and device based on a micro-service gateway, medium and equipment

Abstract

The application discloses the technical field of micro-service gateway and relates to a unified service scheduling method and device based on a micro-service gateway, a medium and equipment, which comprises the following steps: deploying a service gateway to each middle platform tenant; pulling corresponding service configurations from a gateway configuration center through the service gateway; acquiring full initialization data of the service gateway through a management tool; connecting the service gateway to a registration center in the corresponding middle platform tenant to realize automatic service registration and route construction; when the route is changed, sending a change notification to a message component through the management tool; and the service gateway receives the change notification and updates the memory route. The application solves the technical problems that the system based on the micro-service gateway cannot realize fault isolation and automatic service registration in the prior art, realizes hierarchical routing and multi-tenant isolation by setting multiple gateway components, ensures the isolation of the traffic of each middle platform, avoids single-node faults, realizes automatic service registration and route construction, and effectively unifies the service call management of each middle platform.

Description

Technical Field

[0001] This invention relates to a unified service scheduling method, apparatus, medium, and device based on a microservice gateway, belonging to the field of microservice gateway technology. Background Technology

[0002] As Chinese enterprises comprehensively advance digital transformation, the State Grid Corporation of my country is vigorously promoting its enterprise middle platform strategy, building business middle platforms, data middle platforms, and technology middle platforms. These platforms cover the company's power grid production, financial management, marketing services, project management, and other business operations, as well as data analysis needs such as data aggregation and computation, and technological applications in areas such as artificial intelligence, GIS, and video. This has created a "large middle platform, small front-end" digital application model, laying a solid foundation for the company to quickly and flexibly respond to new business needs and provide emerging services. On top of the enterprise middle platform, business applications such as Marketing 2.0, PMS 3.0, and State Grid Online are being built to quickly support the digital application needs of the new power system. However, in promoting the middle platform strategy and fully leveraging its value to serve front-end businesses, some problems still exist, affecting its widespread adoption:

[0003] Due to differences in construction timing and the products used, there are certain differences in the technical roadmap of microservice gateways in the middle platform. Most newly built middle platforms are based on Spring Cloud to build microservice systems, while some use microservice gateway products from native cloud vendors, such as CSB, APIGateway, and Romma. Although these technical differences do not have much impact on the use of front-end business applications, they have created some difficulties in terms of business service integration and unified service scheduling.

[0004] Most middleware platforms use the mainstream OAuth 2.0 protocol for authentication and authorization between clients and services, employing Appid and AppSecret to transmit client identification and key information, and using service path URLs for routing. However, some middleware platforms, due to their earlier development and considerations such as using web services for compatibility with traditional business services, have designed and maintained their own routing and authentication information to implement related functions. These issues have created significant challenges for subsequent application developers using various middleware services, establishing a certain barrier to entry. Often, different middleware services require different authentication logic and different parameters.

[0005] Microservices (or microservice architecture) is a cloud-native architectural approach where a single application consists of many loosely coupled and independently deployable smaller components or services. Its main purpose is to decompose functionality into discrete services, thereby reducing system coupling and providing more flexible service support. The concept of microservices emerged in 2012 as a way to accelerate the development of web and mobile applications. It began to gain attention in 2014, and 2015 can be considered the inaugural year of microservices.

[0006] His main difference from the traditional monolithic web development model is:

[0007] The monolithic architecture package all functionality into a single WAR file, with virtually no external dependencies (except for the container). It's deployed within a JEE container (Tomcat, JBoss, WebLogic) and includes all logic such as DO / DAO, Services, and the UI. Its advantages include simple development, centralized management, minimal duplication of development, and local functionality, eliminating the overhead of distributed management and invocation. However, it also suffers from limitations such as low throughput, difficult maintenance, inflexibility, and poor scalability. In contrast, the microservice architecture breaks down the monolithic application into more independent microservices based on principles like business decoupling, enabling agile development and deployment.

[0008] Different microservices typically have different network addresses, and external clients may need to call the interfaces of multiple services to fulfill a single business requirement. Allowing clients to communicate directly with each microservice presents several problems: clients will make multiple requests to different microservices, increasing client complexity; cross-domain requests exist, which can be complex to handle in certain scenarios; authentication is complex, as each service requires independent authentication; refactoring is difficult, as project iterations may necessitate refactoring of microservices—for example, merging multiple services into one or splitting one service into multiple parts. If clients communicate directly with microservices, refactoring becomes extremely difficult. Furthermore, some microservices may use firewall-protected or browser-unfriendly protocols, making direct access challenging.

[0009] A gateway acts as an intermediary layer between the client and the server, handling all external requests first. This means that API implementation focuses more on business logic, while security, performance, and monitoring are handled by the gateway. This improves business flexibility without compromising security. It offers advantages such as security, ease of monitoring, ease of authentication, and easy unified authorization. Only the gateway system is exposed externally; microservices can remain hidden on the internal network, protected by a firewall. Monitoring data can be collected at the gateway and pushed to external systems for analysis. Authentication can be performed at the gateway before forwarding requests to backend microservices, eliminating the need for authentication within each microservice. This reduces the number of interactions between the client and each microservice.

[0010] A microservice gateway is a system that allows us to perform authentication, security control, unified log processing, and easy monitoring by exposing the microservice gateway system.

[0011] There are many technologies for implementing microservice gateways. Typical examples include Nginx (Tengine X), a high-performance HTTP and reverse proxy web server that also provides IMAP / POP3 / SMTP services. Zuul, from Netflix, is a JVM-based routing and server-side load balancer. Spring Cloud Gateway is a Spring-based gateway project that integrates circuit breakers and path rewriting, offering better performance than Zuul.

[0012] Patent application number 202210432495.X—a business fusion method based on a service gateway—registers business systems as services to a service gateway. It employs RESTful API technology in the business systems to publish functions as interfaces, and associates services and API interfaces in the gateway. The gateway configures services and interfaces; it uses a multi-interface publishing method to connect the API interfaces included in the service with users, providing data services to them; it achieves data interconnection and interoperability, providing data to superiors and subordinates, and supporting data sharing across multiple departments. However, this invention registers the services of each business system to a unified gateway for business service fusion. All service request traffic from all systems is routed and forwarded through this business fusion gateway, which can easily lead to single-node failures and reliability risks. Furthermore, when the service pressure of one system is high, it can easily affect service requests from other systems, failing to achieve fault isolation and causing localized impacts on the global system. Furthermore, in a cross-tenant environment on a cloud platform, services cannot be registered to a unified business convergence gateway through the original business system's registration center. Instead, services need to be registered and published to the convergence gateway manually or through other means, which is not suitable for the automatic service registration under the current cloud-native microservice architecture. Summary of the Invention

[0013] The purpose of this invention is to provide a unified service scheduling method, apparatus, medium, and device based on a microservice gateway, addressing the problems in existing technologies where microservice gateway-based systems cannot achieve fault isolation and cannot automatically register services.

[0014] To achieve the above objectives / to solve the above technical problems, the present invention is implemented using the following technical solution.

[0015] In a first aspect, the present invention provides a unified service scheduling method based on a microservice gateway, comprising:

[0016] Deploy service gateways to each middleware tenant and configure the corresponding middleware tenant IDs; the service gateways connect to the gateway configuration center, management tools, and messaging components;

[0017] The service gateway retrieves the corresponding service configuration from the gateway configuration center, and the service gateway starts listening to the message component body according to the default configuration of the message component;

[0018] The management tool obtains the full initialization data of the service gateway and the corresponding middleware tenant ID, and connects the service gateway to the registration center within the corresponding middleware tenant to achieve automatic service registration and route construction.

[0019] When a route changes, the management tool sends a change notification to the message component, and the service gateway receives the change notification and updates the memory route.

[0020] Furthermore, it also includes collecting service gateway operation logs through the messaging component, which are then subscribed to and processed by the management tool.

[0021] Furthermore, it also includes using a traffic gateway as the traffic entry point for service requests before deploying the service gateway to each middleware tenant; the traffic gateway adopts a lightweight load balancing component.

[0022] Furthermore, when deploying the service gateway to each middleware tenant, other components are deployed to a public VPC to achieve a unified entry point and scheduling management for services.

[0023] Furthermore, when deploying service gateways to each middleware tenant, a cascading gateway is set up to cascade with the service gateway and traffic gateway. The cascading gateway is used for service connections between parallel networks, basic capability authentication and authorization, and mutual trust authentication with the next gateway.

[0024] Furthermore, the service gateway enables listening to the message component body according to the default configuration of the message component, including listening to relevant route changes, permission changes and configuration parameter information of the message component.

[0025] Furthermore, the service gateway adopts reactive programming and a filter chain processing pattern, and improves throughput through fully asynchronous processing; the service gateway inserts customized extension components into the processing chain through the filter chain processing pattern, and the customized extension components include blacklist / whitelist components, authentication and authorization components, and access log components.

[0026] Secondly, the present invention provides a unified service scheduling device based on a microservice gateway, comprising:

[0027] The gateway deployment module is used to deploy service gateways to each middleware tenant and configure the corresponding middleware tenant IDs; the service gateways connect to the gateway configuration center, management tools, and messaging components.

[0028] The gateway configuration module is used to pull the corresponding service configuration from the gateway configuration center through the service gateway. The service gateway starts listening to the message component body according to the default configuration of the message component.

[0029] The data initialization module is used to obtain the full initialization data of the service gateway and the corresponding middleware tenant ID through the management and control tool, and connect the service gateway to the registration center within the corresponding middleware tenant to realize automatic service registration and route construction.

[0030] The change notification module is used to send a change notification to the message component through the management tool when the route changes. The service gateway receives the change notification and updates the memory route.

[0031] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the unified service scheduling method based on a microservice gateway as described in any of the first aspects.

[0032] Fourthly, the present invention provides an apparatus comprising:

[0033] Memory, used to store instructions;

[0034] A processor for executing the instructions, causing the device to perform operations implementing the unified service scheduling method based on a microservice gateway as described in any of the first aspects.

[0035] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0036] This invention provides a unified service scheduling method, apparatus, medium, and device based on a microservice gateway. By setting up multi-level gateway components, hierarchical routing is achieved. Service gateways are deployed to each middleware tenant, realizing multi-tenant isolation, ensuring traffic isolation between middleware platforms, and avoiding single-node failures. Through management tools, the service gateways are connected to the registry center within the corresponding middleware tenant to achieve automatic service registration and route construction, effectively unifying the management of service calls across middleware platforms, and facilitating the management and value discovery of middleware services. Attached Figure Description

[0037] Figure 1 The figure shown is a schematic diagram of the overall process of a unified service scheduling method based on a microservice gateway provided in Embodiment 1 of the present invention;

[0038] Figure 2 The diagram shown is a schematic representation of the overall service scheduling process in a unified service scheduling method based on a microservice gateway provided in Embodiment 1 of the present invention.

[0039] Figure 3 The diagram shown is a schematic representation of the operation flow when a client initiates a call to a middleware service in a unified service scheduling method based on a microservice gateway according to Embodiment 1 of the present invention.

[0040] Figure 4 The diagram shown is a schematic diagram of the internal request flow of a service gateway in a unified service scheduling method based on a microservice gateway provided in Embodiment 1 of the present invention. Detailed Implementation

[0041] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical solution of the present invention, rather than limitations thereof. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments can be combined with each other.

[0042] The term "and / or" simply describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0043] Example 1

[0044] like Figure 1 As shown in the figure, this embodiment introduces a unified service scheduling method based on a microservice gateway, including:

[0045] Deploy service gateways to each middleware tenant and configure the corresponding middleware tenant IDs; the service gateways connect to the gateway configuration center, management tools, and messaging components;

[0046] The service gateway retrieves the corresponding service configuration from the gateway configuration center, and the service gateway starts listening to the message component body according to the default configuration of the message component;

[0047] The management tool obtains the full initialization data of the service gateway and the corresponding middleware tenant ID, and connects the service gateway to the registration center within the corresponding middleware tenant to achieve automatic service registration and route construction.

[0048] When a route changes, the management tool sends a change notification to the message component, and the service gateway receives the change notification and updates the memory route.

[0049] The service gateway's operational logs are collected through the messaging component and then subscribed to and processed by the management tool.

[0050] The following section provides a detailed description of the unified service scheduling method based on a microservice gateway described in this embodiment. For example... Figure 2 As shown, this embodiment designs a unified service scheduling platform, including a traffic gateway, a service gateway, management and control tools, a cascading gateway, a gateway configuration center, a message component, and a data storage component.

[0051] The service gateway, acting as the service gateway for a single middleware platform, implements service proxy functions within its domain. It primarily handles service routing and authentication, and possesses capabilities such as scalable logging, security protection, rate limiting, and circuit breaking.

[0052] A traffic gateway can serve as a unified traffic entry point for service requests. It employs lightweight load balancing components, such as commonly used Nginx, OpenRestry, or Alibaba ALB, to separate request traffic, enabling service request traffic access and load balancing. Routing policies can be configured according to gateway tenants, prioritizing service routing and forwarding. The use of lightweight components also ensures that the gateway layer does not negatively impact service forwarding performance.

[0053] Cascading gateways primarily enable cascading with other gateways. They are mainly used for service connections between parallel networks when headquarters and provincial / municipal companies independently deploy middleware platforms. They provide basic capabilities such as authentication, authorization, and mutual trust authentication with the next-hop gateway. Cascading gateways at the same level have the same capabilities.

[0054] The management and control tools are mainly used to manage the functions and configurations of various gateways.

[0055] The gateway configuration center is responsible for the service registration, configuration management and distribution functions of the entire service scheduling platform.

[0056] The message component uses the MQ message component, which is mainly used for cross-domain message communication, configuration distribution and log collection between management tools and service gateways. It can be used to decouple data request forwarding and management control.

[0057] The data storage components include RDS relational database and Redis cache database, which are mainly used for storing various types of data on the service scheduling platform, including relational storage of basic data, as well as caching of core authentication, routing data, etc.

[0058] This platform is designed and implemented primarily with consideration of the current multi-tenant isolation environment based on State Grid Cloud. VPC1 and VPC2 are the networks where various middleware applications are deployed, and they are isolated from other VPCs (Virtual Private Clouds). VPC0 is a public VPC, and only this VPC is allowed to communicate with other VPCs. Therefore, the service gateway is deployed under each middleware tenant, while other components are deployed under the public VPC, thereby achieving a unified entry point and scheduling management for services.

[0059] The following section details the cross-tenant interaction between the service gateway and the management tool. The interaction logic for other cascade gateways and traffic gateways is similar but simplified.

[0060] First, deploy the service gateway to each middleware tenant and configure the corresponding middleware tenant ID or code so that the management tools can identify and manage the corresponding middleware tenant.

[0061] Next, the service gateway configuration is distributed. The service gateway can connect to the configuration center based on the domain name and port of its built-in gateway registration configuration center, and pull the corresponding service configuration from the gateway configuration center. At the same time, according to the default configuration of the message component, it starts listening to specific subjects of the message component, listening for information such as relevant route changes, permission changes, and configuration parameters.

[0062] Subsequently, the service gateway data is initialized. Full initialization data for the service gateway is obtained from the initialization service of the management tool. Its own routing table, permission table, etc., are constructed. Simultaneously, the middleware tenant ID or code is identified, and a connection is made to the registry center within this middleware tenant to achieve automatic service registration and route construction. This is compatible with various service registries, including common ones such as EDS, CSE, and Nacos.

[0063] Next, a change notification is sent. After the management tool changes the tenant route, it sends a change notification to the TOPIC topic associated with the middle platform tenant in the message queue (MQ). The middle platform tenant's service gateway receives the change notification and updates the in-memory route. The switch parameters are sent through the same TOPIC topic and are distinguished by message type.

[0064] Finally, service gateway operation logs are collected. The message queue (MQ) receives the gateway operation logs, which are then subscribed to and processed by the management platform. This subscription processing includes writing to Elasticsearch (ES) or driving Flink for real-time calculation. Each gateway node periodically sends heartbeat information via the MQ message component to monitor its health status.

[0065] It should be noted that, generally speaking, RDS and Redis cannot be accessed across VPCs, and gateways cannot directly connect to the storage.

[0066] The overall service scheduling process during actual access and runtime is as follows: Figure 3 As shown in the diagram, a call to the middleware service initiated by the client typically involves five forwarding steps. Steps ① and ③ primarily involve the overhead of the cloud platform's inter-tenant load balancer (SLB). Step ② uses the traffic gateway as the entry point, acting as a soft load balancer to route services between different service gateway tenants. Step ④ involves the traffic gateway routing the request to the designated middleware tenant service gateway. Step ⑤ involves the service gateway performing authentication and authorization before forwarding the request to the appropriate service. Generally, service gateway authentication and authorization are integrated with a unified authentication center to implement business application authentication and service authorization. Therefore, in this embodiment, the conventional OAuth 2.0 protocol is used, integrated with the company's unified authorization center.

[0067] like Figure 4 The diagram shown is a schematic diagram of the internal request flow of the service gateway in an embodiment of the present invention.

[0068] In this embodiment, the service gateway adopts reactive programming and a filter chain processing pattern, using fully asynchronous processing as the main means to improve throughput. Spring Cloud Gateway itself is implemented using Reactor + Netty technology, which has the advantages of high concurrency and high throughput of reactive programming. The design and development of related extended components must fully comply with the requirements of Reactor programming and be implemented using reactive programming.

[0069] Customized extension components such as blacklists / whitelists, authentication and authorization, and access logging are all inserted into the processing chain using filters. Non-core business logic within these filters, such as logging, sending access logs, and dynamic routing configuration, is executed asynchronously and is not coupled with core components. Extended filters perform parameter checks and exception handling to prevent gateway unavailability due to runtime anomalies.

[0070] The blacklist / whitelist filter component controls access to applications and IPs, preventing access to those on the blacklist. Its key feature is efficient blacklist caching. Blacklists typically have small amounts of data, allowing them to be entirely cached in memory. Data changes are communicated via a message bus, and gateway nodes subscribe to and update the memory cache.

[0071] The authentication object in the Filter component is the business application. The business application needs to register with the platform, which assigns it an appId and an appSecret. When the application makes a call, it first uses the appId and appSecret to obtain a token. Subsequent service calls need to add x-token and x-app-id to the request header.

[0072] After the authentication and authorization component intercepts the request, it checks the validity of the token and whether the access URL has permission. If the verification is successful, it proceeds to the next step.

[0073] The authentication and authorization function is entirely self-developed and is one of the functions that has a significant impact on gateway performance. Under high concurrency, the cost of querying authentication and authorization data is high. Therefore, it is necessary to use a combination of memory first-level caching and Redis second-level caching to cache the original authentication data, authorization data, and authentication and authorization result data, and update the cached data with an asynchronous message notification mechanism.

[0074] In Redis, the cached application information consists of appid and appSecret, and the token information consists of appid, token, and token plaintext; the cache permission configuration information consists of appid and URL pattern, and the cache authentication result consists of appid, valid address, and true / false.

[0075] The authentication process is as follows:

[0076] (1) The application uses appId and appSecret to apply for a token. After successful gateway authentication, the token and token plaintext are written to Redis and local cache.

[0077] (2) When the application calls the service, add authentication parameters such as x-app-id and x-token to the header.

[0078] (3) The gateway node checks the header. If there are no authentication parameters, it returns an unauthenticated error code. Otherwise, it loads the token from the local cache or Redis. If the token does not exist or has expired, it returns an unauthenticated error code. If the token is valid, the authentication is successful.

[0079] The authentication process is as follows:

[0080] (1) Parse the request URL, remove URL parameters, and obtain the valid address.

[0081] (2) Check if there is an authentication result for this valid address in the local cache or Redis. If there is, process it directly based on the cache result, and the processing method is to allow or deny access.

[0082] (3) If there is no authentication result in both levels of cache, it generally means that the application is calling this address for the first time. Then, it will match in the application permission configuration list and the matching result will be true / false. After that, the authentication result will be cached in memory and Redis. The authentication result is appid, valid address and true / false. Based on the authentication result, subsequent processing will be carried out. The processing method is to allow or deny access.

[0083] When configuration data changes, the management tool sends a notification. Upon receiving the change message, the gateway node deletes the relevant local cache entries and updates the Redis cache entries. The latest data is then loaded from Redis when needed later. For example, after deleting an application's access permissions to a URL, the cached application permission record and corresponding authentication results in Redis must be deleted, as well as the authentication results cached locally on each gateway node, to ensure consistency between configuration and results.

[0084] In production environments, application registration and permission changes are infrequent, so caching can effectively improve performance.

[0085] The access log filter component sends access logs to the message bus using asynchronous messaging.

[0086] The access log mainly consists of data items such as application identifier, request address, application IP, user identifier, user IP, terminal type, network type (internal / external network), status (successful call, authentication failure, authorization failure, etc.), initiation time, forwarding time, middleware identifier, and request / response. Among these, the application identifier, user identifier, user IP, terminal type, and network type (internal / external network) are passed by the caller in the request header. The request address and application IP are obtained by the system analyzing the request object. The middleware identifier comes from the gateway configuration file. Request / response data is intercepted and extracted by a filter. The size of the saved request / response data needs to be controlled here; normally, only a portion of the data needs to be extracted.

[0087] Operation logs are typically stored locally in log files. The operation log collection component uses FileBeat + Elasticsearch to asynchronously collect log files. Unifying the collection, storage, and analysis of operation logs from gateway cluster nodes enables rapid location and analysis of runtime anomalies. Collecting logs from each POD node in a container environment is particularly important for problem analysis.

[0088] Local log file writing uses an asynchronous log appender from an open-source logging framework, separating log file writing from the main logic to reduce the impact on the main logic.

[0089] FileBeat scans specified log files outside the gateway program process, without affecting the operation of the gateway program.

[0090] This embodiment designs a hierarchical, multi-level gateway node system to implement hierarchical routing and multi-tenant isolation control. Different gateway nodes perform different functions. Considering the different deployment tenants in each middleware platform, the service gateway is deployed down to each middleware tenant, connecting to its original registry center. This enables automatic service registration and discovery within the middleware platform without requiring secondary discovery and routing configuration. This is a physical multi-tenant implementation of service scheduling capabilities. Service requests from each middleware platform are independent of each other, and request blocking or failures will not affect the services of other middleware platforms. The service gateway and management tools communicate using MQ to ensure asynchronous communication efficiency and ensure the isolation of control flow data and request data flow. The service gateway implements local caching to ensure the performance of request forwarding.

[0091] This method effectively unifies the management of service calls across various middleware platforms. By leveraging the proprietary registry centers of each middleware platform, services are registered with the scheduling platform for unified publishing and management. Other business applications can then access services from all the major middleware platforms through a unified service call entry point. This facilitates the management and value discovery of middleware services, lowers the barrier to entry for front-end applications, and leverages the advantages of enterprise-level infrastructure. It ensures traffic isolation across middleware platforms, avoids single-node failures, and utilizes cloud-native elastic scaling and fault recovery capabilities to guarantee the high availability and reliability of the unified service scheduling platform.

[0092] Example 2

[0093] Based on the same inventive concept as Embodiment 1, this embodiment introduces a unified service scheduling device based on a microservice gateway, comprising:

[0094] The gateway deployment module is used to deploy service gateways to each middleware tenant and configure the corresponding middleware tenant IDs; the service gateways connect to the gateway configuration center, management tools, and messaging components.

[0095] The gateway configuration module is used to pull the corresponding service configuration from the gateway configuration center through the service gateway. The service gateway starts listening to the message component body according to the default configuration of the message component.

[0096] The data initialization module is used to obtain the full initialization data of the service gateway and the corresponding middleware tenant ID through the management and control tool, and connect the service gateway to the registration center within the corresponding middleware tenant to realize automatic service registration and route construction.

[0097] The change notification module is used to send a change notification to the message component through the management tool when the route changes. The service gateway receives the change notification and updates the memory route.

[0098] The specific functions of each module described above are explained in the relevant content of the method in Embodiment 1, and will not be repeated here.

[0099] Example 3

[0100] Based on the same inventive concept as other embodiments, this embodiment introduces a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the unified service scheduling method based on a microservice gateway as described in any of Embodiment 1.

[0101] Example 4

[0102] Based on the same inventive concept as other embodiments, this embodiment describes a device comprising:

[0103] Memory, used to store instructions;

[0104] A processor is configured to execute the instructions, causing the device to perform operations implementing the unified service scheduling method based on a microservice gateway as described in any of Embodiment 1.

[0105] In summary, the present invention provides a unified service scheduling method, apparatus, medium, and device based on a microservice gateway. By setting up multi-level gateway components, hierarchical routing is achieved. Service gateways are deployed to each middleware tenant, achieving multi-tenant isolation, ensuring traffic isolation between middleware platforms, and avoiding single-node failures. Through management tools, the service gateways are connected to the registry center within the corresponding middleware tenant to achieve automatic service registration and route construction, effectively unifying the management of service calls across middleware platforms, and facilitating the management and value discovery of middleware services.

[0106] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0107] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0108] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0110] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A unified service scheduling method based on a microservice gateway, characterized in that, include: Deploy the service gateway to each middleware tenant and configure the corresponding middleware tenant ID; The service gateway connects the gateway configuration center, management tools, and messaging components; The service gateway retrieves the corresponding service configuration from the gateway configuration center, and the service gateway starts listening to the message component body according to the default configuration of the message component; The management tool obtains the full initialization data of the service gateway and the corresponding middleware tenant ID, and connects the service gateway to the registration center within the corresponding middleware tenant to achieve automatic service registration and route construction. When a route changes, the management tool sends a change notification to the message component, and the service gateway receives the change notification and updates the memory route. Before deploying the service gateway to each middleware tenant, the traffic gateway is used as the traffic entry point for service requests; the traffic gateway adopts a lightweight load balancing component. When deploying the service gateway to each middleware tenant, other components are deployed to the public VPC to achieve a unified entry point and scheduling management for services; When deploying service gateways to each middleware tenant, cascade gateways are set up to cascade with service gateways and traffic gateways. The cascade gateways are used for service connections between parallel networks, basic capability authentication and authorization, and mutual trust authentication with the next gateway.

2. The unified service scheduling method based on a microservice gateway according to claim 1, characterized in that, It also includes collecting service gateway operation logs through the messaging component, which are then subscribed to and processed by the management tool.

3. The unified service scheduling method based on a microservice gateway according to claim 1, characterized in that, The service gateway starts listening to the message component body according to the default configuration of the message component, including listening to relevant route changes, permission changes and configuration parameter information of the message component.

4. The unified service scheduling method based on a microservice gateway according to claim 1, characterized in that, The service gateway adopts reactive programming and a filter chain processing pattern, and improves throughput through fully asynchronous processing. The service gateway inserts customized extension components into the processing chain through the filter chain processing pattern. The customized extension components include blacklist / whitelist components, authentication and authorization components, and access log components.

5. A unified service scheduling device based on a microservice gateway, characterized in that, include: The gateway deployment module is used to deploy service gateways to each middleware tenant and configure the corresponding middleware tenant IDs. The service gateway connects the gateway configuration center, management tools, and messaging components; The gateway configuration module is used to pull the corresponding service configuration from the gateway configuration center through the service gateway. The service gateway starts listening to the message component body according to the default configuration of the message component. The data initialization module is used to obtain the full initialization data of the service gateway and the corresponding middleware tenant ID through the management and control tool, and connect the service gateway to the registration center within the corresponding middleware tenant to realize automatic service registration and route construction. The change notification module is used to send a change notification to the message component through the management tool when the route changes. The service gateway receives the change notification and updates the memory route. Before deploying the service gateway to each middleware tenant, the traffic gateway is used as the traffic entry point for service requests; the traffic gateway adopts a lightweight load balancing component. When deploying the service gateway to each middleware tenant, other components are deployed to the public VPC to achieve a unified entry point and scheduling management for services; When deploying service gateways to each middleware tenant, cascade gateways are set up to cascade with service gateways and traffic gateways. The cascade gateways are used for service connections between parallel networks, basic capability authentication and authorization, and mutual trust authentication with the next gateway.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the unified service scheduling method based on a microservice gateway as described in any one of claims 1-4.

7. A device, characterized in that, include: Memory, used to store instructions; A processor is configured to execute the instructions, causing the device to perform operations implementing the unified service scheduling method based on a microservice gateway as described in any one of claims 1-4.

Images