Hybrid cloud platform software version release method, system and device and computer equipment

Abstract

The invention relates to a hybrid cloud platform software version release method, system and device and computer equipment. The method is applied to a block chain network, the block chain network comprises a version issuing master node, version issuing slave nodes, deployment nodes and redundant nodes, and the method comprises the following steps: the version issuing master node receives a to-be-issued version software package sent by a version issuing party; the version issuing main node proposes a software version issuing proposal carrying the version software package based on the version software package to be issued; and the version issuing master node notifies the version issuing slave node, the deployment node and the redundant node to perform consensus verification on the software version issuing proposal, so that the deployment node updates the installed version. By adopting the method, the reliability of hybrid cloud platform software version release can be improved.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a hybrid cloud platform software version publishing method, system, device, computer equipment, computer-readable storage medium and computer program product. Background Art

[0002] Hybrid cloud architecture combines the advantages of public cloud and private cloud, bringing greater flexibility and choice to enterprises. Public cloud provides highly scalable computing resources and rich cloud services, while private cloud provides stricter security and data control.

[0003] However, with the development and evolution of hybrid cloud platforms, enterprises have increasing requirements for their functions and performance, especially in version release and version management, with high requirements for security and reliability.

[0004] Currently, the traditional version release process still has the problem of low reliability. Summary of the invention

[0005] Based on this, it is necessary to provide a hybrid cloud platform software version release method, system, device, computer equipment, computer-readable storage medium and computer program product that can improve the reliability of software version release in response to the above technical problems.

[0006] In a first aspect, the present application provides a hybrid cloud platform software version release method, which is applied to a blockchain network, wherein the blockchain network includes a release master node, a release slave node, a deployment node, and a redundant node, including:

[0007] The publishing master node receives the version software package to be published sent by the publisher;

[0008] The version master node proposes a software version release proposal for the version software package based on the version software package to be released;

[0009] The release master node notifies the release slave nodes, deployment nodes, and redundant nodes to perform consensus verification on the software version release proposal so that the deployment node can update the installed version.

[0010] In one embodiment, notifying the release slave node, the deployment node, and the redundant node to perform consensus verification on the software version release proposal so that the deployment node updates the installed version includes:

[0011] The release master node sends a pre-prepare message to the release slave node, deployment node, and redundant node. The pre-prepare message is used to instruct the release slave node, deployment node, and redundant node to verify the validity of the software version release proposal;

[0012] Receive preparation messages from release slave nodes, deployment nodes, and redundant nodes. The preparation messages are sent when the software version release proposal passes the validity verification;

[0013] When the number of received prepare messages reaches a preset number threshold, a commit message is sent to the release slave node, deployment node, and redundant node, and the commit message is used to instruct the release slave node, deployment node, and redundant node to verify the validity of the commit message;

[0014] Receive confirmation messages from release slave nodes, deployment nodes, and redundant nodes. The confirmation messages are sent when the submitted messages pass validity verification.

[0015] When the number of received confirmation messages reaches a preset number threshold, the deployment node updates the installed version.

[0016] In one embodiment, the redundant nodes include internal nodes in the development environment, the test environment, and the backup environment.

[0017] In one of the embodiments, the preset quantity threshold is determined based on the total quantity of release master nodes, release slave nodes, deployment nodes and redundant nodes.

[0018] In one embodiment, the hybrid cloud platform software version release method further includes:

[0019] When receiving a network access request, extracting the identity of the request sending node carried in the network access request;

[0020] Based on the identity identification, verify the legitimacy of the identity of the node sending the request;

[0021] When the identity of the request sending node is determined to be legitimate, the request sending node is added to the blockchain network.

[0022] In one embodiment, the number of release slave nodes is multiple, and the hybrid cloud platform software version release method further includes:

[0023] When the distribution master node is unavailable, a new distribution master node is elected from multiple distribution slave nodes to take over the tasks performed by the distribution master node.

[0024] In the second aspect, the present application also provides a hybrid cloud platform software version release system, including a release master node, a release slave node, a deployment node, and a redundant node:

[0025] The release master node receives the version software package to be released sent by the release party, proposes a software version release proposal for the version software package based on the version software package to be released, and sends a pre-preparation message to the release slave node, deployment node and redundant node. The pre-preparation message is used to instruct the release slave node, deployment node and redundant node to verify the validity of the software version release proposal;

[0026] The release slave node, deployment node, and redundant node feed back the preparation message to the remaining nodes except themselves. The preparation message is sent when the software version release proposal passes the validity verification;

[0027] When the number of received prepare messages reaches a preset threshold, the release master node sends a commit message to the release slave node, deployment node, and redundant node. The commit message is used to instruct the release slave node, deployment node, and redundant node to verify the validity of the commit message.

[0028] The release slave node, deployment node, and redundant node feed back confirmation messages to the remaining nodes except themselves. The confirmation message is sent when the submission message passes the validity verification;

[0029] When the number of received confirmation messages reaches a preset number threshold, the deployment node updates the installed version.

[0030] In a third aspect, the present application also provides a hybrid cloud platform software version publishing device, including:

[0031] The version receiving module is used to receive the version software package to be released sent by the publisher;

[0032] A proposal generation module is used to propose a software version release proposal for a version software package based on the version software package to be released;

[0033] The consensus module is used to notify the release slave nodes, deployment nodes, and redundant nodes to perform consensus verification on the software version release proposal so that the deployment nodes can update the installed version.

[0034] In a fourth aspect, the present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps in any one of the above-mentioned hybrid cloud platform software version release method embodiments are implemented.

[0035] In a fifth aspect, the present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps in any one of the above-mentioned hybrid cloud platform software version release method embodiments are implemented.

[0036] In a sixth aspect, the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps in any one of the above-mentioned hybrid cloud platform software version release method embodiments.

[0037] The above-mentioned hybrid cloud platform software version release method, system, device, computer equipment, computer-readable storage medium and computer program product, on the one hand, combine the characteristics of the hybrid cloud environment and introduce blockchain technology. Due to the tamper-proof nature of the blockchain, it can ensure the integrity and authenticity of the software version, prevent unauthorized tampering and malicious attacks, and trace the source and historical changes of each version, so as to better manage the version release process and troubleshoot problems. Nodes participating in the version release can view and verify the data on the blockchain, thereby enhancing the transparency and credibility of the version release process. In addition, it can simplify the version release process, enhance the interoperability and consistency between different cloud platforms in the hybrid cloud environment, and reduce the complexity and risk of version management. On the other hand, by redesigning the consensus process and role node functions, a controllable redundant node is introduced as one of the nodes participating in the consensus verification of the hybrid cloud platform software version, which expands the number of consensus nodes, can improve the fault tolerance and stability of the consensus process, and also provide backup support for disaster recovery during the version release process, which is conducive to improving the reliability and continuity of software version release. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0039] Figure 1 An application environment diagram of a hybrid cloud platform software version release method in one embodiment;

[0040] Figure 2 A schematic diagram of a process for publishing a hybrid cloud platform software version in one embodiment;

[0041] Figure 3 It is a flowchart of a method for publishing a hybrid cloud platform software version in another embodiment;

[0042] Figure 4 A schematic diagram of a comparison between a traditional consensus node role and a consensus node role of the present application in one embodiment;

[0043] Figure 5 A schematic diagram of a process for publishing a hybrid cloud platform software version in a detailed embodiment;

[0044] Figure 6 It is a structural block diagram of a hybrid cloud platform software version publishing system in one embodiment;

[0045] Figure 7 It is a structural block diagram of a hybrid cloud platform software version publishing device in one embodiment;

[0046] Figure 8 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] The centralized release model used in the new version release of the traditional hybrid cloud management platform software has some problems that cannot be ignored. Usually, this centralized release model is controlled by a centralized manager or platform, which makes the system prone to single point failure and single point control risks. In order to meet these challenges, this application focuses on the release of the hybrid cloud management platform software, and revolves around the purpose of achieving decentralization to ensure the security, reliability and efficiency of the version release and management process.

[0049] In view of the characteristics of hybrid cloud services and the needs of users of hybrid cloud services, the following factors need to be considered in the release of hybrid cloud management platform software (hybrid cloud platform software):

[0050] 1. Ensure the security of the version release process.

[0051] 2. Ensure transparency of every step and decision in the release process.

[0052] 3. Ensure that the source and historical changes of each version are traceable to facilitate troubleshooting and backtracking.

[0053] 4. It can realize decentralized management of the version release process and reduce the risks of single point failure and single point control.

[0054] 5. It can realize the automation and intelligence of the version release process, reduce manual intervention, and improve release efficiency.

[0055] 6. Reduce the computing power consumed in the version release process.

[0056] 7. Improve the flexibility of updating the new version of the hybrid cloud management platform software so that you can choose the update time at any time without being restricted by the fixed version release time.

[0057] 8. In view of the fact that the user's hybrid cloud deployment environment may have an isolated environment that cannot connect to the public network, the adaptability of the version release of the hybrid cloud management platform software is improved.

[0058] Therefore, in order to meet the above needs, this application proposes a version release method for a decentralized hybrid cloud management platform software based on blockchain technology to improve the reliability of the hybrid cloud management platform software version release. Through blockchain technology, a secure and reliable data environment is provided for the software version release process. Taking full account of the characteristics of the hybrid cloud management platform software and users, a consensus verification method for matching software version release is selected. On this basis, in order to adapt to the hybrid cloud management software version release, the consensus verification process and the roles of the nodes participating in the consensus verification are innovatively designed. The nodes participating in the consensus verification can be composed of users of hybrid cloud services and the publisher of the hybrid cloud management platform software, and these nodes are abstracted into the master node, the slave node, and the deployment node. In particular, redundant nodes are introduced into the nodes participating in the consensus verification to expand the number of nodes for consensus verification and improve the consensus fault tolerance of the deployment nodes. At the same time, since the nodes participating in the consensus are composed of users and software publishers, users can update the version of the hybrid cloud management platform software in an isolated environment where they cannot connect to the external network.

[0059] During the actual business version release process, the release master node receives the version software package to be released from the release party, and based on the version software package to be released, proposes a software version release proposal, and notifies the release slave node, deployment node and redundant node to perform consensus verification of the proposal, so that the deployment node can update the installed version.

[0060] The above solution is based on blockchain technology to realize the version release and management of decentralized hybrid cloud management platform software, adopts an automated version release process, uses a distributed network to ensure the secure transmission and storage of data, and ensures the reliability and transparency of version release through a decentralized consensus mechanism. By designing the release slave nodes and redundant node roles that participate in the consensus verification of version release, the consensus verification fault tolerance of the deployment nodes is improved, thereby improving the reliability of the version release process.

[0061] The hybrid cloud platform software version publishing method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the blockchain network includes a master node 102, a slave node 104, a deployment node 106 and a redundant node 108, wherein the number of slave nodes 104, deployment nodes 106 and redundant nodes 108 is multiple. The publisher communicates with the master node 102 through the network. The master node 102, the slave node 104, the deployment node 106 and the redundant node 108 can be connected through Bluetooth, USB (Universal Serial Bus) or network communication connection methods, and this application does not limit this.

[0062] The hybrid cloud platform software version release method is implemented based on the blockchain network. The version master node 102 receives the version software package to be released sent by the publisher, and based on the version software package to be released, proposes a software version release proposal for the version software package. Then, the version master node 102 notifies the version slave node 104, the deployment node 106 and the redundant node 108 to perform consensus verification on the software release proposal, so that the deployment node 106 updates the installed version.

[0063] Among them, the master node 102, the slave node 104, the deployment node 106 and the redundant node 108 may include but are not limited to independent physical servers, or service nodes in the alliance chain system, and each node in the alliance chain system forms a point-to-point network. In addition, it can also be a server cluster composed of multiple physical servers, or it can be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0064] In an exemplary embodiment, Figure 2 As shown, a hybrid cloud platform software version release method is provided, and the method is applied to Figure 1 The blockchain network in is used as an example to illustrate, including the following S100 to S300. Among them:

[0065] S100: The publishing master node receives a version software package to be published sent by a publisher.

[0066] Among them, the main node is a node that has the ability to release the hybrid cloud platform software version, such as the publisher of the hybrid cloud platform software, responsible for initiating and organizing the consensus process. The version package is the software package of the new version of the hybrid cloud management platform software. The publisher refers to the terminal or device used to submit the version package and send the version release request.

[0067] In actual applications, the publisher may first initiate a request to publish the version software package to the publisher master node, the request carries the version software package to be published, and the publisher master node receives the version software package to be published sent by the publisher.

[0068] S200, the version master node proposes a software version release proposal for the version software package based on the version software package to be released.

[0069] The software version release proposal represents the installation operation of the new version of the software. The software version release proposal may include the unique identifier of the software package, data package metadata, download link or path, installation script, and digital signature of the release master node. The data package metadata may include the name, version number, publisher, release timestamp, and hash value (used to verify the integrity of the data package) of the version to be released.

[0070] In actual applications, the version master node generates a software version release proposal for the version software package based on the information of the version software package to be released.

[0071] S300, the version release master node notifies the version release slave node, deployment node and redundant node to perform consensus verification on the software version release proposal, so that the deployment node updates the installed version.

[0072] Among them, consensus verification is to reach an agreement on the validity verification of the proposal. Deployment nodes can be user nodes that need to update the software version of the hybrid cloud platform. They are mainly responsible for participating in consensus verification, verifying the validity of the proposal, and finally reaching consensus to obtain the corresponding software package and update process information. At the same time, deployment nodes do not have the possibility of becoming a master node, which means that deployment nodes do not participate in the election process of master nodes and will not be considered as potential master node candidates. Their role is mainly to ensure the correctness of the consensus process and the reliability of software updates, rather than leading the consensus process. Such a design ensures that when some deployment nodes fail or are unavailable, the remaining deployment nodes can still continue to participate in the consensus process and obtain update packages, thereby ensuring the stability and reliability of the system. It is understandable that the number of deployment nodes can be multiple.

[0073] A release slave node can be a node with the hybrid cloud platform software release capability. It is understandable that there can be multiple release slave nodes. A release slave node can take over the work of releasing a new version of the software package when the release master node fails or is unavailable to ensure the normal operation of the version update process. At the same time, the release slave node will also participate in consensus verification to increase the fault tolerance of the deployment node.

[0074] The redundant nodes may include but are not limited to internal nodes in a software development environment, a software testing environment, and a standby environment. It is understandable that the number of redundant nodes may be multiple.

[0075] In this embodiment, in order to improve the fault tolerance of the consensus process, controllable redundant nodes are added. The redundant nodes are only responsible for participating in the PBFT consensus process and completing the software version update. They do not have the possibility of becoming the master node. That is, in the view rotation process, deployment nodes and redundant nodes other than the release node are not considered. Redundant nodes can be internal nodes of the company, not provided by the customer environment, which can ensure the reliability and security of redundant nodes. In addition, redundant nodes can also provide the latest software version development environment for developers and testers.

[0076] In actual applications, the release master node can notify the release slave nodes, deployment nodes and redundant nodes to verify the consensus of the software version release proposal based on the consensus protocol. When a security consensus is reached, all deployment nodes update the installed version, thus completing the version process. Among them, the consensus protocol includes PBFT (Practical Byzantine Fault Tolerance).

[0077] In the above-mentioned hybrid cloud platform software version release method, on the one hand, combined with the characteristics of the hybrid cloud environment, blockchain technology is introduced. Due to the tamper-proof nature of the blockchain, the integrity and authenticity of the software version can be guaranteed, unauthorized tampering and malicious attacks can be prevented, and the source and historical changes of each version can be traced, so as to better manage the version release process and troubleshoot problems. Moreover, the nodes participating in the version release can view and verify the data on the blockchain, thereby enhancing the transparency and credibility of the version release process. In addition, the version release process can be simplified, the interoperability and consistency between different cloud platforms in the hybrid cloud environment are enhanced, and the complexity and risk of version management are reduced. On the other hand, by redesigning the consensus process and the role node function, a controllable redundant node is introduced as one of the nodes participating in the consensus verification of the hybrid cloud platform software version, and the number of consensus nodes is expanded, which can improve the fault tolerance and stability of the consensus process, and also provide backup support for disaster recovery during the version release process, which is conducive to improving the reliability and continuity of software version release.

[0078] In order to improve the reliability of software version release, in an exemplary embodiment, Figure 3 As shown, S300 includes S310 to S350. Among them:

[0079] S310, the release master node sends a pre-preparation message to the release slave node, deployment node and redundant node, and the pre-preparation message is used to instruct the release slave node, deployment node and redundant node to verify the validity of the software version release proposal.

[0080] In this embodiment, consensus verification is performed through PBFT consensus, where the pre-prepared message may include a view number, a summary (hash value) of the proposal, a message sequence number, a signature of the moderator node, a unique identifier of the proposal, and data packet metadata.

[0081] Specifically, the release master node generates a pre-preparation message and broadcasts the pre-preparation message to the release slave nodes, deployment nodes, and redundant nodes to enter the pre-preparation phase of the PBFT consensus.

[0082] S320, receiving the preparation message fed back by the release slave node, deployment node and redundant node, and the preparation message is sent when the software version release proposal passes the validity verification.

[0083] In actual applications, after receiving the pre-prepare message sent by the master node, the release slave node, deployment node, and redundant node verify the validity of the proposal. The validity of the proposal can be verified by using the public key of the release master node to verify the digital signature, check the proposal summary to ensure the integrity of the content, and check the uniqueness of the proposal. After the verification is passed, a prepare message is generated and sent to the nodes participating in the consensus verification other than itself, including the release master node. The prepare message is used to indicate that the node that received the pre-prepare message has received the pre-prepare message and agreed to the proposal. The release master node receives the prepare message fed back by the release slave node, deployment node, and redundant node.

[0084] S330, when the number of received preparation messages reaches a preset threshold, a submission message is sent to the release slave node, deployment node and redundant node, and the submission message is used to instruct the release slave node, deployment node and redundant node to verify the validity of the submission message.

[0085] In actual applications, when the number of prepare messages received by the master node reaches a preset threshold, a commit message is sent to the slave node, deployment node, and redundant node. The preset threshold can be determined based on the PBFT consensus mechanism and the total number of nodes participating in the consensus.

[0086] S340, receiving confirmation messages fed back by the release slave node, deployment node and redundant node, the confirmation message is sent when the submission message passes the validity verification.

[0087] In actual applications, after receiving the submission message from the release master node, the release slave node, deployment node, and redundant node verify the validity of the submission message. After the verification is passed, a confirmation message is generated and sent to other nodes (including the release master node) participating in the consensus verification except itself, and the preparation message is recorded locally. The confirmation message is used to indicate that the node that received the submission message is ready to apply this proposal. The release master node receives the confirmation message fed back by the release slave node, deployment node, and redundant node.

[0088] S350: When the number of received confirmation messages reaches a preset number threshold, the deployment node updates the installed version.

[0089] In actual applications, the consensus verification of the proposal can be determined to be completed when the number of confirmation messages received by the moderator node reaches the preset number threshold. For any node in the deployment node, when the number of confirmation messages received reaches the preset number threshold, the received confirmation messages and the confirmation messages sent by itself are recorded and stored locally, the proposal is applied, and the status of its own node is updated to complete the version update.

[0090] Specifically, Figure 4 As shown in the figure, in the traditional PBFT consensus process, the nodes participating in the consensus include the master node and the slave node. The master node is responsible for sending proposals to the slave node and receiving feedback from the slave node. The slave node is responsible for receiving and verifying the proposal sent by the master node, voting on it, and sending the voting results to other slave nodes. The slave node needs to ensure that the number of correct messages Nff received is greater than the number of messages f sent by the malicious nodes in the slave node to ensure majority consensus, that is, N>3f. Among them, N is the total number of nodes.

[0091] In this embodiment, the node roles participating in consensus verification include master nodes, slave nodes, deployment nodes, and redundant nodes. The preset number threshold only focuses on the fault tolerance of deployment nodes. Specifically, the preset number threshold is determined based on the number of master nodes, slave nodes, deployment nodes, and redundant nodes. Suppose the number of honest deployment nodes in the consensus node is , the number of malicious deployment nodes is , the number of redundant nodes is B. Therefore, the total number of consensus nodes , the redundant nodes are the nodes of the publisher of the hybrid cloud management platform software, then the total number of malicious nodes f is the number of malicious deployment nodes The PBFT fault tolerance is N>3f, so the conditions required to successfully complete the consensus in this embodiment are: , Therefore, the number of redundant nodes can improve the fault tolerance of deployed nodes, so that the number of honest deployed nodes can successfully complete the PBFT consensus process when it is no more than 2 / 3N.

[0092] In this embodiment, by introducing redundant nodes for consensus verification, the fault tolerance of the deployed nodes in the consensus verification process is improved, the number of nodes participating in the consensus verification is expanded, and the stability and reliability of the cloud service system are improved. At the same time, the redundant nodes can provide backup support for disaster recovery during the version release process, ensuring the continuity of the version release process. Through consensus verification, the risk of tampering or forgery in the software version release process is reduced, thereby reducing the security threats to the cloud service system and data. At the same time, through consensus verification, the transparency and fairness of the version release process are improved, which is conducive to ensuring the integrity, authenticity, and traceability of the software version.

[0093] In order to improve the reliability of consensus verification, in an exemplary embodiment, the hybrid cloud platform software version release method further includes S420 to S460. Among them:

[0094] S420: When receiving a network access request, extract an identity of a node sending the request carried in the network access request.

[0095] S440, based on the identity identifier, verify the legitimacy of the identity of the node sending the request.

[0096] S460, when it is determined that the identity of the request sending node is legal, the request sending node is added to the blockchain network.

[0097] The network access request is used to represent a request to join the blockchain network. The request sending node refers to the node that sends the network access request.

[0098] In practical applications, a node identity authentication mechanism can be pre-set on the blockchain through a smart contract: when a network access request is received, the identity of the node sending the request is verified. Specifically, when a node wants to join the network, it needs to submit a network access request, which carries the node's identity, such as a public key or digital certificate. The identity of the node sending the request carried in the network access request is extracted.

[0099] After obtaining the identity of the request sending node, the legitimacy of the identity of the request sending node is verified according to the identity. Specifically, the legitimacy of the identity of the request sending node can be verified by verifying whether the signature comes from the request sending node or verifying the validity of the digital certificate according to the public key. After confirming that the signature or digital certificate is valid, the identity of the request sending node is determined to be legal.

[0100] When the identity of the request sending node is determined to be legitimate, the request sending node is added to the blockchain network.

[0101] In this embodiment, the legitimacy of the node identity is verified before the node joins the network, which is beneficial to improving the security and credibility of the software version release process.

[0102] In an exemplary embodiment, the number of the publishing slave nodes is multiple, and the method further includes S500.

[0103] S500, when the distribution master node is unavailable, elect a new distribution master node from multiple distribution slave nodes to take over the tasks executed by the distribution master node.

[0104] The situations where the moderator node is unavailable may include but are not limited to the moderator node not responding within a preset time range, failure occurring, or being attacked by the network resulting in inability to communicate normally.

[0105] In practical applications, the publishing slave node can periodically send heartbeat information to the publishing master node to determine whether the publishing master node is unavailable. In this embodiment, unlike the traditional PBFT, not all nodes participating in the consensus in the blockchain have the probability of becoming the master node through view rotation, but only the master node is selected and replaced from the publishing node. This design enables the system to have the ability to self-repair when the publishing node fails, ensuring the continuity and reliability of the update process, thereby improving the stability and fault tolerance of the system. Specifically, when the publishing master node is unavailable, a new publishing master node candidate can be proposed from multiple publishing slave nodes through the view rotation mechanism of PBFT, and a new publishing master node can be jointly elected through the consensus protocol so that the new publishing master node can take over the tasks performed by the publishing master node.

[0106] The specific process of view rotation includes:

[0107] 1. View proposal: other nodes except the moderator node propose new moderator node candidates according to certain rules and algorithms.

[0108] 2. View election: Nodes jointly elect a new moderator node through a consensus protocol.

[0109] 3. View switching: The newly elected moderator node takes over the original moderator node role and continues to lead the version release process.

[0110] At the same time, these release slave nodes can not only take over the work of the release master nodes to ensure the normal operation of the update, but also participate in the PBFT consensus process, increase the fault tolerance number of deployed nodes, and improve the fault tolerance and availability of the system.

[0111] In this embodiment, on the one hand, when the release master node is unavailable, the release slave node can elect a new release master node to take over the release master node's tasks to continue to lead the consensus verification, thereby improving the continuity and availability of software version releases. On the other hand, the release slave node is also a node that participates in consensus verification, which increases the number of fault-tolerant deployment nodes and improves the fault-tolerance and availability of the software version release process.

[0112] In an exemplary embodiment, a permission management mechanism is also introduced into the blockchain network. Specifically, the blockchain includes a smart contract for managing node permissions (referred to as the permission management smart contract), which contains the rules and logic for permission configuration. Nodes can send requests to the smart contract to apply for permissions for specific operations. The smart contract verifies the request according to pre-set rules, and grants or refuses to grant the corresponding permissions to the node based on the verification results. In addition, the smart contract records logs of all permission management events, including permission applications, approval results, permission changes, etc. These log records cannot be tampered with on the blockchain, which can provide transparency and traceability.

[0113] In addition, an access control list can be established, which defines the scope of authority and operation authority of different types of nodes. The access control list is dynamically managed by the authority management smart contract, and its scope of authority and operation authority are dynamically adjusted according to the identity and role of the node. If a node abuses its authority or its authority changes, the smart contract can provide a permission revocation function to cancel the node's authority or limit its scope of authority.

[0114] In one embodiment, the blockchain network also includes multiple approval nodes. When a node submits an application for permission, it needs to go through an approval process. Specifically, the approval process may include the approval of multiple nodes, or be responsible for a specific approval node. Nodes with approval capabilities can be customized according to actual needs. The purpose of the approval process is to ensure the rationality and security of permissions. For example, the approval node can verify whether the node initiating the application is qualified for the specific permission applied for, so as to ensure the rationality of the permission application.

[0115] In this embodiment, through the permission management mechanism based on blockchain, it is ensured that only authorized nodes can participate in the decision-making and execution of version release, thereby enhancing the security and credibility of the entire release process. It is conducive to protecting sensitive data and key information in the version release process, ensuring compliance with relevant security and compliance standards, and improving users' trust and satisfaction with the version release process.

[0116] The main purpose of the above hybrid cloud platform software version release method is to solve the technical problems such as security, credibility and transparency existing in the traditional version release process, and achieve the following technical effects:

[0117] 1. Enhanced security: The traditional software version release process may be at risk of being tampered with or forged, causing security threats to the company's systems and data. Blockchain technology, through its tamper-proof characteristics, can ensure the integrity and authenticity of the software version and prevent unauthorized tampering and malicious attacks.

[0118] 2. Traceability: Blockchain technology can record every key step and operation in the software version release process, including version creation, verification, approval and release, etc. It enables enterprises to trace the source and historical changes of each version, so as to better manage the version release process and troubleshoot problems.

[0119] 3. Improved transparency: Blockchain technology provides decentralized data storage and consensus mechanisms, ensuring the transparency and fairness of the version release process. All nodes participating in the version release can view and verify the data on the blockchain, thereby enhancing the transparency and credibility of the version release process.

[0120] 4. Smart contract automation: Smart contracts on the blockchain can programmatically execute pre-defined rules and logic to achieve automated version verification, authorized access, deployment and other functions. Through smart contracts, enterprises can simplify the version release process, improve efficiency, and reduce human errors and delays.

[0121] 5. Decentralized consensus: The consensus mechanism in the blockchain network ensures the consistency and security of all nodes in the network, without the risk of single point failure and single point control. Through the consensus mechanism of the blockchain, it can be ensured that the release and verification of the software version are jointly participated by multiple nodes, which improves the reliability and robustness of the system.

[0122] In order to make a clearer description of the hybrid cloud platform software version release method provided by this application, the following is combined with a specific embodiment and the attached Figure 5 To illustrate, this specific embodiment includes the following steps:

[0123] S1, the publishing master node receives the version software package to be published sent by the publisher.

[0124] S2: The version master node proposes a software version release proposal for the version software package based on the version software package to be released.

[0125] S3, the release master node sends a pre-preparation message to the release slave node, deployment node and redundant node. The pre-preparation message is used to instruct the release slave node, deployment node and redundant node to verify the validity of the software version release proposal. The redundant nodes include the internal nodes in the development environment, test environment and backup environment.

[0126] S4, receiving the preparation message fed back by the release slave node, deployment node and redundant node. The preparation message is sent when the software version release proposal passes the validity verification.

[0127] S5. When the number of prepared messages received reaches a preset threshold, a submission message is sent to the release slave node, deployment node and redundant node. The submission message is used to instruct the release slave node, deployment node and redundant node to verify the validity of the submission message. The preset threshold is determined based on the number of deployment nodes and redundant nodes.

[0128] S6, receiving confirmation messages fed back from the release slave node, deployment node and redundant node. The confirmation message is sent when the submission message passes the validity verification. When the number of confirmation messages received reaches a preset threshold, the deployment node updates the installed version.

[0129] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0130] In an example embodiment, Figure 6 As shown, a hybrid cloud platform software version release system is provided, including a release master node 120, a release slave node 140, a deployment node 160 and a redundant node 180:

[0131] The publishing master node 120 receives the version software package to be released sent by the publisher, and based on the version software package to be released, proposes a software version release proposal for the version software package, and sends a pre-preparation message to the publishing slave node 140, the deployment node 160 and the redundant node 180. The pre-preparation message is used to instruct the publishing slave node 140, the deployment node 160 and the redundant node 180 to verify the validity of the software version release proposal.

[0132] The release slave node 140, deployment node 160 and redundant node 180 feed back a preparation message to the remaining nodes except themselves. The preparation message is sent when the software version release proposal passes the validity verification.

[0133] When the number of received prepare messages reaches a preset threshold, the publishing master node 120 sends a submission message to the publishing slave node 140, the deployment node 160 and the redundant node 180. The submission message is used to instruct the publishing slave node 140, the deployment node 160 and the redundant node 180 to verify the validity of the submission message. The preset threshold is determined based on the number of deployment nodes and redundant nodes.

[0134] The release slave node 140, deployment node 160 and redundant node 180 feed back confirmation messages to the remaining nodes except themselves, and the confirmation messages are sent when the submission message passes the validity verification.

[0135] When the number of received confirmation messages reaches a preset number threshold, the deployment node 160 updates the installed version.

[0136] Among them, the specific version release process refers to the content in the above-mentioned hybrid cloud platform software version release method embodiment, which will not be repeated here.

[0137] In the above-mentioned hybrid cloud platform software version release system, on the one hand, blockchain technology is introduced in combination with the characteristics of the hybrid cloud environment. Due to the tamper-proof nature of the blockchain, the integrity and authenticity of the software version can be guaranteed, unauthorized tampering and malicious attacks can be prevented, and the source and historical changes of each version can be traced, so as to better manage the version release process and troubleshoot problems. Moreover, the nodes participating in the version release can view and verify the data on the blockchain, thereby enhancing the transparency and credibility of the version release process. In addition, the version release process can be simplified, the interoperability and consistency between different cloud platforms in the hybrid cloud environment are enhanced, and the complexity and risk of version management are reduced. On the other hand, by redesigning the consensus process and the role node function, a controllable redundant node is introduced as one of the nodes participating in the consensus verification of the hybrid cloud platform software version, and the number of consensus nodes is expanded, which can improve the fault tolerance and stability of the consensus process, and also provide backup support for disaster recovery during the version release process, which is conducive to improving the reliability and continuity of software version release.

[0138] In an exemplary embodiment, Figure 7 As shown, a hybrid cloud platform software version publishing device 600 is provided, including: a version receiving module 610, a proposal generating module 620 and a consensus module 630, wherein:

[0139] The version receiving module 610 is used to receive the version software package to be released sent by the publisher.

[0140] The proposal generation module 620 is used to propose a software version release proposal for the version software package based on the version software package to be released.

[0141] The consensus module 630 is used to notify the release slave node, deployment node and redundant node to perform consensus verification on the software version release proposal so that the deployment node can update the installed version.

[0142] In an exemplary embodiment, the consensus module 630 is also used to send a pre-preparation message to the release slave node, deployment node and redundant node, the pre-preparation message is used to instruct the release slave node, deployment node and redundant node to verify the validity of the software version release proposal; receive the preparation message fed back by the release slave node, deployment node and redundant node, the preparation message is sent when the software version release proposal passes the validity verification; when the number of preparation messages received reaches a preset number threshold, send a submission message to the release slave node, deployment node and redundant node, the submission message is used to instruct the release slave node, deployment node and redundant node to verify the validity of the submission message; receive confirmation messages fed back by the release slave node, deployment node and redundant node, the confirmation message is sent when the submission message passes the validity verification; when the number of confirmation messages received reaches a preset number threshold, the deployment node updates the installed version.

[0143] In an exemplary embodiment, the hybrid cloud platform software version publishing device 600 also includes a network access verification module 640, which is used to extract the identity of the request sending node carried in the network access request when a network access request is received; based on the identity, verify the legitimacy of the identity of the request sending node; when it is determined that the identity of the request sending node is legitimate, add the request sending node to the blockchain network.

[0144] In an exemplary embodiment, the hybrid cloud platform software version publishing device 600 also includes a takeover module 650, which is also used to select a new release master node from multiple release slave nodes to take over the tasks performed by the release master node when the release master node is unavailable.

[0145] In an exemplary embodiment, the hybrid cloud platform software version publishing device 600 further includes a rights management module 660 for managing the rights of nodes in the network according to a rights management mechanism.

[0146] Each module in the hybrid cloud platform software version release device 600 can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0147] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 8As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a hybrid cloud platform software version publishing method is implemented.

[0148] Those skilled in the art will understand that Figure 8 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0149] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the steps in any one of the above-mentioned hybrid cloud platform software version release method embodiments are implemented.

[0150] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in any one of the above-mentioned hybrid cloud platform software version release method embodiments are implemented.

[0151] In one embodiment, a computer program product is provided, including a computer program, which, when executed by a processor, implements the steps in any one of the above-mentioned hybrid cloud platform software version release method embodiments.

[0152] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0153] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0154] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0155] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A hybrid cloud platform software version release method, characterized in that: Applied to a blockchain network, the blockchain network includes a release node, a deployment node, and a redundant node, the release node includes a release master node and a release slave node; the method includes: The publishing master node receives the version software package to be published sent by the publisher; The version master node proposes a software version release proposal for the version software package based on the version software package to be released; The release master node notifies the release slave node, the deployment node and the redundant node to perform consensus verification on the software version release proposal, so that the deployment node updates the installed version.

2. The method according to claim 1, characterized in that The release master node notifies the release slave node, the deployment node, and the redundant node to perform consensus verification on the software version release proposal, so that the deployment node updates the installed version, including: The release master node sends a pre-preparation message to the release slave node, the deployment node and the redundant node, wherein the pre-preparation message is used to instruct the release slave node, the deployment node and the redundant node to verify the validity of the software version release proposal; Receive preparation messages fed back by the release slave node, the deployment node, and the redundant node, wherein the preparation messages are sent when the software version release proposal passes the validity verification; When the number of the received preparation messages reaches a preset number threshold, sending a submission message to the release slave node, the deployment node and the redundant node, wherein the submission message is used to instruct the release slave node, the deployment node and the redundant node to verify the validity of the submission message; Receive confirmation messages fed back by the release slave node, the deployment node, and the redundant node, wherein the confirmation messages are sent when the submission message passes the validity verification; When the number of received confirmation messages reaches the preset number threshold, the deployment node updates the installed version.

3. The method according to claim 1, characterized in that The redundant nodes include internal nodes in a development environment, a test environment and a standby environment.

4. The method according to claim 2, characterized in that: The preset quantity threshold is determined based on the total quantity of the publishing master node, the publishing slave node, the deployment node and the redundant node.

5. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: When receiving a network access request, extracting an identity of a node sending the request carried in the network access request; Based on the identity identifier, verify the legitimacy of the identity of the request sending node; When it is determined that the identity of the request sending node is legal, the request sending node is added to the blockchain network.

6. The method according to any one of claims 1 to 3, characterized in that: The number of the version issuing slave nodes is multiple, and the method further includes: In the case that the distribution master node is unavailable, a new distribution master node is elected from the plurality of distribution slave nodes to take over the tasks performed by the distribution master node.

7. A hybrid cloud platform software version release system, characterized in that: Applied to the blockchain network, the system includes a master node, a slave node, a deployment node, and a redundant node: The release master node receives the version software package to be released sent by the release party, proposes a software version release proposal for the version software package based on the version software package to be released, and sends a pre-preparation message to the release slave node, the deployment node and the redundant node, wherein the pre-preparation message is used to instruct the release slave node, the deployment node and the redundant node to verify the validity of the software version release proposal; The release slave node, the deployment node, and the redundant node feed back a preparation message to the remaining nodes except themselves, and the preparation message is sent when the software version release proposal passes the validity verification; When the number of received preparation messages reaches a preset number threshold, the release master node sends a submission message to the release slave node, the deployment node and the redundant node, and the submission message is used to instruct the release slave node, the deployment node and the redundant node to verify the validity of the submission message; The release slave node, the deployment node and the redundant node feed back a confirmation message to the remaining nodes except themselves, and the confirmation message is sent when the submission message passes the validity verification; When the number of received confirmation messages reaches the preset number threshold, the deployment node updates the installed version.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images