Method, apparatus and device for degraded execution of a service

Abstract

This specification discloses a method, apparatus, and device for service degradation execution. The scheme includes: based on a first sidecar module in an upstream first application, detecting whether the current service state of the service execution system has reached a degradation threshold; if so, marking each request within a preset degradation time window with a degradation label based on the first sidecar module; when the first application calls a downstream second application, writing the degradation label into a network packet through the first sidecar module; obtaining the degradation label by parsing the network packet through a second sidecar module in the second application, and rewriting the degradation label into the next network packet, so as to pass the degradation label step-by-step to each application along the service execution link; obtaining the corresponding degradation label passed in by the sidecar module according to the degradation SDK in each application, and performing degradation operations on each application based on the degradation label, thus performing adaptive degradation of the service execution link.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to a method, apparatus, and device for degrading the execution of a business. Background Technology

[0002] In a microservice distributed architecture, business requests may require the collaborative processing of multiple applications to complete. When a dependent downstream service fails, or a dependent function cannot meet the current business requirements, it may lead to problems such as page loading failure and payment interruption. This not only affects user experience but may also result in financial losses and damage user trust in the enterprise.

[0003] The current approach of using pre-emptive machine capacity expansion and partial downgrading of weakly dependent and weakly perceived functions to alleviate traffic pressure is insufficient to cope with the capacity demands of sudden traffic surges, and lacks dynamic response capabilities, making it difficult to meet the differentiated downgrading requirements under sudden traffic surge scenarios.

[0004] Furthermore, existing traffic redirection methods based on remote degradation platforms handle abnormal traffic by switching it off the original business link to an independent degradation platform. However, this method interrupts the original business link, making it difficult for downstream applications in the link to obtain the degradation status of upstream applications, thus hindering coordinated degradation among applications in the link. It also fails to meet the requirement of achieving adaptive application degradation without interrupting the link.

[0005] Therefore, there is a need for a way to adaptively degrade applications across the entire business execution process. Summary of the Invention

[0006] This specification provides one or more embodiments of a service degradation execution method, apparatus, and medium to solve the following technical problem: the need for an adaptive degradation method for the entire application chain during service execution.

[0007] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows: This specification provides one or more embodiments of a service degradation execution method, applied to a service execution system. The service execution system includes at least multiple applications, wherein each application's machine has a corresponding sidecar module and a degradation SDK. The method includes: Based on the first sidecar module in the first application upstream, it detects whether the current business status of the business execution system has reached the degradation threshold. If so, then within the preset downgrade time window, each request is marked with a downgrade target based on the first sidecar module; When the first application calls the downstream second application, the degradation label is written into the network packet through the first sidecar module; The second sidecar module in the second application parses the network packet to obtain the degradation label, and rewrites the degradation label into the next network packet to pass the degradation label to each application level along the service execution link; Based on the degradation SDK in each application, obtain the degradation label passed in by the corresponding sidecar module, and perform degradation operations for each application based on the degradation label to perform adaptive degradation of the business execution link.

[0008] This specification provides a service degradation execution device according to one or more embodiments, which uses a service execution system. The service execution system includes at least multiple applications, wherein each application's machine has a corresponding sidecar module and a degradation SDK. The device includes: The detection module is used to detect whether the current business status of the business execution system has reached the degradation threshold, based on the first sidecar module in the first application upstream. The annotation module is used to annotate each request within a preset degradation time window based on the first sidecar module if the condition is met. The writing module is used to write the degradation label into the network packet through the first sidecar module when the first application calls the downstream second application. The transmission module is used to parse the network packet through the second sidecar module in the second application to obtain the degradation label, and rewrite the degradation label into the next network packet, so as to pass the degradation label to each application level by level along the service execution link; The degradation module is used to obtain the degradation target passed by the corresponding sidecar module according to the degradation SDK in each application, and perform degradation operations for each application based on the degradation target to perform adaptive degradation of the business execution link.

[0009] This specification provides one or more embodiments of a service degradation execution device, applied to a service execution system. The service execution system includes at least multiple applications, wherein each application's machine has a corresponding sidecar module and a degradation SDK. The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Based on the first sidecar module in the first application upstream, it detects whether the current business status of the business execution system has reached the degradation threshold. If so, then based on the first sidecar module, each request within the preset downgrade time window is marked with a downgrade target; When the first application calls the downstream second application, the degradation label is written into the network packet through the first sidecar module; The second sidecar module in the second application parses the network packet to obtain the degradation label, and rewrites the degradation label into the next network packet to pass the degradation label to each application level along the service execution link; Based on the degradation SDK in each application, obtain the degradation label passed in by the corresponding sidecar module, and perform degradation operations for each application based on the degradation label to perform adaptive degradation of the business execution link.

[0010] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: By using the sidecar module, degradation labels are progressively passed down through the business execution chain to each application in the business cluster. This ensures that each application receives a degradation label and executes the corresponding degradation operation based on it. This guarantees that degradation operations only affect business traffic that meets the specified conditions. This step-by-step propagation of degradation labels along the business execution chain facilitates collaborative degradation execution among applications and avoids degradation gaps caused by missing information. Furthermore, the step-by-step propagation of degradation labels in the chain allows the same request to execute different degradation operations in different applications based on their respective degradation SDKs, achieving differentiated degradation by triggering different degradation operations for the same degradation label in different applications. Labeling each request with degradation labels within a preset degradation time window reduces computational resource consumption. Automatic detection using the sidecar module and degradation operations based on the degradation SDK improve processing efficiency and reduce manual costs. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A schematic diagram of a method flow for a service degradation execution method provided in an embodiment of this specification; Figure 2 A flowchart illustrating a traditional business degradation method provided in the embodiments of this specification; Figure 3 This specification provides a schematic diagram of an application invocation architecture for an application scenario. Figure 4This specification provides a schematic diagram of the identification process for a degradation identifier in an application scenario, as illustrated in an embodiment of the present invention. Figure 5 This specification provides a schematic diagram of a process architecture for transferring degradation targets between applications in an application scenario, as illustrated in the embodiments of this specification. Figure 6 This specification provides a schematic diagram of the downstream application call flow of an RPC call request in an application scenario, as illustrated in an embodiment of this specification. Figure 7 This specification provides a schematic diagram of end-to-end adaptive degradation of a service in an application scenario, as illustrated in the embodiments of this specification. Figure 8 This specification provides a schematic diagram of a configuration management architecture for a central configuration platform, as illustrated in the embodiments thereof. Figure 9 This is a schematic diagram illustrating a multi-level downgrade in an application scenario provided by an embodiment of this specification; Figure 10 This is a schematic diagram of an SDK downgrade determination process in an application scenario provided by an embodiment of this specification; Figure 11 A schematic diagram of an adaptive degradation logical architecture for a business execution link provided in the embodiments of this specification; Figure 12 A schematic diagram of the logic flow for a degradation determination provided in an embodiment of this specification; Figure 13 A schematic diagram of the logical flow of a failure response timing storage provided in an embodiment of this specification; Figure 14 A schematic diagram of the logical architecture of a failure response timing storage provided in the embodiments of this specification; Figure 15 A schematic diagram of the logic flow for a successful response timing storage provided in the embodiments of this specification; Figure 16 A schematic diagram of the logical architecture of a successful response time-series storage provided in the embodiments of this specification; Figure 17 A schematic diagram of the architecture of a remote image stabilization platform provided in the embodiments of this specification; Figure 18 A schematic diagram of the logical flow of heterogeneous link copy return provided in the embodiments of this specification. Figure 19 A comparative diagram illustrating an adaptive degradation method for improving link capacity, provided in an embodiment of this specification. Figure 20 This is a comparative schematic diagram of a flood storage trigger provided in the embodiments of this specification; Figure 21 A schematic diagram of the structure of a service degradation execution device provided in the embodiments of this specification; Figure 22 This is a schematic diagram of a service degradation execution device provided in an embodiment of this specification. Detailed Implementation

[0012] This specification provides a method, apparatus, and medium for degrading the execution of services.

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

[0014] Figure 1 This diagram illustrates a method flow for a degraded execution method for a business application, as provided in an embodiment of this specification. This method can be applied to financial business systems, e-commerce business systems, internet middleware platforms, and other business systems or platform applications that require degraded disaster recovery of business call chains under high-concurrency scenarios. The process can be executed based on the business execution system and its computing devices (e.g., application servers in each domain, or terminal computing devices communicating with the business execution system in each domain). Furthermore, certain input parameters or intermediate results in the process can be manually adjusted to help optimize the degraded execution of the business application.

[0015] Figure 2 This is a flowchart illustrating a traditional business degradation method provided in an embodiment of this specification. As can be seen from the background description above, in a microservice distributed architecture, business requests may require the collaborative processing of multiple applications to complete. For example, the purchase business of an e-commerce platform in a microservice distributed architecture will trigger the collaborative processing of multiple cross-applications such as gateway, order service, payment service, points service, and notification service. At this time, if a dependent downstream service fails or a dependent function cannot meet the current business requirements, it may lead to problems such as page loading failure and payment interruption.

[0016] Specifically, the reasons for the instability of the aforementioned business systems include: sudden increases in traffic, network failures, and code issues. Currently, a common approach is to employ two solutions simultaneously: pre-emptively expanding machine capacity and downgrading some weakly dependent and less aware functions, in order to achieve a relative balance between user experience and cost. That is, Figure 2Traditional methods typically involve pre-assessing the timing and magnitude of peak traffic to expand data center capacity. This is done through manual or scheduled degradation, downgrading less impactful functions to meet capacity demands, and then restoring them after the peak traffic subsides. However, both manual and scheduled configuration pushes are best suited for deterministic degradation scenarios. They struggle to handle sudden surges in traffic and lack dynamic response capabilities, making it difficult to meet the differentiated degradation needs of sudden traffic spikes.

[0017] For example, current competition among internet companies leads to frequent large-scale promotional events, which increase traffic to business systems several times compared to normal days. Therefore, to address capacity issues and support these events, preventing server downtime due to sudden traffic surges, the aforementioned degradation methods are used. However, for scenarios where peak traffic times are difficult to predict, such as live-streaming flash sales, degradation can only be implemented before the live stream begins and restored afterward. But for high-frequency services, such as frequent live streams by popular broadcasters, this approach incurs significant manpower and maintenance costs, and the frequent online changes and prolonged degradation can also impact the business itself.

[0018] In addition, there are existing traffic diversion methods based on remote degradation platforms to solve capacity issues. However, this method switches abnormal traffic out of the original business link to an independent degradation platform for degradation processing, which interrupts the original business link. As a result, downstream applications in the link have difficulty obtaining the degradation status of upstream applications. Therefore, it is difficult to achieve coordinated degradation of various applications in the link and it is difficult to meet the requirement of application adaptive degradation without interrupting the link.

[0019] Based on the above, there is a need for an adaptive degradation method for the entire application chain during business execution. This addresses the problem that existing methods lack the ability to propagate degradation labels vertically throughout the entire chain, failing to meet the requirement for nodes to make self-determined degradation decisions without interrupting the chain. Therefore, in this embodiment, online application traffic and various machine metrics are monitored. When traffic increases or CPU usage is too high, a degradation label is applied to requests. All applications in the execution chain of the business execution system consume this degradation label and perform some degraded execution of business logic based on it. This temporarily degrades some weak dependencies to reduce system load, allowing the business execution system to handle higher traffic without rate limiting. Once traffic decreases or the system state stabilizes, requests are no longer tagged with degradation labels, and the degradation operation automatically stops.

[0020] Based on this overall approach, further proposals were put forward, such as Figure 1The method for degrading the execution of a service shown is applied to a service execution system, which includes at least multiple applications, wherein each application's machine has a corresponding sidecar module and a degrading SDK.

[0021] The following detailed description of each step of the method, with reference to specific embodiments, illustrates the method, which includes the following steps: S102: Based on the first sidecar module in the first application upstream, detect whether the current business status of the business execution system has reached the degradation threshold.

[0022] In the embodiments of this specification, the service degradation execution method is applied to a service execution system, which is a distributed system in the current domain that deploys multiple microservice applications and collaborates through network communication to complete the processing of service requests in the current domain. Based on the above, the service execution system includes at least multiple applications located in the service execution chain, each application's pod has a corresponding sidecar module and a corresponding degradation SDK, and may also include a remote debouncing platform or a central configuration platform that communicates with the multiple applications.

[0023] In a distributed microservice architecture, the business execution chain is the application call path formed by multiple applications processing a business request in a specific order. Specifically, when a user initiates a business request, the request requires the collaborative processing of multiple applications to complete. These applications are arranged according to the order of business processing, with the request passing through each application sequentially until the execution result is returned, thus forming a complete business execution chain.

[0024] The current business status of the business execution system is a dynamic indicator parameter that reflects the overall operation of the business execution system, including but not limited to at least one of the following: business traffic that reflects the business request pressure currently being borne by the system, and system status that reflects the system's processing capacity, service quality, and resource consumption.

[0025] The upstream first application is a node that acts as the request entry point or pre-processing node during the request processing, used to receive external requests or forward requests to downstream applications. In the embodiments of this specification, only the first application is used as the starting node for degradation labeling. However, the first application is not limited to the first node in the business execution chain, but can be any upstream application in the business execution chain that can trigger degradation determination.

[0026] Each application's machine has a sidecar module deployed, so the first application's machine, i.e., the same running instance of the first application, has a corresponding first sidecar module deployed. This first sidecar module is used to intercept the first application's inbound and outbound traffic and has functions such as traffic parsing, protocol conversion, metric collection, and degradation label injection. In the embodiments of this specification, the first sidecar module can be a mosn implementation of Sidecar.

[0027] The business execution of the embodiments in this specification is based on the Service Mesh architecture. Service Mesh is the infrastructure layer in the service mesh used to handle inter-service communication. It separates the network communication-related functions in microservices, such as traffic management, service discovery, load balancing, and secure communication, from the business applications and forms a sidecar module that is deployed together with the application to achieve non-intrusive interception and management of business traffic.

[0028] Figure 3 This is a schematic diagram of an application invocation architecture in an application scenario provided by an embodiment of this specification. Combined with... Figure 3 As shown, the first sidecar module is a specific implementation of the sidecar proxy in the Service Mesh architecture. After the sidecar module and the application are deployed on the same machine, the sidecar module proxies all network traffic of the application. When the application receives external calls or calls external applications, the traffic passes through the sidecar module. Therefore, building common capabilities in the sidecar module implements various middleware capabilities without intruding on business applications.

[0029] In this Service Mesh architecture, based on the first sidecar module of the first application upstream, it detects whether the current business state of the business execution system has reached the degradation threshold, specifically including at least one of the following methods: The first sidecar module intercepts requests received by the first application and counts the number of requests within the current second-level time window. When the count exceeds the preset business traffic threshold, it is determined that the current business state of the business execution system has reached the degradation threshold. Furthermore, the first-sidecar module periodically monitors the operational status information of the business execution system, such as CPU level and thread pool status, and determines the status information. When the operational status information exceeds a preset operational status threshold, for example, CPU usage exceeds 80%, it is determined that the operational status information exceeds the preset operational status threshold, and at this time, the current business status of the business execution system has reached the degradation threshold.

[0030] The aforementioned degradation thresholds, such as business traffic thresholds and operational status thresholds, are all uniformly distributed to the corresponding sidecar modules of each application based on the central configuration platform. If a degradation threshold is reached through any of the above methods, the subsequent degradation process is triggered; if neither method reaches the degradation threshold, the subsequent process is not triggered.

[0031] S104: If so, then based on the first sidecar module, mark the downgrade targets for each request within the preset downgrade time window.

[0032] If, based on the above S102, it is determined that the current business state of the business execution system has reached the degradation threshold, then the first sidecar module opens a preset degradation time window. During the duration of the preset degradation time window, the first sidecar module marks each subsequently received request with a degradation tag. After the preset degradation time window expires, the first sidecar module stops marking subsequent requests and performs the next round of testing on the business execution system. For example, in a certain scenario, if it is set that all requests are tagged with a degradation tag 10 seconds after the QPS exceeds 10000, then the count is performed within the current second-level time window. When the count value exceeds 10000, a timer is started for 10 seconds. During these 10 seconds, all requests are not judged but are tagged with the same degradation tag. After 10 seconds, the process ends, and the next QPS judgment is performed.

[0033] The aforementioned degradation label is used to identify whether a request is in a degradation state and is passed along the business execution chain as the request proceeds. This allows each application in the business execution chain to extract the degradation label through its degradation SDK and, based on the degradation label, query the pre-set degradation association configuration uniformly allocated to each application's degradation SDK by the central configuration platform to determine the target degradation operation that each application needs to perform. The degradation label can be a string identifier or structured data containing information such as degradation scenario identifier and degradation intensity level.

[0034] The preset degradation time window is used to limit the time range for the first sidecar module to mark the degradation. In the embodiments of this specification, the duration of the preset degradation time window can be uniformly configured by the central configuration platform and distributed to each sidecar module, or it can be pre-stored in the local configuration file of the first sidecar module.

[0035] During the duration of the preset degradation time window, the first sidecar module intercepts the outbound request of the first application, obtains the request object corresponding to the outbound request, and writes the degradation label and the preset transparent transmission field name into the request attribute set of the request object. The written request object will be serialized into a network packet and passed to the downstream application, thereby realizing the transparent transmission of the degradation label in the business execution link.

[0036] Figure 4This is a schematic diagram illustrating the identification process for a degradation flag in an application scenario provided in this specification. When the first application receives a business request, its first sidecar module identifies the traffic requiring traffic statistics, calculates the magnitude of the identified traffic, and if the magnitude exceeds the configured degradation threshold, then the traffic of subsequent requests within a preset degradation time window is tagged with a degradation flag. This degradation flag is passed to subsequent applications when they are subsequently called. Figure 4 As shown, after upstream application A judges the request and marks it with a degradation label, the request with the degradation label is passed to application B, and then passed to application C based on application B, thus realizing the transfer of the degradation label between applications.

[0037] S106: When the first application calls the downstream second application, the degradation label is written into the network packet through the first sidecar module.

[0038] The second application is the application downstream of the first application in the business execution chain and is invoked by the first application. That is, during the first application's request processing, it needs to send a call request to the second application to obtain services or data provided by the second application. For example, if the first application is an order service, then when the first application calls the downstream inventory service, the inventory service is the second application. If the first application is an inventory service, then when it calls the downstream payment service, the payment service is the second application. Therefore, in the embodiments of this specification, the first application and the second application are determined relative to the calling relationship in the business execution chain. The same application can simultaneously act as both the upstream first application and the downstream second application in a single business execution chain.

[0039] Figure 5 This is a schematic diagram of a process architecture for transferring degradation targets between applications in an application scenario provided by an embodiment of this specification. Figure 5 When the first application upstream needs to call the service of the second application downstream, the first sidecar module of the first application intercepts the outbound request of the first application, obtains the request object (SofaRequest) of the outbound request, and writes a degradation label and a preset pass-through field name into the request property set (requestProps) of the request object to obtain the written request object. The written request object is then serialized into a network packet. The degradation label is written into the request header of this network packet, enabling the second sidecar module of the downstream second application to obtain the degradation label carried in the request when parsing the network packet.

[0040] S108: The degradation label is obtained by parsing the network packet through the second sidecar module in the second application, and the degradation label is rewritten into the next network packet so as to pass the degradation label to each application level by level along the service execution link.

[0041] When passing downgrade tags between applications, the first sidecar module in the first application constructs a network packet from the request object corresponding to the outbound request, and the downgrade tag is written into the request header of the network packet. At this time, the second sidecar module in the second application parses the network packet to obtain the downgrade tag, and then performs downgraded business processing based on the target downgrade operation corresponding to the downgrade tag during the business processing of the second application. When it needs to continue calling the downstream third application after execution, the process corresponding to step S106 above continues, that is, the second sidecar module uses a preset pass-through field name as the key and the downgrade tag as the value to reconstruct the key-value pair and write it into the request attribute set of the request object corresponding to the current call of the second application, thereby generating the next network packet, and passing the downgrade tag to the third application based on this network packet. In each call in the business execution chain, the sidecar modules corresponding to each application pass down the downgrade tag level by level in the above manner until the downgrade tag reaches the end application of the business execution chain or meets the preset stop-passing condition, thereby realizing the level-by-level pass-through of the downgrade tag along the entire business execution chain.

[0042] Figure 6 This document illustrates a downstream application call flow diagram for an RPC call request in an application scenario provided by an embodiment of this specification. A call relationship exists between a first application and a second application. When the first application processes a business request, it needs to call the downstream second application. Therefore, the first sidecar module of the first application writes the degradation label of the request into the request header of the network packet and sends the network packet to the second sidecar module of the machine to which the second application belongs. After receiving the network packet, the second sidecar module parses the request header of the network packet to obtain the degradation label and treats the request as an inbound request of the second application. The second sidecar module writes the obtained degradation label into the request attribute set of the request object of the current inbound request of the second application, so that the second application can receive the request object and perform degradation operations based on the degradation label using the degradation SDK. When the second application finishes processing the inbound request and calls the downstream service, it treats the call request as an outbound request of the second application. At this time, the second sidecar module writes the degradation label into the request attribute set of the request object of the outbound request, constructs the next network packet, and sends the next network packet to the third sidecar module of the machine to which the downstream third application belongs.

[0043] Optionally, in one feasible embodiment of this specification, before the sidecar module corresponding to the downstream application rewrites the degradation label into the next network packet, the sidecar module corresponding to the downstream application can also obtain the current valid transmission count of the degradation label and determine whether the current valid transmission count has reached the preset transmission count. If it has not reached the preset transmission count, the above-mentioned transparent transmission process of the degradation label continues. If the preset transmission count has been reached, the transmission of the degradation label is stopped, or the degradation strength level corresponding to the degradation label is reduced and then transmission continues.

[0044] S110: Based on the degradation SDK in each application, obtain the degradation target passed by the corresponding sidecar module, and perform degradation operations for each application based on the degradation target to perform adaptive degradation of the business execution link.

[0045] Figure 7 This is a schematic diagram illustrating end-to-end adaptive degradation of a service in an application scenario provided by an embodiment of this specification. Figure 8 This is a schematic diagram of a configuration management architecture for a central configuration platform provided in an embodiment of this specification. The following is in conjunction with... Figure 7 and Figure 8 This provides an intuitive explanation of the adaptive degradation process.

[0046] Combination Figure 7 Each application in this business execution system has a corresponding SDK, and Figure 7 The arrows in the diagram indicate that degradation targets are passed through along the business execution chain. The SDKs corresponding to each application then determine the degradation level for each passed-through target. Specifically, during the transmission of degradation targets in the business execution chain, each application's degradation SDK, after receiving the degradation target from the sidecar module, obtains the pre-defined degradation association configuration. Based on this configuration, it determines the corresponding degradation operation for each degradation target. For example, the first application performs log degradation, the second application performs cache read degradation, and the third application performs fast return degradation, thus achieving adaptive degradation in the business execution chain.

[0047] The degradation SDK is used to implement the transmission of degradation targets within the application, the acquisition and management of degradation association configurations, and the matching and assertion of degradation points. In the embodiments of this specification, each application can obtain degradation target processing capabilities by introducing the degradation SDK without modifying the business code. Through the cooperation between the degradation SDK and the sidecar module, the end-to-end transparent transmission of degradation targets and the execution of degradation operations are completed.

[0048] Degradation association configurations are maintained through a central configuration platform. After users configure the degradation association configuration for each service on the central platform, these configurations are distributed to all machines in the service application cluster, ensuring that the degradation SDKs on each machine have a unified degradation association configuration. This degradation association configuration includes a degradation label and a degradation point. The degradation point is a user-defined string on the central configuration platform, representing a specific degradation logic. For example, a string "RUNTIME_LOG_DEGRADE" can be declared to represent the operation of "degrading runtime logs".

[0049] Specifically, the degradation SDK intercepts request objects received by each application through inbound interception points, extracts degradation labels from the request object's request attribute set, and stores the degradation labels in the thread variable of the current request processing thread to achieve the transfer of degradation labels within the application. Using the degradation label in the thread variable as the key, the degradation SDK queries the mapping relationship between degradation labels and degradation points contained in the degradation association configuration to obtain the set of degradation points associated with the degradation label. The degradation SDK uses a preset assertion interface to determine whether the application's current business operation hits any degradation point in the degradation point set. If it corresponds to any degradation point in the set, it determines that the application's current business operation needs to be degraded, and executes the corresponding target degradation operation based on the hit degradation point. If no match is found, the business logic executes normally.

[0050] In the above process, each application in the business execution chain independently executes the above judgment and execution steps. Each application uses the degradation label carried in the request as a unified decision basis. Based on the degradation SDK corresponding to each application, the degradation logic of each relevant application is triggered on the entire business execution chain, realizing collaborative and adaptive differentiated degradation of each application.

[0051] In the embodiments described in this specification, the sidecar module propagates the degradation label level by level to each application in the business cluster along the business execution chain. This ensures that each application receives the degradation label and performs the corresponding degradation operation based on it. The degradation operation only affects business traffic that meets the conditions, achieving step-by-step propagation of the degradation label along the business execution chain. This facilitates collaborative degradation execution among applications and avoids degradation gaps caused by missing information. Furthermore, the degradation operation, based on the combination of the sidecar module and the degradation SDK, does not intrude on the business code, so updates and iterations do not require modification of the business code, reducing system maintenance costs. Through the step-by-step propagation of the degradation label in the chain, the same request can execute different degradation operations in different applications based on their respective degradation SDKs, achieving differentiated degradation by triggering different degradation operations for the same degradation label in different applications. Labeling each request with degradation labels within a preset degradation time window reduces the consumption of computing resources. Automatic detection based on the sidecar module and degradation operation based on the degradation SDK improves processing efficiency and reduces costs.

[0052] Combination Figure 4 As shown, in one feasible embodiment of this specification, based on the first sidecar module in the upstream first application, the detection of whether the current business state of the business execution system has reached the degradation threshold specifically includes: When the current business state of the business execution system is business traffic, the first-sidecar module parses the current request and determines whether to count the current request based on the matching relationship between the parameter fields of the current request and the configuration values. The parameter fields are specified parameters indicating the business attributes of the request, including but not limited to: the request method name, the request business type field, and the caller identifier field in the request header. The specific name and location of these parameter fields can be preset by developers based on the business scenario. The configuration values ​​are the benchmark values ​​compared with the parameter fields and are stored in the local configuration file of the first-sidecar module, or uniformly distributed to the first-sidecar module through the central configuration platform.

[0053] Here, the request method name is used as a parameter field. The first sidecar module parses the current request method name and obtains its configuration value. It then checks whether the current request method name matches the method name in the configuration value. Only if the method name matches the method name in the configuration value is the first sidecar module determined that the current request is a request that needs to be included in the statistics, and subsequent detection is performed.

[0054] This approach enables more granular differentiation of different business scenarios within gateway interfaces with equal-width interfaces. For example, in a gateway application, all services share the same interface, but specific services are distinguished by a field in the parameters. In this case, the first-sidecar module can differentiate and statistically analyze a particular service.

[0055] After determining whether traffic statistics are needed for the current request, if it is determined that statistics are required, the current request's business traffic is matched against the degradation thresholds of each degradation tier to determine whether the business execution system has reached the degradation threshold of the target degradation tier. If the degradation threshold is reached, the corresponding degradation tag is added to subsequent requests.

[0056] Each degradation tier corresponds to a different degradation threshold and a different priority. The target degradation tier is determined based on the priority ranking of degradation tiers that have reached the degradation threshold. In a scenario, the central configuration platform's traffic targeting rules, frequency counting rules, threshold configuration, traffic tagging rules, and multi-tier configuration examples for the sidecar module are as follows: "Degradation Tier 1: Traffic is targeted at interface A; business traffic threshold is 10,000 qps; the degradation label to be applied is degradation label A; priority is 2; Degradation Tier 2: Traffic is targeted at interface A; business traffic threshold is 20,000 qps; the degradation labels to be applied are degradation label A and degradation label B; priority: 1."

[0057] At this point, the corresponding sidecar module will determine whether the current request belongs to interface A, which requires traffic statistics, based on the traffic segmentation rules. If so, it will perform business traffic statistics on the request for interface A. When the count exceeds the business traffic threshold, it is determined that a degradation threshold has been reached. In other words, the sidecar module judges the total business traffic of the current request and selects the highest priority target degradation level from those levels that meet the business traffic threshold. That is, the level with the lower priority number takes effect. For example: if the current request is 5000 QPS, no degradation level takes effect; if the current request is 15000 QPS, degradation level 1 takes effect, and the current request will be labeled with degradation tag A; if the current request is 30000 QPS, degradation level 2 takes effect, and the current request will be labeled with both degradation tags A and B. Figure 9 As shown in the multi-level degradation diagram, when the current request volume exceeds 10,000 qps but has not yet reached 20,000 qps, only degradation point A is executed; while when the current request volume exceeds 20,000 qps, degradation points A and B are executed simultaneously.

[0058] Traffic statistics can be performed at either a single-machine or cluster level. At the single-machine level, each machine's sidecar module maintains a counter. Each sidecar module instance is independent. When the current request traffic on the current machine exceeds its corresponding threshold, the remaining request traffic within the current degradation time window is tagged with a degradation flag. At the cluster level, a distributed cache count key is shared across the business cluster. Each time a request arrives on a machine in the cluster, this distributed cache count key is incremented. If the value of the distributed cache count key exceeds its corresponding threshold, the remaining request traffic within the current degradation time window is tagged with a degradation flag by the sidecar module.

[0059] Furthermore, in another feasible embodiment of this specification, during the process of detecting whether the current business status of the business execution system has reached the degradation threshold based on the first sidecar module of the upstream first application, in addition to detecting and statistically analyzing the requested business traffic, degradation determination can also be made based on the running status information of the business execution system. Specifically: based on a preset detection period, the running status information of the business execution system, such as CPU level and thread pool status, is obtained through the corresponding sidecar module of the upstream application. If at least one running status in the running status information has reached its corresponding degradation threshold, such as CPU exceeding 80%, then it is determined that the business execution system needs to be degraded, and therefore the current request has also reached the degradation threshold. Subsequent requests within the degradation time window need to be marked with degradation targets.

[0060] Specifically, in a feasible embodiment of the present specification, if the service execution system reaches a degradation threshold, a timer is started based on the first sidecar module to open a preset degradation time window. Thus, within the preset degradation time window, based on the first sidecar module, each received request is marked according to the degradation flag corresponding to the target degradation level.

[0061] Wherein, in one feasible manner, the preset degradation time window is pre-configured by service personnel. In another feasible embodiment, the preset degradation time window is determined based on the target degradation level and the excess traffic value by which the service traffic exceeds the degradation threshold, that is, the reference duration of the preset degradation time window is matched based on each target degradation level. It can be understood that the higher the degradation level, the longer the reference duration, and the lower the degradation level, the shorter the reference duration. For example, in a certain scenario, the reference duration corresponding to the first degradation level with a degradation threshold of 10000 qps is 10 seconds, and the reference duration corresponding to the second degradation level with a degradation threshold of 20000 qps is 20 seconds. The excess traffic value by which the service traffic exceeds the degradation threshold is used to dynamically adjust on the basis of the reference duration. The extension duration corresponding to the excess traffic value is positively correlated with the magnitude of the excess traffic value. By pre-configuring multiple excess traffic value intervals, the extension duration corresponding to each excess traffic value is determined, so that the time length of the preset degradation time window is determined according to the reference duration and the extension duration.

[0062] Specifically, in one or more embodiments of the present specification, when a first application invokes a downstream second application, the process of writing the degradation flag into the network packet through the first sidecar module includes: When the first application invokes the downstream second application, based on the first sidecar module, a first key-value pair with the degradation flag as the value is constructed according to the degradation flag and the transparent transmission field name of the service execution link, that is, in a certain scenario, the first key-value pair is: <key: service_degrade_tags, value: degradation flag>.

[0063] The first key-value pair is written into the first request attribute set in the first request object through the first sidecar module, so as to obtain the first request object after writing. That is, the request attribute set is a container field in the request object for carrying custom key-value pairs. Therefore, the first sidecar module stores the first key-value pair into the first request attribute set by calling the writing method of the first request object. Wherein the first request object is the request object SofaRequest corresponding to the invocation request of the first application.

[0064] The first request object, after being written, is serialized to generate a network packet. During the generation of this network packet, the first key-value pair is written into the request header of the network packet. That is, during the serialization process, the first key-value pair in the first request attribute set is mapped to the request header of the network packet, enabling the downstream sidecar module to obtain the degradation label in the request when parsing the network packet.

[0065] Furthermore, in one or more embodiments of this specification, the degradation label is obtained by parsing network packets through the second sidecar module corresponding to the second application, and the degradation label is rewritten into the next network packet to pass the degradation label to each application level by level along the service execution link, specifically including: The second sidecar module corresponding to the second application receives network packets, parses the request header of the network packets, and extracts a first key-value pair with the preset transparent field name as the key to obtain the degradation tag. When the second application calls the next application, the second sidecar module constructs a second key-value pair with the preset transparent field name, such as "service_degrade_tags", as the key and the parsed degradation tag as the value. When the second application needs to continue calling the next application, the second key-value pair is written into the second request attribute set of the second request object to obtain the written second request object. It can be understood that the second request object corresponds to the call request of the second application. The written second request object is serialized. During the serialization process, the second key-value pair in the second request attribute set of the second request object is mapped to the request header of the next network packet, thus obtaining the next network packet carrying the second key-value pair. Each application repeats the above process during the call process, thereby realizing the step-by-step transmission of the degradation tag along the business execution link. This process differs from directly forwarding the same message. It can rebuild key-value pairs and write new request objects in each layer of the call, so that the degradation target can be passed in a way that is independent of the request object at each hop in the business execution chain. This achieves full-link transparent transmission of the degradation target and avoids the problem of the degradation target being lost or confused due to changes in the business semantics of the request object.

[0066] Furthermore, to avoid the infinite propagation of degradation targets, reduce unnecessary degradation target propagation and degradation judgment, and lower the computational cost of the degradation sidecar module and degradation SDK, in one feasible embodiment, the method further includes: determining the initial propagation range of the business execution link based on the target degradation level. This initial propagation range is used to limit the number of application nodes that the degradation target can pass through in the business execution link. Different degradation levels are pre-configured with corresponding initial propagation ranges. It can be understood that the higher the degradation level, the higher the severity of the fault or the greater the traffic pressure, requiring coverage of more downstream nodes, thus resulting in a larger initial propagation range. For example, in a certain scenario, the initial propagation range for the first degradation level is 3 hops, and the initial propagation range for the second degradation level is 5 hops.

[0067] When a degradation label is passed from the current application to the next, the effective transmission count of the business execution chain is determined based on the number of applications to which the degradation label has already been passed. The effective transmission count is incremented by 1 for each application passed. If the effective transmission count has not reached the initial transmission range, the degradation label is written into the next network packet based on the sidecar module corresponding to the application. If the effective transmission count has reached the initial transmission range, the transmission of the degradation label is stopped, or the target degradation level corresponding to the degradation label is downgraded to enable the downstream application to perform a lighter degradation operation than the current application.

[0068] Specifically, Figure 10 This document provides a schematic diagram of an SDK degradation determination process in one or more embodiments of this specification. (In conjunction with...) Figure 10 The process of obtaining the corresponding degradation label from the sidecar module based on the degradation SDK corresponding to each application is as follows: If an application in the business execution chain receives the corresponding request object, it intercepts and parses the request object based on the inbound interception point in the fallback SDK parsing of each application (here, the RpcBeforeFilter registered in the fallback SDK). This extracts the fallback label from the request object's request attribute set and stores it in the thread variable (RpcInvokeContext) of each request. Essentially, the fallback label is re-recorded in the application's thread variable, allowing the fallback SDK corresponding to that application to directly read the fallback label from the thread variable during business execution. In other words, during the application's business execution, the business code can directly read the fallback label based on the thread variable without being aware of the underlying transmission details, achieving thread-level pass-through of the fallback label within the application. Specifically, the fallback SDK processes the fallback label through the interception point provided by the RPC framework. The Remote Procedure Call (RPC) framework enhances the original mechanism through the chain of responsibility pattern (filter mechanism). The degradation SDK adds a filter and registers it into the RPC framework. In this way, when each request arrives at the application, the degradation target will be processed first, and the same applies when calling downstream applications.

[0069] In the application's RPC framework, some metadata is passed between threads using thread variables. Therefore, when a request arrives, it first passes through an adaptive degradation filter. This filter parses the request parameters and places the degradation label into a thread variable, enabling the degradation label to be passed within the application and carried downstream when called. Specifically, after processing, the sidecar module passes the inbound request object to the application for processing, which then parses it into an RPC call request. The degradation SDK adds an aspect to the RPC framework. When any inbound request (i.e., a call request from the upstream application) arrives, it first passes through the degradation SDK's inbound interception point. This aspect parses the inbound request object, extracts its degradation label, and adds it to the RPC framework's thread variable to ensure the degradation label is passed through within the business thread. Before the RPC framework finishes processing the request, it enters the degradation SDK's outbound interception point to clean up the thread variable. If the business requires declaring an asynchronous thread, then some business logic needs to be processed in the asynchronous thread. This can be done by manually cloning or automatically copying the thread variable.

[0070] Furthermore, following the previous embodiment, if the application calls a downstream application during the transmission of the degradation label within the application, the method further includes: reading the degradation label from a thread variable based on the outbound interception point (RpcAfterFilter) of the degradation SDK in the application. The degradation label is then backfilled into the request attribute of the outbound request object via the degradation SDK, and the backfilled outbound request object is written into a network packet, so that the degradation label can be transmitted to the downstream application via the network packet based on the application's corresponding sidecar module. The network packet generation process and the transmission process of the degradation label between applications are consistent with the above embodiment and will not be described again here.

[0071] Figure 11 This specification provides a schematic diagram of an adaptive degradation logic architecture for a business execution chain, representing one or more embodiments. In the process of implementing adaptive degradation of the business execution chain by performing degradation operations on each application based on degradation targets: The degradation association configuration is obtained through the degradation SDK in each application. This degradation association configuration is pushed to the degradation SDK of each application's machine based on the central configuration platform of the business execution system. The degradation association configuration includes the association between the degradation label and the degradation operation. For example, the degradation association configuration of application A in a certain link is as follows: "Downgrade Target A: Downgrade Point 1 # Downgrade Target B: Downgrade Point 2". (Continuing from the above...) Figure 4In the corresponding embodiment, based on the first sidecar module in the first application upstream, the central configuration platform configures the following degradation rules for the sidecar module: If the current request rate is 5000 QPS, no degradation level is active, and degradation is not triggered; if the current request rate is 15000 QPS, degradation level 1 is active, and the 5000 requests exceeding the threshold will be marked with degradation label A, and degradation point 1 will be degraded; if the current request rate is 30000 QPS, degradation level 2 is active, and the 10000 requests exceeding the threshold will be marked with both degradation labels A and B, and degradation points 1 and 2 will be degraded. Here, the degradation point is a user-defined string representing a specific degradation logic. For example, a string "RUNTIME_LOG_DEGRADE" can be declared to represent the operation of "degrading the runtime log". After the degradation association configuration is configured based on the central configuration platform, the configuration will be pushed to all machines in the business cluster. At this time, the degradation SDK parses the degradation association configuration and converts it into a key-value structure for storage.

[0072] Each application's corresponding degradation SDK queries its degradation association configuration based on the degradation label to obtain one or more degradation points associated with the degradation label. Then, based on the matching result between the business operation executed by the application and the one or more degradation points, the target degradation operation of the application is determined, and the adaptive degradation of the application is achieved by executing the target degradation operation.

[0073] Furthermore, Figure 12 This is a schematic diagram of the logic flow for a degradation determination provided in one or more embodiments of this specification. In conjunction with this... Figure 12 The above content determines the target degradation operation for the application based on the matching results between the business operations performed by the application and one or more degradation operations. Adaptive degradation of the application is achieved by executing the target degradation operation, specifically including: The degradation SDK utilizes a predefined assertion interface. For example, in one scenario, the SDK provides an assertion method called "boolean matchAdaptiveDegrade(String degradePoint)". This method takes the degradation point identifier corresponding to the business operation as input and queries whether the identifier exists in one or more degradation points. The degradation point identifier is pre-assigned for each degradable business operation and is a string or enumeration value used to identify that operation. For instance, the business operation "print runtime logs" is assigned the degradation point identifier "RUNTIME_LOG_DEGRADE", and "read cache" is assigned the degradation point identifier "CACHE_READ_DEGRADE". This degradation point identifier is predefined when writing the business code and is passed as an input parameter to the predefined assertion interface when the assertion interface is called at the execution location of the business operation.

[0074] Specifically, within the internal logic of the preset assertion interface, the degradation SDK obtains the degradation label carried by the current request from the thread variable of the current request, and then queries the degradation association configuration with the degradation label as the key to obtain a set of degradation points consisting of one or more degradation points associated with the degradation label, and determines whether the passed-in degradation point identifier exists in the set of degradation points.

[0075] If it exists, the interface returns a true value based on the preset assertion, indicating that the current business operation needs to be downgraded. At this time, the downgrade SDK obtains the target downgrade operation according to the downgrade point corresponding to the downgrade point identifier, executes the downgrade of the business operation, and realizes the adaptive downgrade of the application.

[0076] If it does not exist, the interface returns a false value based on the preset assertion, thereby indicating that the business operation will not be downgraded and the business code will execute the business operation normally.

[0077] To illustrate this more clearly, consider the following scenario: In a code location that prints runtime logs, the developer predefines the degradation point identifier as "RUNTIME_LOG_DEGRADE" and calls the assertion interface `matchAdaptiveDegrade("RUNTIME_LOG_DEGRADE")`. If the current request carries the degradation identifier "canary", and the degradation association configuration associates "canary" with the degradation point "RUNTIME_LOG_DEGRADE", the assertion interface returns a true value, indicating that the business code needs to degrade and skips the log printing operation. If the current request does not carry a degradation identifier, or "canary" is not associated with the degradation point "RUNTIME_LOG_DEGRADE", the assertion interface returns a false value, and the business code prints logs normally.

[0078] Figure 13 This is a schematic diagram illustrating the logical flow of a failure response timing storage method provided in one or more embodiments of this specification. Figure 14 This is a schematic diagram illustrating the logical architecture of a failure response timing storage provided for one or more embodiments of this specification. (In conjunction with...) Figure 13 and Figure 14 The following description aims to ensure that, in the event of a failure of the original service, a copy of the data can still be displayed to the client by accessing a newly saved response snapshot. Furthermore, in one or more embodiments of this specification, the method further includes the following procedures: When performing degradation operations on various applications based on degradation targets, a fallback operation can be implemented by receiving responses from each request interface through the sidecar module in each application, parsing the responses, and determining whether the responses from each request interface failed. If a failure occurs, the request parameters corresponding to the failed response are obtained, and a snapshot key is constructed based on the key fields of the request parameters. These key fields are determined based on the business scenario of the request and are used to identify the requested business object. Based on the constructed snapshot key, a valid snapshot is queried from the database, and the decoded valid snapshot is returned to the application's sidecar module, which then returns the valid snapshot to the upstream application of the application. Specifically, this process can be executed based on a remote stabilization platform. The architecture of this remote stabilization platform provides the basic capabilities; the business only needs to implement customized interfaces to complete the access of a business scenario. The core interfaces that the business needs to implement are as follows: /

[0079] Build snapshot key

[0080] @param requestObjList: The list of original requests @param bizconfig: Business configuration @return / String buildKey(List <object>originRequestList, BizConfig bizconfig); /

[0081] Customize the response snapshot. Modify the input parameter `snapshot`.

[0082] @param snapshot: The snapshot to be modified @param bizconfig: Business configuration / void modifySnapshot(Object snapshot, BizConfig bizconfig); "In addition, after obtaining the snapshot, if necessary, you can call the modifySnapshot method of this interface to perform some customized processing, such as calling the downstream to update certain fields in the snapshot, etc.

[0083] Figure 15 This is a schematic diagram illustrating the logical flow of a successful response timing storage provided for one or more embodiments of this specification. Figure 16 This is a schematic diagram of the logical architecture of a successful response timing storage provided for one or more embodiments of this specification.

[0084] Combination Figure 15 and Figure 16 The following explains the process: If the sidecar module in the application receives responses from various request interfaces, parses these responses, and determines that each request interface's response is successful, then the sidecar module processes the fallback response interface (commonRemoteDegrade) from the remote debouncing platform. In the interface processing logic, this response is stored in the database. When adding this successful response to the database, the request parameters corresponding to the successful response are retrieved. A snapshot key is constructed based on the key fields of the request parameters, or based on user-specified rules. For example, if the userId and bizMode in the request parameters are set as the snapshot key for caching, these two fields are concatenated, and the concatenated string is stored as the snapshot key along with the successful response. The data items stored in the database at this time include: bizCode: the business scenario name, used to represent the specific business, corresponding to an interface (or different businesses within the same interface based on different parameters); the snapshot key concatenated from the request; the serialized response snapshot; and the snapshot saving time.

[0085] It should be noted that the above snapshots can be overwritten based on the snapshot key, or a new data entry can be written directly, with the time used to distinguish between old and new snapshots.

[0086] Figure 17 This is a schematic diagram of the architecture of a remote image stabilization platform provided for one or more embodiments of this specification. Figure 18 This is a schematic diagram illustrating the logical flow of heterogeneous link message return provided for one or more embodiments of this specification. Figure 17 and Figure 18 The descriptions provided are merely illustrative and do not constitute a limitation on the scope of protection of this application. Based on the following two figures, the remote image stabilization platform includes: a base, a service module, and an image stabilization SDK.

[0087] The base, as the underlying platform, provides general degradation capabilities and is maintained by the middle platform developers. It defines the execution framework of the entire process and is supplemented by configuration and control capabilities for business scenarios, as well as interaction with the database.

[0088] Each business unit maintains its own business module, within which it writes its own customized business logic, such as constructing snapshot keys and responding to modifications. Each business module corresponds to a code repository, and multiple business modules can be dynamically deployed simultaneously to a common degradation platform, thus isolating the development and operations of each business unit. Furthermore, a business module can be divided into multiple business scenarios to handle a specific business. Business scenarios are defined using traffic identification rules and correspond to a business interface.

[0089] The stabilization SDK exposes the base's capabilities to business modules via interfaces, enabling interaction between the base and business modules. Since the relationship between business modules and the base is many-to-one, business modules can directly call the interfaces provided by the base. The base, in turn, calls module services via SPI, allowing routing to specific modules by module name. Furthermore, the stabilization aspect in the stabilization SDK is handled when MoSN calls the stabilization platform, loading the configuration for the specific business scenario based on the business scenario code.

[0090] In distributed applications, each business process involves collaboration among multiple applications. If one application fails, the entire business logic may fail. In particular, some services may rely on external organizations; if these external organizations go down, users must wait for them to resolve the issue. This can result in the entire page crashing, leading to customer complaints. Therefore, in one or more embodiments of this specification, the sidecar module, upon receiving a response, parses the response according to configured rules, extracts data from the response, and determines whether the response has failed. Specifically, the user-configured rules for identifying the response to be processed are as follows: "class Response { private String codeType; private String resultCode; }” The error code parsing rule is configured as "codeType+" / "+resultCode", and the exception result code list is configured as "BUSINESS_FAILED / SYSTEM_ERROR". The sidecar module will parse the response according to the error code rule. If the response's codeType = BUSINESS_FAILED and resultCode = SYSTEM_ERROR, then the request is considered abnormal and a failure response, and therefore remote degradation will be performed.

[0091] If the response fails, the request, including the API name, request parameters, and response data, is sent to the remote stabilization platform. This forwarding process involves calling an API provided by the remote stabilization platform. "Object commonRemoteDegrade(List <object>Based on this, we can know that the interface has two input parameters: originRequestList, which is the list of request parameters of the original call, that is, the request parameters of the calling application B; and originResponse, which is the response object of the original call, that is, the response returned by application B.

[0092] The remote anti-shake platform adds customer-facing information to the failure response, allowing the sidecar module to replace the original response with this information when returning upstream. This enables the client to display yellow bar data based on the customer-facing information upon receiving the response. During this process, each business cluster configures a business code when configuring the sidecar module rules. This business code identifies each business scenario. Therefore, the remote anti-shake platform can identify the current business scenario through this business code and load the code logic and business configuration for that scenario. For example, an anti-shake extension field can be added to the response to store the yellow bar data. This yellow bar data is configured in the backend and can be pre-configured with different text based on different request parameters and response error codes. For instance, if the `city` field is retrieved from the request and the yellow bar data is set to "Your city {city} is experiencing a current service error, please try again later," then when the `city` field is "Hangzhou," the yellow bar data will be filled with: "Your city 'Hangzhou' is experiencing a current service error, please try again later." The system enables dynamic yellow bar data retrieval, displaying yellow bars only for failed requests. This avoids the need for manual, temporary push notifications of traditional yellow bars, and ensures that yellow bar data is displayed regardless of whether the original business call was successful, allowing users in unaffected areas to also see the yellow bar information.

[0093] Based on the above, this solution decouples the information flow and business flow. Under the Service Mesh architecture, for query-type businesses, based on the aforementioned examples of failed and successful response time-series storage, when a request succeeds, the sidecar module forwards the original interface response to the remote debouncing platform for storage. When the original request fails, the sidecar module obtains a response snapshot from the remote debouncing platform and returns it to the upstream business. This approach is suitable for interfaces with relatively fixed responses, such as interfaces with fixed configuration information.

[0094] Therefore, the sidecar module was used in this process to forward the response of the original interface to a dedicated remote debouncing platform to add yellow bars and query snapshots to the original failure response, thus providing a backup for failed calls.

[0095] For internal processing exceptions, such as when a user submits a payment request offline, the business unit accepts and processes the request. If an internal exception exists, the request processing will fail. To address this, and to provide heterogeneous fallback for internal processing exceptions, one feasible approach is for the application's corresponding sidecar module to identify a failed response and then call the fallback response interface of the remote debouncing platform.

[0096] Before processing the interface, it first passes through a debouncing aspect. This aspect is responsible for loading the corresponding user configuration based on the interface information carried by the sidecar module and the user-configured business scenario code. Then, a fallback method is executed. This fallback method first performs business validation, then determines whether debouncing is allowed. The request object is serialized and stored in the database. The fallback method simulates a successful response and returns it to the sidecar module. The sidecar module replaces the original failure response with this successful response and returns it to the upstream application.

[0097] The scheduling system sends scheduling information to the remote stabilization platform at a fixed frequency, such as every 5 seconds. Upon receiving the scheduling command, the remote stabilization platform retrieves a certain number of transactions to be restored from the database, deserializes them again into business request objects, and calls the restoration processor to execute the restoration operation. The restoration processor logic is defined by the business logic itself; a feasible approach is to call the business execution system again to replay the request. The restoration processor returns the restoration result, including a success or failure status. The remote stabilization platform updates the status of the transaction object based on this status. If successful, the transaction will not be retrieved again; if it fails, it will be retrieved again in a subsequent scheduling task to execute the restoration logic. If multiple restoration attempts fail, the status will be set to "stuck," and manual intervention will be notified.

[0098] Figure 19 This diagram illustrates a comparative approach to adaptive degradation for improving link capacity, provided in one or more embodiments of this specification. Figure 20 This is a comparative schematic diagram illustrating one or more embodiments of flood storage triggered according to this specification. Based on Figure 19 It is evident that in scenarios with sudden traffic surges, the lack of adaptive degradation can lead to capacity bottlenecks or system crashes. The embodiments in this specification, by introducing an adaptive degradation scheme, can automatically degrade several business logics within the application, thereby improving processing capacity and enabling smoother handling of traffic peaks. Similarly, based on... Figure 20 It can be seen that after introducing adaptive degradation, downstream calls can be automatically degraded, and the current request is recorded to continue to accumulate floods. After the sudden traffic, the floods are automatically released, thereby avoiding downtime caused by capacity bottlenecks.

[0099] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 21 , Figure 22 As shown.

[0100] Figure 21 This is a schematic diagram of the structure of a service degradation execution device provided in one or more embodiments of this specification. It is applied to a service execution system, which includes at least multiple applications. Each application's machine has a corresponding sidecar module and a degradation SDK. The device includes: Detection module 2102 is used to detect whether the current business status of the business execution system has reached the degradation threshold based on the first sidecar module in the first application upstream. The annotation module 2104 is used to, if so, annotate each request within a preset degradation time window with degradation targets based on the first sidecar module; The writing module 2106 is used to write the degradation label into the network packet through the first sidecar module when the first application calls the downstream second application. The transmission module 2108 is used to parse the network packet through the second sidecar module in the second application to obtain the degradation label, and rewrite the degradation label into the next network packet, so as to transmit the degradation label to each application level by level along the service execution link; The degradation module 2110 is used to obtain the degradation target passed by the corresponding sidecar module according to the degradation SDK in each application, and perform degradation operations for each application based on the degradation target to perform adaptive degradation of the business execution link.

[0101] Optionally, in one or more embodiments of this specification, the writing module 2106 is specifically used for: When the first application calls the downstream second application, based on the first sidecar module, a first key-value pair with the degradation label as the value is constructed according to the preset transparent field name of the degradation label and the business execution link. The first key-value pair is written into the first request attribute set in the first request object through the first sidecar module to obtain the first request object after writing; the first request object corresponds to the call request of the first application; The first request object after being written is serialized to generate a network packet; wherein the network packet carries the first key-value pair.

[0102] Optionally, in one or more embodiments of this specification, the transmission module 2108 is specifically used for: The network packet is received by the second sidecar module corresponding to the second application, the request header of the network packet is parsed, the first key-value pair with the preset transparent field name as the key is extracted, and the degradation label is obtained. When the second application calls the next application, the second sidecar module uses the preset transparent field name as the key and the degradation label as the value to construct a second key-value pair and write it into the second request attribute set of the second request object to obtain the second request object after writing. The second request object after being written is serialized to obtain the next network packet carrying the second key-value pair, thereby realizing the step-by-step transmission of the degradation target along the service execution link.

[0103] Optionally, in one or more embodiments of this specification, the degradation module 2110 is specifically used for: If the application receives the corresponding request object, it extracts the degradation label from the request attribute set of the request object based on the inbound interception point of the degradation SDK corresponding to the application, and stores it in the thread variable of each request. When the application's business is executed, the degradation label in the thread variable is read based on the degradation SDK corresponding to the application.

[0104] Optionally, in one or more embodiments of this specification, the apparatus further includes: a call transmission module 2112; The call passing module 2112 is used to read the degradation flag of the thread variable based on the outbound interception point of the degradation SDK in the application if the application calls a downstream application. The degradation SDK is used to backfill the degradation label into the request attribute of the outbound request object, and the backfilled outbound request object is written into the network packet so that the degradation label can be transmitted to the downstream application based on the network packet by the sidecar module corresponding to the application.

[0105] Optionally, in one or more embodiments of this specification, the detection module 2102 is specifically used for: When the current business state of the business execution system is business traffic, the current request is parsed based on the first sidecar module, and the matching relationship between the parameter fields of the current request and the configuration values ​​is used to determine whether to count the current request. If so, the traffic of the current request will be counted repeatedly within the counting time window; By matching the service traffic with the degradation threshold of each degradation tier, it is determined whether the service execution system has reached the degradation threshold of the target degradation tier; wherein, each degradation tier corresponds to a different degradation threshold and a different priority, and the target degradation tier is obtained based on the priority sorting of degradation tiers that have reached the degradation threshold.

[0106] Optionally, in one or more embodiments of this specification, the annotation module 2104 is specifically used for: If the business execution system reaches the degradation threshold, a preset degradation time window is opened based on the timer started by the first sidecar module; wherein, the preset degradation time window is determined based on the target degradation level and the excess traffic value of the business traffic exceeding the degradation threshold; Within the preset downgrade time window, based on the first sidecar module, each received request is marked according to the downgrade label corresponding to the target downgrade level.

[0107] Optionally, in one or more embodiments of this specification, the degradation module 2102 is specifically used for: The degradation association configuration is obtained through the degradation SDK in each of the applications; wherein, the degradation association configuration is pushed to the degradation SDK of the machine to which each application belongs based on the central configuration platform of the business execution system, including the association relationship between degradation label and degradation point; Based on the degradation label, query the degradation association configuration to obtain one or more degradation points associated with the degradation label; Based on the matching results between the business operations performed by the application and the one or more degradation points, the target degradation operation of the application is determined, and the adaptive degradation of the application is achieved by executing the target degradation operation.

[0108] Optionally, in one or more embodiments of this specification, the degradation module 2110 is specifically used for: Using the preset assertion interface of the degradation SDK, the degradation point identifier corresponding to the business operation is used as the input parameter to query whether the degradation point identifier exists in one or more degradation points; wherein, the degradation point identifier is a pre-assigned identifier for the degradeable business operation; If it exists, then return a true value based on the preset assertion interface, obtain the target degradation operation according to the degradation point corresponding to the degradation point identifier, execute the degradation of the business operation, and realize the adaptive degradation of the application.

[0109] Optionally, in one or more embodiments of this specification, the device further includes: a snapshot module 2114; The snapshot module 2114 is used to receive responses to each request through the sidecar module in each application when performing degradation operations on each application based on the degradation target, and to parse the responses to determine whether the responses have failed. If so, then obtain the request parameters corresponding to the failed response, and construct a snapshot key based on the key fields of the request parameters; wherein, the key fields are determined based on the business scenario of the request and are used to identify the business object of the request; Based on the snapshot key, a valid snapshot is queried from the database to return the decoded valid snapshot to the sidecar module of the application, so as to return the valid snapshot to the upstream application of the application.

[0110] Optionally, in one or more embodiments of this specification, the apparatus further includes: a range determination module 2116; The range determination module 2116 is used to determine the initial transmission range of the service execution link based on the target downgrade level. Based on the number of applications that have already been passed the degradation label, determine the effective number of times the business execution link has been passed. If the number of valid transmissions does not reach the initial transmission range, the degradation label is written into the next network packet based on the sidecar module corresponding to the application. If the number of valid transmissions reaches the initial transmission range, then the transmission of the downgrade label is stopped, or the target downgrade level corresponding to the downgrade label is downgraded.

[0111] Optionally, in one or more embodiments of this specification, the detection module 2102 is specifically used for: When the current business state of the business execution system is the system state, the running status information of the business execution system is obtained through the sidecar module corresponding to the upstream application based on the preset detection period; If at least one of the running status information reaches the corresponding degradation threshold, then the business execution system is determined to have reached the degradation threshold.

[0112] Figure 22 This is a schematic diagram of the structure of a service degradation execution device provided in one or more embodiments of this specification. It is applied to a service execution system, which includes at least multiple applications. Each application's machine has a corresponding sidecar module and a degradation SDK. The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Based on the first sidecar module in the first application upstream, it detects whether the current business status of the business execution system has reached the degradation threshold. If so, then within the preset downgrade time window, each request is marked with a downgrade target based on the first sidecar module; When the first application calls the downstream second application, the degradation label is written into the network packet through the first sidecar module; The second sidecar module in the second application parses the network packet to obtain the degradation label, and rewrites the degradation label into the next network packet to pass the degradation label to each application level along the service execution link; Based on the degradation SDK in each application, obtain the degradation label passed in by the corresponding sidecar module, and perform degradation operations for each application based on the degradation label to perform adaptive degradation of the business execution link.

[0113] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0114] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0115] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0116] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

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

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

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

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

[0121] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0122] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0123] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0124] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0125] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0126] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0127] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0128] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.< / object> < / object>

Claims

1. A method for degrading the execution of a service, applied to a service execution system, the service execution system comprising at least multiple applications, wherein each application's machine has a corresponding sidecar module and a degradation SDK, the method comprising: Based on the first sidecar module in the first application upstream, it detects whether the current business status of the business execution system has reached the degradation threshold. If so, then based on the first sidecar module, each request within the preset downgrade time window is marked with a downgrade target; When the first application calls the downstream second application, the degradation label is written into the network packet through the first sidecar module; The second sidecar module in the second application parses the network packet to obtain the degradation label, and rewrites the degradation label into the next network packet to pass the degradation label to each application level along the service execution link; Based on the degradation SDK in each application, obtain the degradation label passed in by the corresponding sidecar module, and perform degradation operations for each application based on the degradation label to perform adaptive degradation of the business execution link.

2. The method as described in claim 1, wherein when the first application calls the downstream second application, the degradation label is written into the network packet through the first sidecar module, specifically including: When the first application calls the downstream second application, based on the first sidecar module, a first key-value pair with the degradation label as the value is constructed according to the preset transparent field name of the degradation label and the business execution link. The first key-value pair is written into the first request attribute set in the first request object through the first sidecar module, and the first request object after writing is obtained. The first request object corresponds to the invocation request of the first application; The first request object after being written is serialized to generate a network packet; wherein the network packet carries the first key-value pair.

3. The method as described in claim 2, wherein the degradation label is obtained by parsing the network packet through the second sidecar module corresponding to the second application, and the degradation label is rewritten into the next network packet, so as to pass the degradation label to each application level by level along the service execution link, specifically includes: The network packet is received by the second sidecar module corresponding to the second application, the request header of the network packet is parsed, the first key-value pair with the preset transparent field name as the key is extracted, and the degradation label is obtained. When the second application calls the next application, the second sidecar module constructs a second key-value pair using the preset transparent field name as the key and the degradation label as the value; The second key-value pair is written into the second request attribute set of the second request object through the second sidecar module, and the second request object after writing is obtained. The second request object after being written is serialized to obtain the next network packet carrying the second key-value pair, thereby realizing the step-by-step transmission of the degradation target along the service execution link.

4. The method as described in claim 1, wherein the degradation label passed in by the corresponding sidecar module is obtained according to the degradation SDK corresponding to each application, specifically includes: If the application receives the corresponding request object, it extracts the degradation label from the request attribute set of the request object based on the inbound interception point of the degradation SDK corresponding to the application, and stores it in the thread variable of each request. When the application's business is executed, the degradation label in the thread variable is read based on the degradation SDK corresponding to the application.

5. The method of claim 4, further comprising: If the application calls a downstream application, then based on the outbound interception point of the downgrade SDK in the application, the downgrade flag of the thread variable is read; The degradation SDK is used to backfill the degradation label into the request attribute of the outbound request object, and the backfilled outbound request object is written into the network packet so that the degradation label can be transmitted to the downstream application based on the network packet by the sidecar module corresponding to the application.

6. The method as described in claim 1, based on the first sidecar module in the upstream first application, detects whether the current business state of the business execution system has reached a degradation threshold, specifically including: When the current business state of the business execution system is business traffic, the current request is parsed based on the first sidecar module, and the matching relationship between the parameter fields of the current request and the configuration values ​​is used to determine whether to count the current request. If so, the traffic of the current request will be counted repeatedly within the counting time window; By matching the service traffic with the degradation threshold of each degradation tier, it is determined whether the service execution system has reached the degradation threshold of the target degradation tier; wherein, each degradation tier corresponds to a different degradation threshold and a different priority, and the target degradation tier is obtained based on the priority sorting of degradation tiers that have reached the degradation threshold.

7. The method as described in claim 6, based on the first sidecar module, marks each request within a preset degradation time window with a degradation label, specifically including: If the business execution system reaches the degradation threshold, a preset degradation time window is opened based on the timer started by the first sidecar module; wherein, the preset degradation time window is determined based on the target degradation level and the excess traffic value of the business traffic exceeding the degradation threshold; Within the preset downgrade time window, based on the first sidecar module, each received request is labeled according to the downgrade label corresponding to the target downgrade level.

8. The method as described in claim 1, wherein degradation operations are performed on each of the applications based on the degradation target to perform adaptive degradation of the service execution chain, specifically including: The degradation association configuration is obtained through the degradation SDK in each of the applications; wherein, the degradation association configuration is pushed to the degradation SDK of the machine to which each application belongs based on the central configuration platform of the business execution system, including the association relationship between degradation label and degradation point; Based on the degradation label, query the degradation association configuration to obtain one or more degradation points associated with the degradation label; Based on the matching results between the business operations performed by the application and the one or more degradation points, the target degradation operation of the application is determined, and the adaptive degradation of the application is achieved by executing the target degradation operation.

9. The method as described in claim 8, wherein a target degradation operation for the application is determined based on the matching result between the business operations performed by the application and the one or more degradation points, and adaptive degradation of the application is achieved by executing the target degradation operation, specifically including: Using the preset assertion interface of the degradation SDK, the degradation point identifier corresponding to the business operation is used as the input parameter to query whether the degradation point identifier exists in one or more degradation points; wherein, the degradation point identifier is a pre-assigned identifier for the degradeable business operation; If it exists, then return a true value based on the preset assertion interface, obtain the target degradation operation according to the degradation point corresponding to the degradation point identifier, execute the degradation of the business operation, and realize the adaptive degradation of the application.

10. The method of claim 1, further comprising: When performing degradation operations on each of the applications based on the degradation target, the sidecar module in each application receives the response to each request, parses the response, and determines whether the response has failed. If so, then obtain the request parameters corresponding to the failed response, and construct a snapshot key based on the key fields of the request parameters; wherein, the key fields are determined based on the business scenario of the request and are used to identify the business object of the request; Based on the snapshot key, a valid snapshot is queried from the database to return the decoded valid snapshot to the application's sidecar module, so as to return the valid snapshot to the application's upstream application.

11. The method of claim 6, further comprising: Based on the target downgrade level, determine the initial transmission range of the business execution link; Based on the number of applications that have already been passed the degradation label, determine the effective number of times the business execution link has been passed. If the number of valid transmissions does not reach the initial transmission range, the degradation label is written into the next network packet based on the sidecar module corresponding to the application. If the number of valid transmissions reaches the initial transmission range, then the transmission of the downgrade label is stopped, or the target downgrade level corresponding to the downgrade label is downgraded.

12. The method as described in claim 1, wherein, based on the first sidecar module in the upstream first application, detecting whether the current business state of the business execution system has reached a degradation threshold, specifically includes: When the current business state of the business execution system is the system state, the running status information of the business execution system is obtained through the sidecar module corresponding to the upstream application based on the preset detection period; If at least one of the running status information reaches the corresponding degradation threshold, then it is determined that the current request of the business execution system has reached the degradation threshold.

13. A service degradation execution device, applied to a service execution system, the service execution system including at least multiple applications, wherein each application's machine has a corresponding sidecar module and a degradation SDK, the device comprising: The detection module is used to detect whether the current business status of the business execution system has reached the degradation threshold, based on the first sidecar module in the first application upstream. The annotation module is used to annotate each request within a preset degradation time window based on the first sidecar module if the condition is met. The writing module is used to write the degradation label into the network packet through the first sidecar module when the first application calls the downstream second application. The transmission module is used to parse the network packet through the second sidecar module in the second application to obtain the degradation label, and rewrite the degradation label into the next network packet, so as to pass the degradation label to each application level by level along the service execution link; The degradation module is used to obtain the degradation target passed by the corresponding sidecar module according to the degradation SDK in each application, and perform degradation operations for each application based on the degradation target to perform adaptive degradation of the business execution link.

14. The apparatus of claim 13, wherein the writing module is specifically used for: When the first application calls the downstream second application, based on the first sidecar module, a first key-value pair with the degradation label as the value is constructed according to the preset transparent field name of the degradation label and the business execution link. The first key-value pair is written into the first request attribute set in the first request object through the first sidecar module, and the first request object after writing is obtained. The first request object corresponds to the invocation request of the first application; The first request object after being written is serialized to generate a network packet; wherein the network packet carries the first key-value pair.

15. The apparatus of claim 14, wherein the transfer module is specifically used for: The network packet is received by the second sidecar module corresponding to the second application, the request header of the network packet is parsed, the first key-value pair with the preset transparent field name as the key is extracted, and the degradation label is obtained. When the second application calls the next application, the second sidecar module constructs a second key-value pair using the preset transparent field name as the key and the degradation label as the value; The second key-value pair is written into the second request attribute set of the second request object through the second sidecar module, and the second request object after writing is obtained. The second request object after writing is serialized to obtain the next network packet carrying the second key-value pair, thereby realizing the step-by-step transmission of the degradation target along the service execution link.

16. The apparatus of claim 13, wherein the degradation module is specifically used for: If the application receives the corresponding request object, it extracts the degradation label from the request attribute set of the request object based on the inbound interception point of the degradation SDK corresponding to the application, and stores it in the thread variable of each request. When the application's business is executed, the degradation label in the thread variable is read based on the degradation SDK corresponding to the application.

17. The apparatus of claim 16, further comprising: Call the delivery module; The call passing module is used to read the degradation flag of the thread variable based on the outbound interception point of the degradation SDK in the application if the application calls a downstream application. The degradation SDK is used to backfill the degradation label into the request attribute of the outbound request object, and the backfilled outbound request object is written into the network packet so that the degradation label can be transmitted to the downstream application based on the network packet by the sidecar module corresponding to the application.

18. The apparatus of claim 13, wherein the detection module is specifically used for: When the current business state of the business execution system is business traffic, the current request is parsed based on the first sidecar module, and the matching relationship between the parameter fields of the current request and the configuration values ​​is used to determine whether to count the current request. If so, the traffic of the current request will be counted repeatedly within the counting time window; By matching the service traffic with the degradation threshold of each degradation tier, it is determined whether the service execution system has reached the degradation threshold of the target degradation tier; wherein, each degradation tier corresponds to a different degradation threshold and a different priority, and the target degradation tier is obtained based on the priority sorting of degradation tiers that have reached the degradation threshold.

19. The apparatus of claim 18, wherein the annotation module is specifically used for: If the business execution system reaches the degradation threshold, a preset degradation time window is opened based on the first sidecar module, starting a timer; wherein, The preset degradation time window is determined based on the target degradation level and the excess traffic value of the service traffic exceeding the degradation threshold; Within the preset downgrade time window, based on the first sidecar module, each received request is marked according to the downgrade label corresponding to the target downgrade level.

20. The apparatus of claim 13, wherein the degradation module is specifically used for: The downgrade association configuration is obtained through the downgrade SDK in each of the aforementioned applications; wherein... The degradation association configuration is pushed to the degradation SDK of each application's machine based on the central configuration platform of the business execution system, including the association between degradation labels and degradation points; Based on the degradation label, query the degradation association configuration to obtain one or more degradation points associated with the degradation label; Based on the matching results between the business operations performed by the application and the one or more degradation points, the target degradation operation of the application is determined, and the adaptive degradation of the application is achieved by executing the target degradation operation.

21. The apparatus of claim 20, wherein the degradation module is specifically used for: Using the preset assertion interface of the degradation SDK, with the degradation point identifier corresponding to the business operation as the input parameter, it queries whether the degradation point identifier exists in one or more degradation points; wherein, The degradation point identifier is a pre-assigned identifier for degradeable business operations; If it exists, then return a true value based on the preset assertion interface, obtain the target degradation operation according to the degradation point corresponding to the degradation point identifier, execute the degradation of the business operation, and realize the adaptive degradation of the application.

22. The apparatus of claim 13, further comprising: Snapshot module; The snapshot module is used to receive responses to each request through the sidecar module in each application when performing degradation operations based on the degradation target, and to parse the responses to determine whether the responses have failed. If so, then obtain the request parameters corresponding to the failed response, and construct a snapshot key based on the key fields of the request parameters; wherein, the key fields are determined based on the business scenario of the request and are used to identify the business object of the request; Based on the snapshot key, a valid snapshot is queried from the database to return the decoded valid snapshot to the application's sidecar module, so as to return the valid snapshot to the application's upstream application.

23. The apparatus of claim 18, further comprising: Range determination module; The range determination module is used to determine the initial transmission range of the business execution link based on the target downgrade level. Based on the number of applications that have already been passed the degradation label, determine the effective number of times the business execution link has been passed. If the number of valid transmissions does not reach the initial transmission range, the degradation label is written into the next network packet based on the sidecar module corresponding to the application. If the number of valid transmissions reaches the initial transmission range, then the transmission of the downgrade label is stopped, or the target downgrade level corresponding to the downgrade label is downgraded.

24. The apparatus of claim 13, wherein the detection module is specifically used for: When the current business state of the business execution system is the system state, the running status information of the business execution system is obtained through the sidecar module corresponding to the upstream application based on the preset detection period; If at least one of the running status information reaches the corresponding degradation threshold, then the business execution system is determined to have reached the degradation threshold.

25. A service degradation execution device, applied to a service execution system, the service execution system including at least multiple applications, wherein each application's machine has a corresponding sidecar module and a degradation SDK, the device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Based on the first sidecar module in the first application upstream, it detects whether the current business status of the business execution system has reached the degradation threshold. If so, then within the preset downgrade time window, each request is marked with a downgrade target based on the first sidecar module; When the first application calls the downstream second application, the degradation label is written into the network packet through the first sidecar module; The second sidecar module in the second application parses the network packet to obtain the degradation label, and rewrites the degradation label into the next network packet to pass the degradation label to each application level along the service execution link. Based on the degradation SDK in each application, obtain the degradation label passed in by the corresponding sidecar module, and perform degradation operations for each application based on the degradation label to perform adaptive degradation of the business execution link.

Images