具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个所述特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在本申请中，“示例性”一词用来表示“用作例子、例证或说明”。本申请中被描述为“示例性”的任何实施例不一定被解释为比其它实施例更优选或更具优势。为了使本领域任何技术人员能够实现和使用本申请，给出了以下描述。在以下描述中，为了解释的目的而列出了细节。应当明白的是，本领域普通技术人员可以认识到，在不使用这些特定细节的情况下也可以实现本申请。在其它实例中，不会对公知的结构和过程进行详细阐述，以避免不必要的细节使本申请的描述变得晦涩。因此，本申请并非旨在限于所示的实施例，而是与符合本申请所公开的原理和特征的最广范围相一致。

本申请提供了一种peer节点指令传输的方法、装置、代理服务器及存储介质，以下分别进行说明。

下面首先对本申请实施例中涉及到的一些基本概念进行介绍：

链码：chaincode简称链码，一般是用户使用go语言编写的应用代码。链码被部署在Fabric(Fabric一个由模块化架构支撑的分布式账本解决方案平台，提供高度的保密性、弹性、灵活性和伸缩性。它被设计支持不同组件的插拔，并且适应经济生态系统的复杂性)网络节点上，运行在Docker容器(一种虚拟系统，共享操作系统核心，占用资源少，启动速度快)中，并通过gRPC协议(在很多Remote Procedure Call Protocol系统里，gRPC是基于定义一个服务，指定一个可以远程调用的带有参数和返回类型的方法)与相应的peer节点(peer节点是一个物理的概念，一台服务器可以充当peer的作用，这台服务器既可以是私有物理机，也可以是云上的资源，peer是整个Fabric体系的基础设施)进行交互，以操作分布式账本中的数据。

请参阅图1，图1为本申请实施例所提供的peer节点指令传输的方法的场景示意图，该peer节点指令传输的系统可以包括服务器10和代理服务器20，服务器10和代理服务器20通信连接，服务器10可以向代理服务器20传输数据，代理服务器20也可以向服务器10传输数据，如图1中的服务器10，可以根据获得的实时数据传输给代理服务器20；代理服务器20可以计算得到peer节点指令传输的方案，然后将peer节点指令传输的方案传输给服务器10。

本申请实施例中，服务器10其包括但不限于独立的服务器，也可以是服务器组成的服务器网络或服务器集群等，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云服务器。其中，云服务器由基于云计算(CloudComputing)的大量计算机或网络服务器构成。

本申请实施例中，上述代理服务器20同样可以是独立的服务器，也可以是服务器组成的服务器网络或服务器集群，例如，本申请实施例中所描述的peer节点指令传输的装置，同样的其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云服务器。其中，云服务器由基于云计算(Cloud Computing)的大量计算机或网络服务器构成。

本申请的实施例中，服务器10和代理服务器20之间可通过任何通信方式实现通信，包括但不限于，基于第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)、长期演进(Long Term Evolution，LTE)、全球互通微波访问(WorldwideInteroperability for Microwave Access，WiMAX)的移动通信，或基于TCP/IP协议族(TCP/IP Protocol Suite，TCP/IP)、用户数据报协议(User Datagram Protocol，UDP)的计算机网络通信等。

本领域技术人员可以理解，图1中示出的应用环境，仅仅是与本申请方案一种应用场景，并不构成对本申请方案应用场景的限定，其他的应用环境还可以包括比图1中所示更多或更少的终端设备和后台设备，例如图1中仅示出1个终端设备或后台设备，该peer节点指令传输的系统还可以包括一个或多个可处理数据的其他服务器和代理服务器，具体此处不作限定。

另外，如图1所示，该peer节点指令传输的系统还可以包括存终端设备30，所述终端设备30可以是台式机、便携式电脑、网络服务器、掌上电脑(Personal DigitalAssistant，PDA)、移动手机、平板电脑、无线终端设备、通信设备、嵌入式设备等。所述终端设备30与所述代理服务器20的连接方式包括但不限于，基于第三代合作伙伴计划(3rdGeneration Partnership Project，3GPP)、长期演进(Long Term Evolution，LTE)、全球互通微波访问(Worldwide Interoperability for Microwave Access，WiMAX)的移动通信，或基于TCP/IP协议族(TCP/IP Protocol Suite，TCP/IP)、用户数据报协议(User DatagramProtocol，UDP)的计算机网络通信等。所述终端设备30，可以用于发送数据指令至代理服务器20，如创建、启动、停止、升级链码容器生命周期指令。

需要说明的是，图1所示的peer节点指令传输的系统的场景示意图仅仅是一个示例，本申请实施例描述的peer节点指令传输的系统以及场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着peer节点指令传输的系统的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

如图2所示，图2为本申请实施例中peer节点指令传输的方法，应用于链码系统，所述链码系统包括代理服务器，多个docker服务器和多个peer节点，所述多个docker服务器与所述多个peer节点网络连接，所述方法应用于代理服务器，所述方法可以包括如下步骤201～205：

201、获取至少一个peer节点发送的链码容器生命周期指令。

所述peer节点由于前文已经介绍，此处便不再赘述。当不同的peer节点生成的不同的链码容器生命周期指令时，例如：创建、启动、停止、升级链码容器生命周期指令时，需要相应的服务器执行。通常在复杂的网络情况中，节点的指令发送至服务器执行时，通常会通过代理服务器，代理服务器可以避开网络中复杂的情况，有助于提升传输速度。

202、判断所述多个docker服务器中的第一docker服务器是否宕机。

当peer节点与docker服务器直连时，若docker服务器宕机，docker服务器上相应的链码容器便不能使用。因此，为了避免这种情况发生，需要docker服务器一直不宕机，但总会有意外情况导致docker服务器出现不可用的时候，所以本申请的目的是为了链码容器能一直运行。因此，当docker服务器出现宕机时，若有其他可用的docker服务器，可以使得链码容器迁移至可用的docker服务器，从而使得链码容器可以根据链码容器生命周期指令进行相应的工作。

因此，为了避免将所述链码容器生命周期指令发送至宕机的docker服务器，在代理服务器获取到各个peer节点发送的链码容器生命周期指令后，为了使得这些链码容器生命周期指令能够顺利的执行，因此需要判断当前的docker服务器是否出现宕机，若处于宕机情况下，链码容器便无法执行相应的指令。本步骤设计了多个docker服务器，目的是为了避免一个docker服务器出现宕机的情况时，能够将链码容器迁移至其他的docker服务器，以执行这些链码容器生命周期指令。

需要说明的是，所述第一docker服务器可以是所述多个docker服务器中的任意一个服务器，也可以是所述多个docker服务器中，优先度第一的服务器，例如：传输延迟最低的服务器，具体此处不做限定。

在本申请一些实施例中，所述判断所述多个docker服务器中的第一docker服务器是否宕机，包括：

按照预设周期获取所述第一docker服务器发送的用于通讯的数据包。

为了能够实现更好的实现判断的准确性，本申请实施例可以在代理服务器与所述第一docker服务器之间，建立一种特殊的通讯机制，正常服务器之间的传输功能，通过预设周期内，传送的自定义的数据包，来证明所述第一docker服务器“在线”，若所述第一docker服务器“在线”。

示例性的，所述预设周期可以为3秒，所述数据包可以为任意一种数据，例如“00001111”，此时可以设定为所述第一docker服务器，每3秒钟向代理服务器传送2次数据为“00001111”的数据包。

根据上文的描述，若所述第一docker服务器能够发送数据包至代理服务器，此时代理服务器便能根据是否接收到数据包，来判断所述第一docker服务器是否出现宕机情况，此时便会出现两种情况：

示例性的，若依旧采用上述中的例子，此时若代理服务器每3秒能够获取到所述第一docker服务器发送的2次，数据为“00001111”的数据包，此时便可以判断所述第一docker服务器工作正常，未宕机。

(1)若获取到所述第一docker服务器发送的数据包，确定所述第一docker服务器未宕机。

示例性的，若依旧采用上述中的例子，此时若代理服务器每3秒能够获取到所述第一docker服务器发送的2次，数据为“00001111”的数据包，此时便可以判断所述第一docker服务器工作正常。

(2)若未获取到所述第一docker服务器发送的数据包，确定所述第一docker服务器宕机。

示例性的，若依旧采用上述中的例子，此时若代理服务器没有每3秒能够获取到所述第一docker服务器发送的2次，数据为“00001111”的数据包，或间歇性的获取每3秒能够获取到所述第一docker服务器发送的2次，数据为“00001111”的数据包，此时便可以判断所述第一docker服务器工作不正常，处于宕机情况，或者将要宕机的情况。

本申请实施例的目的是为了避免将所述链码容器生命周期指令发送至所述第一docker服务器时，传输失败的问题。

203、若所述第一docker服务器未宕机，转送所述链码容器生命周期指令至所述第一docker服务器。

由于docker服务器的宕机会使得链码容器同样无法使用，将所述链码容器生命周期指令转至一个未宕机的docker服务器是为了实现链码容器的迁移，由于上述步骤202已经说明，此处便不再赘述。

根据上述实施例的描述，若已经可以判断出所述第一docker服务器未宕机时，直接将所述链码容器生命周期指令转送给所述第一docker服务器，通过所述第一docker服务器执行链码容器生命周期指令来控制链码的生命周期，具体此处不再赘述。

204、若所述第一docker服务器宕机，判断所述多个docker服务器中除所述第一docker服务器之外的其他docker服务器是否宕机。

若根据上述实施例的描述，若所述第一docker服务器宕机，此时所述第一docker服务器无法正常执行所述链码容器生命周期指令，若此时仍然将所述链码容器生命周期指令转送至所述第一docker服务器时，由于所述第一docker服务器宕机，便无法正常接收到相应的链码容器生命周期指令，此时便会传输失败，为了避免这种传输失败的情况，就需要转送至其他正常工作的docker服务器。

为了避免其他的docker服务器也出现宕机的情况，此时便需要判断其他docker服务器是否出现宕机的情况，避免链码容器生命周期指令仍然会传输失败的情况。

在本申请一些实施例中，所述若所述第一docker服务器宕机，判断所述多个docker服务器中除所述第一docker服务器之外的其他docker服务器是否宕机，包括：

按照预设周期获取所述其他docker服务器发送的用于通讯的数据包。

若未获取到与所述其他docker服务器发送的对应的数据包，确定所述其他docker服务器中未发送对应数据包的docker服务器宕机。

若获取到与所述其他docker服务器发送的对应的数据包，确定所述其他docker服务器均未宕机。

此步骤目的与上述实施例中的目的相同，此处不再赘述。

同样的，为了此处是为了根据不同的docker服务器发送的各个相对应的数据包，确定其他的docker服务器是否出现宕机的情况，上述实施例均有描述，此处不再赘述。

同样的与上述实施例相同的地方此处不再赘述。需要说明的是，可以根据不同的docker服务器发送的数据包，识别不同的docker服务器的身份。

示例性的，例如不同的docker服务器发送的数据包可以包含身份识别信息，例如：docker服务器A发送的数据包A中可以包含身份识别码，例如数据包A可以为“A00001111”，其中第一位A便为身份识别码，此时根据身份识别码，便可以获得数据包A来自docker，以此类推。

但需要说明的是，根据数据包的进行不同docker服务器的身份识别，仅仅是本申请实施例中一种识别方式，当然若直接根据代理服务器与各个docker服务器相连的网络信息，也可以进行识别，例如IP地址等，具体此处不做限定。

根据本实施例中上文的描述，若未获取到docker服务器B发送的数据包B，数据包B可以为“B00001111”，未检测到身份识别位为B的数据包，因此可以判断docker服务器B出现宕机情况，以此类推。

需要说明的是，根据数据包的进行不同docker服务器的身份识别，仅仅是本申请实施例中一种识别方式，当然若直接根据代理服务器与各个docker服务器相连的网络信息，也可以进行识别，例如IP地址等，具体此处不做限定。

为了更好的实施本申请提供的方案，在本申请一些实施例中，所述若未获取到与所述其他docker服务器发送的对应的数据包，确定所述其他docker服务器中未发送对应数据包的docker服务器宕机之后，所述方法还包括：

若重新获取到宕机docker服务器发送的数据包，确定所述宕机服务器恢复正常。

在正常的使用场景下，宕机的docker服务器不会一直处于宕机状态，例如会有工作人员对宕机的docker服务器进行修复，并重新连接网络，此时，之前宕机的docker服务器会按照之前设定的方式，发送相应的数据包至代理服务器，若代理服务器又重新获取到相应的docker服务器发送的相应数据包，便可以确定宕机的docker服务器恢复正常，并可以重新作为执行所述链码容器生命周期指令的执行主体，本实施例的目的是为了避免随着时间的推移，宕机docker服务器越来越多，若宕机的docker服务器无法重新使用，docker服务器越来越少的问题。

205、若所述其他docker服务器中至少有一个docker服务器未宕机，转送所述链码容器生命周期指令至未宕机的服务器中的第一未宕机的docker服务器，以使得所述第一未宕机的docker服务器执行链码容器生命周期指令。

此时在所述第一docker服务器宕机时，其他所述docker服务器中，至少有一个docker服务器未出现宕机情况时，便可以将所述链码容器生命周期指令发送至未宕机的docker服务器。

其中，若所述第一docker服务器出现宕机，但所述其他docker服务器中，有多个docker服务器未出现宕机时，可以将所述链码容器生命周期指令转送至任意一个未出现宕机情况的docker服务器，当然可以将所述链码容器生命周期指令转送至一个未出现宕机情况的docker服务器中，一个优先度最高的docker服务器，例如：所述优先度最高可以为在未宕机的docker服务器中，一个传输速度最高的docker服务器。

本申请实施例提供的peer节点指令传输的方法可以对部署的多个docker服务器保持同步通信，若在所述多个docker服务器中的服务器解决节点发送的指令发生服务器宕机的情况时，可以直接交由其他同步通信的服务器处理，解决了当服务器出现问题时，无法响应节点指令的问题，同时可以在服务器宕机情况解决之前，响应节点的指令，提高了响应效率。

为了更好的理解本方案，此处结合上述部分实施例，做一个总的说明，例如：

1)多个docker服务器中有A、B、C三台可用的docker服务器，docker代理服务将和A、B、C三台docker服务器保持通讯，此时docker代理服务中的可用列表中存在A、B、C。

2)当peer节点收到了启动的操作后，会发起创建并启动链码容器生命周期指令给docker代理服务器。

3)docker代理服务器接收到peer发来的执行指令请求时，从docker服务可用列表中选出第一个，即docker服务器A，并将该执行指令发送给docker服务器A。

4)docker服务器A接收到docker代理服务器的转送的执行指令请求时，执行该指令，最终，链码容器在docker服务器A的主机上运行起来。

5)当docker服务器A宕机后，相应的链码容器也停止，此时docker代理服务器监测到docker服务器A不可用(在预设的周期内，没有收到相应的数据包，没有收到数据包，即意味着所述docker服务器宕机)，便将其从可用列表中移除，此时可用列表中只有docker服务器B、docker服务器C。此时，docker代理服务器将所述执行指令转送至docker服务器B或docker服务器C任意一个服务器即可。

在本申请一些实施方式中，所述方法还包括：

若监测到额外的docker服务器，判断所述额外的docker服务器是否宕机，所述额外的docker服务器为在原有的所述多个docker服务器的基础之上，新增的docker服务器。

在通常的情景下，docker服务器也会存在永久性宕机的问题，例如随着使用时间的增加，docker服务器出现不可逆的损坏，导致报废的情况，本申请实施例的目的是为了防止，随着时间的推移，当越来越多的docker服务器出现永久性宕机的问题时，若没有重新补充的docker服务器时，会出现越来越少的docker服务器执行所述链码容器生命周期指令的问题。

此时当有额外的docker服务器入网时，同样需要对新的docker服务器判断，若新的docker服务器入网时，因为调试等问题还无法正常使用时，依旧无法处理所述链码容器生命周期指令，因此同样对新入网的docker服务器做出判断。具体的，判断所述额外的docker服务器是否宕机与上述实施例相同，此处不再赘述。同样的检测所述额外的docker服务器是否宕机，依然会出现以下两种结果：

(1)若所述额外的docker服务器宕机，确定所述额外的docker服务器不可用。

判断额外的docker服务器不可用的方法与上述实施例相同，此处不再赘述。

(2)若所述额外的docker服务器未宕机，确定所述额外的docker服务器为候选docker服务器，用于所述第一docker服务器宕机时，发送所述链码容器生命周期指令至所述候选docker服务器。

当新入网的额外的docker服务器未出现宕机时，便可以确定新的docker服务器可以用于执行所述链码容器生命周期指令，此时便可以将这些可用的新的docker服务器设定为候选docker服务器，这些候选docker服务器可以被视为所述其他docker服务器中的docker服务器，即若所述第一docker服务器出现宕机时，用于处理所述链码容器生命周期指令。

在本申请一些实施例中，所述若所述第一docker服务器未宕机，转送所述链码容器生命周期指令至所述第一docker服务器，所述方法还包括：

(1)若所述第一docker服务器在执行所述链码容器生命周期指令时宕机，确定传输失败，判断所述多个docker服务器中的其他docker服务器是否宕机。

(2)若所述其他docker服务器中至少有一个docker服务器未宕机，重新转送所述链码容器生命周期指令至第一未宕机的docker服务器。

本申请实施例的目的是为了，在所述第一docker服务器接收到所述链码容器生命周期指令之后，在没有完成相应的链码容器生命周期指令之前，发生宕机的情况。

在通常的环境下，会有极少数情况，服务器在执行相应的指令期间时发生宕机的情况，此时指令无法正常完成，即无法将完成的结果反馈至代理服务器，或者反馈给一个指定终端，为了能够继续执行相应的指令，直至正常完成，本申请实施例可以将调用其他未宕机的服务器继续执行相应的指令，避免出现指令未完全执行的情况。

判断docker服务器未宕机的方法与上述实施例相同，此处不再赘述。

为了更好实施本申请实施例中peer节点指令传输的方法，在peer节点指令传输的方法之上，本申请实施例中还提供一种peer节点指令传输的装置，应用于链码系统，所述链码系统包括代理服务器，多个docker服务器和多个peer节点，所述多个docker服务器与所述多个peer节点网络连接，所述方法应用于代理服务器，如图3所示，所述装置300包括：

获取模块301，用于获取至少一个peer节点发送的链码容器生命周期指令；

第一判断模块302，用于判断所述多个docker服务器中的第一docker服务器是否宕机；

第一转送模块303，用于若所述第一docker服务器未宕机，转送所述链码容器生命周期指令至所述第一docker服务器；

第二判断模块304，用于若所述第一docker服务器宕机，判断所述多个docker服务器中除所述第一docker服务器之外的其他docker服务器是否宕机；

第二转送模块305，用于若所述其他docker服务器中至少有一个docker服务器未宕机，转送所述链码容器生命周期指令至未宕机的服务器中的第一未宕机的docker服务器，以使得所述第一未宕机的docker服务器执行链码容器生命周期指令。

本申请实施例提供的peer节点指令传输的方法可以在所述获取模块301获取链码容器生命周期指令之后，所述第一判断模块302可以判断部署的多个docker服务器是否宕机，若均未宕机时，所述第一转送模块303可以将所述链码容器生命周期指令转送至第一docker服务器，若所述第一docker服务器宕机，第二判断模块304可以继续判断剩余的服务器是否宕机，在剩余的docker服务器中至少还有一个服务器未出现宕机的情况下时，所述第二转送模块305可以将链码容器生命周期指令转送至未宕机的docker服务器，解决了当服务器出现问题时，无法响应节点指令的问题，同时可以在服务器宕机情况解决之前，响应节点的指令，提高了响应效率。

在本申请一些实施方式中，所述第一判断模块302具体用于：

按照预设周期获取所述第一docker服务器发送的用于通讯的数据包；

若获取到所述第一docker服务器发送的数据包，确定所述第一docker服务器未宕机；

若未获取到所述第一docker服务器发送的数据包，确定所述第一docker服务器宕机。

在本申请一些实施方式中，第二判断模块304具体用于：

按照预设周期获取所述其他docker服务器发送的用于通讯的数据包；

若获取到与所述其他docker服务器发送的对应的数据包，确定所述其他docker服务器均未宕机；

若未获取到与所述其他docker服务器发送的对应的数据包，确定所述其他docker服务器中未发送对应数据包的docker服务器宕机。

在本申请一些实施方式中，第二判断模块304具体还用于：

若监测到额外的docker服务器，判断所述额外的docker服务器是否宕机，所述额外的docker服务器为在原有的所述多个docker服务器的基础之上，新增的docker服务器；

若所述额外的docker服务器宕机，确定所述额外的docker服务器不可用；

若所述额外的docker服务器未宕机，确定所述额外的docker服务器为候选docker服务器，用于所述第一docker服务器宕机时，发送所述链码容器生命周期指令至所述候选docker服务器。

在本申请一些实施方式中，第二判断模块304具体还用于：

若所述第一docker服务器在执行所述链码容器生命周期指令时宕机，确定传输失败，判断所述多个docker服务器中的其他docker服务器是否宕机；

若所述其他docker服务器中至少有一个docker服务器未宕机，重新转送所述链码容器生命周期指令至第一未宕机的docker服务器。

另一方面，本申请还提供一种代理服务器，所述代理服务器包括：

一个或多个处理器；

存储器；以及

一个或多个应用程序，其中所述一个或多个应用程序被存储于所述存储器中，并配置为由所述处理器执行以实现任意一项所述的peer节点指令传输的步骤。

本申请实施例还提供一种代理服务器，其集成了本申请实施例所提供的任一种peer节点指令传输的方法，如图4所示，其示出了本申请实施例所涉及的代理服务器的结构示意图，具体来讲：

该代理服务器可以包括一个或者一个以上处理核心的处理器401、一个或一个以上计算机可读存储介质的存储器402、电源403和输入单元404等部件。本领域技术人员可以理解，图4中示出的代理服务器结构并不构成对代理服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器401是该代理服务器的控制中心，利用各种接口和线路连接整个代理服务器的各个部分，通过运行或执行存储在存储器402内的软件程序和/或模块，以及调用存储在存储器402内的数据，执行代理服务器的各种功能和处理数据，从而对代理服务器进行整体监控。可选的，处理器401可包括一个或多个处理核心；处理器401可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，优选的，处理器401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器401中。

存储器402可用于存储软件程序以及模块，处理器401通过运行存储在存储器402的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器402可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据代理服务器的使用所创建的数据等。此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器402还可以包括存储器控制器，以提供处理器401对存储器402的访问。

代理服务器还包括给各个部件供电的电源403，优选的，电源403可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源403还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该代理服务器还可包括输入单元404，该输入单元404可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

尽管未示出，代理服务器还可以包括显示单元等，在此不再赘述。具体在本实施例中，代理服务器中的处理器401会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序，从而实现各种功能，例如：

获取至少一个peer节点发送的链码容器生命周期指令；

判断所述多个docker服务器中的第一docker服务器是否宕机；

若所述第一docker服务器未宕机，转送所述链码容器生命周期指令至所述第一docker服务器直连的链码容器；

若所述第一docker服务器宕机，判断所述多个docker服务器中除所述第一docker服务器之外的其他docker服务器是否宕机；

若所述其他docker服务器中至少有一个docker服务器未宕机，转送所述链码容器生命周期指令至未宕机的服务器中的第一未宕机的docker服务器，以使得所述第一未宕机的docker服务器执行链码容器生命周期指令。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请实施例提供一种计算机可读存储介质，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。其上存储有计算机程序，所述计算机程序被处理器进行加载，以执行本申请实施例所提供的任一种peer节点指令传输的方法中的步骤。例如，所述计算机程序被处理器进行加载可以执行如下步骤：

判断所述多个docker服务器中的第一docker服务器是否宕机；

若所述第一docker服务器未宕机，转送所述链码容器生命周期指令至所述第一docker服务器；

若所述第一docker服务器宕机，判断所述多个docker服务器中除所述第一docker服务器之外的其他docker服务器是否宕机；

若所述其他docker服务器中至少有一个docker服务器未宕机，转送所述链码容器生命周期指令至未宕机的服务器中的第一未宕机的docker服务器，以使得所述第一未宕机的docker服务器执行链码容器生命周期指令。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见上文针对其他实施例的详细描述，此处不再赘述。

具体实施时，以上各个单元或结构可以作为独立的实体来实现，也可以进行任意组合，作为同一或若干个实体来实现，以上各个单元或结构的具体实施可参见前面的方法实施例，在此不再赘述。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的一种peer节点指令传输的方法及装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。