A flow monitoring method and device for a distributed system

Abstract

The present invention discloses a traffic monitoring method and device for a distributed system, and relates to the field of computer technology. A specific implementation of the method includes: obtaining a service call request; according to the request identifier of the service call request, incrementing the number of calls corresponding to the service call request in the storage node; wherein the storage node is embedded in the application of the distributed system, and the storage node stores the number of calls corresponding to one or more request identifiers; according to whether the number of calls meets the traffic control conditions, the service call request is processed. This implementation reduces the operation and maintenance deployment cost and improves the stability of the monitoring cluster.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a flow monitoring method and device for a distributed system. Background Art

[0002] At present, the traffic monitoring methods of distributed systems generally include the following two methods: one is to implement flow control and anti-brushing based on Redis, for example, recording the service call volume through Redis, and rejecting the request if the service call volume exceeds the threshold within a certain period of time; the other is to implement data monitoring such as API call information based on middleware such as MQ or DB.

[0003] In the process of implementing the present invention, the inventors found that there are at least the following problems in the prior art:

[0004] Both of the above methods require the deployment of monitoring clusters, which increases the operation and maintenance deployment costs and wastes system resources. In addition, table locks or row locks based on Redis will increase instability and reduce system throughput; in the middleware-based method, the instability or failure of the middleware will also affect the stability of the monitoring cluster. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a method and device for monitoring the flow of a distributed system. The storage node embedded in the application of the distributed system records the number of calls corresponding to each request identifier. After receiving a service call request, the number of calls in the storage node is increased accordingly, and the service call request is processed according to whether the number of calls meets the flow control conditions. In this way, the flow monitoring of the distributed system can be realized without the need to deploy an additional monitoring cluster, which reduces the operation and maintenance deployment cost; and avoids the unstable factors caused by table locks or row locks in the Redis method, improves the system throughput and cluster stability; in addition, it also avoids the risk of middleware instability and improves the stability of the monitoring cluster.

[0006] To achieve the above objective, according to one aspect of an embodiment of the present invention, a method for monitoring traffic in a distributed system is provided.

[0007] A method for monitoring traffic in a distributed system according to an embodiment of the present invention includes: obtaining a service call request;

[0008] According to the request identifier of the service call request, the number of calls corresponding to the service call request in the storage node is incremented; wherein the storage node is embedded in the application of the distributed system, and the storage node stores the number of calls corresponding to one or more request identifiers respectively;

[0009] The service call request is processed according to whether the number of calls meets the traffic control conditions.

[0010] Optionally, the application corresponds to a plurality of application nodes in the distributed system, and each of the application nodes is embedded with the storage node;

[0011] After the number of calls corresponding to the service call request in any one of the storage nodes is incremented, the method further includes:

[0012] The calling times on the storage nodes respectively corresponding to the multiple application nodes are synchronized.

[0013] Optionally, the storage node further stores a statistical condition corresponding to each call count; and the step of incrementing the call count corresponding to the service call request in the storage node according to the request identifier of the service call request includes:

[0014] According to the request identifier, incrementing the number of calls corresponding to the preset duration of the statistical condition in the storage node;

[0015] Processing the service call request according to whether the number of calls meets the traffic control condition includes:

[0016] Determine whether the number of calls corresponding to the preset duration is greater than the traffic threshold indicated by the traffic control condition;

[0017] If so, determine that the number of calls meets the traffic control condition and reject the service call request.

[0018] Optionally, the method further comprises:

[0019] Parsing a user identifier and a calling service identifier from the service calling request, and determining the request identifier according to the user identifier and the calling service identifier;

[0020] When the number of calls corresponding to the preset duration is not greater than the traffic threshold, the method further includes:

[0021] The target service is called according to the calling service identifier, and the number of calls corresponding to the statistical condition of successful processing in the storage node is incremented.

[0022] Optionally, the increasing the number of calls corresponding to the service call request in the storage node includes:

[0023] The number of calls is incremented in a thread-safe manner.

[0024] Optionally, the method further comprises:

[0025] According to a preset period, using a node in the distributed system to obtain a distributed lock from the storage node;

[0026] The node that obtains the distributed lock performs a persistence operation on the data in the storage node.

[0027] Optionally, the storage node is deployed based on a Hazelcast framework.

[0028] To achieve the above objective, according to another aspect of an embodiment of the present invention, a flow monitoring device for a distributed system is provided.

[0029] A flow monitoring device for a distributed system according to an embodiment of the present invention comprises: a request acquisition module, a times processing module and a request processing module; wherein:

[0030] The request acquisition module is used to obtain the service call request;

[0031] The number processing module is used to increment the number of calls corresponding to the service call request in the storage node according to the request identifier of the service call request; wherein the storage node is embedded in the application of the distributed system;

[0032] The request processing module is used to process the service call request according to whether the number of calls meets the traffic control conditions.

[0033] To achieve the above objective, according to another aspect of an embodiment of the present invention, a flow monitoring device in a distributed system is provided.

[0034] A flow monitoring device in a distributed system according to an embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement a flow monitoring method in a distributed system according to an embodiment of the present invention.

[0035] To achieve the above objective, according to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided.

[0036] A computer-readable storage medium according to an embodiment of the present invention stores a computer program, and when the program is executed by a processor, a flow monitoring method in a distributed system according to an embodiment of the present invention is implemented.

[0037] One embodiment of the above invention has the following advantages or beneficial effects: by recording the number of calls corresponding to each request identifier through a storage node embedded in the application of the distributed system, the number of calls in the storage node is increased accordingly after receiving the service call request, and the service call request is processed according to whether the number of calls meets the traffic control conditions. In this way, traffic monitoring of the distributed system can be realized without the need to deploy an additional monitoring cluster, reducing the cost of operation and maintenance deployment; and avoiding the unstable factors caused by table locks or row locks in the Redis method, improving the system throughput and cluster stability; in addition, it also avoids the risk of middleware instability and improves the stability of the monitoring cluster.

[0038] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0040] Figure 1 is a schematic diagram of main steps of a traffic monitoring method for a distributed system according to an embodiment of the present invention;

[0041] Figure 2 is an architecture diagram of a distributed system according to an embodiment of the present invention;

[0042] Figure 3 is a functional architecture diagram of a flow monitoring device for a distributed system according to an embodiment of the present invention;

[0043] Figure 4 is a schematic diagram of main modules of a flow monitoring device of a distributed system according to an embodiment of the present invention;

[0044] Figure 5 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0045] Figure 6 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0046] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0047] It should be pointed out that the embodiments of the present invention and the technical features therein may be combined with each other without conflict.

[0048] Figure 1 It is a schematic diagram of main steps of a traffic monitoring method for a distributed system according to an embodiment of the present invention.

[0049] like Figure 1 As shown, a flow monitoring method of a distributed system according to an embodiment of the present invention mainly includes the following steps:

[0050] Step S101: Obtain a service call request;

[0051] Step S102: according to the request identifier of the service call request, incrementing the call count corresponding to the service call request in the storage node; wherein the storage node is embedded in the application of the distributed system, and the storage node stores the call counts corresponding to one or more request identifiers respectively;

[0052] Step S103: Process the service call request according to whether the number of calls meets the traffic control condition.

[0053] In one embodiment of the present invention, Figure 2 As shown, the application corresponds to multiple application nodes in the distributed system, and each of the application nodes is embedded with the storage node; after incrementing the number of calls corresponding to the service call request in any one of the storage nodes, the method may also include: synchronizing the number of calls on the storage nodes corresponding to the multiple application nodes respectively.

[0054] Storage nodes can be deployed based on the Hazelcast framework. Storage nodes embedded in application nodes are Hazelcast nodes. Each Hazelcast node can communicate with other nodes in the cluster to exchange data with other nodes, such as synchronizing the number of calls stored in itself with other nodes. The exchanged data can also include: a list of Hazelcast instances surviving in the current cluster, adding or deleting records stored in the cache, etc.

[0055] Among them, Hazelcast is a distributed memory framework that can be embedded in applications, so its life cycle is consistent with the main application and has good stability. And it is memory-based, processing data very quickly, it is also distributed, and multi-node deployment applications will store the same data copy, so it is very suitable for embedded in the application node of the distributed system. Based on the embedded Hazelcast node, the application can listen to all inbound requests and parse the request information, and then store the request identifier and call times in the Hazelcast node in the form of key-value according to the results of the analysis. The Hazelcast node collects and sends it to other nodes for backup. Further, current limiting operations such as QPS can be implemented based on the data stored in the Hazelcast node, and the distributed lock and scheduling tasks of the Hazelcast node can be used to insert the data stored in the Hazelcast node as key-value into the relational library for persistence. In addition, the monitoring page can read the data in the Hazelcast node in real time; when the project is restarted, the persistent statistical data will be reloaded to the Hazelcast node.

[0056] As described above, the request identifier and the number of calls can be recorded in the Hazelcast node in the form of key-value. In one embodiment of the present invention, the number of calls recorded by the Hazelcast node also corresponds to a statistical condition, and the specific implementation of step S102 may include: according to the request identifier, incrementing the number of calls corresponding to the preset duration of the statistical condition in the storage node; processing the service call request according to whether the number of calls meets the traffic control condition, including: determining whether the number of calls corresponding to the preset duration is greater than the traffic threshold indicated by the traffic control condition; if so, determining that the number of calls meets the traffic control condition, and rejecting the service call request.

[0057] In this implementation, the preset duration can be 1 second. When recording the number of calls, the Map structure can be used to record the request identifier, the number of calls, and the statistical conditions. Here, the user identifier and the calling service identifier can be parsed from the service call request, and the request identifier can be determined based on the user identifier and the calling service identifier. Thus, a data structure Map can be constructed in Hazelcast. The parameters contained in the Map are key, value (counter for recording the number of calls), TTL (Time ToLive, survival time value, for example, can be set to 1s), and unit (time unit). After the service call request is obtained for the first time, the service call request will be parsed into a key based on the user id-calling service id. The value and TTL are set to 1 at this time, and the time unit can be seconds. If the same user requests the same interface (calls the same service) within the next second, the value value is incremented, that is, the number of calls with a statistical condition of 1s in the Hazelcast node is incremented. When the counter reaches the QPS (Queries-per-second, query rate per second) limit, that is, the number of calls corresponding to the preset duration of 1s is greater than the traffic threshold, an exception will be thrown and the service call request will be rejected. Otherwise, this key will be deleted after 1 second, and the user can request service information normally in the next second.

[0058] In addition, the preset duration can also be other durations greater than 1s (such as one day). If the QPS check passes, the total number of calls for the day can be queried based on the key of user id-calling service id, and it can be determined whether the incremented number of calls exceeds the traffic threshold corresponding to the total number of calls. If it exceeds, it is determined that the number of calls meets the traffic control conditions, and the service call request is rejected and an exception is thrown.

[0059] In another embodiment of the present invention, if the number of calls satisfies the QPS check and the total number of calls on the day, that is, the number of calls corresponding to the preset duration is not greater than the traffic threshold, the target service can be called according to the calling service identifier, and the statistical condition in the storage node is incremented for the number of calls corresponding to successful processing.

[0060] Here, if the number of calls meets the QPS check and the total number of calls for the day, the service call request can be executed, that is, the target service is called according to the call service identifier, and the result of the successful execution of the service call request is returned to the user, and the number of calls with the statistical condition of successful processing in the hazelcast node is incremented. Furthermore, the success rate of successful processing can be calculated based on the incremented total number of calls, and the success rate is stored in the hazelcast node.

[0061] According to the above embodiment, by defining a key mainly composed of user id-service id, the value corresponding to this key is the number of service calls. Next, if this key is called within the same day, the value of this key (number of calls) will be incremented, and then it is determined whether the traffic control conditions are met based on the increment result. If the traffic control conditions are met, the service call request is rejected and an exception is returned. The number of calls is incremented in a thread-safe manner. For example, the IMap of the Hazelcast node can be used to extend the two interfaces java.util.concurrent.ConcurrentMap and java.util.Map in the jdk concurrent package to implement a thread-safe increment operation.

[0062] In another embodiment of the present invention, the method may further include: according to a preset period, using the nodes in the distributed system to obtain a distributed lock from the storage node; using the node that obtains the distributed lock to perform a persistence operation on the data in the storage node.

[0063] For example, if the preset period is 10 seconds, then every 10 seconds each server in the distributed system will obtain a distributed lock in the Hazelcast node, and the server node that obtains the distributed lock will schedule tasks to persist the data in the Hazelcast node to the database. If the distributed system is restarted later, the data in the database can be reloaded to the Hazelcast node.

[0064] The flow monitoring method of the distributed system provided by the embodiment of the present invention can be based on Figure 3 The functional architecture shown is implemented. Preferably, the distributed system is a small or medium-sized distributed system composed of 2 to 5 servers. The single-node configuration of such a small or medium-sized distributed system is not very high. In the prior art, it is often necessary to deploy a monitoring cluster separately. However, the distributed system monitoring method provided by the embodiment of the present invention can record the number of calls corresponding to each request identifier through an embedded storage node, thereby realizing the traffic monitoring of the distributed system without deploying an additional monitoring cluster, thereby reducing the operation and maintenance deployment cost.

[0065] according to Figure 3In the functional architecture shown, the service call request first arrives at the request processing module, where the request will strip out information such as user ID, call service ID and call parameters, and integrate the request ID (key of Map structure). All subsequent operations will be performed based on the request ID. Then, the service call request arrives at the flow limiting module, which will put the key and the number of calls into the Hazelcast node and set the TTL to 1 second. If the query of this key exceeds the maximum number of calls allowed by the service within one second, it means that the QPS check is not passed, that is, the traffic control condition is met. At this time, an exception is directly thrown, and then it is received and returned to the user through the exception request processor of the request processing module. In addition, if the QPS check passes, the service call request will enter the call upper limit calculation logic. The call upper limit calculation logic will query the total number of calls on the day in the Hazelcast node according to the key, and throw an exception if it exceeds the upper limit. If the total number of calls on the day does not exceed the upper limit, that is, the traffic control condition is not met, the service call request will arrive at the statistics module, where the total number of calls on the day of this service will be incremented, and the service call request will be executed. The execution result will be included in the service call success rate indicator, and the request will be successfully returned to the user. After the total number of calls and success rate are calculated, they will be synchronously refreshed to the Hazelcast node.

[0066] The Hazelcast node will record the number of calls of different requests from different users and other information. In the persistence module, the scheduled task will periodically initiate persistence operations. First, it will obtain a distributed lock in the Hazelcast node to ensure that only one server node can perform persistence operations. Next, the server node that obtains the lock will synchronize the data to the business MySQL database. In addition, if users want to view real-time service call information, they can view relevant indicator information from the statistics module. All indicator information is taken from the Hazelcast node to ensure real-time performance.

[0067] It can be seen from the traffic monitoring method of a distributed system according to an embodiment of the present invention that the number of calls corresponding to each request identifier is recorded by a storage node embedded in the application of the distributed system. After receiving a service call request, the number of calls in the storage node is increased accordingly, and the service call request is processed according to whether the number of calls meets the traffic control conditions. In this way, traffic monitoring of a distributed system can be achieved without the need for additional deployment of a monitoring cluster, reducing the cost of operation and maintenance deployment; and avoiding the unstable factors caused by table locks or row locks in the Redis method, improving the system throughput and cluster stability; in addition, it also avoids the risk of middleware instability and improves the stability of the monitoring cluster.

[0068] Figure 4 4 is a schematic diagram of main modules of a flow monitoring device for a distributed system according to an embodiment of the present invention.

[0069] like Figure 4 As shown, a flow monitoring device 400 of a distributed system according to an embodiment of the present invention includes: a request acquisition module 401, a times processing module 402 and a request processing module 403; wherein,

[0070] The request acquisition module 401 is used to acquire a service call request;

[0071] The number processing module 402 is used to increment the number of calls corresponding to the service call request in the storage node according to the request identifier of the service call request; wherein the storage node is embedded in the application of the distributed system;

[0072] The request processing module 403 is used to process the service call request according to whether the number of calls meets the traffic control condition.

[0073] In one embodiment of the present invention, the application corresponds to a plurality of application nodes in the distributed system, and each of the application nodes is embedded with the storage node;

[0074] The times processing module 402 is further configured to synchronize the times of calls on the storage nodes corresponding to the plurality of application nodes respectively after incrementing the times of calls corresponding to the service call request in any one of the storage nodes.

[0075] In one embodiment of the present invention, the storage node further stores a statistical condition corresponding to each call count; the count processing module 402 is used to increment the call count corresponding to the preset duration of the statistical condition in the storage node according to the request identifier;

[0076] The request processing module 403 is used to determine whether the number of calls corresponding to the preset duration is greater than the traffic threshold indicated by the traffic control condition; if so, determine that the number of calls meets the traffic control condition and reject the service call request.

[0077] In one embodiment of the present invention, the number processing module 402 is used to parse the user identifier and the calling service identifier from the service calling request, and determine the request identifier according to the user identifier and the calling service identifier;

[0078] The request processing module 403 is used to call the target service according to the calling service identifier when the number of calls corresponding to the preset duration is not greater than the traffic threshold, and to increment the number of calls corresponding to the statistical condition of successful processing in the storage node.

[0079] In one embodiment of the present invention, the number processing module 402 is used to perform an auto-increment operation on the number of calls in a thread-safe manner.

[0080] In one embodiment of the present invention, the request processing module 403 is also used to obtain a distributed lock from the storage node using a node in the distributed system according to a preset period; and to perform persistence operations on the data in the storage node using the node that obtains the distributed lock.

[0081] In one embodiment of the present invention, the storage node is deployed based on the Hazelcast framework.

[0082] It can be seen from the flow monitoring device of the distributed system according to the embodiment of the present invention that the number of calls corresponding to each request identifier is recorded by the storage node embedded in the application of the distributed system. After receiving the service call request, the number of calls in the storage node is increased accordingly, and the service call request is processed according to whether the number of calls meets the flow control conditions. In this way, the flow monitoring of the distributed system can be realized without the need to deploy an additional monitoring cluster, which reduces the operation and maintenance deployment cost; and avoids the unstable factors caused by table locks or row locks in the Redis method, improves the system throughput and cluster stability; in addition, it also avoids the risk of middleware instability and improves the stability of the monitoring cluster.

[0083] Figure 5 An exemplary system architecture 500 is shown to which the traffic monitoring method of a distributed system or the traffic monitoring device of a distributed system according to an embodiment of the present invention can be applied.

[0084] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, 503, a network 504 and a server 505. Network 504 is used to provide a medium for communication links between terminal devices 501, 502, 503 and server 505. Network 504 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0085] Users can use terminal devices 501, 502, 503 to interact with server 505 through network 504 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 501, 502, 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0086] The terminal devices 501 , 502 , and 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0087] Server 505 may be a server that provides various services, such as a backend management server that provides support for shopping websites browsed by users using terminal devices 501, 502, and 503. The backend management server may analyze and process received data such as product information query requests, and feed back the processing results to the terminal device.

[0088] It should be noted that the traffic monitoring method of the distributed system provided in the embodiment of the present invention is generally executed by the server 505 , and accordingly, the traffic monitoring device of the distributed system is generally arranged in the server 505 .

[0089] It should be understood that Figure 5 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0090] Reference below Figure 6 , which shows a schematic diagram of the structure of a computer system 600 of a terminal device suitable for implementing an embodiment of the present invention. Figure 6 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0091] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0092] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0093] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present invention are executed.

[0094] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0095] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0096] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor, for example, it may be described as: a processor includes a request acquisition module, a number processing module and a request processing module. The names of these modules do not constitute a limitation on the modules themselves in some cases, for example, the request acquisition module may also be described as a "module for obtaining service call requests".

[0097] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes: obtaining a service call request; according to the request identifier of the service call request, incrementing the number of calls corresponding to the service call request in the storage node; wherein the storage node is embedded in the application of the distributed system, and the storage node stores the number of calls corresponding to one or more request identifiers; and processing the service call request according to whether the number of calls meets the traffic control conditions.

[0098] According to the technical solution of the embodiment of the present invention, the storage node embedded in the application of the distributed system records the number of calls corresponding to each request identifier. After receiving the service call request, the number of calls in the storage node is increased accordingly, and the service call request is processed according to whether the number of calls meets the traffic control conditions. In this way, the traffic monitoring of the distributed system can be realized without the need to deploy an additional monitoring cluster, which reduces the operation and maintenance deployment cost; and avoids the unstable factors caused by table locks or row locks in the Redis method, improves the system throughput and cluster stability; in addition, it also avoids the risk of middleware instability and improves the stability of the monitoring cluster.

[0099] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A traffic monitoring method for a distributed system, characterized in that: Applications for distributed systems, including: Get the service call request; According to the request identifier of the service call request, the number of calls corresponding to the service call request in the storage node is incremented; wherein the storage node is embedded in the application of the distributed system, the storage node is deployed based on the Hazelcast framework, the Hazelcast framework is a distributed memory framework embedded in the application, the storage node stores the number of calls corresponding to one or more request identifiers, and the storage node is a Hazelcast node; Processing the service call request according to whether the number of calls meets the traffic control condition; The application corresponds to a plurality of application nodes in the distributed system, each of the application nodes being embedded with the storage node; After the number of calls corresponding to the service call request in any one of the storage nodes is incremented, the method further includes: The calling times on the storage nodes respectively corresponding to the multiple application nodes are synchronized.

2. The method according to claim 1, characterized in that: The storage node also stores a statistical condition corresponding to each call count; and the step of incrementing the call count corresponding to the service call request in the storage node according to the request identifier of the service call request includes: According to the request identifier, incrementing the number of calls corresponding to the preset duration of the statistical condition in the storage node; Processing the service call request according to whether the number of calls meets the traffic control condition includes: Determine whether the number of calls corresponding to the preset duration is greater than the traffic threshold indicated by the traffic control condition; If so, determine that the number of calls meets the traffic control condition and reject the service call request.

3. The method according to claim 2, characterized in that Also includes: Parsing a user identifier and a calling service identifier from the service calling request, and determining the request identifier according to the user identifier and the calling service identifier; When the number of calls corresponding to the preset duration is not greater than the traffic threshold, the method further includes: The target service is called according to the calling service identifier, and the number of calls corresponding to the statistical condition of successful processing in the storage node is incremented.

4. The method according to claim 1, characterized in that: The increasing the number of calls corresponding to the service call request in the storage node includes: The number of calls is incremented in a thread-safe manner.

5. The method according to claim 1, characterized in that Also includes: According to a preset period, using an application node in the distributed system to obtain a distributed lock from the storage node; The application node that obtains the distributed lock performs a persistence operation on the data in the storage node.

6. A flow monitoring device for a distributed system, characterized in that: The application program configured for use in a distributed system includes: a request acquisition module, a times processing module and a request processing module; wherein, The request acquisition module is used to obtain the service call request; The number processing module is used to increment the number of calls corresponding to the service call request in the storage node according to the request identifier of the service call request; wherein the storage node is embedded in the application of the distributed system, the storage node is deployed based on the Hazelcast framework, the Hazelcast framework is a distributed memory framework embedded in the application, the storage node stores the number of calls corresponding to one or more request identifiers, and the storage node is a Hazelcast node; The request processing module is used to process the service call request according to whether the number of calls meets the traffic control condition; The application corresponds to a plurality of application nodes in the distributed system, each of the application nodes being embedded with the storage node; The times processing module is further used for: after incrementing the calling times corresponding to the service calling request in any one of the storage nodes, synchronizing the calling times on the storage nodes corresponding to the multiple application nodes respectively.

7. A flow monitoring device in a distributed system, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 5.

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

Images