Micro-service remote management method and system
By compiling, packaging and uploading microservice software packages on the server, the client subscribes to the message queue download and performs silent updates through Kubernetes, the problem of remote update of microservices is solved, and an efficient and convenient update process is achieved, improving the user experience.
Patent Information
- Application Number
- CN202411570744.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-06
- Publication Date
- 2025-03-21
AI Technical Summary
The existing technology is difficult to realize remote update of microservices, which leads to cumbersome and time-consuming update process, and the service interruption of microservices during update seriously affects the user experience.
Obtain application code through the server, use continuous integration tools and shell scripts to compile and package the software package, upload it to the FTP server's mirror repository, and create a message queue to store software information and mirror repository address. The client subscribes to the message queue through the intranet, downloads the software package, and performs silent update operations through Kubernetes, records update logs in real time and generates update reports.
Remote update of microservices is realized, manual intervention during the update process is reduced, service interruption is avoided, and update convenience and user experience is improved.
Smart Images

Figure CN119676223A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of microservice management technology, and in particular to a microservice remote management method and system. Background Art
[0002] After the development of microservices (applications) is completed, they need to be deployed to various clients, and clients are often distributed in different places, that is, microservices need to be distributed and deployed. When a microservice version is updated, it is also necessary to update the distributed microservices, that is, update the microservices running on each client. In order to improve the delivery efficiency of microservices, the continuous integration and continuous deployment (CI / CD) method is generally adopted in the microservice development process, that is, microservices need to be continuously deployed and updated.
[0003] However, for security reasons, many microservices are deployed in an intranet environment, and microservices cannot be updated remotely. As a result, each update of a microservice requires engineers to go to the client site where the microservice is deployed to perform related operations, which is time-consuming and laborious. In addition, during the update process, the services provided by the microservice will be interrupted, which seriously affects the user experience of users who are currently calling the microservice.
[0004] Therefore, how to provide a microservice remote management method and system to improve the convenience of microservice updates and user experience has become a technical problem that needs to be solved urgently. Summary of the invention
[0005] The technical problem to be solved by the present invention is to provide a microservice remote management method and system to improve the convenience of microservice update and user experience.
[0006] In a first aspect, the present invention provides a microservice remote management method, comprising the following steps:
[0007] Step S1, the server obtains the input application code for updating the microservice, compiles and packages the application code through continuous integration tools and shell scripts, obtains the software package of the microservice, and sets the software information of the software package;
[0008] Step S2: The server uploads the software package to the image repository of the FTP server;
[0009] Step S3: the server creates a message queue, and binds and stores the software information corresponding to the software package and the image repository address to the message queue;
[0010] Step S4: After the client and the server are authenticated, the client subscribes to the message queue through the intranet to obtain software information and the image repository address;
[0011] Step S5: After the client verifies the version based on the software information, it downloads the software package from the FTP server based on the mirror repository address;
[0012] Step S6: Based on the software package, the client performs a silent update operation on the locally deployed microservice through Kubernetes, and records the update log in real time;
[0013] Step S7: The client generates an update result, generates an update report based on the update result and the update log, and feeds back the update report in real time.
[0014] Furthermore, the step S2 is specifically as follows:
[0015] The server automatically uploads the software package to the image repository of the FTP server through the gitlab multi-branch scheduled task, and the FTP server manages the image repository through jar;
[0016] The step S4 is specifically as follows:
[0017] The client sets a whitelist based on the IP address, and the server establishes a connection with the client through the VPN server. After the client authenticates the server through the whitelist, the continuous integration tool and the shell script obtain the software information and the image warehouse address by subscribing to the message queue based on the intranet through API calls.
[0018] Furthermore, the step S5 is specifically as follows:
[0019] The client performs version verification on the locally installed microservice based on the software information to determine whether the version of the software information is higher than the version of the locally installed microservice. If so, the client accesses the image repository address based on an HTTPS request, and then downloads the corresponding software package from the image repository of the FTP server.
[0020] Furthermore, the step S6 is specifically as follows:
[0021] The client performs a backup operation on the microservice running locally, creates a new Pod based on the software package through Kubernetes, and replaces the old Pod of the microservice running locally; the new Pod is configured with a probe for detecting whether it is successfully registered with the Nacos service registration center;
[0022] Kubernetes registers the new Pod to the Nacos service registration center, and queries the service instance corresponding to the new Pod through the probe polling. When the service instance corresponding to the new Pod is online and in a readable state, the new Pod is successfully registered and started normally;
[0023] Kubernetes executes a predefined lifecycle hook on the old Pod to adjust the weight of the old Pod in the Nacos service registration center to 0, and then switches the traffic of the old Pod to the new Pod to perform a silent update operation, and records in real time at least the update log including the new Pod startup time and the old Pod weight adjustment process.
[0024] Furthermore, the step S7 is specifically as follows:
[0025] The client generates an update result indicating a successful update or a failed update, generates an update report based on the update result and the update log, encrypts the update report to obtain an encrypted report, stores the encrypted report, and pushes the encrypted report to a pre-managed management terminal in real time.
[0026] In a second aspect, the present invention provides a microservice remote management system, comprising the following modules:
[0027] A software package generation module is used for the server to obtain the input application code for updating the microservice, compile and package the application code through continuous integration tools and shell scripts, obtain the software package of the microservice, and set the software information of the software package;
[0028] The software package uploading module is used for the server to upload the software package to the mirror repository of the FTP server;
[0029] A message queue update module is used for creating a message queue on the server side, and binding and storing the software information corresponding to the software package and the image warehouse address to the message queue;
[0030] The message queue subscription module is used to obtain software information and image repository address by subscribing to the message queue through the intranet after the client and the server are authenticated;
[0031] A software package downloading module, used for the client to download the software package from the FTP server based on the image warehouse address after performing version verification based on the software information;
[0032] A silent update module is used for the client to perform silent update operations on the locally deployed microservices through Kubernetes based on the software package and record the update log in real time;
[0033] The update report management module is used for the client to generate update results, generate update reports based on the update results and update logs, and feed back the update reports in real time.
[0034] Furthermore, the software package upload module is specifically used for:
[0035] The server automatically uploads the software package to the image repository of the FTP server through the gitlab multi-branch scheduled task, and the FTP server manages the image repository through jar;
[0036] The message queue subscription module is specifically used for:
[0037] The client sets a whitelist based on the IP address, and the server establishes a connection with the client through the VPN server. After the client authenticates the server through the whitelist, the continuous integration tool and the shell script obtain the software information and the image warehouse address by subscribing to the message queue based on the intranet through API calls.
[0038] Furthermore, the software package download module is specifically used for:
[0039] The client performs version verification on the locally installed microservice based on the software information to determine whether the version of the software information is higher than the version of the locally installed microservice. If so, the client accesses the image repository address based on an HTTPS request, and then downloads the corresponding software package from the image repository of the FTP server.
[0040] Furthermore, the silent update module is specifically used for:
[0041] The client performs a backup operation on the microservice running locally, creates a new Pod based on the software package through Kubernetes, and replaces the old Pod of the microservice running locally; the new Pod is configured with a probe for detecting whether it is successfully registered with the Nacos service registration center;
[0042] Kubernetes registers the new Pod to the Nacos service registration center, and queries the service instance corresponding to the new Pod through the probe polling. When the service instance corresponding to the new Pod is online and in a readable state, the new Pod is successfully registered and started normally;
[0043] Kubernetes executes a predefined lifecycle hook on the old Pod to adjust the weight of the old Pod in the Nacos service registration center to 0, and then switches the traffic of the old Pod to the new Pod to perform a silent update operation, and records in real time at least the update log including the new Pod startup time and the old Pod weight adjustment process.
[0044] Furthermore, the update report management module is specifically used to:
[0045] The client generates an update result indicating a successful update or a failed update, generates an update report based on the update result and the update log, encrypts the update report to obtain an encrypted report, stores the encrypted report, and pushes the encrypted report to a pre-managed management terminal in real time.
[0046] The advantages of the present invention are:
[0047] 1. Obtain the input application code for updating microservices through the server, compile and package the application code through continuous integration tools and shell scripts to obtain the software package of the microservice, set the software information of the software package, upload the software package to the mirror warehouse of the FTP server, bind and store the software information and mirror warehouse address corresponding to the software package to the created message queue; then after the client authenticates with the server, obtain the software information and mirror warehouse address through the intranet subscription message queue, perform version verification based on the software information, download the software package from the FTP server based on the mirror warehouse address, and perform silent update operations on the locally deployed microservices through Kubernetes based on the software package, record the update log in real time, generate update results, and based on the update results and The update log generates an update report and provides real-time feedback; that is, after the client authenticates the server through the whitelist, it obtains software information and the address of the image warehouse based on the intranet subscription message queue through API calls to perform remote update operations, without the need to perform related operations on site as traditionally; and during the update process, a new Pod is created based on the software package through Kubernetes and registered with the Nacos service registration center, and a predefined lifecycle hook is executed for the old Pod of the locally running microservice to adjust the weight of the old Pod in the Nacos service registration center to 0, and then switch the traffic of the old Pod to the new Pod. During this process, the traffic is not interrupted to perform silent update operations, thereby greatly improving the convenience of microservice updates and user experience.
[0048] 2. Managing the image repository through jar can effectively reduce disk space, speed up the build, improve stability, and reduce external dependencies.
[0049] 3. Automatically uploading the software package to the FTP server through the gitlab multi-branch scheduled task can reduce manual intervention and realize automatic deployment and updating of the software package.
[0050] 4. Use HTTPS to request access to the mirror repository address to download the software package. Since HTTPS uses the SSL / TLS encryption algorithm to encrypt the transmitted data, it ensures that the data is not easily stolen or tampered with during the transmission process, which greatly improves the security of software package downloading.
[0051] 5. By encrypting the update report to obtain an encrypted report, storing the encrypted report, and pushing the encrypted report to the pre-managed management terminal in real time, it is not only convenient for later traceability and ensures the security of update report storage, but also enables relevant staff to receive update reports in a timely manner. BRIEF DESCRIPTION OF THE DRAWINGS
[0052] The present invention will be further described below in conjunction with embodiments with reference to the accompanying drawings.
[0053] Figure 1 It is a flow chart of a microservice remote management method of the present invention.
[0054] Figure 2 It is a structural schematic diagram of a microservice remote management system of the present invention. DETAILED DESCRIPTION
[0055] The technical solution in the embodiment of the present application has the following overall idea: after the client authenticates the server through the whitelist, it obtains the software information and the image warehouse address based on the intranet subscription message queue through API calls to perform remote update operations, without the need to perform related operations on site as traditionally; during the update process, a new Pod is created based on the software package through Kubernetes and registered with the Nacos service registration center, and a predefined lifecycle hook is executed on the old Pod of the locally running microservice to adjust the weight of the old Pod in the Nacos service registration center to 0, thereby switching the traffic of the old Pod to the new Pod. During this process, the traffic is not interrupted to perform silent update operations, thereby improving the convenience of microservice updates and user experience.
[0056] Please refer to Figure 1 to Figure 2 As shown, a preferred embodiment of a microservice remote management method of the present invention includes the following steps:
[0057] Step S1, the server obtains the input application code (git code) for updating the microservice, compiles and packages the application code through the continuous integration tool and the shell script, obtains the software package of the microservice, and sets the software information of the software package; the software information at least includes the version number and generation time of the microservice; the continuous integration tool is Jenkins;
[0058] Step S2: The server uploads the software package to the image repository of the FTP server;
[0059] Step S3: the server creates a message queue, and binds and stores the software information corresponding to the software package and the image repository address to the message queue;
[0060] Step S4: After the client and the server are authenticated, the client subscribes to the message queue through the intranet to obtain software information and the image repository address;
[0061] Step S5: After the client verifies the version based on the software information, it downloads the software package from the FTP server based on the mirror repository address;
[0062] Step S6: Based on the software package, the client performs a silent update operation on the locally deployed microservice through Kubernetes, and records the update log in real time; that is, the rolling update mechanism of Kubernetes is adopted;
[0063] Step S7: The client generates an update result, generates an update report based on the update result and the update log, and feeds back the update report in real time.
[0064] The present invention realizes the full process automation from project construction to update deployment of microservices through the pipeline tasks of Jenkins and the rolling update mechanism of Kubernetes; the old Pod adjusts the weight in the Nacos service registration center through the lifecycle hook to ensure that the microservice update process is imperceptible to users and minimize service interruptions; the registration status of the new Pod is detected by the probe, and the update report is automatically fed back after the update is completed to ensure that relevant personnel are aware of the update progress in a timely manner.
[0065] The step S2 is specifically as follows:
[0066] The server automatically uploads the software package to the image repository of the FTP server through the gitlab multi-branch scheduled task, and the FTP server manages the image repository through jar; managing the image repository through jar can effectively reduce disk space, speed up the build speed, improve stability, and reduce external dependencies; automatically uploading the software package to the FTP server through the gitlab multi-branch scheduled task can reduce manual intervention and realize automatic deployment and updating of the software package.
[0067] The step S4 is specifically as follows:
[0068] The client sets a whitelist based on the IP address, and the server establishes a connection with the client through the VPN server. After the client authenticates the server through the whitelist, the continuous integration tool and the shell script obtain the software information and the image warehouse address by subscribing to the message queue based on the intranet through API calls.
[0069] The step S5 is specifically as follows:
[0070] The client verifies the version of the locally installed microservice based on the software information to determine whether the version of the software information is higher than the version of the locally installed microservice. If so, the client accesses the mirror repository address based on the HTTPS request, and then downloads the corresponding software package from the mirror repository of the FTP server. The software package is downloaded by accessing the mirror repository address through the HTTPS request. Since HTTPS uses the SSL / TLS encryption algorithm to encrypt the transmitted data, it ensures that the data is not easily stolen or tampered with during the transmission process, which greatly improves the security of the software package download.
[0071] The step S6 is specifically as follows:
[0072] The client performs a backup operation on the microservice running locally, creates a new Pod based on the software package through Kubernetes, and replaces the old Pod of the microservice running locally; the new Pod is configured with a probe for detecting whether it is successfully registered with the Nacos service registration center;
[0073] Kubernetes registers the new Pod to the Nacos service registration center, and queries the service instance corresponding to the new Pod through the probe polling. When the service instance corresponding to the new Pod is online and in a readable state (read), the new Pod is successfully registered and started normally;
[0074] Kubernetes executes a predefined lifecycle hook on the old Pod to adjust the weight of the old Pod in the Nacos service registration center to 0, and then switches the traffic of the old Pod to the new Pod to perform a silent update operation, and records in real time at least the update log including the new Pod startup time and the old Pod weight adjustment process.
[0075] The step S7 is specifically as follows:
[0076] The client generates an update result indicating a successful update or a failed update, generates an update report based on the update result and the update log, encrypts the update report to obtain an encrypted report, stores the encrypted report, and pushes the encrypted report to a pre-managed management terminal in real time. By encrypting the update report to obtain an encrypted report, storing the encrypted report, and pushing the encrypted report to a pre-managed management terminal in real time, it is not only convenient for later tracing and ensures the security of the update report storage, but also allows relevant staff to receive the update report in a timely manner.
[0077] The step of encrypting the update report to obtain the encrypted report specifically includes:
[0078] The client creates a pair of public and private keys based on the RSA algorithm, encrypts the public key through the XTEA algorithm to obtain a secret key, performs MAC calculation on the update report to obtain a MAC value, obtains the current timestamp, encrypts the update report, the MAC value, and the timestamp through the private key to obtain encrypted data, maps the encrypted data through a preset mapping rule to obtain mapping data, and encrypts the mapping data and the secret key through the RC6 algorithm to obtain an encrypted report.
[0079] A preferred embodiment of a microservice remote management system of the present invention includes the following modules:
[0080] The software package generation module is used for the server to obtain the input application code (git code) for updating the microservice, compile and package the application code through the continuous integration tool and shell script to obtain the software package of the microservice, and set the software information of the software package; the software information at least includes the version number and generation time of the microservice; the continuous integration tool is Jenkins;
[0081] The software package uploading module is used for the server to upload the software package to the mirror repository of the FTP server;
[0082] A message queue update module is used for creating a message queue on the server side, and binding and storing the software information corresponding to the software package and the image warehouse address to the message queue;
[0083] The message queue subscription module is used to obtain software information and image repository address by subscribing to the message queue through the intranet after the client and the server are authenticated;
[0084] A software package downloading module, used for the client to download the software package from the FTP server based on the image warehouse address after performing version verification based on the software information;
[0085] A silent update module is used for the client to perform silent update operations on the locally deployed microservices through Kubernetes based on the software package and record update logs in real time; that is, to adopt the rolling update mechanism of Kubernetes;
[0086] The update report management module is used for the client to generate update results, generate update reports based on the update results and update logs, and feed back the update reports in real time.
[0087] The present invention realizes the full process automation from project construction to update deployment of microservices through the pipeline tasks of Jenkins and the rolling update mechanism of Kubernetes; the old Pod adjusts the weight in the Nacos service registration center through the lifecycle hook to ensure that the microservice update process is imperceptible to users and minimize service interruptions; the registration status of the new Pod is detected by the probe, and the update report is automatically fed back after the update is completed to ensure that relevant personnel are aware of the update progress in a timely manner.
[0088] The software package upload module is specifically used for:
[0089] The server automatically uploads the software package to the image repository of the FTP server through the gitlab multi-branch scheduled task, and the FTP server manages the image repository through jar; managing the image repository through jar can effectively reduce disk space, speed up the build speed, improve stability, and reduce external dependencies; automatically uploading the software package to the FTP server through the gitlab multi-branch scheduled task can reduce manual intervention and realize automatic deployment and updating of the software package.
[0090] The message queue subscription module is specifically used for:
[0091] The client sets a whitelist based on the IP address, and the server establishes a connection with the client through the VPN server. After the client authenticates the server through the whitelist, the continuous integration tool and the shell script obtain the software information and the image warehouse address by subscribing to the message queue based on the intranet through API calls.
[0092] The software package download module is specifically used for:
[0093] The client verifies the version of the locally installed microservice based on the software information to determine whether the version of the software information is higher than the version of the locally installed microservice. If so, the client accesses the mirror repository address based on the HTTPS request, and then downloads the corresponding software package from the mirror repository of the FTP server. The software package is downloaded by accessing the mirror repository address through the HTTPS request. Since HTTPS uses the SSL / TLS encryption algorithm to encrypt the transmitted data, it ensures that the data is not easily stolen or tampered with during the transmission process, which greatly improves the security of the software package download.
[0094] The silent update module is specifically used for:
[0095] The client performs a backup operation on the microservice running locally, creates a new Pod based on the software package through Kubernetes, and replaces the old Pod of the microservice running locally; the new Pod is configured with a probe for detecting whether it is successfully registered with the Nacos service registration center;
[0096] Kubernetes registers the new Pod to the Nacos service registration center, and queries the service instance corresponding to the new Pod through the probe polling. When the service instance corresponding to the new Pod is online and in a readable state (read), the new Pod is successfully registered and started normally;
[0097] Kubernetes executes a predefined lifecycle hook on the old Pod to adjust the weight of the old Pod in the Nacos service registration center to 0, and then switches the traffic of the old Pod to the new Pod to perform a silent update operation, and records in real time at least the update log including the new Pod startup time and the old Pod weight adjustment process.
[0098] The update report management module is specifically used for:
[0099] The client generates an update result indicating a successful update or a failed update, generates an update report based on the update result and the update log, encrypts the update report to obtain an encrypted report, stores the encrypted report, and pushes the encrypted report to a pre-managed management terminal in real time. By encrypting the update report to obtain an encrypted report, storing the encrypted report, and pushing the encrypted report to a pre-managed management terminal in real time, it is not only convenient for later tracing and ensures the security of the update report storage, but also allows relevant staff to receive the update report in a timely manner.
[0100] The step of encrypting the update report to obtain the encrypted report specifically includes:
[0101] The client creates a pair of public and private keys based on the RSA algorithm, encrypts the public key through the XTEA algorithm to obtain a secret key, performs MAC calculation on the update report to obtain a MAC value, obtains the current timestamp, encrypts the update report, the MAC value, and the timestamp through the private key to obtain encrypted data, maps the encrypted data through a preset mapping rule to obtain mapping data, and encrypts the mapping data and the secret key through the RC6 algorithm to obtain an encrypted report.
[0102] In summary, the advantages of the present invention are:
[0103] 1. Obtain the input application code for updating microservices through the server, compile and package the application code through continuous integration tools and shell scripts to obtain the software package of the microservice, set the software information of the software package, upload the software package to the mirror warehouse of the FTP server, bind and store the software information and mirror warehouse address corresponding to the software package to the created message queue; then after the client authenticates with the server, obtain the software information and mirror warehouse address through the intranet subscription message queue, perform version verification based on the software information, download the software package from the FTP server based on the mirror warehouse address, and perform silent update operations on the locally deployed microservices through Kubernetes based on the software package, record the update log in real time, generate update results, and based on the update results and The update log generates an update report and provides real-time feedback; that is, after the client authenticates the server through the whitelist, it obtains software information and the address of the image warehouse based on the intranet subscription message queue through API calls to perform remote update operations, without the need to perform related operations on site as traditionally; and during the update process, a new Pod is created based on the software package through Kubernetes and registered with the Nacos service registration center, and a predefined lifecycle hook is executed for the old Pod of the locally running microservice to adjust the weight of the old Pod in the Nacos service registration center to 0, and then switch the traffic of the old Pod to the new Pod. During this process, the traffic is not interrupted to perform silent update operations, thereby greatly improving the convenience of microservice updates and user experience.
[0104] 2. Managing the image repository through jar can effectively reduce disk space, speed up the build, improve stability, and reduce external dependencies.
[0105] 3. Automatically uploading the software package to the FTP server through the gitlab multi-branch scheduled task can reduce manual intervention and realize automatic deployment and updating of the software package.
[0106] 4. Use HTTPS to request access to the mirror repository address to download the software package. Since HTTPS uses the SSL / TLS encryption algorithm to encrypt the transmitted data, it ensures that the data is not easily stolen or tampered with during the transmission process, which greatly improves the security of software package downloading.
[0107] 5. By encrypting the update report to obtain an encrypted report, storing the encrypted report, and pushing the encrypted report to the pre-managed management terminal in real time, it is not only convenient for later traceability and ensures the security of update report storage, but also enables relevant staff to receive update reports in a timely manner.
[0108] Although the specific implementation modes of the present invention are described above, those skilled in the art should understand that the specific implementation modes described are only illustrative and are not intended to limit the scope of the present invention. Equivalent modifications and changes made by those skilled in the art in accordance with the spirit of the present invention should be included in the scope of protection of the claims of the present invention.
Claims
1. A microservice remote management method, characterized in that: The steps include: Step S1, the server obtains the input application code for updating the microservice, compiles and packages the application code through continuous integration tools and shell scripts, obtains the software package of the microservice, and sets the software information of the software package; Step S2: The server uploads the software package to the image repository of the FTP server; Step S3: the server creates a message queue, and binds and stores the software information corresponding to the software package and the image repository address to the message queue; Step S4: After the client and the server are authenticated, the client subscribes to the message queue through the intranet to obtain software information and the image repository address; Step S5: After the client verifies the version based on the software information, it downloads the software package from the FTP server based on the mirror repository address; Step S6: Based on the software package, the client performs a silent update operation on the locally deployed microservice through Kubernetes, and records the update log in real time; Step S7: The client generates an update result, generates an update report based on the update result and the update log, and feeds back the update report in real time.
2. A microservice remote management method as claimed in claim 1, characterized in that: The step S2 is specifically as follows: The server automatically uploads the software package to the image repository of the FTP server through the gitlab multi-branch scheduled task, and the FTP server manages the image repository through jar; The step S4 is specifically as follows: The client sets a whitelist based on the IP address, and the server establishes a connection with the client through the VPN server. After the client authenticates the server through the whitelist, the continuous integration tool and shell script obtain software information and the image warehouse address by subscribing to the message queue based on the intranet through API calls.
3. A microservice remote management method as claimed in claim 1, characterized in that: The step S5 is specifically as follows: The client performs version verification on the locally installed microservice based on the software information to determine whether the version of the software information is higher than the version of the locally installed microservice. If so, the client accesses the image repository address based on an HTTPS request, and then downloads the corresponding software package from the image repository of the FTP server.
4. A microservice remote management method as claimed in claim 1, characterized in that: The step S6 is specifically as follows: The client performs a backup operation on the microservice running locally, creates a new Pod based on the software package through Kubernetes, and replaces the old Pod of the microservice running locally; the new Pod is configured with a probe for detecting whether it is successfully registered with the Nacos service registration center; Kubernetes registers the new Pod to the Nacos service registration center, and queries the service instance corresponding to the new Pod through the probe polling. When the service instance corresponding to the new Pod is online and in a readable state, the new Pod is successfully registered and started normally; Kubernetes executes a predefined lifecycle hook on the old Pod to adjust the weight of the old Pod in the Nacos service registration center to 0, and then switches the traffic of the old Pod to the new Pod to perform a silent update operation, and records in real time at least the update log including the new Pod startup time and the old Pod weight adjustment process.
5. A microservice remote management method as claimed in claim 1, characterized in that: The step S7 is specifically as follows: The client generates an update result indicating a successful update or a failed update, generates an update report based on the update result and the update log, encrypts the update report to obtain an encrypted report, stores the encrypted report, and pushes the encrypted report to a pre-managed management terminal in real time.
6. A microservice remote management system, characterized in that: Includes the following modules: A software package generation module is used for the server to obtain the input application code for updating the microservice, compile and package the application code through the continuous integration tool and shell script, obtain the software package of the microservice, and set the software information of the software package; The software package uploading module is used for the server to upload the software package to the mirror repository of the FTP server; A message queue update module is used for creating a message queue on the server side, and binding and storing the software information corresponding to the software package and the image warehouse address to the message queue; The message queue subscription module is used to obtain software information and image repository address by subscribing to the message queue through the intranet after the client and the server are authenticated; A software package downloading module, used for the client to download the software package from the FTP server based on the image warehouse address after performing version verification based on the software information; A silent update module is used for the client to perform silent update operations on the locally deployed microservices through Kubernetes based on the software package and record the update log in real time; The update report management module is used for the client to generate update results, generate update reports based on the update results and update logs, and feed back the update reports in real time.
7. A microservice remote management system as claimed in claim 6, characterized in that: The software package upload module is specifically used for: The server automatically uploads the software package to the image repository of the FTP server through the gitlab multi-branch scheduled task, and the FTP server manages the image repository through jar; The message queue subscription module is specifically used for: The client sets a whitelist based on the IP address, and the server establishes a connection with the client through the VPN server. After the client authenticates the server through the whitelist, the continuous integration tool and shell script obtain software information and the image warehouse address by subscribing to the message queue based on the intranet through API calls.
8. A microservice remote management system as claimed in claim 6, characterized in that: The software package download module is specifically used for: The client performs version verification on the locally installed microservice based on the software information to determine whether the version of the software information is higher than the version of the locally installed microservice. If so, the client accesses the image repository address based on an HTTPS request, and then downloads the corresponding software package from the image repository of the FTP server.
9. A microservice remote management system as claimed in claim 6, characterized in that: The silent update module is specifically used for: The client performs a backup operation on the microservice running locally, creates a new Pod based on the software package through Kubernetes, and replaces the old Pod of the microservice running locally; the new Pod is configured with a probe for detecting whether it is successfully registered with the Nacos service registration center; Kubernetes registers the new Pod to the Nacos service registration center, and queries the service instance corresponding to the new Pod through the probe polling. When the service instance corresponding to the new Pod is online and in a readable state, the new Pod is successfully registered and started normally; Kubernetes executes a predefined lifecycle hook on the old Pod to adjust the weight of the old Pod in the Nacos service registration center to 0, and then switches the traffic of the old Pod to the new Pod to perform a silent update operation, and records in real time at least the update log including the new Pod startup time and the old Pod weight adjustment process.
10. A microservice remote management system according to claim 6, characterized in that: The update report management module is specifically used for: The client generates an update result indicating a successful update or a failed update, generates an update report based on the update result and the update log, encrypts the update report to obtain an encrypted report, stores the encrypted report, and pushes the encrypted report to a pre-managed management terminal in real time.