Synchronization method, network, electronic equipment and storage medium

Abstract

The embodiment of the invention relates to the technical field of SD-WAN, and discloses a synchronization method, a network, electronic equipment and a storage medium. The method comprises the following steps: periodically sending a first message to a server, wherein communication between a client and the server is realized through short connection; receiving first data returned by the server according to the first message, wherein the first data comprises data uniquely representing each micro-service currently deployed on the server; under the condition that the received first data is inconsistent with the locally stored first data, a second message is sent to the server side, and the second message carries information indicating the micro-service corresponding to the inconsistent part of the first data received by the client side and the locally stored first data; and receiving second data returned by the server according to the second message, wherein the second data comprises configuration data of the micro-service corresponding to the inconsistent part of the first data received by the client and the locally stored first data. And the micro-service operation effect in the SD-WAN can be improved at least.

Description

Technical Field

[0001] Embodiments of the present application relate to the technical field of Software Defined Wide Area Network (SD-WAN), and in particular to a synchronization method, a network, an electronic device, and a storage medium. Background Art

[0002] SD-WAN is a network technology that uses the principles of software-defined networking (SDN) to manage and optimize the performance of wide area networks (WANs). It enables enterprises and other objects to securely connect users, applications, and data across multiple locations while providing higher performance, reliability, and scalability. In order to achieve a more flexible and scalable SD-WAN, business deployment is usually carried out in the form of microservices.

[0003] However, microservices in SD-WAN do not currently work well. Summary of the invention

[0004] The embodiments of the present application provide a synchronization method, a network, an electronic device, and a storage medium, which are at least beneficial to improving the operation effect of microservices in SD-WAN.

[0005] According to some embodiments of the present application, a first aspect of the embodiments of the present application provides a synchronization method, which is applied to a client, and the method includes: periodically sending a first message to a server, wherein communication between the client and the server is achieved through a short connection; receiving first data returned by the server based on the first message, wherein the first data includes data that uniquely represents each microservice currently deployed on the server; in a case where the received first data is inconsistent with the first data stored locally, sending a second message to the server, wherein the second message carries information indicating the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally; receiving second data returned by the server based on the second message, wherein the second data includes configuration data of the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally.

[0006] According to some embodiments of the present application, the second aspect of the embodiments of the present application also provides a synchronization method, which is applied to a server, and the method includes: receiving a first message periodically sent by a client, wherein communication between the client and the server is achieved through a short connection; returning first data to the client based on the first message currently received, wherein the first data includes data that uniquely represents each microservice currently deployed on the server; receiving a second message sent by the client, wherein the second message carries information indicating the microservice corresponding to the inconsistent part between the first data received by the client and the locally stored first data; returning second data to the client based on the second message, wherein the second data is configuration data of the microservice corresponding to the inconsistent part between the first data received by the client and the locally stored first data.

[0007] According to some embodiments of the present application, a third aspect of the embodiments of the present application also provides an SD-WAN network, including: a plurality of clients and a server, wherein each of the clients is used to implement the synchronization method as described in the first aspect, and the server is used to implement the synchronization method as described in the second aspect.

[0008] According to some embodiments of the present application, the fourth aspect of the embodiments of the present application also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the synchronization method as described in the first aspect, or execute the synchronization method as described in the second aspect.

[0009] According to some embodiments of the present application, the fifth aspect of the embodiments of the present application further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the synchronization method as described in the first aspect, or implements the synchronization method as described in the second aspect.

[0010] The technical solution provided in the embodiment of the present application has at least the following advantages:

[0011] The client sends a first message to trigger the server to send the first data, so that the client can determine whether the microservices currently maintained by the server and the client are inconsistent through the data in the first data that uniquely represents the microservices currently deployed on the server, so as to timely discover the synchronization problems of the microservices of the server and the client. In addition, in the case of inconsistency, the client still sends a second message to trigger the server to send the second data, so that the client can complete the synchronization of the microservice configuration with the server through the configuration data of the inconsistent microservices in the second data, so as to solve the previously perceived asynchrony problem. Among them, since the first message is sent periodically, the client will periodically perceive whether the microservices maintained by the current server and the client are consistent, and in the event of inconsistency, promptly resolve the inconsistency problem and achieve synchronization through the interaction of the second message and the second data, so as to achieve basic synchronization between the server and the client, without the need for the server to maintain a long connection with the client to synchronize the configuration of microservice changes in a timely manner. Moreover, in this process, the data transmission from the server to the client is triggered by the message sent by the client first, is passive, and the connections are short connections. Therefore, when the client is suspended, the client computer is powered off or the client fails, there will be no connection with the server. At the same time, it no longer relies on the channel provided by the SDP service for communication, avoiding the server from maintaining unnecessary connections and overcoming the dependence on the SDP service. The synchronization of microservices in the SD-WAN is maintained with less server-side bearing pressure, and other services can be supported to be deployed independently of the SDP service, making the deployment of microservices in the SD-WAN more reliable and stable, and the deployment methods are more diverse, and ultimately improving the business operation effect in the SD-WAN. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0013] Figure 1 It is a simplified structural diagram of the SD-WAN network provided in an embodiment of the present application;

[0014] Figure 2 This is the process of the synchronization method provided in the embodiment of the present application Figure 1 ;

[0015] Figure 3 This is the process of the synchronization method provided in the embodiment of the present application Figure 2 ;

[0016] Figure 4This is the process of the synchronization method provided in the embodiment of the present application Figure 3 ;

[0017] Figure 5 This is the process of the synchronization method provided in the embodiment of the present application Figure 4 ;

[0018] Figure 6 This is the process of the synchronization method provided in the embodiment of the present application Figure 5 ;

[0019] Figure 7 This is the process of the synchronization method provided in the embodiment of the present application Figure 6 ;

[0020] Figure 8 This is the process of the synchronization method provided in the embodiment of the present application Figure 7 ;

[0021] Fig. 9 This is a schematic diagram of the structure of the server provided in the embodiment of the present application. Figure 1 ;

[0022] Fig.10 This is a schematic diagram of the structure of the server provided in the embodiment of the present application. Figure 2 ;

[0023] Fig.11 This is a schematic diagram of the structure of the server provided in the embodiment of the present application. Figure 3 ;

[0024] Fig.12 is an interactive flow chart of the synchronization method provided in an embodiment of the present application;

[0025] Fig.13 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] As can be seen from the background technology, the synchronization effect between the server and the client in the current SD-WAN is not good.

[0027] After analysis, it can be seen that the reason for the above problems is at least that: for the microservice architecture, the synchronization of microservices is very important. In the existing SD-WAN, since the configuration changes of microservices may occur at any time, in order to synchronize the changed configuration to the client in time, the server will maintain the corresponding long connection for the client. In this way, when the configuration of the microservice changes, the changed configuration will be synchronized to the client in real time through the long connection. In the process of maintaining the long connection, only when the client actively exits will the client's offline status be notified to the server. In other cases, such as the client's pseudo-death, the client computer is powered off or shut down, or the client fails, the server will not be able to perceive the client offline, that is, the server will still maintain a long connection for the pseudo-death, shutdown or faulty client. This will bring some unnecessary load pressure to the server, and because there are many long connections maintained, the quality of at least some of the long connections will be affected, resulting in unstable connection and affecting the synchronization effect. In addition, the communication between the client and the server in the current SD-WAN network depends on the communication channel provided by the Software Defined Perimeter (SDP). After removing the SDP module, the server will not be able to synchronize the microservice configuration to the client.

[0028] In order to solve the above technical problems, the embodiments of the present application provide a synchronization method, a server, a network, an electronic device and a storage medium, wherein the client periodically sends a first message to the server, so that the client will periodically obtain the first data of the server, so as to timely perceive the inconsistency problem of the microservice configuration maintained by the client and the server through the periodically received first data and the locally stored first data, so that in the case of inconsistency, the client can send a second message to the server, so that the client will obtain the configuration data of the corresponding inconsistent microservice, solve the synchronization problem in time, and realize configuration synchronization. In this process, the process is initiated by the client and the server responds, so , short connections can be used for communication between the server and the client, and the server no longer needs to maintain a long connection to synchronize the changed microservice configuration to the client at any time. By converting the original long connection into a short connection, unnecessary connections will not be maintained for clients in states such as suspended animation, reducing the load on the server, which is conducive to improving the stability of the connection between the client and the server. In addition, the configuration synchronization of microservices does not need to be implemented through the SDP service, so that microservices can be supported to run independently of SDP, making the deployment of microservices in SD-WAN more reliable and stable, and the deployment methods are more diverse, and ultimately improving the business operation effect in SD-WAN.

[0029] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present application, many technical details are provided in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented.

[0030] The division of the following embodiments is for the convenience of description and shall not constitute any limitation on the specific implementation of the present application. The embodiments may be combined with each other and referenced to each other without contradiction.

[0031] In order to facilitate those skilled in the art to better understand the synchronization method provided in the embodiment of the present application, the scenario in which the synchronization method in the embodiment of the present application is applied is first described. The SD-WAN based on the microservice architecture includes several clients and servers, among which the server is mainly used to provide business data configuration, business logic calculation, log analysis and display, etc. The client is mainly used to connect to the specified network, customer behavior control and behavior log reporting server, etc. It should be noted that Figure 1 This is just a brief illustration of the service-side and client-side structures in SD-WAN when executing services in a microservices manner. It is understandable that for the service side, it may specifically be a server cluster composed of database servers, data center servers, etc., and it may also be a business microservice cluster composed of gateways, business services (such as network orchestration, task scheduling, network computing, file processing and other services), and a middleware cluster composed of databases such as DB (Data Base), Redis, Kafka, RocketMQ, etc. For the client, it may specifically be a mobile phone, PC, or a web version opened by a browser. I will not go into details here.

[0032] based on Figure 1The SD-WAN provided by the illustrated embodiment, the embodiment of the present application also provides corresponding synchronization methods respectively applied to the client and the server. Through the synchronization method provided by the embodiment of the present application, in the SD-WAN, the client sends a first message to trigger the server to send the first data, so that the client can determine whether the microservices maintained by the current server and the client are inconsistent through the data in the first data that uniquely represents each microservice currently deployed on the server, so as to timely discover the synchronization problem of the microservices of the server and the client, and, in the case of inconsistency, the client still sends a second message to trigger the server to send the second data, so that the client can complete the synchronization of the microservice configuration with the server through the configuration data of the inconsistent microservices in the second data, so as to solve the previously perceived asynchrony problem. Among them, since the first message is sent periodically, the client will periodically perceive whether the microservices maintained by the current server and client are consistent, and in the event of inconsistency, promptly resolve the inconsistency problem and achieve synchronization through the interaction of the second message and the second data, so as to achieve basic synchronization between the server and the client, without the need for the server to maintain a long connection with the client to synchronize the configuration of microservice changes in a timely manner. Moreover, in this process, the data transmission from the server to the client is triggered by the message sent by the client first, which is passive, and the connections are short connections. Therefore, when the client is suspended, the client computer is powered off or the client fails, there will be no connection with the server. At the same time, it no longer relies on the channel provided by the SDP service for communication, avoiding the server from maintaining unnecessary connections and overcoming the dependence on the SDP service. The synchronization of microservices in SD-WAN is maintained with less server-side bearing pressure, and other services can be supported to be deployed independently of the SDP service, making the deployment of microservices in SD-WAN more reliable and stable, and the deployment methods are more diverse, and ultimately improving the business operation effect in SD-WAN. The following will be combined with Figure 2-Figure 8 The process shown describes the synchronization method applied to the client and the synchronization method applied to the server respectively.

[0033] In some embodiments, Figure 2 As shown, when the synchronization method is applied to the client, it can include the following steps:

[0034] Step 101, periodically sending a first message to a server, wherein the communication between the client and the server is achieved through a short connection.

[0035] Step 102: Receive first data returned by the server according to the first message, wherein the first data includes data uniquely representing each microservice currently deployed on the server.

[0036] Step 103: When the received first data is inconsistent with the locally stored first data, a second message is sent to the server, wherein the second message carries information indicating the microservice corresponding to the inconsistent portion between the first data received by the client and the locally stored first data.

[0037] Step 104: Receive second data returned by the server according to the second message, wherein the second data includes configuration data of the microservice corresponding to the inconsistent part between the first data received by the client and the first data stored locally.

[0038] In this way, the client communicates with the server through a short connection, and the client actively and periodically sends a first message to obtain the first data of the server and determine whether the received first data (i.e., the data maintained by the server that uniquely represents the microservices currently deployed on the server) and the first data locally stored on the client (i.e., the data maintained by the client that uniquely represents the microservices currently deployed on the server) are consistent. In the event of inconsistency, the second data of the server is obtained in time by sending a second message to the server to synchronize the microservice configuration with the server, solve the current inconsistency and asynchrony problems between the client and the server, and achieve that the server does not need to maintain a corresponding long connection for each client, and can synchronize the configuration of the server and the client, overcome the dependence that needs to be maintained during the configuration synchronization process, reduce the load bearing pressure on the server, improve the communication quality and configuration information synchronization effect between the client and the server, and at the same time overcome the dependence on the SDP service, so that other services can be deployed independently of the SDP service, reducing the restrictions on the deployment of microservices.

[0039] To facilitate understanding by those skilled in the art Figure 2 The embodiment shown, the steps of which will be explained below.

[0040] In step 101, a first message is periodically sent to the server. As mentioned above, the sending of the first message is mainly to enable the server to return the first data. On this premise, the form and content of the first message can be set according to the needs, and the embodiments of the present application do not limit it. For example, the first message can be configured as a GET request, wherein the content indicated in the GET request is the first data, etc. In this way, the sending of the first message can be compatible with the existing HyperText Transfer Protocol (HTTP) protocol, with lower implementation difficulty, and can make full use of existing network resources to complete synchronization. For example, the first message can be configured as an identifier agreed upon by the client and the server. After receiving the agreed identifier, the server triggers the process of sending the first data to the client, etc. In this way, the data volume of the first message is small, avoiding the interaction of the first message on the client and the server causing excessive load pressure.

[0041] And, as mentioned above, the periodic sending of the first message is mainly to obtain the first data so that the client can perceive the microservice configuration changes of the server in time through the first data. At this time, the shorter the period of sending the first message, the shorter the maximum time of inconsistency and asynchronism between the client and the server, the stronger the real-time nature of synchronization and the better the effect. However, limited by the carrying capacity of the client and the server, the period of sending the first message cannot be infinitely small. And considering other influencing factors, such as network status, performance requirements, etc., in some embodiments, the first message can be associated with one or more of the client status, the server status, the frequency of microservice configuration changes, the network status, and the requirements for synchronization performance, so that the period of sending the first message is adapted to the client, the server, the microservice, the network, or the client's requirements, and the first message is sent at an appropriate frequency, while balancing other influencing factors. For example, the greater the current bearing pressure of the configuration server, the longer the period of sending the first message, so as to reduce the bearing pressure of the synchronization server by sending the first message at a lower frequency. For example, the worse the configured network is, the shorter the period of sending the first message is, so as to increase the probability of the server receiving the first message by sending the first message more frequently, and ultimately avoid the problem that the server and the client cannot be configured synchronously for a long time, etc., which will not be repeated here. In particular, the period of sending the first message can be configured when the client accesses according to the above factors, or it can be dynamically adjusted according to the above factors after the client accesses, which will not be repeated here.

[0042] Of course, the above is only an example of the first message and the period of sending the first message. In some embodiments, other methods can be used to implement the first message or periodically send the first message, which will not be listed here.

[0043] It should be noted that the embodiments of the present application do not limit short connections, which can be any connection that can be established only when data needs to be sent during data transmission and disconnected after the data is sent. For example, the short connection between the server and the client can be a heartbeat connection, in which case the information exchanged between the server and the client is implemented in the form of a heartbeat data packet, etc., which will not be described in detail here.

[0044] In step 102, the first data returned by the server according to the first message is received. Among them, the embodiment of the present application does not limit the first data, which can be any data that can uniquely represent each microservice currently deployed on the server. For example, in order to reduce the amount of data transmitted, the service identifier of the microservice (that is, the information that can uniquely determine the corresponding microservice in different microservices, such as the ID number of the microservice, etc.) can be used as the first data, so as to ensure that the online and offline conditions of different microservices maintained by the server can be uniquely determined, and the amount of interactive data can be minimized to the greatest extent, thereby shortening the connection establishment time and reducing the load pressure on the server. For example, further considering the impact of microservice updates and iterations, the service identifier and version identifier of the microservice (information that can uniquely determine the current version from different versions of the same microservice, such as the version number, etc.) can be used as the first data. At this time, based on the first data, not only the online and offline conditions of the microservice can be determined, but also the update and iteration conditions of the microservice can be determined, avoiding the problem of inconsistent versions of the microservices maintained by the server and the client. Of course, the above is only an example explanation of the first data. In some embodiments, the first data may also include other data, such as status data of each microservice. In this case, the status of the microservice can be determined through the first data to avoid the problem of inconsistent microservice status maintained by the server and the client, etc., which will not be elaborated here.

[0045] In step 103, when the received first data is inconsistent with the first data stored locally, a second message is sent to the server. As mentioned above, the second message is mainly to enable the server to return the second data to complete the configuration synchronization. On this premise, the form and content of the second message can be set according to the needs, and the embodiments of the present application do not limit it. For example, in order to be compatible with the existing protocol, the second message can be configured as a GET request, wherein the content indicated in the GET request is the second data, etc. For example, in order to further reduce the load-bearing pressure on the client and the server, the second message can be configured as a second message carrying a service identifier of the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally. After receiving the service identifier, the server triggers the process of sending the corresponding second data to the client, etc.

[0046] In addition, it is understandable that the server may record historical microservice information. In this case, the information indicating the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally can be the first data part stored locally by the client that is inconsistent with the server, such as the service identifier of the microservice stored by the client. Further combined with the historical microservice information recorded by the server, the corresponding latest microservice can be determined, thereby generating the second data. For another example, the information indicating the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally can also be the first data part received by the client that is inconsistent with the local storage, such as the service identifier of the microservice issued by the server. In this case, the microservice corresponding to the second data can be directly determined.

[0047] Of course, the above is only an example description of the second message and the content included in the second message. Other methods can also be used to implement the second message, which will not be described here one by one.

[0048] In step 104, according to the second message, the second data is returned to the client. Among them, the embodiment of the present application does not limit the second data. For example, the second data may include the complete configuration data of the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally. For example, considering that the configuration change of the microservice does not necessarily mean that all configurations have changed, the second data may include the configuration data that has been changed in the partial configuration change of the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally. At this time, it is obvious that configuration synchronization can still be achieved based on the second data. Of course, the above is only an example description of the configuration data contained in the second data. Other methods can also be used to implement the second data, etc., which will not be described here one by one.

[0049] Based on the above embodiments, it can also be understood that, in the case where the period of the client sending the first message is allowed to change dynamically as described above, the dynamic change strategy of the period of the client sending the first message can be provided by the client or by the server. Taking the server as an example, when the server decides the period of the client sending the first message, in some embodiments, when the synchronization method is applied to the client, such as Figure 3 As shown, the following steps may also be included:

[0050] Step 201, periodically sending a first message to the server, wherein the communication between the client and the server is achieved through a short connection.

[0051] Step 202: Receive first data returned by the server according to the first message, wherein the first data includes data uniquely representing each microservice currently deployed on the server.

[0052] Step 203: When the currently received first data carries data for indicating the sending period of the first message, adjust the period of sending the first message to the server according to the currently received first data.

[0053] Step 204: When the received first data is inconsistent with the locally stored first data, a second message is sent to the server, wherein the second message carries information indicating the microservice corresponding to the inconsistent portion between the first data received by the client and the locally stored first data.

[0054] Step 205: Receive second data returned by the server according to the second message, wherein the second data includes configuration data of the microservice corresponding to the inconsistent part between the first data received by the client and the first data stored locally.

[0055] In this way, on the basis of the foregoing embodiment, the server is further allowed to carry data for indicating the sending period of the first message in the first data, so that the server can instruct the client on the period of sending the first message, thereby better determining the period of sending the first message of each client through the server's perception of the global clients, and taking into account the mutual influence between different clients, so that the period of sending the first message of each client is more appropriate, which is more conducive to maintaining SD-WAN.

[0056] To facilitate better understanding of those skilled in the art Figure 3 The steps of the embodiment shown are explained below. Among them, steps 201-202 and steps 204-205 are substantially the same as steps 101-104 in the aforementioned embodiment, and the main difference is that data for indicating the sending period of the first message is also introduced into the first data, so that step 203 is also executed between steps 202 and 204, and the same parts will not be described here.

[0057] In step 203, when the currently received first data carries data for indicating the sending period of the first message, the period for sending the first message to the server is adjusted according to the currently received first data. Among them, the embodiment of the present application does not limit the data for indicating the sending period of the first message. For example, the data for indicating the sending period of the first message may be a fixed period of indication. For example, the data for indicating the sending period of the first message may be a function that can be run on the client and output the currently recommended period for the client to send the first message. The data for indicating the sending period of the first message will not be illustrated one by one here.

[0058] In addition, the embodiment of the present application does not emphasize that each first data carries data for indicating the sending period of the first message. It is understandable that when the period for sending the first message needs to be adjusted, the data for indicating the sending period of the first message is carried. Of course, the data for indicating the sending period of the first message can also be carried all the time, but when no adjustment is required, the data content is empty.

[0059] It should be noted that Figure 3 The illustrated embodiment is merely an example of an execution order of related steps. In some embodiments, step 203 may also occur simultaneously with step 204 or step 205, etc., and their execution orders are no longer listed here.

[0060] It should also be noted that Figure 3 The illustrated embodiment is only an example of adjusting the period of the client sending the first message based on the server indication. In some embodiments, the client can also automatically run the corresponding function to adjust the period of the client sending the first message in real time; in some embodiments, the data used to indicate the period of sending the first message can also be sent from the server to the client through an independent communication process, etc., which will not be listed here one by one.

[0061] Based on any of the above embodiments, it can also be understood that various situations may occur during the operation of SD-WAN: for example, the client may be attacked and the data may be tampered; another example is that the client operation failure causes the microservice configuration to be modified; another example is that the network quality is very poor, resulting in the loss of part of the second data, etc. In these cases, the synchronization between the client and the server may be destroyed. Therefore, in order to solve the above problems that may arise, in some embodiments, when the synchronization method is applied to the client, such as Figure 4 As shown, the following steps may also be included:

[0062] Step 301, periodically sending a first message to the server, wherein the communication between the client and the server is achieved through a short connection.

[0063] Step 302: Receive first data returned by the server according to the first message, wherein the first data includes data uniquely representing each microservice currently deployed on the server.

[0064] Step 303: When the received first data is inconsistent with the locally stored first data, a second message is sent to the server, wherein the second message carries information indicating the microservice corresponding to the inconsistent portion between the first data received by the client and the locally stored first data.

[0065] Step 304: Receive second data returned by the server according to the second message, wherein the second data includes configuration data of the microservice corresponding to the inconsistent part between the first data received by the client and the first data stored locally.

[0066] Step 305: Send a third message to the server.

[0067] Step 306: Receive third data returned by the server according to the third message, wherein the third data at least includes configuration data of each microservice currently deployed on the client.

[0068] In this way, on the basis of the aforementioned embodiment, the server can return the third data through the third message sent by the client, thereby realizing the complete synchronization of all microservice configuration data of the client and the server through the configuration data of each microservice currently deployed on the server contained in the third data, that is, combining the synchronization of the inconsistent configuration data with the synchronization of the full configuration data of all microservices, thereby covering the inconsistency and asynchrony problems of the microservices on the client and the server, and further improving the synchronization effect between the client and the server.

[0069] To facilitate better understanding of those skilled in the art Figure 4 The steps of the embodiment shown are explained below. Among them, steps 301 to 304 are substantially the same as steps 101 to 104 in the above embodiment, and the main difference is that after step 304, steps 305 to 306 are further executed, and the same parts will not be described here.

[0070] In step 305, a third message is sent to the server. Among them, the embodiment of the present application does not limit the third message. As mentioned above, the third message is mainly to enable the server to return the third data to complete the full configuration data synchronization of the microservice. On this premise, the form and content of the third message can be set according to demand, and the embodiment of the present application does not limit it. For example, the third message can be configured as a GET request, wherein the content indicated in the GET request is the third data, etc., so that the sending of the third message will be compatible with the existing protocol. For example, the third message can be configured as an identifier agreed upon by the client and the server. After receiving the agreed identifier, the server triggers the process of sending the third data to the client, etc., so that the data volume of the third message can be reduced, thereby further reducing the load-bearing pressure on the client and the server.

[0071] In addition, the embodiments of the present application do not limit the timing of sending the third message. For example, the third message can be similar to the first message, and can be a message sent periodically. Similarly, the period for the client to send the third message can be a fixed period or a dynamically changing period, wherein, when dynamically changing, the server can provide a strategy for dynamically changing the period for the client to send the third message, or the client can provide a strategy for dynamically changing the period for the client to send the third message, etc. For example, the third message can be sent by the client under certain conditions without periodicity, such as when the client sends the first message multiple times in a row and none of these first messages subsequently triggers the process of sending the second message, that is, a long time has passed since the last synchronization of the client, and during this period of time, some situations may occur that cause unpredictable changes in the microservice configuration of the client. Therefore, in order to avoid the adverse effects of this problem, the client triggers the sending of the third message to perform a full data synchronization of the microservice, etc.

[0072] It should be noted that, when the third message is a periodically sent message, the client sends the third message at a period greater than the period of sending the first message. In other words, the synchronization frequency of the inconsistent part is higher than the synchronization frequency of the full data, so that partial synchronization and full synchronization can be more fully combined and excessive resources can be avoided in synchronization.

[0073] Of course, the above is only an example description of the third message and the sending of the third message, which can also be implemented in other ways, which will not be described here one by one.

[0074] In step 306, the third data returned by the server according to the third message is received. Among them, the embodiment of the present application does not limit the third data. For example, the third data can be all the configuration data of all microservices deployed on the client. In this way, on the basis of ensuring the synchronization of the microservices on the client and the server, the data volume of the third data can be reduced. For example, the third data can be all the configuration data of all microservices deployed on the server. In this way, there is no need to consider the differences in microservices of different clients, the processing flow on the server can be simplified, and the third data can be sent by broadcasting, so that all the configuration data of each client in the SD-WAN can be updated at one time. Of course, the above is only an example description of the third data, which will not be listed one by one here.

[0075] It should be noted that Figure 4 The process shown is only an example of the execution order of related steps. In some embodiments, steps 305-306 may also be executed before step 301, etc., which will not be described in detail here.

[0076] It should also be noted that Figure 4The embodiment shown is only Figure 2 In some embodiments, steps 305-306 can also be combined with Figure 3 In the illustrated embodiment, detailed description will not be given here.

[0077] It is also understandable that the server may not always be able to support the second message or third message sent to all clients and return the corresponding data. For example, when a microservice commonly deployed by multiple clients undergoes configuration changes in a short period of time, a large number of clients will be triggered to send the second message to the server and return the corresponding second data. However, this processing volume is too large and the server may not be able to support all clients. Therefore, in order to avoid the above problems, in some embodiments, when the synchronization method is applied to the client, such as Figure 5 As shown, the following steps are also included:

[0078] Step 401, periodically sending a first message to the server, wherein the communication between the client and the server is achieved through a short connection.

[0079] Step 402: Receive first data returned by the server according to the first message, wherein the first data includes data uniquely representing each microservice currently deployed on the server, and status data of the server and / or the microservice.

[0080] Step 403: When the received first data is inconsistent with the locally stored first data, determine whether to allow establishment of a short connection according to the status data of the server and / or the microservice.

[0081] Step 404: When establishing a short connection is allowed, a second message is sent to the corresponding microservice of the server, wherein the second message carries information indicating the microservice corresponding to the inconsistent portion between the first data received by the client and the first data stored locally.

[0082] Step 405: Receive second data returned by the server according to the second message, wherein the second data includes configuration data of the microservice corresponding to the inconsistent part between the first data received by the client and the first data stored locally.

[0083] In this way, by carrying the status data of the server and / or microservice in the first data returned by the server, the client can determine whether to directly initiate a short connection to interact with the second message and the second data based on the data, thereby avoiding increasing the load pressure of the server and / or microservice at an inappropriate time, which is conducive to further reducing the load pressure of the server and further improving the synchronization effect between the client and the server.

[0084] To facilitate better understanding of those skilled in the art Figure 5 The steps of the embodiment shown are explained below. Among them, step 401-step 402 and step 405 are substantially the same as step 101-step 102 and step 104 in the aforementioned embodiment, and the main difference is that the first data in step 402 also carries the status data of the server and / or microservice, and steps 403-step 404 are also executed after step 402, and the same parts will not be repeated here.

[0085] In step 403, when the received first data is inconsistent with the locally stored first data, it is determined whether to allow the establishment of a short connection based on the status data of the server and / or microservice. Among them, the embodiment of the present application does not limit the specific judgment method. It can be understood that it can be judged only based on the status data of the server and / or microservice, and can also be further judged in combination with the status of the client itself, such as judging whether synchronization is urgently needed in combination with the current service usage of the client, or judging in combination with the client priority, etc., which will not be listed one by one here.

[0086] In step 404, if a short connection is allowed to be established, a second message is sent to the corresponding microservice on the server side. The sending of the second message is substantially the same as the sending of the second message in step 103 in the aforementioned embodiment, and the difference lies mainly in the different conditions that need to be met for sending the second message, and the same parts will not be described one by one here.

[0087] It should be noted that Figure 5 Only for Figure 2 In the embodiment shown in the figure, the example of the client determining whether it is currently suitable to send the second message is further combined. In some embodiments, steps 403-404 can also be further combined with Figure 3 , Figure 4 The embodiments shown in the figures are combined, and they will not be described one by one here.

[0088] It should also be noted that Figure 5 This is only an example provided for considering the impact of the bearing pressure brought to the client by sending the second message. In some embodiments, the server can also directly carry the start time allowed by the corresponding client to initiate the second message in the returned first data, so that the client in the SD-WAN can synchronize according to the indicated time periods, etc., which will not be elaborated here.

[0089] Correspondingly, the synchronization method can also be applied to the server. In this case, in some embodiments, such as Figure 6 As shown, the synchronization method may include the following steps:

[0090] Step 501: receiving a first message periodically sent by a client, wherein the communication between the client and the server is implemented through a short connection.

[0091] Step 502: Return first data to the client according to the currently received first message, wherein the first data includes data uniquely representing each microservice currently deployed on the server.

[0092] Step 503: Receive a second message sent by the client, wherein the second message carries information indicating a microservice corresponding to an inconsistent portion between the first data received by the client and the first data stored locally.

[0093] Step 504: Return second data to the client according to the second message, wherein the second data is configuration data of the microservice corresponding to the inconsistent portion between the first data received by the client and the first data stored locally.

[0094] In this way, the server communicates with the client through a short connection, and the server passively sends the first data to the client through the first message periodically sent by the client, so that when the first data received by the client (that is, the data that is uniquely represented by the server and maintained by the server and currently deployed microservices on the server) and the first data locally stored by the client (that is, the data that is uniquely represented by the client and currently deployed microservices on the server) are inconsistent, the client obtains the second data of the server by sending a second message to the server, thereby achieving microservice configuration synchronization with the server, and promptly solving the current inconsistency and asynchrony problems between the client and the server, so that the server does not need to maintain a corresponding long connection for each client, and the configuration of the server and the client can be synchronized, thus overcoming the dependency that needs to be maintained during the configuration synchronization process, reducing the load bearing pressure on the server, improving the communication quality and configuration information synchronization effect between the client and the server, and at the same time overcoming the dependency on the SDP service, so that other services can be deployed independently of the SDP service, and reducing restrictions on the deployment of microservices.

[0095] It is not difficult to find that Figure 6 The embodiment shown is Figure 2-Figure 5 The embodiment corresponding to the embodiment shown, Figure 6 The illustrated embodiment can be used with Figure 2-Figure 5 The illustrated embodiments are implemented in conjunction with each other. Figure 2-Figure 5 The relevant technical details mentioned in the illustrated embodiment are still valid in this embodiment, and will not be described here in order to reduce repetition. Figure 6 The relevant technical details involved in the embodiments of the synchronization method applied to the server mentioned in the embodiment shown and the subsequent embodiments can also be applied in Figure 2-Figure 5In the embodiment of the synchronization method applied to the client shown, the following includes: the features named the same in the synchronization methods applied to the client and the application server have the same or approximately the same meaning; the sending and receiving actions involved in the synchronization method applied to the client will generate corresponding sending and receiving actions in the synchronization method applied to the server, thereby forming a corresponding new embodiment, and this part will not be repeated here.

[0096] It is understandable that some data that can be consumed and processed by microservices (i.e., consumption data) will also be generated on the client, and these data can also be transmitted through the interaction process between the client and the server in the aforementioned embodiment. Based on this, in some embodiments, such as Figure 7 As shown, when applied to the server, the synchronization method may further include the following steps:

[0097] Step 601: Receive a first message periodically sent by a client, wherein the communication between the client and the server is implemented through a short connection, and the first message carries consumption data of the client.

[0098] Step 602: Return first data to the client according to the currently received first message, wherein the first data includes data uniquely representing each microservice currently deployed on the server.

[0099] Step 603: Store the currently received consumption data of the client, and perform consumption processing on the consumption data of the client based on the corresponding microservice.

[0100] Step 604: Receive a second message sent by the client, wherein the second message carries information indicating a microservice corresponding to an inconsistent portion between the first data received by the client and the first data stored locally.

[0101] Step 605: Return second data to the client according to the second message, wherein the second data is configuration data of the microservice corresponding to the inconsistent part between the first data received by the client and the first data stored locally.

[0102] In this way, on the basis of the foregoing embodiment, the client's consumption data is carried by the first message, so that the first message can be fully utilized for data interaction between the client and the server, and the periodic sending of the first message realizes the periodic reporting of the client's consumption data, so that the server will receive and process the client's data in the SD-WAN in a timely manner, which is conducive to improving the quality of microservices.

[0103] To facilitate better understanding of those skilled in the art Figure 7The steps of the embodiment shown are explained below. Among them, steps 601-602 and steps 604-605 are roughly the same as steps 501-504 in the above embodiment, and the main difference is that the first message in step 601 also carries the consumption data of the client, so that step 603 is also executed after step 602 and before step 604, and the same parts will not be repeated here.

[0104] In step 603, the consumption data of the client currently received is stored, so as to perform consumption processing on the consumption data of the client based on the corresponding microservice. Among them, the embodiment of the present application does not limit the consumption data of the client, which can be the consumption data generated by the client device itself, such as the status data of the client; it can also be the consumption data generated by the component on the client, such as the status data of the component in the client, etc. For example, the consumption data of the client can include user ID (userID), device ID (deviceID), etc., so that in the case of a microservice with an online client, the user ID (userID) and the device ID (deviceID) will be used as the consumption data of the microservice. It can be understood that the consumption data may be different depending on the client, the component on the client, and the microservice, and accordingly, the consumption processing method of the consumption data may also be different. Generally speaking, these can be flexibly configured according to the needs or application scenarios when applying, and will not be repeated here.

[0105] It should be noted that Figure 6 This is only an example of the execution order of related steps. It is understandable that in some embodiments, step 603 can also be executed simultaneously with step 602, or before step 602, etc., which will not be listed one by one here.

[0106] It is also understandable that the configuration of the microservice may change at any time. In order to facilitate the client to perceive the microservice configuration changes of the server more timely, the server can synchronously update the first data accordingly when the configuration changes. Based on this, in some embodiments, such as Figure 8 As shown, when applied to the server, the synchronization method may further include the following steps:

[0107] Step 701: When a configuration change occurs in at least one microservice, update first data according to the microservice with the changed configuration.

[0108] Step 702: Receive a first message periodically sent by the client, wherein the communication between the client and the server is achieved through a short connection.

[0109] Step 703: Return first data to the client according to the currently received first message, wherein the first data includes data uniquely representing each microservice currently deployed on the server.

[0110] Step 704: Receive a second message sent by the client, wherein the second message carries information indicating a microservice corresponding to an inconsistent portion between the first data received by the client and the first data stored locally.

[0111] Step 705: Return second data to the client according to the second message, wherein the second data is configuration data of the microservice corresponding to the inconsistent part between the first data received by the client and the first data stored locally.

[0112] In this way, by binding the microservice configuration change with the update of the first data, the first data can be updated in time, so that the client can perceive the microservice configuration change in time after obtaining the first data for synchronization.

[0113] To facilitate better understanding of those skilled in the art Figure 8 The steps of the embodiment shown are explained below. Among them, steps 702 to 705 are substantially the same as steps 501 to 504 in the above embodiment, and the main difference is that the first data is updated before step 701, and the same parts will not be described here.

[0114] In step 701, when at least one microservice has a configuration change, the first data is updated according to the microservice with the configuration change. The embodiment of the present application does not limit the updating method of the first data. For example, a trigger flag may be sent when the microservice configuration changes to start the update of the first data. For example, the inconsistent first data may be updated by querying, etc., which will not be described in detail here.

[0115] It should be noted that Figure 8 It is only an example of the execution order of related steps. It is understandable that the update of the first data may occur at any time. For example, the first data is updated while the first message is received. Also, the first data is updated after the second data is sent and before the new first message is received, etc. These will not be listed one by one here.

[0116] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0117] On the other hand, the embodiment of the present application also provides a server, such as Fig. 9 As shown, it includes: a gateway service cluster module, a general service module, and several microservice modules.

[0118] Among them, the gateway service cluster module is configured to receive messages sent by the client through a short connection, and to send data sent by the general service module and the microservice module to the client through a short connection; the general service module is connected to the gateway service cluster module and is configured to send the first message sent by the client forwarded by the gateway service cluster module to the gateway service cluster module according to the first message, wherein the first data includes data that uniquely represents each microservice currently deployed on the server; each microservice module is connected to the gateway service cluster module and is configured to obtain second data and send it to the gateway service cluster module according to the second message when receiving a second message sent by the client forwarded by the gateway service cluster module; and / or, when receiving a third message sent by the client forwarded by the gateway service cluster module, obtain third data and send it to the gateway service cluster module according to the third message, wherein the second message carries information for indicating the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally; the second data is the configuration data of the microservice corresponding to the inconsistent part of the first data received by the client and the first data stored locally, and the third data includes the configuration data of each microservice currently deployed on the server.

[0119] In some embodiments, Fig.10 As shown, the server can further include a queue module, which is connected to the general service module and each microservice module and is configured to perform at least one of the following processes: receiving and storing the consumption data of the client in the first message forwarded by the general service module; receiving and storing the consumption data of the microservice module generated in the service client; receiving and storing the corresponding changed part of the first data when the configuration of the microservice module changes. Wherein, in the case where the queue module stores the corresponding changed part of the first data when the configuration of the microservice module changes, the general service module is further configured to monitor the queue module to obtain the corresponding changed part of the first data when the configuration of the microservice module changes from the queue module.

[0120] In this way, asynchronous communication and decoupling are achieved through the queue module, so that different microservices or components on the server side can exchange data through the queue to support the independent work of different components or services and improve the scalability and reliability of the server side.

[0121] In some embodiments, Fig.11As shown, the server may further include a storage module, which is connected to the general service module and configured to receive and store at least part of the first data newly acquired by the general service module to update the stored first data; the general service module is also configured to read the latest first data from the storage module when receiving the first message sent by the client forwarded by the gateway service cluster module; wherein the storage module is a module that provides local storage, and / or a module connected to external storage.

[0122] Of course, the above is only an example. The embodiments of the present application do not limit the structure of the server, which can be any structure that can support the aforementioned synchronization method applied to the server. For example, the server can also include a reverse proxy module, such as Nginx, to provide functions such as load balancing. For example, the server can also include external storage, such as Redis, to improve data access performance and reduce database load. By storing hot data in memory, fast reading and response can be achieved, thereby improving the performance and scalability of the system.

[0123] In this way, when the configuration of a microservice changes, it will generate a configuration change identifier, such as the service identifier of the microservice with the changed configuration (which may also further include information such as the version number after the configuration change), and store it in the message queue (MQ) provided by the queue module. Then, the general service cluster perceives the microservice configuration change by monitoring the queue module, and obtains the information written to the message queue based on it. The obtained information will be further written to Redis for storage, thereby completing the first data update when the microservice configuration changes.

[0124] Furthermore, after the gateway service cluster receives the first message sent by the client through Nginx, it forwards it to the gateway service cluster module, and the gateway service cluster module further forwards it to the general service module, and the general service module will read the latest first data from Redis based on the first message and return the first data to the client through the gateway service cluster module and Nginx. If the client determines that it is not synchronized with the server based on the first data, it sends a second message to the gateway service cluster module through Nginx, and then the gateway service cluster module forwards the second message to the corresponding microservice, which sends its own configuration data to the gateway service cluster module, and finally sends the corresponding microservice configuration data to the client through Redis in the form of second data, so that the client completes the synchronization of the inconsistent microservice configuration data based on the received second data.

[0125] In addition, the client can also send a third message to the gateway service cluster module through Nginx, and the gateway service cluster module forwards the third message to each microservice, so that the microservice sends its own configuration data to the gateway service cluster module, and finally sends all the microservice configuration data to the client through Redis in the form of third data, so that the client can complete the full configuration data synchronization based on the received third data.

[0126] It is not difficult to find that the server embodiment is an embodiment corresponding to the method embodiment, and it can be implemented in conjunction with the method embodiment. The relevant technical details mentioned in the method embodiment are still valid in this embodiment, and in order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in the server embodiment can also be applied in the method embodiment.

[0127] It is worth mentioning that all modules involved in this embodiment are logic modules. In practical applications, a logic unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, in order to highlight the innovative part of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed by this application, but this does not mean that there are no other units in this embodiment.

[0128] Based on the aforementioned embodiments, the embodiments of the present application also provide an SD-WAN network, a plurality of clients and a server, wherein each client is used to implement the synchronization method applied to the client provided in any of the aforementioned embodiments or a combination thereof, and the server is used to implement the synchronization method applied to the server provided in any of the aforementioned embodiments or a combination thereof.

[0129] In order to facilitate those skilled in the art to better understand the implementation of the corresponding synchronization method in the SD-WAN network, the following will be combined with Fig.12 The interactive process of the synchronization method shown in FIG. Fig.12 In order to facilitate understanding, the structure of SD-WAN and the server is described in a simplified and illustrative way, which does not mean that the interaction process only involves Fig.12 The results shown either include Fig.12 Steps shown.

[0130] like Fig.12 As shown, the synchronization method includes the following steps:

[0131] Step 801: The microservice module stores the corresponding configuration identifier (service identifier and version identifier) ​​in the message queue based on its own configuration changes.

[0132] Step 802: The general service module obtains the configuration identifier through monitoring.

[0133] Step 803: The general service module writes the newly acquired configuration identifier into Redis so that it is updated into the first data.

[0134] Step 804: The client sends a first message to the general service module through a heartbeat connection.

[0135] Step 805: The general service module writes the consumption data carried by the first message into the message queue.

[0136] Step 806: The corresponding microservice module reads the consumption data from the consumption queue to perform consumption processing.

[0137] Step 807: The general service module reads the latest first data from Redis according to the first message.

[0138] Step 808: The universal service module returns the read first data to the client.

[0139] Step 809: The client filters the portion of the first data that is consistent with the local cache based on the received first data.

[0140] Step 810: The client sends a second message to the corresponding microservice module based on the filtered first data.

[0141] Step 811: The microservice module returns the second data to the client in the form of third data to synchronize the microservice configurations of the client and the server.

[0142] The configuration identifier is defined as follows:

[0143] "signals": [{ / / Notification signal, supports multiple signals in one message queue, value is recommended to be timestamp or version number, the specific content can be agreed upon by each module and the client

[0144] "key": 1001,

[0145] "value": "1718246112816"

[0146] }{

[0147] "key": 1002,

[0148] "value": "1717411956886"

[0150] }].

[0151] The client has a hard-coded mapping of the relationship between the key value and the business interface address, for example:

[0152] 1001-> / xdlpApi / getConfig

[0153] 1002-> / idpApi / getConfig

[0154] In this way, after receiving 1001, the client will initiate a request to the interface ( / xdlpApi / getConfig) and send a second message to the corresponding microservice to achieve configuration synchronization.

[0155] In addition, the present application also provides an electronic device, such as Fig.13 As shown, it includes: at least one processor 1301; and a memory 1302 that is communicatively connected to the at least one processor 1301; wherein the memory 1302 stores instructions that can be executed by the at least one processor 1301, and the instructions are executed by the at least one processor 1301 so that the at least one processor 1301 can execute the synchronization method described in any of the above method embodiments.

[0156] Among them, the memory 1302 and the processor 1301 are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors 1301 and the memory 1302 together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor 1301 is transmitted on a wireless medium through an antenna, and further, the antenna also receives data and transmits the data to the processor 1301.

[0157] The processor 1301 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management and other control functions. The memory 1302 can be used to store data used by the processor 1301 when performing operations.

[0158] Another aspect of the present application embodiment further provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the above method embodiment is implemented.

[0159] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including a number of instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0160] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present application, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present application.

Claims

1. A synchronization method, characterized in that: Applied to a client, the method comprises: Periodically sending a first message to a server, wherein the communication between the client and the server is realized through a short connection; Receiving first data returned by the server according to the first message, wherein the first data includes data uniquely representing each microservice currently deployed on the server; In the case where the first data received is inconsistent with the first data stored locally, a second message is sent to the server, wherein the second message carries information indicating the microservice corresponding to the inconsistent portion between the first data received by the client and the first data stored locally; Receive second data returned by the server according to the second message, wherein the second data includes configuration data of a microservice corresponding to an inconsistent portion of the first data received by the client and the first data stored locally.

2. The synchronization method according to claim 1, characterized in that: In a case where the currently received first data carries data for indicating a sending period of the first message, after receiving the first data returned by the server according to the first message, the method further includes: Adjust the period of sending the first message to the server according to the first data currently received.

3. The synchronization method according to claim 1, characterized in that: The method further comprises: Sending a third message to the server; Receiving third data returned by the server according to the third message; Among them, the third data at least includes configuration data of each microservice currently deployed on the client; the third message is a message sent periodically, and the period of sending the third message is greater than the period of sending the first message.

4. The synchronization method according to claim 1, characterized in that: The first data also includes status data of the server and / or microservice, and when the received first data is inconsistent with the first data stored locally, sending a second message to the server includes: When the received first data is inconsistent with the locally stored first data, determining whether to allow establishment of a short connection according to the status data of the server and / or microservice; When establishment of a short connection is allowed, the second message is sent to the corresponding microservice of the server.

5. The synchronization method according to any one of claims 1 to 4, characterized in that: The period of sending the first message is associated with at least one of the following information: the state of the client, the state of the server, the frequency of microservice configuration changes, the network state, and the requirement for synchronization performance.

6. A synchronization method, characterized in that: Applied to the server, the method includes: Receiving a first message periodically sent by a client, wherein the communication between the client and the server is implemented through a short connection; Returning first data to the client according to the first message currently received, wherein the first data includes data uniquely representing each microservice currently deployed on the server; Receiving a second message sent by the client, wherein the second message carries information for indicating a microservice corresponding to an inconsistent portion between the first data received by the client and the first data stored locally; According to the second message, second data is returned to the client, wherein the second data is configuration data of a microservice corresponding to an inconsistent portion between the first data received by the client and the first data stored locally.

7. The synchronization method according to claim 6, characterized in that: The first message carries the consumption data of the client. After receiving the first message periodically sent by the client, the method further includes: The currently received consumption data of the client is stored, so as to perform consumption processing on the consumption data of the client based on the corresponding microservice; The consumption data of the client includes the device consumption data of the client and / or the consumption data of the components on the client.

8. The synchronization method according to claim 6 or 7, characterized in that: The first data includes the service identifier and version identifier of each microservice currently deployed on the server.

9. The synchronization method according to claim 6 or 7, characterized in that: Before returning the first data to the client according to the first message, the method further includes: When a configuration change occurs to at least one microservice, the first data is updated according to the microservice with the changed configuration.

10. An SD-WAN network, characterized in that: include: A plurality of clients and servers, wherein each of the clients is used to implement the synchronization method as described in any one of claims 1 to 5, and the server is used to implement the synchronization method as described in any one of claims 6 to 9.

11. An electronic device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the synchronization method as described in any one of claims 1 to 5, or to execute the synchronization method as described in any one of claims 6 to 9.

12. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the synchronization method according to any one of claims 1 to 5 is implemented, or the synchronization method according to any one of claims 6 to 9 is implemented.

Images