Service chain invocation request processing method and apparatus, electronic device, and program product

Abstract

The application discloses a service chain calling request processing method and device, electronic equipment and program product, and relates to the technical field of micro services, wherein the processing method comprises the following steps: receiving a service chain calling request initiated by a user through a gateway component, judging the user type of the user based on business requirements, setting a gray label in the service chain calling request through the gateway component in the case that the user type is a gray type, obtaining a target service chain calling request, routing and forwarding the target service chain calling request through a service routing component based on preset service instance information and preset service version configuration information, and routing the target service chain calling request to the service instance corresponding to the last micro service in the service calling link information. The application solves the technical problem that consistency of gray service chain calling cannot be guaranteed in the related art.

Description

Technical Field

[0001] This invention relates to the field of microservices technology, and more specifically, to a method and apparatus for processing service chain call requests, as well as electronic devices and program products. Background Technology

[0002] The TravelSky Application Platform (TAP) is an independently controllable PaaS (Platform as a Service) cloud computing application platform. TAP boasts high performance, high availability, and high concurrency, serving as the open cloud computing platform technology foundation for the cloudification and microservice-based operation of the civil aviation passenger PPS (Passenger Processing System) business system. It is the core foundational platform for realizing the "de-hosting" of civil aviation operations.

[0003] The Microservice Distributed Control System (MDCS) is the core RPC (Remote Procedure Call) transaction framework of the TAP platform. Based on hierarchical addressing theory, MDCS designs a high-performance cloud-native microservice framework based on hierarchical partitioned service discovery.

[0004] Figure 1 This is a schematic diagram of an optional MDCS microservice framework architecture based on related technologies, such as... Figure 1 As shown, it includes: a global registry center, a partition registry center, a configuration center, a routing component, and microservices. The global registry center is responsible for registering routes and for microservices to subscribe to routes; the configuration center is responsible for configuring microservice subscriptions; and the partition registry center is responsible for registering microservices within each partition and for the routing component to subscribe to services.

[0005] When microservice A accesses microservice B, it first finds the corresponding partition for microservice B based on the service partition mapping table, then finds the routing component for the corresponding partition based on the global registry center, and sends a request. The routing component sends the request to the corresponding microservice B based on the microservice registration information and microservice version control information of this partition.

[0006] The core idea of ​​the MDCS microservice framework is that each partition has its own dedicated set of routing components and a partition registry center, and all inter-service calls are scheduled through the routing components. This microservice framework design reduces the global risks that a single registry center might cause, and the fact that services need to access each other through the routing components allows for convenient and flexible control of service scheduling strategies. During service canary releases, the routing components can transparently implement traffic canary control. Figure 2 This is a diagram illustrating an optional MDCS microservice traffic canary deployment method from related technologies, such as... Figure 2 As shown, SVCA / SVCB / SVCC (Service A / Service B / Service C) have deployed version 1.0.0 / 1.0.1 services respectively. Users can initiate requests through the API (Application Programming Interface) gateway, and the routing component can implement canary traffic control for different versions based on the microservice version control information.

[0007] When a service chain call relationship exists, for example Furthermore, since each service has two versions released, it is impossible to precisely control the version during the service chain call process. Figure 3 This is a diagram illustrating an optional service chain call and service version based on related technologies, such as... Figure 3 As shown, SVCA 1.0.0, SVCA 1.0.1, SVCB 1.0.0, SVCB 1.0.1, SVCC 1.0.0, and SVCC 1.0.1 are deployed. Users initiate service chain call requests through the API gateway. During the service routing process, there are eight possible combinations of service chain call versions. The service chain call results are shown in Table 1.

[0008] Table 1

[0009]

[0010] As business complexity increases, implementing a complex business function requires the involvement of multiple service implementations. Therefore, during the canary rollout process, when switching some users, it is necessary to ensure that the entire service chain calls use the canary version, i.e. .

[0011] Therefore, based on the above requirements, it is necessary to implement a transparent and non-intrusive service chain canary call mechanism on the basis of the existing MDCS microservice framework to ensure the consistency of canary service chain calls.

[0012] There is currently no effective solution to the above problems. Summary of the Invention

[0013] This invention provides a method, apparatus, electronic device, and program product for processing service chain call requests, so as to at least solve the technical problem in the related art that the consistency of gray-scale service chain calls cannot be guaranteed.

[0014] According to one aspect of the present invention, a method for processing service chain call requests is provided, applied to a service distributed control system of a microservice framework. The service distributed control system includes at least a gateway component and a service routing component. The processing method includes: receiving a service chain call request initiated by a user through the gateway component, and determining the user type based on business requirements, wherein the service chain call request contains sequentially connected service call chain information; if the user type is a grayscale type, setting a grayscale marker in the service chain call request through the gateway component to obtain a target service chain call request; and routing and forwarding the target service chain call request through the service routing component based on preset service instance information and preset service version configuration information, until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information, wherein the service instance is used to process the business processing logic in the target service chain call request.

[0015] Furthermore, the service distributed control system also includes: a delivery and deployment component and a service registration component. Before receiving service chain call requests initiated by users through the gateway component, it also includes: deploying each service instance of each microservice through the delivery and deployment component, wherein each service instance has corresponding metadata, which includes at least: service name, service address, and service version; when a microservice starts a service instance, the service registration component registers the metadata of the service instance to the service registry center and updates the preset service instance information of the service registry center.

[0016] Furthermore, the service distributed control system also includes a service configuration component, which, before receiving service chain call requests initiated by users through the gateway component, also includes configuring a base version, a canary version, and a traffic policy for each microservice through the service configuration component to obtain preset service version configuration information, wherein the traffic policy is a strategy for scheduling requests.

[0017] Furthermore, the steps for determining a user's user type based on business needs include: obtaining a gray-scale strategy based on business needs, wherein the gray-scale strategy includes at least a gray-scale list; matching the user's user identifier with each gray-scale user identifier in the gray-scale list, and determining that the user's user type is gray-scale if a match is successful.

[0018] Furthermore, the step of obtaining the target service chain call request by setting a grayscale label in the service chain call request through the gateway component includes: parsing the service chain call request to determine the communication protocol field; adding a grayscale label to the communication protocol field to obtain the target service chain call request.

[0019] Furthermore, based on preset service instance information and preset service version configuration information, the service routing component routes and forwards the target service chain call request until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information. This step includes: parsing the target service chain call request to obtain the communication protocol field and the name of the called service; determining the target service instance of the called microservice indicated by the called service name based on the communication protocol field, preset service instance information, and preset service version configuration information; processing the business processing logic in the target service chain call request through the target service instance to obtain the next called service name; and invoking the service routing component to continue routing the target service chain call request to the next target service instance corresponding to the next called microservice indicated by the next called service name, until the target service chain call request is routed to the last target service instance corresponding to the last microservice in the service call chain information.

[0020] Furthermore, the step of determining the target service instance of the called microservice indicated by the called service name based on the communication protocol field, preset service instance information, and preset service version configuration information includes: if the communication protocol field carries a grayscale label, determining whether the called microservice indicated by the called service name has a grayscale version based on the preset service version configuration information; if the called microservice has a grayscale version, querying the service instance corresponding to the service version equal to the grayscale version based on the preset service instance information, and determining the service instance as the target service instance; if the called microservice does not have a grayscale version, determining any service instance indicated by the called service name as the target service instance based on the preset service instance information, wherein the service version of the target service instance is the base version.

[0021] Furthermore, the step of determining the target service instance of the called microservice indicated by the called service name based on the communication protocol field, preset service instance information, and preset service version configuration information further includes: if the communication protocol field does not carry a grayscale label, determining whether the called microservice indicated by the called service name has a grayscale version based on the preset service version configuration information; if the called microservice has a grayscale version, determining whether the called microservice is configured with a traffic policy based on the preset service version configuration information; if it is determined that the called microservice is configured with a traffic policy, counting the current request volume; and based on the traffic policy and the current request volume... The system determines whether to route the target service chain call request to the service instance corresponding to the grayscale version. If it is determined that the target service chain call request should be routed to the service instance corresponding to the grayscale version, based on the preset service instance information, it queries the service instance corresponding to the service version that is equal to the grayscale version and identifies the service instance as the target service instance. If the called microservice does not have a grayscale version, or if it is determined that the target service chain call request should not be routed to the service instance corresponding to the grayscale version, based on the preset service instance information, it identifies any service instance indicated by the name of the called service as the target service instance, where the service version of the target service instance is the base version.

[0022] According to another aspect of the present invention, a service chain call request processing apparatus is also provided, applied to a service distributed control system of a microservice framework. The service distributed control system includes at least a gateway component and a service routing component. The processing apparatus includes: a judgment unit, configured to receive a service chain call request initiated by a user through the gateway component and determine the user type based on business requirements, wherein the service chain call request includes sequentially connected service call chain information; a setting unit, configured to set a grayscale marker in the service chain call request through the gateway component when the user type is grayscale, thereby obtaining a target service chain call request; and a routing unit, configured to route and forward the target service chain call request through the service routing component based on preset service instance information and preset service version configuration information, until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information, wherein the service instance is used to process the business processing logic in the target service chain call request.

[0023] Furthermore, the service distributed control system also includes: a delivery and deployment component and a service registration component. The processing device is also used to: before receiving a service chain call request initiated by a user through the gateway component, deploy each service instance of each microservice through the delivery and deployment component, wherein each service instance has metadata, and the metadata includes at least: service name, service address, and service version; when a microservice starts a service instance, register the metadata of the service instance to the service registry center through the service registration component, and update the preset service instance information of the service registry center.

[0024] Furthermore, the service distributed control system also includes a service configuration component. The processing device is further configured to: before receiving a service chain call request initiated by a user through the gateway component, configure a base version, a canary version, and a traffic policy for each microservice through the service configuration component to obtain preset service version configuration information, wherein the traffic policy is a strategy for scheduling requests.

[0025] Furthermore, the judgment unit is also used to: obtain a grayscale strategy based on business needs, wherein the grayscale strategy includes at least a grayscale list; match the user's user identifier with each grayscale user identifier in the grayscale list, and determine that the user's user type is grayscale if the match is successful.

[0026] Furthermore, the setting unit is also used to: parse the service chain call request and determine the communication protocol field; add a grayscale label to the communication protocol field to obtain the target service chain call request.

[0027] Furthermore, the routing unit is also used to: parse the target service chain call request to obtain the communication protocol field and the name of the called service; determine the target service instance of the called microservice indicated by the called service name based on the communication protocol field, preset service instance information, and preset service version configuration information; process the business processing logic in the target service chain call request through the target service instance to obtain the next called service name; and call the service routing component to continue routing the target service chain call request to the next target service instance corresponding to the next called microservice indicated by the next called service name, until the target service chain call request is routed to the last target service instance corresponding to the last microservice in the service call chain information.

[0028] Furthermore, the routing unit is also used to: when the communication protocol field carries a grayscale label, determine whether the called microservice indicated by the called service name has a grayscale version based on the preset service version configuration information; when the called microservice has a grayscale version, query the service instance corresponding to the service version equal to the grayscale version based on the preset service instance information, and determine the service instance as the target service instance; when the called microservice does not have a grayscale version, determine any service instance indicated by the called service name as the target service instance based on the preset service instance information, wherein the service version of the target service instance is the base version.

[0029] Furthermore, the routing unit is also used to: when the communication protocol field does not carry a grayscale label, determine whether the called microservice indicated by the called service name has a grayscale version based on the preset service version configuration information; when the called microservice has a grayscale version, determine whether the called microservice has a traffic policy configured based on the preset service version configuration information; when it is determined that the called microservice has a traffic policy configured, count the current request volume; based on the traffic policy and the current request volume, determine whether to route the target service chain call request to the service instance corresponding to the grayscale version; when it is determined that the target service chain call request should be routed to the service instance corresponding to the grayscale version, query the service instance corresponding to the service version equal to the grayscale version based on the preset service instance information, and determine the service instance as the target service instance; when the called microservice does not have a grayscale version, or when it is determined that the target service chain call request should not be routed to the service instance corresponding to the grayscale version, determine any service instance indicated by the called service name as the target service instance based on the preset service instance information, wherein the service version of the target service instance is the base version.

[0030] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements a method for processing service chain call requests as described above.

[0031] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described service chain call request processing methods.

[0032] In this invention, a gateway component receives service chain call requests initiated by users and determines the user type based on business requirements. If the user type is grayscale, the gateway component sets a grayscale marker in the service chain call request to obtain the target service chain call request. Based on preset service instance information and preset service version configuration information, the service routing component routes and forwards the target service chain call request until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information. This solves the technical problem in related technologies that cannot guarantee the consistency of grayscale service chain calls.

[0033] This invention employs a service chain canary deployment mechanism based on the microservice framework MDCS. A gateway component receives service chain call requests initiated by users and parses the sequentially connected service call chain information. Based on business requirements, it determines the user type. When the user type is confirmed to be canary, the gateway component injects a canary marker into the request to generate a target service chain call request. Then, a service routing component subscribes to preset service instance information and preset service version configuration information. Based on the canary marker and version mapping relationship, the target request is routed and forwarded level by level until it reaches the microservice instance at the end of the chain to execute business logic. This ensures that all microservice nodes in the service chain call the same canary version instance, achieving end-to-end consistency and precise control of canary traffic during the service chain call process. This solves the technical problem of existing microservice frameworks in complex service chain scenarios, where independent canary deployments of each service lead to chaotic version combinations and an inability to guarantee overall business logic consistency. It avoids business conflicts or data anomalies caused by version inconsistencies and improves the stability of canary deployments. Attached Figure Description

[0034] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0035] Figure 1 This is a schematic diagram of an optional MDCS microservice framework architecture based on related technologies;

[0036] Figure 2 This is a schematic diagram of an optional MDCS microservice traffic grayscale implementation based on related technologies;

[0037] Figure 3 This is a diagram illustrating an optional service chain call and service version based on related technologies;

[0038] Figure 4 This is a flowchart of an optional service chain call request processing method according to an embodiment of the present invention;

[0039] Figure 5 This is a flowchart of an optional service chain call request processing method according to an embodiment of the present invention;

[0040] Figure 6 This is a schematic diagram of an optional service routing rule according to an embodiment of the present invention;

[0041] Figure 7 This is a schematic diagram of an optional service chain call according to an embodiment of the present invention;

[0042] Figure 8 This is a schematic diagram of an optional service chain call request processing device according to an embodiment of the present invention;

[0043] Figure 9 This is a hardware structure block diagram of an electronic device (or mobile device) for processing service chain call requests according to an embodiment of the present invention. Detailed Implementation

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

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

[0046] It should be noted that all related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected and involved in this invention are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data comply with the relevant laws, regulations, and standards of the relevant regions, and necessary measures have been taken to ensure compliance with public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained only after receiving consent from the aforementioned user or organization.

[0047] This invention proposes a non-intrusive service chain canary release method based on the microservice framework MDCS, which can ensure consistent service chain calls when multiple microservices are launched simultaneously for canary release.

[0048] This invention offers non-intrusiveness and service chain consistency guarantees. First, business applications require no code modification; they only need to register version information upon service startup and configure the mapping between the base version and the grayscale version through the delivery deployment component. This allows for rapid access to grayscale capabilities, significantly reducing the access cost and operational complexity of grayscale releases. Second, by uniformly injecting grayscale tags through the API gateway and implementing cross-node pass-through of the tags in the service routing component, it ensures that in complex service chain call scenarios (such as A→B→C), all services in the entire call chain accurately call the same grayscale version, avoiding business logic conflicts or data anomalies caused by version inconsistencies. Furthermore, this invention supports independent configuration of traffic ratios for multiple services, offering flexible and adjustable grayscale strategies. It allows for fine-grained control of the grayscale traffic share for each service, meeting the smooth deployment needs of businesses in batches and for different user groups, and significantly improving the stability and controllability of the civil aviation core transaction system during grayscale releases.

[0049] The present invention will now be described in detail with reference to various embodiments.

[0050] Example 1

[0051] According to an embodiment of the present invention, an embodiment of a service chain call request processing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0052] Figure 4This is a flowchart of an optional service chain call request processing method according to an embodiment of the present invention, such as... Figure 4 As shown, the method includes the following steps:

[0053] Step S401: Receive the service chain call request initiated by the user through the gateway component, and determine the user type based on business requirements. The service chain call request contains information on the sequentially connected service call chain.

[0054] In this embodiment of the invention, a service distributed control system applicable to a microservice framework is provided, which includes: a gateway component, a service routing component, a delivery and deployment component, a service registration component, and a service configuration component.

[0055] When an external user or upstream system initiates a business request, the request first reaches the API gateway component. The gateway component parses the user identifier (such as user ID or tenant identifier) ​​in the request and performs a matching calculation based on pre-defined grayscale policy rules (e.g., the user ID hash value falling within a specific range). If a match is successful, the user is determined to be of grayscale type; otherwise, they are determined to be of normal type. During this process, the gateway component extracts the service call sequence carried in the request, for example, "SVCA→SVCB→SVCC". This sequence represents the sequentially connected service call chain information, used to determine the order of subsequent calls.

[0056] Here, the gateway component refers to the API gateway in the system, which serves as a unified entry point for traffic and is responsible for request admission control and preprocessing.

[0057] User type refers to the user category divided according to the grayscale strategy, including grayscale type and non-grayscale type (normal type), which is used to distinguish whether special grayscale routing logic is executed.

[0058] Service call chain information refers to the topological sequence describing the call relationships between microservices, clarifying the flow path of requests in the microservice architecture.

[0059] Step S402: If the user type is grayscale, the grayscale flag is set in the service chain call request through the gateway component to obtain the target service chain call request.

[0060] In this embodiment of the invention, when the gateway component determines that the user type is grayscale, it injects specific identification information, i.e., a grayscale marker, into the communication protocol header or a specific field. For example, in the communication protocol, the value of the tap-grey field is set to 1. This operation transforms the original ordinary service chain call request into a target service chain call request carrying a grayscale marker. This marker will be transparently transmitted between microservices along with the request, ensuring that each component in the chain can recognize the grayscale attribute of the request.

[0061] Step S403: Based on the preset service instance information and preset service version configuration information, the target service chain call request is routed and forwarded through the service routing component until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information. The service instance is used to process the business processing logic in the target service chain call request.

[0062] In this embodiment of the invention, after receiving a target service chain call request carrying a grayscale marker, the service routing component parses the grayscale marker in the request. If the grayscale marker is identified, the routing component queries the subscribed preset service version configuration information (such as the grayscale version of the service recorded in the configuration center), and combines it with the preset service instance information (the IP (address) and service version of each version service instance registered in the registry center), and forwards the request to the matching grayscale version service instance (such as SVCA version 1.0.1) according to the configuration policy. After the instance finishes processing, the next calling service (such as SVCB) is determined according to the service call chain information, and the above routing logic is executed again until the end of the chain. Finally, the request reaches the service instance corresponding to the last microservice in the chain, and the final business processing logic is executed by that instance.

[0063] Here, the default service instance information refers to the metadata of all currently available microservice instances maintained in the service registry, including information such as IP address, port, and current running version.

[0064] The default service version configuration information refers to the version policy maintained in the service configuration center, including the base version, gray-scale version and corresponding traffic ratio of each service.

[0065] A service instance refers to a logical unit that actually deploys and runs microservice code, responsible for executing specific business logic.

[0066] In summary, a service chain canary deployment mechanism based on the MDCS microservice framework can be adopted. The gateway component receives service chain call requests initiated by users and parses the sequentially connected service call chain information. Based on business requirements, it determines the user type. When the user type is confirmed to be canary, the gateway component injects a canary tag into the request to generate the target service chain call request. Then, the service routing component subscribes to preset service instance information and preset service version configuration information. Based on the canary tag and version mapping relationship, the target request is routed and forwarded level by level until the request reaches the microservice instance at the end of the chain to execute business logic. This ensures that all microservice nodes in the service chain call the same canary version instance, achieving end-to-end consistency and precise control of canary traffic during the service chain call process. This solves the technical problem of existing microservice frameworks in complex service chain scenarios, where independent canary deployments of each service lead to chaotic version combinations and an inability to guarantee overall business logic consistency. It avoids business conflicts or data anomalies caused by version inconsistencies and improves the stability of canary deployments.

[0067] Optionally, the service distributed control system further includes: a delivery deployment component and a service registration component. In order to update service instance information in real time, in the service chain call request processing method provided in Embodiment 1 of this application, before receiving the service chain call request initiated by the user through the gateway component, each service instance of each microservice is deployed through the delivery deployment component. The service instance has corresponding metadata, which includes at least: service name, service address, and service version. When the microservice starts a service instance, the service registration component registers the metadata of the service instance with the service registry center and updates the preset service instance information of the service registry center.

[0068] In this embodiment of the invention, when a service instance starts, it registers its own metadata with the partition registry center through the service registration component, including the service name, IP address, and version number (such as 1.0.0 or 1.0.1).

[0069] Specifically, operations personnel or automated pipelines deliver the microservice code package and configuration files to the target server via deployment components and start the microservice to generate the corresponding service instance. During the service instance startup initialization phase, the instance collects its own runtime metadata, which includes at least a "service name" to uniquely identify the service, a "service address" (such as IP address and port number) for network communication, and a "service version" (e.g., 1.0.0 or 1.0.1) to identify the current running version of the instance. Then, the service instance initiates a registration request to the distributed service registry center through the internally integrated service registration component, reporting the collected metadata. After receiving the registration request, the service registry center writes the new service instance information into its maintained data structure, thereby updating the "preset service instance information," so that subsequent routing components can obtain the latest service instance list and its version attributes.

[0070] Here, the delivery and deployment component refers to the operation and maintenance tools or platform modules responsible for building, packaging, distributing, and managing the startup of microservice code packages. It is the executor that realizes the physical or logical deployment of service instances.

[0071] The service registration component refers to the client module embedded in the microservice framework, which is responsible for communicating with the registry center when the service instance starts up, and performing functions such as service registration, deregistration and heartbeat reporting.

[0072] A service registry is a central storage component in a microservice architecture that stores instance metadata and provides service discovery and query functionality.

[0073] For example, a service instance is deployed through a delivery component, and its metadata information is registered with the service registry when the service starts. Key information in this metadata includes the service name, service IP address, and service version. The service routing component subscribes to service instance information.

[0074] Figure 5 This is a flowchart of an optional service chain call request processing method according to an embodiment of the present invention, such as... Figure 5 As shown, when a service instance starts, it registers its metadata (including service name sev, service IP, service version ver, and call type kind) with the partition registry center. For example, the metadata of service instance SVCA 1.0.1 includes: sev: SVCA, ip: 10.22.50.7, ver: 1.0.1, kind: rpc; the metadata of service instance SVCB 1.0.1 includes: sev: SVCB, ip: 10.22.50.8, ver: 1.0.1, kind: rpc; and the metadata of service instance SVCC 1.0.1 includes: sev: SVCC, ip: 10.22.50.9, ver: 1.0.1, kind: rpc.

[0075] In this embodiment, by standardizing the deployment and registration process of service instances, the automated collection and centralized management of service metadata are achieved, ensuring the real-time and completeness of the preset service instance information in the service registry. This provides an accurate data foundation for subsequent precise routing based on version information, ensuring the reliability of service discovery and the stability of service chain calls under the microservice architecture.

[0076] Optionally, the service distributed control system further includes a service configuration component. In order to improve the accuracy of determining service version configuration information, in the service chain call request processing method provided in Embodiment 1 of this application, before receiving the service chain call request initiated by the user through the gateway component, the service configuration component configures the basic version, grayscale version and traffic policy for each microservice to obtain preset service version configuration information. The traffic policy is a strategy for scheduling requests.

[0077] In this embodiment of the invention, operations and maintenance personnel maintain the "basic version" and "grayscale version" configuration information of each service in the configuration center by delivering deployment components, forming a version mapping table.

[0078] Specifically, operations and maintenance personnel or automated configuration tools access the configuration center through the service configuration component to create or update version configuration entries for each microservice deployed in the system (such as SVCA, SVCB, etc.). This configuration entry explicitly specifies the base version currently running stably for the microservice (e.g., 1.0.0) and the new canary version used for canary release testing (e.g., 1.0.1). Simultaneously, specific traffic policies are defined for these two versions. These policies specify the distribution ratio or rules for incoming service requests across different versions; for example, setting the base version to receive 90% of the traffic and the canary version to receive 10%, or setting all traffic from a specific user identifier to go to the canary version. The service configuration component persistently stores this configuration data, including the base version, canary version, and corresponding traffic policies, forming preset service version configuration information. When the service routing component subscribes to this configuration information, it can obtain the latest version mapping relationship and scheduling rules, thereby distributing requests to the appropriate service instances according to the policy when executing routing decisions.

[0079] Here, the service configuration component refers to the module used to create, modify, query, and publish microservice configuration data. It is usually used as a client or management interface of the configuration center for operations and maintenance personnel or for the system to automatically inject version control policies.

[0080] The base version refers to the version of the microservice that is currently providing stable services and carrying the majority of business traffic. It is usually a mature version that has been fully tested and put into operation.

[0081] A gray-scale release refers to a new release version of a microservice that is tested and validated only within a specific range or proportion of user traffic, in order to reduce the risks that may arise from launching a new version.

[0082] Traffic strategy refers to a set of rules that define how to distribute requests flowing into a service to different version instances, including but not limited to traffic percentage allocation and precise routing rules based on user tags.

[0083] Preset service version configuration information refers to a structured data set stored in the configuration center that describes the version status of each microservice and the corresponding traffic allocation rules. It is the data source on which the service routing component selects versions.

[0084] For example, the base version, canary version, and traffic policy for each service are configured through the delivery component and written to the service configuration center. The service routing component subscribes to the configuration policy for each service. Service configuration information is shown in Table 2:

[0085] Table 2

[0086]

[0087] In this embodiment, the service configuration component enables centralized management and dynamic configuration of service version policies, allowing the preset service version configuration information to reflect the gray-scale requirements of business releases in real time. This ensures that the service routing component can accurately schedule requests based on the latest traffic policies, thereby achieving flexibility and controllability in gray-scale releases. It supports different services to independently configure differentiated gray-scale ratios, meeting the operational and maintenance needs for smoothly launching new versions in complex business scenarios.

[0088] To improve the accuracy of determining a user's user type, in the service chain call request processing method provided in Embodiment 1 of this application, a grayscale strategy is obtained based on business requirements. The grayscale strategy includes at least a grayscale list. The user's user identifier is matched with each grayscale user identifier in the grayscale list, and if the match is successful, the user's user type is determined to be grayscale.

[0089] In this embodiment of the invention, based on the gray-scale requirements of the service release, a preset gray-scale strategy is loaded from the configuration center or local cache. The core data set of this strategy is a gray-scale list, which contains a set of user identifiers (such as user ID, device fingerprint, or tenant ID) authorized to enter the gray-scale environment. When the API gateway component receives a service chain call request initiated by a user, the gateway component extracts the user identifier in the request and compares or hashes it with each gray-scale user identifier in the gray-scale list. If the user identifier to be matched is found to exist in the gray-scale list, the match is considered successful, and the user type corresponding to the request is marked as gray-scale type; if no match is found, the user type is determined to be a normal type, thereby completing the gray-scale attribute determination of the user identity.

[0090] In this embodiment, an automated and accurate identification of grayscale users is achieved through a precise matching mechanism based on the grayscale list. This ensures that only authorized user traffic can be marked as grayscale, thereby preventing non-target users from accidentally entering the grayscale environment and ensuring the accuracy and security of the grayscale release process.

[0091] In order to accurately set grayscale tags in service chain call requests, the service chain call request processing method provided in Embodiment 1 of this application parses the service chain call request to determine the communication protocol field; and adds grayscale tags to the communication protocol field to obtain the target service chain call request.

[0092] In this embodiment of the invention, when a grayscale user initiates a request, the API gateway component identifies the user's identity (e.g., through user ID, tenant identifier, grayscale policy, etc.) and injects a grayscale marker into the request's communication header. This marker will be passed down level by level in the service chain to ensure that the grayscale identifier is consistent throughout the entire call chain.

[0093] Specifically, after receiving a service chain call request initiated by an upstream user, the API gateway component parses the request to extract the communication protocol fields. These fields typically include an HTTP header (Hypertext Transfer Protocol Header) or a custom binary protocol header, used to carry metadata for the service call. After determining that the user type is grayscale, the API gateway component inserts or modifies specific key-value pairs, i.e., grayscale tags, in the parsed communication protocol fields (e.g., setting the field name "tap-grey" to the value "1"). This operation transforms the original ordinary request into a target service chain call request carrying a grayscale identifier. This target service chain call request is then forwarded to the service routing component, enabling other microservice nodes in the chain to identify the grayscale attribute of the request by parsing the same communication protocol fields, thereby achieving end-to-end transparent transmission of grayscale tags.

[0094] For example, when a request reaches the API gateway component, and the API gateway component determines that the user is a gray-scale user based on the rules, then it adds the following to the communication protocol: The tag is then forwarded to the service routing component. The core fields of the communication protocol are shown in Table 3.

[0095] Table 3

[0096]

[0097] In this embodiment, by parsing the service chain call request and injecting grayscale tags at the gateway layer, the standardized embedding and transparent transmission of grayscale identifiers at the communication protocol level are realized. This ensures the consistency of grayscale identity recognition among all nodes in the call chain from the entry point to the end point, avoids the problem of inconsistent grayscale service chain call versions caused by lost or incorrectly transmitted version information, and improves the accuracy and reliability of grayscale release.

[0098] To improve the accuracy of request routing, the service chain call request processing method provided in Embodiment 1 of this application parses the target service chain call request to obtain the communication protocol field and the name of the called service; based on the communication protocol field, preset service instance information, and preset service version configuration information, the target service instance of the called microservice indicated by the called service name is determined; the business processing logic in the target service chain call request is processed through the target service instance to obtain the next called service name; the service routing component is invoked to continue routing the target service chain call request to the next target service instance corresponding to the next called microservice indicated by the next called service name, until the target service chain call request is routed to the last target service instance corresponding to the last microservice in the service call chain information.

[0099] In this embodiment of the invention, after receiving a request, the service routing component parses the grayscale marker in the communication protocol: (1) If the request carries a grayscale marker, the request is routed to the matching grayscale version instance based on the "grayscale version" configuration of the service in the configuration center and the available service instance version information in the registry center; (2) If there is no grayscale marker and the traffic percentage is configured, the request is routed to different version service instances according to the traffic grayscale; otherwise, the request is routed to the basic version instance.

[0100] In service chain call scenarios, such as Grayscale marker The request header is passed through to downstream services. The routing component of each service node makes routing decisions based on the same grayscale tag and version mapping relationship with the configuration center, thereby ensuring that all services in the entire call chain call the same version of the instance, achieving grayscale consistency in the service chain.

[0101] Specifically, the service routing component receives the target service chain call request forwarded by the API gateway component, parses the request, and extracts the communication protocol fields and the name of the service being called in the current request.

[0102] The service routing component queries local cache or subscribed preset service instance information (including the IP, port, version, and other status of each service instance) and preset service version configuration information (including basic version, canary version, and traffic policy). Based on the canary tag in the communication protocol field, combined with the above two types of configuration information, the service routing component uses a preset routing algorithm (if the canary tag matches, it points to the canary version instance; if no tag is found, it points to the basic version instance according to traffic ratio or by default) to select a unique target service instance from the list of available instances. After determining the target service instance, the service routing component forwards the request to that target service instance.

[0103] After the target service instance executes its specific business logic, it generates or resolves the name of the next called service (i.e., the next service node in the service chain). Then, the current service node (or its proxy) invokes its local service routing component to send the target service chain call request to the next node again. This process is repeated cyclically, that is, each time the request is parsed, the target service instance of the next hop is determined, the logic is executed, and the name of the next called service is obtained, until the request is routed to the last target service instance corresponding to the last microservice defined in the service call chain information, thus completing the entire service chain call.

[0104] In this embodiment, by parsing the request fields, combining version configuration and instance information to make dynamic routing decisions, and passing the request step by step in the service chain to the destination, a non-intrusive, end-to-end consistent canary service call mechanism is implemented. This ensures that in a complex microservice architecture, canary user requests can accurately flow through the correct version instance of all service chain nodes, effectively avoiding business anomalies caused by version mixing and improving the stability and reliability of the system's canary release.

[0105] To improve the accuracy of determining the service instance to be routed, in the service chain call request processing method provided in Embodiment 1 of this application, when the communication protocol field carries a grayscale label, it is determined whether the called microservice indicated by the called service name has a grayscale version based on the preset service version configuration information; if the called microservice has a grayscale version, it is queried based on the preset service instance information to find the service instance corresponding to the service version equal to the grayscale version, and the service instance is determined as the target service instance; if the called microservice does not have a grayscale version, it is determined as the target service instance based on the preset service instance information, wherein the service version of the target service instance is the base version.

[0106] In this embodiment of the invention, after receiving a target service chain call request, the service routing component can first check whether the communication protocol field carries a grayscale label. If a grayscale label is detected, it indicates that the current request is grayscale traffic. The service routing component then queries the preset service version configuration information to determine whether the called microservice is configured with a grayscale version. If a grayscale version is configured, the service routing component further queries the preset service instance information, filters out service instances that completely match the grayscale version number, and determines the filtered instance as the target service instance. If the preset service version configuration information shows that the called microservice is not configured with a grayscale version, or although it is configured, there is no available instance, the service routing component falls back to the basic strategy, queries the preset service instance information, and selects any service instance (i.e., the basic version service instance) under the name of the called service as the target service instance.

[0107] In this embodiment, by distinguishing whether a service has a grayscale version, precise grayscale instance matching or the default basic version rollback strategy is executed respectively, thus achieving the robustness and compatibility of grayscale routing logic. This ensures that services that support grayscale can accurately execute grayscale logic, while also ensuring that services that do not support grayscale can still provide services normally, thereby improving the stability and fault tolerance of the microservice framework in complex grayscale scenarios.

[0108] To further improve the accuracy of determining the service instance to be routed, in the service chain call request processing method provided in Embodiment 1 of this application, when the communication protocol field does not carry a grayscale label, it is determined whether the called microservice indicated by the called service name has a grayscale version based on the preset service version configuration information; if the called microservice has a grayscale version, it is determined whether the called microservice is configured with a traffic policy based on the preset service version configuration information; if it is determined that the called microservice is configured with a traffic policy, the current request volume is counted; based on the traffic policy and the current request volume, it is determined whether to route the target service chain call request to the service instance corresponding to the grayscale version; if it is determined that the target service chain call request will be routed to the service instance corresponding to the grayscale version, based on the preset service instance information, the service instance corresponding to the service version equal to the grayscale version is queried, and the service instance is determined as the target service instance; if the called microservice does not have a grayscale version, or if it is determined that the target service chain call request will not be routed to the service instance corresponding to the grayscale version, based on the preset service instance information, any service instance indicated by the called service name is determined as the target service instance, wherein the service version of the target service instance is the base version.

[0109] In this embodiment of the invention, after receiving a target service chain call request, the service routing component checks whether the communication protocol field carries a grayscale label. If no grayscale label is carried, it indicates that the request comes from a regular user. The service routing component then queries the preset service version configuration information to determine whether the called microservice has a grayscale version configured. If a grayscale version exists, the service routing component further queries the preset service version configuration information of the service to confirm whether a traffic policy controlling the proportion of grayscale traffic is configured. If a traffic policy is configured, the service routing component counts the current request volume (such as the total number of requests per unit time or a seed value based on hashing) and, based on the grayscale traffic percentage set in the traffic policy, determines whether the current request falls within the grayscale range using a random algorithm or a hash modulo algorithm. If the determination result is that it falls within the grayscale range, the service routing component, based on the preset service instance information, queries a service instance whose running version matches the grayscale version and identifies it as the target service instance. If the determination result is that it does not fall within the grayscale range, or the called microservice does not have a grayscale version, the service routing component, based on the preset service instance information, selects any service instance (i.e., the basic version service instance) under the name of the called service as the target service instance.

[0110] For example, the service routing component, as the core node of traffic scheduling, executes routing decisions based on the grayscale markers in the communication protocol, the service version policy of the configuration center, and the service instance information of the registration center. The specific rules are as follows: if the request header carries the `tap-grey=1` marker, it directly routes to the grayscale version instance of that service, achieving precise traffic redirection for grayscale users; if it does not carry a grayscale marker, it further determines whether the configuration center has configured a traffic ratio (greyflow). If configured, traffic is randomly distributed to either the base version or the grayscale version according to the ratio; otherwise, it routes uniformly to the base version. This rule supports the transparent transmission of grayscale markers in service chain scenarios, ensuring version consistency throughout the entire call chain. It also supports on-demand configuration of differentiated grayscale policies for multiple services, meeting the flexible deployment needs of complex business scenarios.

[0111] Figure 6 This is a schematic diagram of an optional service routing rule according to an embodiment of the present invention, such as... Figure 6As shown, when a request reaches the service routing component, the component routes the request based on the communication protocol field, the service instance information of the registry center, and the service configuration information of the configuration center. Specifically, it first checks if `tap-grey=1`. If `tap-grey=1`, it looks up the service configuration information based on the `tap-svc` field to determine if `greyver` is configured. If `greyver` is configured, it finds the corresponding `greyver` version service instance based on the registry information and routes the request to that instance. If `greyver` is not configured, it finds the corresponding `basever` version service instance based on the registry information and routes the request to that instance. If tap-grey ≠ 1, then the service configuration information is looked up based on the tap-svc field to determine if greyflow is configured. If greyflow is configured, then the current request should enter greyver based on the previous request volume statistics. If it enters greyver, then the corresponding greyver version service instance is found based on the registration information, and the request is routed to the greyver version service instance. If greyflow is not configured, or if it does not enter greyver, then the corresponding basever version service instance is found based on the registration information, and the request is routed to the basever version service instance.

[0112] In this embodiment, by introducing a random gray-scale distribution mechanism based on traffic strategy, the system can automatically guide a portion of ordinary traffic to the gray-scale version according to a preset ratio without relying on explicit user tagging. This achieves a smooth transition and automated traffic control for gray-scale releases, while maintaining the basic version routing for gray-scale requests that do not hit, thus balancing the flexibility of gray-scale verification with the stability of system operation.

[0113] The following describes in detail another optional implementation method.

[0114] In this embodiment of the invention, a non-intrusive service chain canary call system based on the microservice framework MDCS is proposed, including: an API gateway component, a service routing component, a service registration component, a service configuration center component, and a delivery and deployment component.

[0115] Among them, the API gateway component: according to business needs, it tags grayscale users and sets grayscale tags in the communication protocol.

[0116] Service routing component: Subscribes to the service registry to obtain service instance information; subscribes to the service configuration center to obtain service version configuration information. Based on whether a grayscale flag is set in the communication protocol, and the service version configuration information in the configuration center and the service registration information in the registry, the request is routed to the correct service version instance.

[0117] Service registration component: When a service instance starts, it registers service metadata information, including service IP, service version, etc.

[0118] Service Configuration Center Component: Records service base version and service grayscale version configuration information.

[0119] Deployment components are delivered: Operations personnel deploy service instances and configure service version information through delivery components.

[0120] Figure 7 This is a schematic diagram of an optional service chain call according to an embodiment of the present invention, such as... Figure 7 As shown, operations and maintenance personnel deploy service instances (e.g., SVCA 1.0.0, SVCB 1.0.0, SVCB 1.0.0, SVCA 1.0.1, SVCB 1.0.1, SVCB 1.0.1) using delivery deployment components (delivery tools), and maintain the "base version" and "grayscale version" configuration information for each service in the configuration center, forming a version configuration mapping table. When a service instance starts, it registers its own metadata with the partition registry center through the service registration component, including the service name, IP address, and version number (e.g., 1.0.0 or 1.0.1). The service routing component can subscribe to the service instance information in the partition registry center and the service version configuration information in the configuration center. When user A and other users initiate requests, the API gateway component identifies the user's identity (e.g., user A is a grayscale user, and other users are regular users), and injects a grayscale marker into the communication protocol header of user A's request. This marker is passed down level by level in the service chain to ensure consistency of the grayscale identifier throughout the entire call chain. Upon receiving a request, the service routing component parses the grayscale marker in the communication protocol. If the request carries a grayscale marker, it routes the request to the matching grayscale version instance based on the "grayscale version" configuration of the service in the configuration center and the available service instance version information in the registry. If there is no grayscale marker and a traffic percentage is configured, the request is grayscaled to different version service instances according to the traffic volume; otherwise, it is routed to the base version instance. For example, the route for user A's request is: SVCA 1.0.1->SVCB 1.0.1->SVCB 1.0.1; the route for other users' requests is: SVCA 1.0.0->SVCB 1.0.0->SVCB 1.0.0.

[0121] In this embodiment of the invention, a service chain canary deployment mechanism based on the microservice framework MDCS is adopted. A gateway component receives service chain call requests initiated by users and parses the sequentially connected service call chain information. Based on business requirements, the user type is determined. When the user type is confirmed to be canary, the gateway component injects a canary marker into the request to generate a target service chain call request. Then, a service routing component subscribes to preset service instance information and preset service version configuration information. Based on the canary marker and version mapping relationship, the target request is routed and forwarded level by level until the request reaches the microservice instance at the end of the chain to execute business logic. This ensures that all microservice nodes in the service chain call the same canary version instance, thereby achieving end-to-end consistency and precise control of canary traffic during the service chain call process. This solves the technical problem of existing microservice frameworks in complex service chain scenarios, where independent canary deployments of each service lead to chaotic version combinations and an inability to guarantee overall business logic consistency. It avoids business conflicts or data anomalies caused by version inconsistencies and improves the stability of canary deployments.

[0122] The following is a detailed description with reference to another embodiment.

[0123] Example 2

[0124] The service chain call request processing device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above.

[0125] Figure 8 This is a schematic diagram of an optional service chain call request processing apparatus according to an embodiment of the present invention, such as... Figure 8 As shown, the processing device may include: a judgment unit 80, a setting unit 81, and a routing unit 82.

[0126] The judgment unit 80 is used to receive the service chain call request initiated by the user through the gateway component, and determine the user type based on business requirements. The service chain call request contains the service call chain information connected in sequence.

[0127] Setting unit 81 is used to set a grayscale flag in the service chain call request through the gateway component when the user type is grayscale type, so as to obtain the target service chain call request.

[0128] The routing unit 82 is used to route and forward the target service chain call request through the service routing component based on the preset service instance information and preset service version configuration information, until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information. The service instance is used to process the business processing logic in the target service chain call request.

[0129] The aforementioned processing device can employ a service chain canary deployment mechanism based on the MDCS microservice framework. It receives service chain call requests initiated by users through a gateway component and parses the sequentially connected service call chain information. Based on business requirements, it determines the user type. When the user type is confirmed to be canary, the gateway component injects a canary marker into the request to generate a target service chain call request. Then, it uses a service routing component to subscribe to preset service instance information and preset service version configuration information. Based on the canary marker and version mapping relationship, it routes and forwards the target request level by level until the request reaches the microservice instance at the end of the chain to execute business logic. This ensures that all microservice nodes in the service chain call the same canary version instance, achieving end-to-end consistency and precise control of canary traffic during the service chain call process. This solves the technical problem of existing microservice frameworks in complex service chain scenarios where independent canary deployments of each service lead to chaotic version combinations and an inability to guarantee overall business logic consistency. It avoids business conflicts or data anomalies caused by version inconsistencies and improves the stability of canary deployments.

[0130] Optionally, the service distributed control system further includes: a delivery and deployment component and a service registration component. The processing device is also used to: before receiving a service chain call request initiated by a user through the gateway component, deploy each service instance of each microservice through the delivery and deployment component, wherein the service instance has corresponding metadata, and the metadata includes at least: service name, service address, and service version; when a microservice starts a service instance, register the metadata of the service instance to the service registry center through the service registration component, and update the preset service instance information of the service registry center.

[0131] Optionally, the service distributed control system further includes a service configuration component. The processing device is also configured to: before receiving a service chain call request initiated by a user through the gateway component, configure a base version, a canary version, and a traffic policy for each microservice through the service configuration component to obtain preset service version configuration information, wherein the traffic policy is a strategy for scheduling requests.

[0132] Optionally, the judgment unit is further configured to: obtain a grayscale strategy based on business requirements, wherein the grayscale strategy includes at least a grayscale list; match the user's user identifier with each grayscale user identifier in the grayscale list, and determine that the user's user type is grayscale if the match is successful.

[0133] Optionally, the setting unit is also used to: parse the service chain call request and determine the communication protocol field; add a grayscale label to the communication protocol field to obtain the target service chain call request.

[0134] Optionally, the routing unit is further configured to: parse the target service chain call request to obtain the communication protocol field and the name of the called service; determine the target service instance of the called microservice indicated by the called service name based on the communication protocol field, preset service instance information, and preset service version configuration information; process the business processing logic in the target service chain call request through the target service instance to obtain the next called service name; and call the service routing component to continue routing the target service chain call request to the next target service instance corresponding to the next called microservice indicated by the next called service name, until the target service chain call request is routed to the last target service instance corresponding to the last microservice in the service call chain information.

[0135] Optionally, the routing unit is further configured to: when the communication protocol field carries a grayscale label, determine whether the called microservice indicated by the called service name has a grayscale version based on the preset service version configuration information; when the called microservice has a grayscale version, query the service instance corresponding to the service version equal to the grayscale version based on the preset service instance information, and determine the service instance as the target service instance; when the called microservice does not have a grayscale version, determine any service instance indicated by the called service name as the target service instance based on the preset service instance information, wherein the service version of the target service instance is the base version.

[0136] Optionally, the routing unit is further configured to: when the communication protocol field does not carry a grayscale label, determine whether the called microservice indicated by the called service name has a grayscale version based on the preset service version configuration information; when the called microservice has a grayscale version, determine whether the called microservice has a traffic policy configured based on the preset service version configuration information; when it is determined that the called microservice has a traffic policy configured, count the current request volume; based on the traffic policy and the current request volume, determine whether to route the target service chain call request to the service instance corresponding to the grayscale version; when it is determined that the target service chain call request should be routed to the service instance corresponding to the grayscale version, query the service instance corresponding to the service version equal to the grayscale version based on the preset service instance information, and determine the service instance as the target service instance; when the called microservice does not have a grayscale version, or when it is determined that the target service chain call request should not be routed to the service instance corresponding to the grayscale version, determine any service instance indicated by the called service name as the target service instance based on the preset service instance information, wherein the service version of the target service instance is the base version.

[0137] The aforementioned processing device may further include a processor and a memory. The aforementioned judgment unit 80, setting unit 81, routing unit 82, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0138] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, based on preset service instance information and preset service version configuration information, the service routing component routes and forwards target service chain call requests until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information.

[0139] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0140] This invention also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: receiving a service chain call request initiated by a user through a gateway component, and determining the user type based on business requirements; if the user type is grayscale, setting a grayscale marker in the service chain call request through the gateway component to obtain the target service chain call request; and routing and forwarding the target service chain call request through a service routing component based on preset service instance information and preset service version configuration information, until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information.

[0141] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements a method for processing service chain call requests as described above.

[0142] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the above-described service chain call request processing method.

[0143] Figure 9 This is a hardware structure block diagram of an electronic device (or mobile device) for processing service chain call requests according to an embodiment of the present invention. Figure 9 As shown, an electronic device may include one or more processors (e.g., Figure 9 The processors 902a, 902b, ..., 902n, etc., may include, but are not limited to, processing devices such as microprocessors (MCUs) or programmable logic devices (FPGAs), and a memory 904 for storing data. In addition, it may include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 9 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device may also include components that are more... Figure 9 The more or fewer components shown, or having the same Figure 9 The different configurations shown.

[0144] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0145] The embodiments or examples disclosed herein are not exhaustive, but merely illustrative of some embodiments or examples, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment or example can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment or example can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment or example can be arbitrarily interchanged. Furthermore, optional methods or examples in a particular embodiment or example can be arbitrarily combined; moreover, embodiments or examples can be arbitrarily combined. For example, some or all steps of different embodiments or examples can be arbitrarily combined, and a particular embodiment or example can be arbitrarily combined with optional methods or examples of other embodiments or examples.

[0146] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0147] In the several embodiments provided by this invention, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection can be through some interfaces; the indirect coupling or communication connection of units or modules can be electrical or other forms.

[0148] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0149] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0150] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0151] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for processing service chain invocation requests, characterized in that, A service distributed control system applied to a microservice framework, the service distributed control system comprising at least: a gateway component and a service routing component, the processing method comprising: The gateway component receives service chain call requests initiated by users and determines the user type based on business requirements. The service chain call request contains sequentially connected service call chain information. When the user type is grayscale, the gateway component sets a grayscale marker in the service chain call request to obtain the target service chain call request. Based on the preset service instance information and preset service version configuration information, the service routing component routes and forwards the target service chain call request until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information. The service instance is used to process the business processing logic in the target service chain call request.

2. The processing method according to claim 1, characterized in that, The service distributed control system further includes: a delivery and deployment component, a service registration component, and, before receiving a service chain call request initiated by a user through the gateway component, also includes: Each service instance of each microservice is deployed through the delivery and deployment component, wherein each service instance corresponds to metadata, and the metadata includes at least: service name, service address, and service version; When the microservice starts the service instance, the service instance's metadata is registered to the service registry center through the service registration component, and the preset service instance information of the service registry center is updated.

3. The processing method according to claim 1, characterized in that, The service distributed control system further includes: a service configuration component, which, before receiving a service chain call request initiated by a user through the gateway component, also includes: The service configuration component configures a base version, a canary version, and a traffic policy for each microservice to obtain the preset service version configuration information. The traffic policy is a strategy for scheduling requests.

4. The processing method according to claim 1, characterized in that, The steps for determining the user type based on business requirements include: Based on business needs, obtain a grayscale strategy, wherein the grayscale strategy includes at least: a grayscale list; The user's identifier is matched with each grayscale user identifier in the grayscale list, and if a match is successful, the user's user type is determined to be the grayscale type.

5. The processing method according to claim 1, characterized in that, The step of obtaining the target service chain call request by setting a grayscale marker in the service chain call request through the gateway component includes: The service chain call request is parsed to determine the communication protocol fields; Add a grayscale label to the communication protocol field to obtain the target service chain call request.

6. The processing method according to claim 1, characterized in that, Based on preset service instance information and preset service version configuration information, the service routing component routes and forwards the target service chain call request until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information. This includes the following steps: The target service chain call request is parsed to obtain the communication protocol field and the name of the called service; Based on the communication protocol field, the preset service instance information, and the preset service version configuration information, the target service instance of the microservice being called, indicated by the called service name, is determined. The business processing logic in the target service chain call request is processed by the target service instance to obtain the name of the next called service. The service routing component is invoked to continue routing the target service chain call request to the next target service instance corresponding to the next called microservice indicated by the next called service name, until the target service chain call request is routed to the last target service instance corresponding to the last microservice in the service call chain information.

7. The processing method according to claim 6, characterized in that, The step of determining the target service instance of the microservice to be called, indicated by the called service name, based on the communication protocol field, the preset service instance information, and the preset service version configuration information includes: If the communication protocol field carries a grayscale label, it is determined whether the microservice to be called indicated by the called service name has a grayscale version based on the preset service version configuration information. If the called microservice has the grayscale version, based on the preset service instance information, query the service instance corresponding to the service version that is equal to the grayscale version, and determine the service instance as the target service instance; If the called microservice does not have the grayscale version, based on the preset service instance information, any of the service instances indicated by the called service name is determined as the target service instance, wherein the service version of the target service instance is the base version.

8. The processing method according to claim 6, characterized in that, The step of determining the target service instance of the microservice being called, indicated by the called service name, based on the communication protocol field, the preset service instance information, and the preset service version configuration information, further includes: If the communication protocol field does not carry a grayscale label, it is determined whether the microservice to be called indicated by the called service name has a grayscale version based on the preset service version configuration information. If the called microservice has the grayscale version, determine whether the called microservice has a traffic policy configured based on the preset service version configuration information; If it is determined that the invoked microservice is configured with the traffic policy, the current request volume is counted. Based on the traffic strategy and the current request volume, determine whether to route the target service chain call request to the service instance corresponding to the grayscale version; If it is determined that the target service chain call request will be routed to the service instance corresponding to the gray version, based on the preset service instance information, the service instance corresponding to the service version that is equal to the gray version is queried, and the service instance is determined as the target service instance; If the called microservice does not have the grayscale version, or if it is determined that the target service chain call request will not be routed to the service instance corresponding to the grayscale version, based on the preset service instance information, any of the service instances indicated by the called service name is determined as the target service instance, wherein the service version of the target service instance is the base version.

9. A processing apparatus for service chain invocation requests, characterized in that, A service-distributed control system applied to a microservice framework, the service-distributed control system comprising at least: a gateway component and a service routing component, the processing device comprising: The judgment unit is used to receive a service chain call request initiated by a user through the gateway component, and determine the user type of the user based on business requirements, wherein the service chain call request includes service call chain information connected in sequence; The setting unit is used to set a grayscale marker in the service chain call request through the gateway component when the user type is grayscale type, so as to obtain the target service chain call request. The routing unit is used to route and forward the target service chain call request through the service routing component based on preset service instance information and preset service version configuration information, until the target service chain call request is routed to the service instance corresponding to the last microservice in the service call chain information, wherein the service instance is used to process the business processing logic in the target service chain call request.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the service chaining call request processing method according to any one of claims 1 to 8.

Images