CN107968720B - Information transmission method, cloud system and component - Google Patents
Information transmission method, cloud system and component Download PDFInfo
- Publication number
- CN107968720B CN107968720B CN201610916341.2A CN201610916341A CN107968720B CN 107968720 B CN107968720 B CN 107968720B CN 201610916341 A CN201610916341 A CN 201610916341A CN 107968720 B CN107968720 B CN 107968720B
- Authority
- CN
- China
- Prior art keywords
- component
- request message
- message
- cloud system
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Abstract
After a request message carrying a fault positioning identifier is sent to a cloud system, a response message finally output by the cloud system comprises information reflecting the operation condition of each component, the operation condition of each component and a response message received by each component, so that which device (comprising the components and a user source station server) has a fault can be detected according to the response message finally output by the cloud system, and the accurate positioning of the fault is realized.
Description
Technical Field
The present application relates to the field of electronic information, and in particular, to an information transmission method, a cloud system, and a component.
Background
Cloud systems are now becoming more and more widely used because of their series of advantages. Fig. 1 is a schematic diagram of a client or a browser accessing a server through a cloud system, where the cloud system generally includes at least one node, and each node includes at least one component, and the component is software or a subsystem for performing HTTP processing. In fig. 1, a cloud system includes a primary node and a secondary node, and each of the nodes in each stage includes two components. When a client or a browser needs to access a server, an HTTP request is sent to the cloud system, according to the sequence of the component 1 in the first-level node, the component 2 in the first-level node, the component 1 in the second-level node, and the component 2 in the second-level node, each node in the cloud system receives the HTTP request in sequence and performs corresponding processing on the HTTP request (adding a message header of the component, etc.), and the component 2 in the second-level node finally sends the HTTP request to a user source station server (a transmission path of the HTTP request is shown by a solid line in fig. 1). After receiving the HTTP request, the user source station server responds the requested data to the cloud system, and components in the cloud system respond to the client or the browser in a reverse order (as shown by a dotted arrow in fig. 1) according to the above order.
In the process shown in fig. 1, transmission of a request or a response may not be performed normally due to a failure of a component in the cloud system. In the prior art, technicians are required to manually query operation records of each component, such as log and packet capture analysis, so as to determine the failed component.
Disclosure of Invention
The application provides an information transmission method, a cloud system and a component, and aims to solve the problem that the existing cloud system-based fault location efficiency is not high.
In order to achieve the above object, the present application provides the following technical solutions:
an information transmission method, comprising:
after receiving a first request message, a first component in the cloud system forwards the first request message, wherein the first request message comprises a fault positioning identifier;
after receiving the first request message, a second component in the cloud system sends a second request message to a first device, wherein the first device is other devices except for the components in the cloud system;
after receiving a second response message related to the second request message from the first device, the second component sends a first response message to the first component, wherein the first response message comprises a message header of the second response message and information reflecting the operating condition of the second component;
and after receiving the first response message, the first component sends a feedback message to a sender of the first request message, wherein the feedback message comprises the first response message and information reflecting the operating condition of the first component.
Optionally, after receiving the first request message, the second component in the cloud system sending a second request message to the first device includes:
after receiving the first request message, a second component in the cloud system obtains a second request message by deleting the fault positioning identifier in the first request message;
the second component sends the second request message to the first device.
Optionally, after the first component in the cloud system receives the first request message and before forwarding the first request message, the method further includes:
the first component confirms that the first request message comprises the fault positioning identification and the fault positioning identification passes authentication; and/or
After the second component in the cloud system receives the first request message and before sending a second request message, the method further includes:
and the second component confirms that the first request message comprises the fault positioning identification and the fault positioning identification passes authentication.
Optionally, the information reflecting the operation condition of the first component includes:
at least one of a time when a first data packet is received by the first component, a request processing time of the first component, configuration information of the first component, or a message header used by the first component for forwarding a message.
The information reflecting the operation condition of the second component comprises:
at least one of a time when the second component receives a first data packet, a request processing time of the second component, configuration information of the second component, or a message header used by the second component to forward a message.
Optionally, the sender of the first request message includes:
a second device other than a component in the cloud system, or
Other components in the cloud system.
An information transmission method is suitable for components in a cloud system and comprises the following steps:
after receiving a first request message, sending a second request message, wherein the first request message comprises a fault positioning identifier;
and after receiving a second response message aiming at the second request message, sending a first response message, wherein the first response message comprises information reflecting the operation condition of the component and at least a message header of the second response message.
Optionally, the component is a last component belonging to the cloud system on a request message transmission path, and the sending the second request message includes:
obtaining the second request message by deleting the fault positioning identifier in the first request message;
sending the second request message to a device other than a component in the cloud system.
Optionally, the first response message includes information reflecting an operating condition of the component, and at least a header of the second response message includes:
the first response message includes information reflecting an operating condition of the component and a header of the second response message.
Optionally, the component is a component other than a last component belonging to the cloud system on a request message transmission path, and the sending the second request message includes:
sending the second request message to other components in the cloud system, the second request message including the fault location identification.
Optionally, the first response message includes information reflecting an operating condition of the component, and at least a header of the second response message includes:
the first response message includes information reflecting an operational condition of the component and the second response message.
Optionally, after receiving the first request message and before sending the second request message, the method further includes:
and confirming that the first request message comprises the fault positioning identification, and the authentication of the fault positioning identification is passed.
Optionally, the information reflecting the operation condition of the component includes:
at least one of a time when the component receives a first data packet, a request processing time of the component, configuration information of the component, or a message header used by the component to forward a message.
A cloud system, comprising:
the first component is used for forwarding a first request message after receiving the first request message, wherein the first request message comprises a fault positioning identifier;
the second component is used for sending a second request message after receiving the first request message, and sending a first response message to the first component after receiving a second response message related to the second request message, wherein the first response message comprises a message header of the second response message and information reflecting the operating condition of the second component;
the first component is further configured to send a feedback message to a sender of the first request message after receiving the first response message, where the feedback message includes the first response message and information reflecting an operation condition of the first component.
Optionally, the second component is configured to, after receiving the first request message, send a second request message, where the sending the second request message includes:
the second component is specifically configured to, after receiving the first request message, obtain a second request message by deleting the fault location identifier in the first request message, and send the second request message to the first device outside the cloud system.
Optionally, the first component is further configured to:
after receiving a first request message and before forwarding the first request message, confirming that the first request message comprises the fault positioning identification and the fault positioning identification passes authentication;
the second component is further configured to:
after receiving the first request message and before sending the second request message, confirming that the first request message comprises the fault location identification and the fault location identification passes the authentication.
Optionally, the information reflecting the operation condition of the first component includes:
at least one of a time when a first data packet is received by the first component, a request processing time of the first component, configuration information of the first component, or a message header used by the first component for forwarding a message.
The information reflecting the operation condition of the second component comprises:
at least one of a time when the second component receives a first data packet, a request processing time of the second component, configuration information of the second component, or a message header used by the second component to forward a message.
Optionally, the sender of the first request message includes:
a second device other than a component in the cloud system; or
Other components in the cloud system.
An assembly, comprising:
the first sending module is used for sending a second request message after receiving a first request message, wherein the first request message comprises a fault positioning identifier;
a second sending module, configured to send a first response message after receiving a second response message for the second request message, where the first response message includes information reflecting an operating condition of the component and at least a header of the second response message.
Optionally, the component is a last component belonging to the cloud system on a request message transmission path, and the first sending module is configured to send the second request message and includes:
the first sending module is specifically configured to obtain the second request message by deleting the fault location identifier in the first request message, and send the second request message to a device other than the component in the cloud system.
Optionally, the first response message includes information reflecting an operating condition of the component, and at least a header of the second response message includes:
the first response message includes information reflecting an operating condition of the component and a header of the second response message.
Optionally, the component is a component other than a last component belonging to the cloud system on a request message transmission path, and the first sending module is configured to send the second request message and includes:
the first sending module is specifically configured to send the second request message to other components in the cloud system, where the second request message includes the fault location identifier.
Optionally, the first response message includes information reflecting an operating condition of the component, and at least a header of the second response message includes:
the first response message includes information reflecting an operational condition of the component and the second response message.
Optionally, the first sending module is further configured to:
after receiving the first request message and before sending the second request message, confirming that the first request message comprises the fault positioning identification and the fault positioning identification passes the authentication.
Optionally, the information reflecting the operation condition of the component includes:
at least one of a time when the component receives a first data packet, a request processing time of the component, configuration information of the component, or a message header used by the component to forward a message.
According to the information transmission method and the cloud system, after the request message carrying the fault positioning identifier is sent to the cloud system, the response message finally output by the cloud system comprises the information reflecting the operation condition of each component, the information of the operation condition of each component and the response message received by each component, so that which device (including the component and the user source station server) has a fault can be detected according to the response message finally output by the cloud system, and the accurate positioning of the fault is realized.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
FIG. 1 is a schematic diagram of a client or browser accessing a server through a cloud system;
fig. 2 is a flowchart of an information transmission method disclosed in an embodiment of the present application;
fig. 3 is a flowchart of an example of information transmission disclosed in an embodiment of the present application;
fig. 4 is a flowchart of another information transmission method disclosed in the embodiment of the present application;
fig. 5 is a schematic structural diagram of a cloud system disclosed in an embodiment of the present application;
fig. 6 is a schematic structural diagram of an assembly disclosed in an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
For convenience of explanation, in this embodiment, two devices adjacent to each other in the transmission path indicated by the solid line in fig. 1 are mutually referred to as an upper-stage device and a lower-stage device. For example, component 1 in a level one node is a superior device of component 2 in the level one node, and component 2 in the level one node is a inferior device of component 1 in the level one node. The component 2 in the primary node is the previous device of the component 1 in the secondary node.
It should be noted that the method and apparatus described in the embodiment of the present application are only described with reference to fig. 1 as an example, and the layout and connection manner of the nodes and components in the cloud system are not limited to fig. 1, and therefore, the method and apparatus described in the embodiment of the present application are not limited to the structure shown in fig. 1.
Fig. 2 is an information transmission method disclosed in an embodiment of the present application, which is applied in the scenario shown in fig. 1, and includes the following steps:
s201: if the HTTP request processing of the cloud system fails, a client or a browser which is used as a sending end of the HTTP request generates an HTTP request message (request message 1) carrying a fault location identifier.
Specifically, the fault location identifier may be a preset header of the HTTP request message, where the header is different from an existing HTTP header, and for example, the header is X-AliCDN-TraceInfo.
S202: after receiving the request message 1, the component 1 of the primary node judges whether the request message 1 carries a fault location identifier, if so, executes S203, and if not, processes according to the existing HTTP request processing mode.
S203: and the component 1 of the primary node authenticates the fault positioning identifier, if the fault positioning identifier passes the authentication, S204 is executed, and if the fault positioning identifier does not pass the authentication, the fault positioning identifier is processed according to the existing HTTP request processing mode.
The purpose of authentication is to set authority for fault location operation so as to improve the security of the cloud system. For example, only if the message header authentication of the HTTP request message passes, the components in the cloud system perform fault location, so the fault location process of the cloud system can only be triggered by the sender of the HTTP request message that obtains an accurate message header, and not by any sender of the HTTP request messages.
S204: component 1 of the level one node forwards the request message 2 to component 2 of the level one node.
It should be noted that, in general, when a component forwards a message, a message header including information (e.g., an identifier) of the component is added to a header of the message. In this embodiment, component 1 of the primary node may add such a header to request message 1, and request message 2 differs from request message 1 in that the header used by component 1 of the primary node is added. Of course, the message header may not be added, and in this case, the request message 2 is the same as the request message 1.
S205: and the component 2 of the primary node judges whether the request message 2 carries a fault positioning identifier, if so, executes S206, and if not, processes according to the existing HTTP request processing mode.
S206: and the component 2 of the primary node authenticates the fault positioning identifier, if the fault positioning identifier passes the authentication, S204 is executed, and if the fault positioning identifier does not pass the authentication, the fault positioning identifier is processed according to the existing HTTP request processing mode.
S207: component 2 of the primary node will forward the request message 3 to component 1 of the secondary node.
Similar to S204, the component 2 at the primary peer may or may not add a message header used by the component 2 at the primary peer to the request message 2.
S208: and the component 1 of the secondary node judges whether the request message 3 carries a fault positioning identifier, if so, S209 is executed, and if not, the processing is carried out according to the existing HTTP request processing mode.
S209: and the component 1 of the secondary node authenticates the fault positioning identifier, if the fault positioning identifier passes the authentication, S210 is executed, and if the fault positioning identifier does not pass the authentication, the fault positioning identifier is processed according to the existing HTTP request processing mode.
S210: component 1 of the secondary node forwards the request message 4 to component 2 of the secondary node.
S211: and the component 2 of the secondary node judges whether the request message 4 carries a fault positioning identifier, if so, the step S212 is executed, and if not, the processing is carried out according to the existing HTTP request processing mode.
S212: and the component 2 of the secondary node authenticates the fault positioning identifier, if the fault positioning identifier passes the authentication, S213 is executed, and if the fault positioning identifier does not pass the authentication, the fault positioning identifier is processed according to the existing HTTP request processing mode.
S213: the component 2 of the secondary node deletes the fault locating identity in the request message 4.
Since the component 2 of the secondary node is the last component of the transmission path of the request message in the cloud system, and the component 2 of the secondary node is to send the HTTP request to the user source station server, there is a possibility that the user source station server cannot resolve the fault location identifier, and the fault location requires the server to resolve a message header of a response message fed back after the HTTP request, and therefore, the fault location identifier in the HTTP request needs to be deleted before the HTTP request is sent to the user source station server.
S214: the component 2 of the secondary node forwards the message (request message 5) with the fault location identity deleted to the user source station server.
Request message 5 may also add a header to be used by component 2 of the secondary node compared to request message 4, in addition to not including the fault locating identity.
S215: after receiving the message, the user source station server sends a response message (response message 1) to the component 2 of the secondary node.
S216: after receiving the response message 1, the component 2 of the secondary node sends the message header of the response message 1, the information reflecting the operation condition of the component and the message header used by the component for forwarding the message to the component 1 of the secondary node.
Specifically, the information reflecting the operation condition of the present component may include key information and configuration information of the present component, where the key information includes but is not limited to: request processing time and first packet time. The configuration information is variably configurable information for a domain name.
Because the message body of the response message 1 fed back by the user source station server is data requested by the client or the browser, it has no great significance for fault location of the cloud system, and therefore, in S216, the last component in the cloud system, that is, the component 2 of the secondary node, only sends the message header of the received response message 1 to the upper-level device.
Specifically, the message header of the response message 1, the information reflecting the operation condition of the component, and the message header used by the component for forwarding the message may be integrated into the message body of the response message (response message 2) sent to the component 1 of the secondary node and sent to the component 1 of the secondary node. The header of the response message 2 may be a header used by the present component to forward the message.
S217: after receiving the response message 2, the component 1 of the secondary node integrates the response message 2, the information reflecting the operation condition of the component and the message head used by the component for forwarding the message in the message body of the response message 3 and sends the information to the component 2 of the primary node.
The header of the response message 3 may be a header used by the component 1 of the secondary node to forward the message.
S218: after receiving the response message 3, the component 2 of the primary node integrates the response message 3, the information reflecting the operation condition of the component and the message head used by the component for forwarding the message in the message body of the response message 4 and sends the message head to the component 1 of the primary node.
The header of the response message 4 may be a header used by the component 2 of the level one node to forward the message.
S219: after receiving the response message 4, the component 1 of the primary node integrates the response message 4, the information reflecting the operation condition of the component and the message header used by the component for forwarding the message in the message body of the response message 5 and sends the message body to the client or the browser.
The header of the response message 5 may be a header used by the component 1 of the level one node to forward the message.
It can be seen from the above flow that, after the request message carrying the fault location identifier is sent to the cloud system, the response message 5 finally output by the cloud system includes information reflecting the operating conditions of each component, information carried in a message header used when each component forwards the message, and a response message received by each component, so that which device (including the component and the user source station server) has a fault can be detected according to the response message finally output by the cloud system, thereby implementing accurate location of the fault.
The process shown in fig. 2 is illustrated below with reference to fig. 3:
the client or the browser sends a new HTTP request message (marked as a second HTTP request message) to the cloud system, the message header of the second HTTP request message is X-AliCDN-TraceInfo, and the message body indicates that video data is requested from the user source station. After receiving the second HTTP request message, the component 1 of the primary node of the cloud system parses the message header to obtain the X-AliCDN-TraceInfo, and the component 1 of the primary node determines that the current fault location procedure is performed, instead of ordinary request forwarding. The component 1 of the primary node forwards a second HTTP request message (denoted as a third HTTP request message) to the component 2 of the primary node, where a header of the third HTTP request message is typically a header (denoted as x 1) used by the component 1 of the primary node to send a message, and a message body of the third HTTP request message is the second HTTP request message.
Similarly, component 2 of the primary node forwards a third HTTP request message (denoted as a fourth HTTP request message) to component 1 of the secondary node, and component 1 of the secondary node forwards the fourth HTTP request message to component 2 of the secondary node.
And after analyzing the received fourth HTTP request message, the component 2 of the secondary node deletes the X-AliCDN-TraceInfo and then sends a fifth HTTP request message to the user source station server.
And after receiving the fifth HTTP request message, the user source station server feeds back a response message (marked as a first response message) to the component 2 of the secondary node, wherein the response header of the first response message is the message header of the user source station, and the response body is video data requested by the client or the browser. The component 2 of the second level node feeds back a response message (marked as a second response message) to the component 1 of the second level node, the message header of the second response message is the message header of the component 2 of the second level node, and the message body is the message header of the first response message, and the key information and the configuration information of the component 2 of the second level node.
The component 1 of the second level node feeds back a response message (marked as a third response message) to the component 2 of the first level node, the message header of the third response message is the message header of the component 1 of the second level node, and the message body is the message body of the second response message, and the key information and the configuration information of the component 1 of the second level node.
Similarly, the component 2 of the first-level node feeds back a fourth response message to the component 1 of the first-level node, where the message header is the message header of the component 2 of the first-level node, and the message body is the message body of the third response message, the key information and the configuration information of the component 2 of the first-level node. And feeding back a fifth response message to the client or the browser by the component 1 of the first-level node, wherein the message header is the message header of the component 1 of the first-level node, and the message header is the fourth response message, and the key information and the configuration information of the component 1 of the first-level node.
The client or the browser receives a response message from the cloud system, wherein the response message comprises message headers, key information and configuration information of each component of the cloud system, and therefore, the client or the browser performs the following steps according to the key information of the component 1 of the primary node: the request processing time is too long, and the component 1 of the primary node is determined to be in failure.
From the above example, it can be seen that the information of each component can be collected by sending a request packet carrying the fault location identifier X-AliCDN-TraceInfo to the cloud system without a worker logging in each component to obtain a log of the component to analyze which component fails, so as to analyze which component fails.
It should be noted that, as can be seen from fig. 2 or fig. 3, compared with other components, the last component belonging to the cloud system in the transmission of the request message has an added function of deleting the fault location identifier in the process of forwarding the request message. In the process of forwarding the response message, only the message header of the response message fed back by the upper-level device is forwarded. Therefore, it can also be said that the components in the cloud system are divided according to functions, and can be divided into a second component (i.e., the last component belonging to the cloud system on the request message transmission) and a first component (other components except the second component).
As defined by the above functions, the cloud system may be abstracted as a system including a first component and a second component, and the message passing process between the first component and the second component may be abstracted as:
the first component receives and forwards the first request message to the second component, the second component sends the second request message to the user source station server, the second component receives a second response message which is sent by the user source station server and aims at the second request message, and the first component sends a feedback message to the client or the browser or other components in the cloud system after receiving the first response message.
Fig. 4 is an information transmission method disclosed in an embodiment of the present application, and compared with fig. 2 or fig. 3, the process shown in fig. 4 is mainly described in any one of the components, and includes the following steps:
s400: and if the HTTP request processing of the cloud system fails, the client or the browser generates an HTTP request carrying a fault positioning identifier.
Specifically, the fault location identifier may be a preset header of the HTTP request, which is different from an existing HTTP header, for example, the header is X-AliCDN-TraceInfo.
The execution subject of S400 is a client or a browser, and the execution subject of the following steps is any one of the components shown in fig. 1.
S401: an HTTP request message is received.
It should be noted that, if the cloud system does not have an HTTP request processing failure, the server of the cloud system does not send an HTTP request carrying a failure location identifier, and then the HTTP request received in S401 may be a request sent by the client or the server to access the server.
S402: and judging whether the received HTTP request message carries a fault positioning identifier, if so, executing S403, and if not, processing according to the existing HTTP request processing mode.
Specifically, after receiving the HTTP request message, the component obtains a message header of the HTTP request message by parsing the HTTP request message, and determines that the HTTP request message carries the fault location identifier if the message header is a preset message header, and otherwise determines that the HTTP request message does not carry the fault location identifier. Of course, the fault location identifier may not be included in the message header, as long as it is carried in the request message.
The function of using the fault location identifier is to make the fault location method described in this embodiment compatible with the existing HTTP request processing flow of the cloud system, that is, the component determines whether to perform the fault location flow or perform the ordinary HTTP request processing flow through the fault location identifier.
S403: and authenticating the fault positioning identifier, if the fault positioning identifier passes the authentication, executing S404, and if the fault positioning identifier does not pass the authentication, processing according to the existing HTTP request processing mode.
The purpose of authentication is to set authority for fault location operation so as to improve the security of the cloud system. For example, only if the message header authentication of the HTTP request message passes, the components in the cloud system perform fault location, so the fault location process of the cloud system can only be triggered by the sender of the HTTP request message that obtains an accurate message header, and not by any sender of the HTTP request messages.
S404: and judging whether the self is the last component on the transmission path of the HTTP request message, if so, executing S405 to S409, and if not, executing S406 to S408 and S410.
S405: and deleting the fault positioning identifier.
Since the last component is to send the HTTP request message to the user source station server, there is a possibility that the user source station server cannot resolve the fault location identifier, and the fault location requires the server to resolve the message header of the response message fed back after the HTTP request message, and therefore, the fault location identifier in the HTTP request message needs to be deleted before sending the HTTP request message to the user source station server.
S406: and sending the HTTP request message to the next level device of the component.
When forwarding the HTTP request, the component may add a message header to the received HTTP request message according to service requirements, or may not change the received HTTP request message.
Each component can issue an HTTP request message to the next-level device according to the above-described procedure. After the last component sends HTTP request message to the user source station server, the user source station feeds back response message, and correspondingly, each component feeds back response to the previous-stage device after receiving the response message of the next-stage device. Specifically, after receiving the response message of the next-level device, any one component performs the following process:
s407: and receiving a response message fed back by the next-level equipment of the assembly, wherein the response message comprises a message header and a message body.
S408: and sending the information and the key information carried by a message header used by the component for sending the HTTP request message to the next-level equipment and the configuration information of the component to the previous-level equipment of the component. Specifically, the message header, the key information, and the configuration information of the present component used for sending the HTTP request message may be placed in a message body of a response message that the present component responds to the upper component, and sent to the upper device of the present component.
It should be noted that if the present component is an initial component (component 1 of the primary node) on the transmission path shown in fig. 1, the upper-level device of the present component is a sender of the HTTP request, and if the present component is not the initial component, the upper-level device of the present component is the upper-level component.
S409: and sending the message head of the response message fed back by the next-level equipment to the previous-level equipment.
Since the message body of the response message fed back by the server is the data requested by the client or the browser, it has no great significance for fault location of the cloud system, and therefore, in S209, the last component in the cloud system only sends the message header of the response message to the upper-level device.
Specifically, the HTTP message header, the key information, the configuration information, and the message header in S409 may be integrated into a message body of a response message sent to the higher-level device and sent to the higher-level device.
S410: and sending the message body of the response message fed back by the next-level equipment to the previous-level equipment.
Since the last component has discarded the message body of the response message fed back by the user source station server, and assembles the key information into the message body of the response message sent to the upper-level device (equivalent to modifying the message body of the response message fed back by the user source station server), and then responds to the upper-level device, the message body of the response message received by the upper-level device is the key information for the positioning problem, and therefore, in S210, the last component only sends the message body of the response message fed back by the lower-level device to the upper-level device.
The HTTP message header, the key information, the configuration information in S408 and the message body in S410 may be integrated into a message body of a response message sent to the higher-level device and sent to the higher-level device.
S411: the server of the cloud system receives the response message output by the component.
From S404 to S410, it can be known that the final response message includes the message header, the key information, the configuration information of the HTTP request message of the server and each component, and the message header and the message body of the response message for responding to the HTTP request message (except the message body of the user source station server), so that the server of the cloud system can obtain the operation condition of each component, and can analyze which component the failure occurs in according to the operation condition, without logging in the components one by one to perform troubleshooting. Therefore, compared with the existing fault location method of the cloud system, the method has higher efficiency.
Corresponding to the above method, an embodiment of the present application further discloses a cloud system, as shown in fig. 5, including a first component and a second component. The first component is used for forwarding a first request message after receiving the first request message, wherein the first request message comprises a fault location identifier. And the second component is used for sending a second request message after receiving the first request message, and sending a first response message to the first component after receiving a second response message related to the second request message, wherein the first response message comprises a message header of the second response message and information reflecting the operating condition of the second component. The first component is further configured to send a feedback message to a sender of the first request message after receiving the first response message, where the feedback message includes the first response message and information reflecting an operating condition of the first component.
For specific implementation of functions of the first component and the second component, reference may be made to the method embodiments shown in fig. 2 or fig. 3, which are not described herein again.
It should be noted that the first component and the second component are divided according to functions, the cloud system may include a plurality of first components, as described above, the second component is the last component belonging to the cloud system on the request message transmission path, and all the other components are the first components.
Specifically, the front and rear adjacent components may be disposed in the same node, for example, two first components may be disposed in the same node, and the second component and the previous first component may also be disposed in the same node.
As shown in fig. 6, an embodiment of the present application further discloses an assembly, disposed in a cloud system, including: the device comprises a first sending module and a second sending module.
The first sending module is used for sending a second request message after receiving a first request message, wherein the first request message comprises a fault positioning identifier. The second sending module is configured to send a first response message after receiving a second response message for the second request message, where the first response message includes information reflecting an operating condition of the component and at least a header of the second response message.
Specifically, the specific implementation of the functions of the first sending module and the second sending module may be shown in fig. 4, and is not described here again. Optionally, the components shown in fig. 6 may further include a first receiving module, configured to receive the first request message and the second response message.
The functions described in the method of the embodiment of the present application, if implemented in the form of software functional units and sold or used as independent products, may be stored in a storage medium readable by a computing device. Based on such understanding, part of the contribution to the prior art of the embodiments of the present application or part of the technical solution may be embodied in the form of a software product stored in a storage medium and including several instructions for causing a computing device (which may be a personal computer, a server, a mobile computing device or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (20)
1. An information transmission method, comprising:
after receiving a first request message, a first component in the cloud system forwards the first request message, wherein the first request message comprises a fault positioning identifier;
after receiving the first request message, a second component in the cloud system sends a second request message to a first device, wherein the first device is other devices except for the components in the cloud system;
after receiving a second response message related to the second request message from the first device, the second component sends a first response message to the first component, wherein the first response message comprises a message header of the second response message and information reflecting the operating condition of the second component;
and after receiving the first response message, the first component sends a feedback message to a sender of the first request message, wherein the feedback message comprises the first response message and information reflecting the operating condition of the first component.
2. The method of claim 1, wherein sending a second request message to the first device after the second component in the cloud system receives the first request message comprises:
after receiving the first request message, a second component in the cloud system obtains a second request message by deleting the fault positioning identifier in the first request message;
the second component sends the second request message to the first device.
3. The method of claim 1, wherein after the first component in the cloud system receives the first request message and before forwarding the first request message, further comprising:
the first component confirms that the first request message comprises the fault positioning identification and the fault positioning identification passes authentication; and/or
After the second component in the cloud system receives the first request message and before sending a second request message, the method further includes:
and the second component confirms that the first request message comprises the fault positioning identification and the fault positioning identification passes authentication.
4. The method according to any one of claims 1 to 3, wherein the information reflecting the operating condition of the first component comprises:
at least one of a time when a first data packet is received by the first component, a request processing time of the first component, configuration information of the first component, or a message header used by the first component for forwarding a message;
the information reflecting the operation condition of the second component comprises:
at least one of a time when the second component receives a first data packet, a request processing time of the second component, configuration information of the second component, or a message header used by the second component to forward a message.
5. A method according to any one of claims 1 to 3, wherein the sender of the first request message comprises:
a second device other than a component in the cloud system, or
Other components in the cloud system.
6. An information transmission method is suitable for components in a cloud system, and is characterized by comprising the following steps:
after receiving a first request message, sending a second request message, wherein the first request message comprises a fault positioning identifier;
and after receiving a second response message aiming at the second request message, sending a first response message, wherein the first response message comprises information reflecting the operation condition of the component and at least a message header of the second response message.
7. The method of claim 6, wherein the component is a last component belonging to the cloud system in a request message transmission path, and wherein sending the second request message comprises:
obtaining the second request message by deleting the fault positioning identifier in the first request message;
sending the second request message to a device other than a component in the cloud system.
8. The method of claim 6, wherein the component is a component other than a last component belonging to the cloud system on a request message transmission path, and wherein sending the second request message comprises:
sending the second request message to other components in the cloud system, the second request message including the fault location identification.
9. The method according to any one of claims 6 to 8, wherein after receiving the first request message and before sending the second request message, further comprising:
and confirming that the first request message comprises the fault positioning identification, and the authentication of the fault positioning identification is passed.
10. The method according to any one of claims 6 to 8, wherein the information reflecting the operating condition of the component comprises:
at least one of a time when the component receives a first data packet, a request processing time of the component, configuration information of the component, or a message header used by the component to forward a message.
11. A cloud system, comprising:
the first component is used for forwarding a first request message after receiving the first request message, wherein the first request message comprises a fault positioning identifier;
the second component is used for sending a second request message after receiving the first request message, and sending a first response message to the first component after receiving a second response message related to the second request message, wherein the first response message comprises a message header of the second response message and information reflecting the operating condition of the second component;
the first component is further configured to send a feedback message to a sender of the first request message after receiving the first response message, where the feedback message includes the first response message and information reflecting an operation condition of the first component.
12. The system of claim 11, wherein the second component, upon receiving the first request message, is configured to send a second request message comprising:
the second component is specifically configured to, after receiving the first request message, obtain a second request message by deleting the fault location identifier in the first request message, and send the second request message to the first device outside the cloud system.
13. The system of claim 11, wherein the first component is further configured to:
after receiving a first request message and before forwarding the first request message, confirming that the first request message comprises the fault positioning identification and the fault positioning identification passes authentication;
the second component is further configured to:
after receiving the first request message and before sending the second request message, confirming that the first request message comprises the fault location identification and the fault location identification passes the authentication.
14. The system according to any one of claims 11 to 13, wherein the information reflecting the operating condition of the first component comprises:
at least one of a time when a first data packet is received by the first component, a request processing time of the first component, configuration information of the first component, or a message header used by the first component for forwarding a message;
the information reflecting the operation condition of the second component comprises:
at least one of a time when the second component receives a first data packet, a request processing time of the second component, configuration information of the second component, or a message header used by the second component to forward a message.
15. The system according to any of claims 11 to 13, wherein the sender of the first request message comprises:
a second device other than a component in the cloud system; or
Other components in the cloud system.
16. An assembly, comprising:
the first sending module is used for sending a second request message after receiving a first request message, wherein the first request message comprises a fault positioning identifier;
a second sending module, configured to send a first response message after receiving a second response message for the second request message, where the first response message includes information reflecting an operating condition of the component and at least a header of the second response message.
17. The component of claim 16, wherein the component is a last component belonging to a cloud system on a request message transmission path, and the first sending module is configured to send the second request message and comprises:
the first sending module is specifically configured to obtain the second request message by deleting the fault location identifier in the first request message, and send the second request message to a device other than the component in the cloud system.
18. The component of claim 16, wherein the component is a component other than a last component belonging to a cloud system on a request message transmission path, and wherein the first sending module is configured to send the second request message comprises:
the first sending module is specifically configured to send the second request message to other components in the cloud system, where the second request message includes the fault location identifier.
19. The assembly according to any one of claims 16 to 18, wherein the first sending module is further configured to:
after receiving the first request message and before sending the second request message, confirming that the first request message comprises the fault positioning identification and the fault positioning identification passes the authentication.
20. The component of any of claims 16 to 18, wherein the information reflecting the operational condition of the component comprises:
at least one of a time when the component receives a first data packet, a request processing time of the component, configuration information of the component, or a message header used by the component to forward a message.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610916341.2A CN107968720B (en) | 2016-10-20 | 2016-10-20 | Information transmission method, cloud system and component |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610916341.2A CN107968720B (en) | 2016-10-20 | 2016-10-20 | Information transmission method, cloud system and component |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107968720A CN107968720A (en) | 2018-04-27 |
| CN107968720B true CN107968720B (en) | 2021-03-12 |
Family
ID=61997355
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610916341.2A Active CN107968720B (en) | 2016-10-20 | 2016-10-20 | Information transmission method, cloud system and component |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107968720B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112312162B (en) * | 2020-10-16 | 2022-11-08 | 安擎(天津)计算机有限公司 | Video server for transmitting video stream |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102932245A (en) * | 2012-10-09 | 2013-02-13 | 中兴通讯股份有限公司 | Method and device for processing and tracking terminal access controller access control system (TACACS)+ session |
| CN105530639A (en) * | 2014-09-28 | 2016-04-27 | 中国电信股份有限公司 | Network controller and network control method |
| CN105593835A (en) * | 2013-10-03 | 2016-05-18 | 慧与发展有限责任合伙企业 | Managing a number of secondary clouds by a master cloud service manager |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101287257B (en) * | 2007-04-09 | 2012-10-17 | 华为技术有限公司 | Service tracking method, system and server |
-
2016
- 2016-10-20 CN CN201610916341.2A patent/CN107968720B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102932245A (en) * | 2012-10-09 | 2013-02-13 | 中兴通讯股份有限公司 | Method and device for processing and tracking terminal access controller access control system (TACACS)+ session |
| CN105593835A (en) * | 2013-10-03 | 2016-05-18 | 慧与发展有限责任合伙企业 | Managing a number of secondary clouds by a master cloud service manager |
| CN105530639A (en) * | 2014-09-28 | 2016-04-27 | 中国电信股份有限公司 | Network controller and network control method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107968720A (en) | 2018-04-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110995468B (en) | System fault processing method, device, equipment and storage medium of system to be analyzed | |
| US9384471B2 (en) | Spam reporting and management in a communication network | |
| US20070083930A1 (en) | Method, telecommunications node, and computer data signal message for optimizing virus scanning | |
| KR102167613B1 (en) | Message push method and device | |
| US11165792B2 (en) | System and method for generating heuristic rules for identifying spam emails | |
| US20140259112A1 (en) | Verificaiton Service | |
| CN114208114A (en) | Multi-view security context per participant | |
| CN107968720B (en) | Information transmission method, cloud system and component | |
| CN111953770B (en) | Route forwarding method and device, route equipment and readable storage medium | |
| CN111064729A (en) | Message processing method and device, storage medium and electronic device | |
| CN111385157B (en) | Server abnormity detection method and device | |
| US10050925B1 (en) | Method and system for notifying users of misdirected response messages associated with messages sent on the users' behalf by an intermediary service | |
| CN111786940A (en) | Data processing method and device | |
| CN114095213B (en) | Network access control policy management system | |
| CN113778709B (en) | Interface calling method, device, server and storage medium | |
| JP2019029921A (en) | Transmitter, receiver, and communication method | |
| CN113904847A (en) | Cloud platform binding method, system, equipment and medium of Internet of things card | |
| CN108600209B (en) | Information processing method and device | |
| CN115202800A (en) | Edge cloud service data processing method and device, computer equipment and storage medium | |
| CN113595958A (en) | Safety detection system and method for Internet of things equipment | |
| CN110620799A (en) | Data processing method and system | |
| US9071507B2 (en) | System and method for registering a CIM provider in a CIM system using information of a device to be configured | |
| CN114143088B (en) | Network fault diagnosis method, device, equipment and computer readable storage medium | |
| EP3716540B1 (en) | System and method for generating heuristic rules for identifying spam emails | |
| CN114301960B (en) | Processing method and device for cluster asymmetric traffic, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |