同步可信计算集群的连接状态的方法及装置与流程

本说明书一个或多个实施例涉及计算机技术领域，尤其涉及通过计算机进行可信计算集群与客户端的连接状态同步的方法和装置。

背景技术：

为了计算和数据传输的安全，常常使用可信计算单元构成的可信计算机群进行可信计算和数据处理。其中可信计算集群可以保证其中的代码执行是安全的，操作系统或驱动等都无法获取内部运行时内存的秘密。

现有的可信计算平台中，如果可信计算有代码升级，则需要部署新的可信计算集群。在用新的可信计算集群代替原来的可信计算集群时，若停止原有服务，与新的可信计算集群重新连接，则会导致服务在一定时间段内不可用。如果同时维护多个版本的可信计算集群的连接，则需要客户端用户自己控制版本的切换，即自己管理各个连接状态、各版本之间的流量控制、失败回滚等等问题，对用户自身技能的要求较高，用户体验不友好。

因此，希望能有改进的方案，能够在用新的可信计算集群代替原来的可信计算集群的过程中，能够减少用户参与，实现平滑切换。

技术实现要素：

本说明书一个或多个实施例描述了一种同步可信计算集群的连接状态的方法和装置，利用心跳包在客户端和集群管理器之间同步可信计算集群的连接状态，从而逐步将客户端与可信计算集群的连接从旧版本平滑过渡到新版本，提高可信计算服务的有效性。

根据第一方面，提供了一种同步可信计算集群的连接状态的方法，所述方法通过集群管理器执行，用于客户端与集群管理器管理的多个可信计算集群进行连接状态的同步，所述方法包括：

接收所述客户端按照预定时间间隔发送的心跳包，所述心跳包用于描述所述客户端与所述多个可信计算集群的当前连接状态，并包括当前通道列表和当前分流策略，所述当前通道列表提供所述客户端当前维持的、与所述多个可信计算集群中至少一个可信计算集群之间的可信通道，所述当前分流策略用于描述所述客户端当前在各个可信通道上分配的流量份额；

根据在线可信计算集群的集群信息，确定可用集群列表，并针对所述当前通道列表提供的各个可信通道确定建议分流策略；

向所述客户端发送反馈包，其中包括所述可用集群列表和所述建议分流策略，以供所述客户端根据所述反馈包更新所述当前连接状态。

在一个实施例中，所述多个可信计算集群包括第一集群和第二集群；

所述接收所述客户端按照预定时间间隔发送的心跳包包括，接收第一心跳包，所述第一心跳包中，当前通道列表至少提供所述客户端与所述第一集群预先建立的第一可信通道，当前分流策略包括，所述客户端在所述第一可信通道上分配的第一流量份额；

所述根据在线可信计算集群的集群信息，确定可用集群列表包括：在确定所述第二集群上线的情况下，在所述可用集群列表中添加所述第二集群形成第一可用集群列表；

所述向所述客户端发送反馈包包括，向所述客户端发送第一反馈包，所述第一反馈包中的当前可用集群列表为所述第一可用集群列表，建议分流策略包括为所述第一可信通道分配所述第一流量份额，以供所述客户端在预先配置有所述第二集群的验证信息的情况下，建立与所述第二集群连接的第二可信通道。

在另一个实施例中，所述多个可信计算集群包括第一集群和第二集群；

所述接收所述客户端按照预定时间间隔发送的心跳包包括，接收第二心跳包，所述第二心跳包中，当前通道列表提供所述客户端与所述第一集群预先建立的第一可信通道，以及所述客户端与所述第二集群预先建立的第二可信通道，当前分流策略至少包括，所述客户端在所述第一可信通道上分配的第一流量份额；

所述针对所述当前通道列表提供的各个可信通道确定建议分流策略包括：按照预定规则，根据所述第一流量份额向所述第二可信通道转移第一份额后各个可信通道的流量份额，确定第一建议分流策略；

所述向所述客户端发送反馈包包括，向所述客户端发送第二反馈包，所述第二反馈包中的建议分流策略为所述第一建议分流策略，以供所述客户端基于所述第一建议分流策略更新为各个可信通道分配的流量份额。

在进一步的实施例中，所述预定规则包括以下至少一项：所述第一份额；所述第一流量份额转移出所述第一份额后剩余的流量份额；所述第二可信通道增加所述第一份额后的第二流量份额。

在另一个实施例中，所述接收所述客户端按照预定时间间隔发送的心跳包包括：接收第三心跳包，所述第三心跳包中，当前通道列表提供所述第一可信通道和所述第二可信通道，当前分流策略包括所述客户端在所述第二可信通道上分配的第二流量份额；

所述根据在线可信计算集群的集群信息，确定可用集群列表之前，所述方法还包括：

响应于基于所述第三心跳包确定所述第一可信通道的流量份额完全转移到所述第二可信通道，下线所述第一集群。

在进一步的实施例中，所述向所述客户端发送反馈包包括：

向所述客户端发送第三反馈包，所述第三反馈包中的可用集群列表提供所述第二集群，建议分流策略包括所述客户端在所述第二可信通道上分配的第二流量份额，以供所述客户端在接收到所述第三反馈包后，删除所述第一可信通道。

在一个实施例中，所述可信计算集群包括多个可信计算单元，用于所述客户端的分布式可信计算。

在一个实施例中，所述可信计算单元为围圈Enclave。

根据第二方面，提供一种同步可信计算集群的连接状态的方法，所述方法通过客户端执行，用于所述客户端与集群服务器管理的多个可信计算集群进行连接状态的同步，所述方法包括：

按照预定时间间隔向集群服务器发送心跳包，所述心跳包用于描述所述客户端与所述多个可信计算集群的当前连接状态，并包括当前通道列表和当前分流策略，所述当前通道列表提供所述客户端当前维持的、与所述多个可信计算集群中至少一个可信计算集群之间的可信通道，所述当前分流策略用于描述所述客户端当前在各个可信通道上分配的流量份额；

接收所述集群管理器基于所述心跳包返回的反馈包，所述反馈包用于反馈根据在线可信计算集群的集群信息确定的可用集群列表，以及针对当前通道列表提供的各个可信通道确定的建议分流策略；

根据所述反馈包更新所述当前连接状态。

根据一个实施例，所述多个可信计算集群包括第一集群和第二集群，其中，所述第二集群用于取代所述第一集群；

所述按照预定时间间隔向集群服务器发送心跳包包括，发送第一心跳包，所述第一心跳包中，当前通道列表至少提供，所述客户端与所述第一集群预先建立的第一可信通道，当前分流策略包括，所述客户端在所述第一可信通道上分配的第一流量份额；

所述接收所述集群管理器基于所述心跳包返回的反馈包包括，接收第一反馈包，所述第一反馈包中的当前可用集群列表为，在确定所述第二集群上线的情况下，增加所述第二集群形成的第一可用集群列表；

所述根据所述反馈包更新所述当前连接状态包括：检测是否已配置所述第二集群的验证信息；

若已配置所述第二集群的验证信息，建立与所述第二集群进行连接的第二可信通道。

在进一步的实施例中，所述建立与所述第二集群进行连接的第二可信通道包括：

向所述第二集群发送建立所述第二可信通道的连接请求，以供所述第二集群基于所述连接请求反馈连接信息；

将所述连接信息与所述验证信息进行比较，并在比较结果为一致的情况下，建立所述第二可信通道。

根据另一个实施例，所述多个可信计算集群包括第一集群和第二集群；

所述按照预定时间间隔向集群服务器发送心跳包包括，发送第二心跳包，所述第二心跳包中，当前通道列表提供所述客户端与所述第一集群预先建立的第一可信通道，以及所述客户端与所述第二集群预先建立的第二可信通道，当前分流策略至少包括，所述客户端在所述第一可信通道上分配的第一流量份额；

所述接收所述集群管理器基于所述心跳包返回的反馈包包括，接收第二反馈包，所述第二反馈包中的建议分流策略为，所述集群管理器按照预定规则，根据所述第一流量份额向所述第二可信通道转移第一份额后各个可信通道的流量份额，确定的第一建议分流策略；

所述根据所述反馈包更新所述当前连接状态包括：按照所述第一建议分流策略更新为各个可信通道分配流量份额。

根据又一个实施例，所述按照预定时间间隔向集群服务器发送心跳包包括，发送第三心跳包，所述第三心跳包中，当前通道列表提供所述第一可信通道和所述第二可信通道，当前分流策略包括所述客户端在所述第二可信通道上分配的第二流量份额；

所述接收所述集群管理器基于所述心跳包返回的反馈包包括，接收第三反馈包，所述第三反馈包中，可用集群列表是所述集群管理器在所述第一集群下线的情况下确定的，提供所述第二集群，建议分流策略包括所述客户端在所述第二可信通道上分配的第二流量份额；

所述根据所述反馈包更新所述当前连接状态包括：根据所述第三反馈包中的可用集群列表，删除所述第一可信通道。

根据一种可能的设计，在根据所述反馈包更新所述当前连接状态之后，所述方法还包括：

检测客户端的软件开发工具包是否存在异常；

在存在异常的情况下，提供异常警报。

根据第三方面，提供一种同步可信计算集群的连接状态的装置，所述装置适用于集群管理器，用于客户端与集群管理器管理的多个可信计算集群进行连接状态的同步，所述装置包括：

接收单元，配置为接收所述客户端按照预定时间间隔发送的心跳包，所述心跳包用于描述所述客户端与所述多个可信计算集群的当前连接状态，并包括当前通道列表和当前分流策略，所述当前通道列表提供所述客户端当前维持的、与所述多个可信计算集群中至少一个可信计算集群之间的可信通道，所述当前分流策略用于描述所述客户端当前在各个可信通道上分配的流量份额；

确定单元，配置为根据在线可信计算集群的集群信息，确定可用集群列表，并针对所述当前通道列表提供的各个可信通道确定建议分流策略；

发送单元，配置为向所述客户端发送反馈包，其中包括所述可用集群列表和所述建议分流策略，以供所述客户端根据所述反馈包更新所述当前连接状态。

根据第四方面，提供一种同步可信计算集群的连接状态的装置，所述装置适用于客户端，用于所述客户端与集群服务器管理的多个可信计算集群进行连接状态的同步，所述装置包括：

发送单元，配置为按照预定时间间隔向集群服务器发送心跳包，所述心跳包用于描述所述客户端与所述多个可信计算集群的当前连接状态，并包括当前通道列表和当前分流策略，所述当前通道列表提供所述客户端当前维持的、与所述多个可信计算集群中至少一个可信计算集群之间的可信通道，所述当前分流策略用于描述所述客户端当前在各个可信通道上分配的流量份额；

接收单元，配置为接收所述集群管理器基于所述心跳包返回的反馈包，所述反馈包用于反馈根据在线可信计算集群的集群信息确定的可用集群列表，以及针对当前通道列表提供的各个可信通道确定的建议分流策略；

更新单元，配置为根据所述反馈包更新所述当前连接状态。

根据第五方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面或第二方面的方法。

根据第六方面，提供了一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面或第二方面的方法。

通过本说明书实施例提供的同步可信计算集群的连接状态的方法和装置，用于客户端与集群管理器管理的多个可信计算集群进行连接状态的同步。一方面，通过客户端按照预定时间间隔向集群管理器发送的心跳包，将客户端与多个可信计算集群的当前连接状态汇报给集群管理器。另一方面，集群管理器接收到心跳包后，根据在线可信计算集群的集群信息，确定可用集群列表，并针对所述当前通道列表提供的各个可信通道确定建议分流策略，并将可用集群列表和建议分流策略通过反馈包发送给客户端，以供客户端根据情况更新与多个可信计算集群的当前连接状态。如此，可以实现客户端与集群管理器的连接信息同步，从而在集群管理器所管理的可信计算集群有变化时，客户端及时采取相应策略，提高可信计算服务的有效性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1示出本说明书实施例的实施架构示意图；

图2示出根据一个实施例的同步可信计算集群的连接状态的方法的一个交互周期的时序图；

图3示出根据一个实施例的客户端执行的同步可信计算集群的连接状态的方法的流程图；

图4示出根据一个实施例的集群管理器执行的同步可信计算集群的连接状态的方法的流程图；

图5a-图5f示出根据多个实施例的同步可信计算集群的连接状态的不同周期的示意图；

图6示出根据一个实施例的客户端执行的同步可信计算集群的连接状态的装置的示意性框图；

图7示出根据一个实施例的集群管理器执行的同步可信计算集群的连接状态的装置的示意性框图。

具体实施方式

下面结合附图，对本说明书提供的方案进行描述。

图1是本说明书实施例的一个实施架构示意图。在该实施架构中，集群管理器可以管理一个或多个可信计算集群，例如图1中的第一集群、第二集群，等等。每个可信计算集群可以包括多个可信计算单元。其中，可信计算单元可以是具有一定隔离能力从而可以保证计算安全性的计算模块或计算设备，例如是可信的计算容器围圈(enclave，内存中受保护的可信执行区域)。通过把客户端的执行代码分布在可信计算集群的各个可信计算单元中执行，可以保证客户端的执行代码运行的安全性。值得说明的是，这里的客户端，是相对集群管理器而言的。实际上，这里说的客户端，也可能是为某些终端应用或网站提供支持的应用服务器，而客户端的执行代码，可能用于为这些终端应用或网站提供相应服务。在一些实现中，对于安全等级要求非常高的计算服务，例如征信数据、身份信息等隐私数据的存储和查询服务等，可以通过可信计算集群实现。

如果客户端的执行代码需要升级，则需要将升级的执行代码分布在可信计算集群的各个可信计算单元中，形成新的可信计算集群，来代替原执行代码分布的可信计算集群。进一步地，通过客户端和分布有升级的执行代码的可信计算集群(如第二集群)的连接，来代替和分布有原执行代码的可信计算集群(如第一集群)的连接，可以实现执行代码的升级。可以理解，为了保障数据的安全，客户端和可信计算集群的连接，需要通过专用的可信通道来进行。例如在一个实施例中，可信通道的建立过程可以是：客户端向可信计算集群发送建立可信通道的请求，可信计算集群根据收到的请求向客户端反馈验证信息(如数字签名)，客户端根据预先存储的可信计算集群的标识信息对该验证信息进行校验，如果校验通过，则建立可信通道成功。进一步地，在客户端与建立可信通道的可信计算集群之间进行通信时，可以在所发送的信息中加入前述标识信息或验证信息，从而仅供相应可信计算集群识别出相应信息。

值得说明的是，可信通道是比较形象的说法，是为了描述的方便，并不意味着客户端和计算机群之间必须有物理通道。虽然图1中以虚线示出了第一可信通道和第二可信通道，然而这只是为了示意。实际上，各个可信通道并不一定通过两条不同的线路进行区分。在具体实施例中，可信通道也可以只是在与集群管理器通信过程中，在所发送的信息中通过相应可信计算集群的标识、数字签名等，以供集群管理器只能将相应信息转发给相应可信计算集群，或者只能由相应可信计算集群解密信息，在此不做限定。

通过以上描述可知，在客户端与可信计算集群之间建立可信通道连接需要时间。也就是说，如果断开与第一集群的连接，并建立与第二集群的连接，在该过程中，需要一定时间(如十几秒)，而在该“一定时间”内，会导致执行代码不可用。如果在某个时间段内，客户端同时与第一集群和第二集群进行连接，并由客户端用户控制连接通道的流量分配，对用户形成较高要求。

基于以上问题，图1示出的实施架构中，本说明书实施例提供通过心跳包个反馈包进行可信计算集群的连接状态同步的设计思路。也就是说，至少在通过升级的可信计算集群(如第二集群)代替原可信计算集群(如第一集群)的过程中，通过客户端按照预定时间间隔向集群管理器发送心跳包，反馈客户端与各个可信计算集群的连接状态，并由集群管理器向客户端发送反馈包，反馈可信计算集群的状态。

下面通过图2说明客户端和集群管理器之间的一个交互周期。在该心跳周期内，客户端首先向集群管理器发送心跳包，心跳包用于描述所述客户端与多个可信计算集群的当前连接状态。心跳包中可以包括能够提供客户端当前维持的所有可信通道的当前通道列表，以及客户端当前在各个可信通道上的当前分流策略。当客户端只维持一个可信通道时，该当前分流策略可以是将百分之百的流量分配在该可信通道上。接着，集群管理器基于上述心跳包，根据在线可信计算集群的集群信息，确定可用集群列表，并针对当前通道列表提供的各个可信通道确定建议分流策略。集群管理器向客户端发送的反馈包中，可以包括提供当前在线的可用集群的可用集群列表，以及向客户端提供的建议分流策略。之后，客户端接收到反馈包，可以检测连接信息是否需要改变，并根据检测结果进行后续操作。一方面，客户端可以检测建议分流策略与当前分流策略是否一致，如果不一致，则更新本地分流策略，否则，不作处理。另一方面，客户端可以检测可用集群列表中的可用计算集群是否改变，如增加或减少，若改变，对应增加或删除相应可信通道，否则，不作处理。

如此，通过心跳包和反馈包的交互，可以实现客户端与集群管理器所管理的至少一个可信计算集群之间集群信息、通道信息、流量分配等等连接状态的同步，从而通过流量份额的转移控制可信计算集群的切换，实现在可信计算集群中分布的执行代码的平滑升级。

下面分别从客户端和集群管理器的角度具体描述同步可信计算集群的连接状态的过程。

图3示出根据一个实施例的同步可信计算集群的连接状态的方法流程图。其中，图3示出的方法的执行主体例如是图1中的客户端。该方法从客户端的角度，描述客户端与集群服务器管理的至少一个可信计算集群进行连接状态同步的过程。

如图3所示，通过客户端执行的同步可信计算集群的连接状态的方法包括以下步骤：步骤31，按照预定时间间隔向集群服务器发送心跳包，心跳包用于描述客户端与多个可信计算集群的当前连接状态，并包括当前通道列表和当前分流策略，当前通道列表提供客户端当前维持的、与多个可信计算集群中至少一个可信计算集群之间的可信通道，当前分流策略用于描述客户端当前在各个可信通道上分配的流量份额；步骤32，接收集群管理器基于心跳包返回的反馈包，反馈包用于反馈根据在线可信计算集群的集群信息确定的可用集群列表，以及针对当前通道列表提供的各个可信通道确定的建议分流策略；步骤33，根据反馈包更新当前连接状态。

首先，在步骤31中，按照预定时间间隔向集群服务器发送心跳包。顾名思义，心跳包是一种类似于心跳的数据包。心跳包可以由客户端按照预定时间间隔发送，用于向集群服务器汇报自身与集群服务器所管理的至少一个可信计算集群的当前连接状态。该预定时间间隔可以人工根据经验设定，也可以根据客户端与集群服务器的一次实际通讯时长确定，在此不做限定。该预定时间间隔例如是3秒。当前连接状态例如可以是与哪些可信计算集群连接、连接状态是否正常等等。

一方面，上述心跳包中可以包括当前通道列表，该当前通道列表可以提供客户端当前维持的、与集群管理器所管理的多个可信计算集群中至少一个可信计算集群之间的可信通道。客户端与每个可信计算集群的连接，都需要专用的可信通道。通道列表可以通过可信通道的通道名称、对应的可信集群名称等提供通道信息。值得说明的是，通道列表是为了表述方便所起的名称，并不对通道信息的表现形式进行限定。也就是说，当前通道列表可以是以列表形式记录通道信息，也可以通过数组、集合等形式，在此不做限定。

另一方面，上述心跳包还可以包括当前分流策略。可以理解，在客户端维持有多个可信通道的情况下，如果相应的多个可信计算集群是相应服务的不同版本，则客户端对于当前维持的各个可信通道，还可以具有当前分流策略，用于描述客户端在各个可信通道上分配的流量份额。其中，流量份额可以通过数据量的方式表示，例如100GB(100个十亿字节)，也可以通过总数据量的百分比形式表示，例如80％。作为示例，在图1中，如果客户端同时维持有与第一集群建立的第一可信通道及与第二集群建立的第二可信通道，则两个通道可以分别分配50％的流量份额。在客户端只维持有与第一集群建立的第一可信通道的情况下，可以将第一可信通道分配的流量份额描述为100％。

进一步地，通过上述心跳包，可以使集群管理器在接收到心跳包后，至少将所管理的相关可信集群的信息反馈给客户端。客户端通过步骤32，接收集群管理器基于心跳包返回的反馈包。具体地，反馈包可以包括根据在线可信计算集群的集群信息确定的可用集群列表，以及针对客户端的可信通道的建议分流策略。该建议分流策略也可以认为是集群管理器当前允许或生效的分流策略。

进一步地，根据步骤33，客户端根据反馈包更新当前连接状态。这里的当前连接信息可以包括与所述至少一个可信计算集群之间的可信通道，也可以包括为各个可信通道分配的流量份额。

根据一个实施方式，在集群管理器反馈的集群信息中增加一个可用集群的情况下，客户端根据反馈包可以对当前连接信息中涉及的可信通道进行更新。举例而言，如果可用集群列表中增加了集群为第二集群，客户端可以根据该增加的第二集群的集群信息建立与第二集群连接的可信通道。

在一个实施例中，客户端可以先检测客户端本地是否已配置第二集群的验证信息，若已配置第二集群的验证信息，则建立与第二集群进行连接的第二可信通道。其中，第二集群的验证信息例如可以是第二集群的标识信息，或者签名信息。例如，在可信计算集群中的可信计算单元是Enclave的情况下，相应的验证信息可以是计算机群的标识“mrEnclave2”之类的信息。

具体地，客户端首先可以向第二集群发送建立第二可信通道的连接请求，以供第二集群基于连接请求反馈连接信息(如数字签名等)，然后，将该连接信息与预先配置的验证信息进行比较，并在比较结果为一致的情况下，建立第二可信通道。该建立第二通道的过程，也可以理解为客户端和第二集群协商会话协议的过程，该过程可以参考各种方式进行会话(session)创建的过程，在此不再赘述。

进一步地，客户端还可以在当前通道列表中添加第二可信通道的通道信息，以供在下一个心跳包中把建立的第二通道的信息汇报给集群管理器。

根据另一个实施方式，在接收到的反馈包中反馈的集群信息中减少一个集群的情况下，客户端可以根据反馈包删除相应的可信通道。假设减少的集群称为第一集群(如图1所示)，客户端可以删除已建立的与第一集群连接的第一可信通道。

根据又一个实施方式，在当前分流策略与反馈包中的建议分流策略不一致的情况下，客户端可以按照建议分流策略为各个可信通道分配流量份额。例如，将第一可信通道的流量份额由100％更新为50％，同时将第二可信通道的流量份额由0更新为50％，等等。本领域技术人员可以理解，为各个可信通道分配的流量份额改变之后，当前分配策略随之改变。

可以理解，如果反馈包中的集群信息和建议分流策略与心跳包中的相应信息相比没有改变，则无需更新上述当前连接状态。也就是说，根据反馈包更新当前连接状态，还包括对与所述多个可信计算集群中至少一个可信计算集群之间的可信通道，以及当前在各个可信通道上分配的流量份额都不改变，或者都进行改变的情况。

根据一个可能的设计，客户端在更新当前连接状态的步骤之后，发送下一个心跳包之前，还可以检测本地的执行代码(SDK)是否存在异常。在存在异常的情况下，可以提供异常警报，该异常警报例如可以是弹窗、语音、通知消息等方式提供的警报。在不存在异常的情况下，正常发送心跳包。可选地，这里的数据异常可以是：未按照建议分流策略针对各个可信通道分配流量，或者建议分流策略未在客户端生效，等等。

通过以上过程中心跳包和反馈包的交互，客户端可以及时把自身与集群管理器所管理的各个可信计算集群的连接状态汇报给集群管理器，并把集群管理器建议的分流策略同步到客户端。

图4示出根据一个实施例的同步可信计算集群的连接状态的方法流程图。该方法的执行主体是用于管理多个可信计算集群的集群管理器(如图1中的集群管理器)。该方法从集群管理器的角度，描述客户端与集群服务器管理的多个可信计算集群进行连接状态同步的过程。该集群管理器可以是具有一定数据处理能力的系统、设备、装置、平台或服务器等。

如图4示，该方法包括以下步骤：步骤41，接收客户端按照预定时间间隔发送的心跳包，心跳包用于描述客户端与多个可信计算集群的当前连接状态，并包括当前通道列表和当前分流策略，当前通道列表提供客户端当前维持的、与多个可信计算集群中至少一个可信计算集群之间的可信通道，当前分流策略用于描述客户端当前在各个可信通道上分配的流量份额；步骤42，根据在线可信计算集群的集群信息，确定可用集群列表，并针对当前通道列表提供的各个可信通道确定建议分流策略；步骤43，向客户端发送反馈包，其中包括可用集群列表和建议分流策略，以供客户端根据反馈包更新当前连接状态。

首先，在步骤41中，接收客户端按照预定时间间隔发送的心跳包。该心跳包可以用于描述客户端与集群管理器所管理的多个可信计算集群的当前连接状态。顾名思义，心跳包可以理解为以预定时间间隔为周期发起(类似体现生命迹象的心跳)的数据包。

心跳包可以包括列出客户端当前维持的可信通道的当前通道列表。这些可信通道用于客户端与集群管理器管理的多个可信计算集群中至少一个可信计算集群之间的通信。

心跳包中还可以包括用于描述客户端当前在各个可信通道上分配的流量份额的当前分流策略。可以理解，当客户端可以同时维护多个可信通道时，如果两个或更多可信计算集群提供相同的服务，则客户端数据可以通过任一可信通道发送给相应的可信计算集群。这样的话，如果随机向各个可信通道分配流量，则会导致较多不可控因素。因此，可以在当前维持的各个可信通道上提供相应的分流策略，例如同时维持多个可信通道时，向各个可信通道平均分配流量份额。其中流量份额可以通过字节数确定，也可以根据分配概率或比例表示，在此不做限定。

接着，在步骤42中，集群管理器可以根据在线可信计算集群的集群信息，确定可用集群列表，并针对当前通道列表提供的各个可信通道确定建议分流策略。

一方面，集群管理器可以获取所管理的多个可信计算集群的集群信息，并确定可用集群列表。值得说明的是，虽然集群管理器可以同时管理多个可信计算集群，但不排除某个时刻，集群管理器所管理的可信计算集群，即当前在线的可信计算集群只有一个。对于可信计算集群而言，集群信息可以包括各个相应可信计算集群的集群标识，如第一集群、Cluster1等等，也可以包括各个相应可信计算集群的工作状态，如正常、异常等等，在此不做限定。

可用集群列表中可以针对上述客户端提供其可以使用的可信计算集群的集群信息。可以理解，集群管理器管理的多个可信计算集群，可以分别是针对多个客户端提供的，每个客户端对应其中一个或多个可信计算集群。对某个客户端而言，其对应的可用计算集群必须是在线的，或者说集群管理器确认其为有效的。集群管理器针对一个客户端提供的可用集群列表中给出的可信计算集群，可以是所有有效的、可用的可用计算集群，也可以是针对相应客户端有效的可用计算集群，在此不做限定。

值得说明的是，可用集群列表是为了更好地描述和体现对可用的可信计算集群的罗列，但不以此命名限定罗列可用集群的形式。也就是说，可用集群列表实际上可以是列表形式，也可以是数组、集合等形式，本说明书对此不做限定。

另一方面，集群管理器还可以根据心跳包中确定客户端当前所维持的可信通道，以及所获取的集群信息，给出当前允许客户端在各个可信通道上分配的流量份额，形成建议分流策略。

举例而言，如果客户端仅仅维持一个可信通道，则该可信通道的流量份额可以为100％。如果客户端同时维持两个可信通道，则两个可信通道的流量份额之和可以为100％，如第一可信通道的流量份额为30％、第二可信通道的流量份额为70％。客户端还可能同时维持更多个可信通道，在此不再一一例举。

集群服务器在确定各个可信通道的建议分流策略时，可以依据一定的分配规则，例如根据客户端维持的各个通道平均分配等等。在图1示出的实施架构中，如果用第二集群代替第一集群，则确定各个可信通道的建议分流策略时，还要遵循流量逐渐由与第一集群对应的第一可信通道向第二集群对应的第二可信通道转移的原则确定建议分流策略。

在一个实施例中，建议分流策略是按照预定规则，根据第一可信通道上的第一流量份额向第二可信通道转移一定份额后，各个可信通道的流量份额而确定的。为了描述方便，将这里的一定份额称为第一份额。上述的预定规则可以是将第一流量份额单次向第二可信通道转移的第一份额(如50％)，也可以是第一流量份额转移出第一份额后剩余的流量份额(如0)，还可以是第二可信通道增加第一份额后的第二流量份额(如100％)，等等。

值得注意的是，集群管理器给出的建议分流策略，是针对客户端所维持的可信通道的。也就是说，如果有新的可信计算集群上线，如果客户端和该可信计算集群之间还未建立可信通道，则无法分配流量，在建议分流策略中也不会涉及与该可信计算集群对应的可信通道。

然后，通过步骤43，向客户端发送反馈包，其中包括可用集群列表和建议分流策略。这里，可用集群列表和建议分流策略就通过步骤42确定，在此不再赘述。根据反馈包，客户端可以更新当前连接状态。其中反馈包是集群管理器向客户端反馈的数据包，为了描述方便，将其称为与心跳包相对的反馈包。

一方面，客户端可以根据可用集群列表更新当前维持的与集群管理器所管理的多个可信计算集群中至少一个可信计算集群之间的可信通道。例如，增加一个可信通道，或者减少一个可信通道。

另一方面，如果建议分流策略中，各个通道上分配的流量份额与客户端当前分流策略中各个通道的流量份额不一致，客户端还可以根据建议分流策略更新当前在各个可信通道上分配的流量份额。

在具体的实施例中，可信通道和在各个可信通道上分配的流量份额也可以同时更新或者不更新。可以理解，客户端可信通道和/或通道上的流量份额发生更新时，在集群管理器接收到的下一个心跳包中会体现出来。在此不再赘述。

根据一个可能的设计，至少在建议分流策略改变的情况下，集群管理器还可以在下一次接收到客户端的心跳包时，检测心跳包中的当前分流策略是否按照前一次的建议分流策略更新。若更新，则正常进行后续步骤，否则，发出异常警报，以提示数据错误。关于集群管理器侧的异常警报的形式，与客户端类似，在此不再赘述。

值得说明的是，图3和图4所描述的实施例，分别从客户端和集群管理器端对交互周期进行描述，因此，针对图3和图4的描述相互配合和适应，在此不再赘述。

为了进一步清晰揭示本说明书的实施例，在图1的应用架构下，通过第二集群取代第一集群的场景，参考图5a-图5f，结合图3和图4的方法流程，从客户端和集群管理器的交互的角度，通过以下更具体的多个实施例进行描述。

如图5a所示实施例中，集群管理器所管理的可信计算集群中，在线的可信计算集群为第一集群，如Cluster A。客户端与第一集群预先建立有第一可信通道。此时，客户端向集群管理器发送的心跳包为第一心跳包。第一心跳包中的当前通道列表提供有客户端与第一集群预先建立第一可信通道。当前通道列表中可以记录有第一可信通道的名称Tunnuel A。第一心跳包中的当前分流策略可以是，客户端在第一可信通道上分配的第一流量份额为100％。

在图5a示出的情况下，集群管理器所管理的可信计算集群的集群信息没有改变。换句话说，可用集群列表仍然只包括第一集群Cluster A。由于第一心跳包中也没有增加新的可信通道，集群管理器确定的建议分流策略，仍然为在第一可信通道上分配的第一流量份额为100％。集群服务器根据可用集群列表Cluster A，以及在第一可信通道上分配的第一流量份额为100％的建议分流策略生成第零反馈包。接着集群管理器向客户端发送该第零反馈包。客户端接收该第零反馈包，经过检测，确定当前连接状态无需更新，则继续向集群管理器发送第一心跳包。

接着参考图5b示出的实施例。在该实施例中，集群管理器所管理的可信计算集群中，在线的可信计算集群至少为第一集群Cluster A。客户端与第一集群预先建立有第一可信通道Tunnuel A。此时，客户端向集群管理器发送的心跳包仍为第一心跳包。如前所述，第一心跳包中的当前通道列表提供第一可信通道Tunnuel A，当前分流策略可以包括客户端在第一可信通道Tunnuel A上分配的第一流量份额为100％。

集群管理器接收到该第一心跳包，检测在线可信计算集群，发现新上线了第二集群Cluster B，则确定可用集群列表包括Cluster A和Cluster B。另一方面，由于第二集群Cluster B是新增的可信计算集群，也就是说客户端还没有维持和第二集群Cluster B之间的可信通道，所以各个可信通道的建议分流策略可以维持原有分流策略，即第一心跳包中的当前分流策略，在所述第一可信通道Tunnuel A上分配的第一流量份额100％。集群管理器可以按照新的可用集群列表和建议分流策略，生成第一反馈包，并发送给客户端。

客户端接收到第一反馈包，通过其中的可用集群列表发现新增了第二集群Cluster B，则可以建立与Cluster B连接的第二可信通道Tunnuel B。在一个可能的设计中，客户端可以先进一步检测是否在本地保存了Cluster B的验证信息。这里的验证信息用于在安全计算领域对可信计算集群进行标识，例如在可信计算集群中的可信计算单元为Enclave时，Cluster B的验证信息可以为mrEnclave B。如果在本地保存了Cluster B的验证信息，则建立与Cluster B连接的第二可信通道Tunnuel B。具体地，客户端可以向第二集群Cluster B发送建立第二可信通道的连接请求，以供Cluster B基于连接请求反馈连接信息(如Cluster B的签名信息等)，客户端可以将改连接信息与本地保存的验证信息进行比较，并在比较结果为一致的情况下，建立第二可信通道Tunnuel B。进一步地，客户端可以将Tunnuel B添加进当前通道列表，以在下一个心跳包中进行更新，例如下一个心跳包更新为第二心跳包。另一方面，客户端检测第一反馈包中的建议分流策略与第一心跳包中的当前分流策略一致，不进行更新。

然后参考图5c示出的实施例。在该实施例中，集群管理器所管理的可信计算集群中，在线的可信计算集群有第一集群Cluster A和第二集群Cluster B。客户端与第一集群预先建立有第一可信通道Tunnuel A，且已与Cluster B建立了第二可信通道Tunnuel B。此时，客户端向集群管理器发送的心跳包为第二心跳包。第二心跳包中的当前通道列表提供第一可信通道Tunnuel A和第二可信通道Tunnuel B，当前分流策略至少包括客户端在第一可信通道Tunnuel A上分配的第一流量份额。在图5c示出的状态下，第二心跳包中的当前分流策略仍仅包括客户端在第一可信通道Tunnuel A上分配的第一流量份额，为100％。

集群管理器接收该第二心跳包，没有检测到上线下线的可信计算集群，则可用集群列表中仍为Cluster A和Cluster B。另一方面，检测到客户端维持了新的可信通道，第二可信通道Tunnuel B，则可以将建议分流策略进行修改，以向Tunnuel B分配流量。集群管理器可以按照预定规则，根据第一流量份额100％向第二可信通道转移第一份额(如50％)后各个可信通道的流量份额，确定第一建议分流策略。其中，这里的预定规则可以规定上述第一份额的额度值(如50％等)，也可以规定第一流量份额转移出第一份额后剩余的流量份额(如50％、0等)，还可以是第二可信通道增加第一份额后的第二流量份额(如50％、100％等)。其中，这里以第一份额为50％为示例进行说明，实践中还可以是70％、40％等，在此不做限定。第一建议分流策略中涉及的各个通道的流量分配，也可以理解为已在集群管理器中生效。进一步地，集群管理器可以基于第一建议分流策略生成第二反馈包发送给客户端。

客户端接收第二反馈包。经过检测，客户端确定可用集群列表中的可用集群没有更新，无需建立或删除可信通道。然而第二反馈包中提供的第一建议分流策略与客户端当前分流策略相比发生了改变，于是可以根据第一建议分流策略更新当前分流策略。如更新为：在第一可信通道Tunnuel A上分配的第一流量份额为50％，在第二可信通道Tunnuel B上分配的第二流量份额为50％。

接着参考图5d，图5d示出的实施例和图5c可以看做同一个实施例的不同情况。在图5d的示例中，集群管理器所管理的可信计算集群中，在线的可信计算集群有第一集群Cluster A和第二集群Cluster B。客户端与第一集群预先建立有第一可信通道Tunnuel A，且与Cluster B建立有第二可信通道Tunnuel B。图5d示出的过程也可以看作图5c过程的进一步执行。

此时，客户端向集群管理器发送的第二心跳包中，当前通道列表提供第一可信通道Tunnuel A和第二可信通道Tunnuel B，当前分流策略不仅包括客户端在第一可信通道Tunnuel A上分配的第一流量份额(如50％)，还可以包括客户端在第二可信通道Tunnuel B上分配的第二流量份额(如50％)。

集群管理器接收该第二心跳包，没有检测到上线下线的可信计算集群，则可用集群列表中仍为Cluster A和Cluster B。另一方面，可以将建议分流策略进行修改，以向Tunnuel B分配更多流量。例如集群管理器可以按照预定规则将第一流量份额向第二可信通道再转移一个某个份额(也可以认为是另一个第一份额)，确定新的建议分流策略。其中，这里的预定规则同上。进一步地，集群管理器可以基于新的建议分流策略生成第二反馈包，并发送给客户端。值得说明的是，此处的反馈包仍然沿用图5c的实施例中的说法称为第二反馈包，以表示图5c和图5d示出的是流量从Tunnuel A向Tunnuel B转移中的不同情况(转移逻辑或方法一致)。然而实践中，两者的内容并不一定完全一致。

客户端接收此时的第二反馈包。经过检测，客户端确定可用集群列表中的可用集群没有更新，无需建立或删除可信通道。然而建议分流策略与客户端当前分流策略相比发生了改变，可以根据新的建议分流策略更新当前分流策略。如图5d所示，假设此时，在第一可信通道Tunnuel A上不再分配第一流量份额，在第二可信通道Tunnuel B上分配的第二流量份额为100％。

进一步地，参考图5e所示的实施例，客户端向集群管理器发送第三心跳包。第三心跳包中的当前通道列表提供第一可信通道Tunnuel A和第二可信通道Tunnuel B，当前分流策略包括客户端在第二可信通道Tunnuel B上分配的第二流量份额100％，用于描述第一可信通道的流量份额完全转移到第二可信通道的情况。

集群管理器接收到第三心跳包，根据其中的当前分流策略确定客户端已将原来属于第一可信通道的流量份额完全转移到第二可信通道。此时，集群管理器可以将第一集群下线。如此，所确定的可用集群列表中将减少第一集群，而分流策略可以保持不变，亦即，建议分流策略和第三心跳包中的当前分流策略一致。

根据一个可能的设计，集群管理器向客户端发送与第三心跳包对应的第三反馈包。该第三反馈包中，可用集群列表提供第二集群，建议分流策略包括客户端在第二可信通道上分配的第二流量份额(100％)。此时，客户端根据该第三反馈包，可以删除与第一集群对应的第一可信通道，完成对当前连接状态的更新。

如此，在图5f示出的实施例中，集群管理器所管理的可信计算集群中，在线的可信计算集群为第二集群Cluster B。客户端与第二集群维持有第二可信通道Tunnuel B。此时，客户端向集群管理器发送的心跳包为第四心跳包。第四心跳包中的当前通道列表提供有Tunnuel B，当前分流策略可以是，客户端在Tunnuel B上分配的第二流量份额为100％。

集群管理器接收到第四心跳包，检测到所管理的可信计算集群的集群信息没有改变，第四心跳包中也没有增加新的可信通道。集群服务器根据可用集群列表Cluster B，以及在第二可信通道上分配的第二流量份额100％的建议分流策略生成第四反馈包。接着集群管理器向客户端发送该第四反馈包。客户端接收该第四反馈包，经过检测，确定当前连接状态无需更新，则可以继续向集群管理器发送第四心跳包。

如此，将图5a至图5f示出的各个实施例按次序执行，便可以完成第二集群替换第一集群的过程。其中，各个实施例都可以多次执行。例如，图5a和图5f的实施例多次执行，以保证客户端和集群管理器之间的实时同步。另外，各个实施例的执行结果都可以稳定保持一段时间，以确保流量转移过程中对数据的实时监测，或者对新的计算集群的可用性进行检测。例如，图5c的实施例中，在第一通道上的第一流量份额为50％，第二通道上的第二流量份额为50％的状态下，客户端和集群管理器之间可以有多个心跳包和的反馈包的交互。也就是说，以上命名的第一心跳包、第二心跳包、第三心跳包等，是基于心跳包内容的不同进行区分，而不限定为第一个、第二个、第三个。

回顾以上过程，在可信计算集群进行代码升级，切换集群连接的过程中，通过心跳包和反馈包，通过可信通道上的流量份额的改变，一步一步减少旧的可信计算机群提供的计算服务，增加新的可信计算机群提供的计算服务，从而可以达到计算机群的平稳上下线，提高可信计算的有效性。

根据另一方面的实施例，还提供一种同步可信计算集群的连接状态的装置，适用于集群管理器。图6示出根据一个实施例的同步可信计算集群的连接状态的示意性框图。如图6所示，同步可信计算集群的连接状态信息的装置600包括：接收单元61，配置为接收客户端按照预定时间间隔发送的心跳包，心跳包用于描述客户端与多个可信计算集群的当前连接状态，并包括当前通道列表和当前分流策略，当前通道列表提供客户端当前维持的、与多个可信计算集群中至少一个可信计算集群之间的可信通道，当前分流策略用于描述客户端当前在各个可信通道上分配的流量份额；确定单元62，配置为根据在线可信计算集群的集群信息，确定可用集群列表，并针对当前通道列表提供的各个可信通道确定建议分流策略；发送单元63，配置为向客户端发送反馈包，其中包括可用集群列表和建议分流策略，以供客户端根据反馈包更新当前连接状态。

在一个实施例中，集群管理器所管理的多个可信计算集群包括第一集群和第二集群，其中，第二集群用于取代所述第一集群。接收单元61进一步配置为，接收第一心跳包。第一心跳包中，当前通道列表至少提供客户端与第一集群预先建立的第一可信通道，当前分流策略包括客户端在第一可信通道上分配的第一流量份额。此时，确定单元62还可以进一步配置为：在确定第二集群上线的情况下，在可用集群列表中添加第二集群形成第一可用集群列表；发送单元63还可以进一步配置为，向客户端发送第一反馈包，第一反馈包中的当前可用集群列表为第一可用集群列表，建议分流策略包括为第一可信通道分配第一流量份额，以供客户端在预先配置有第二集群的验证信息的情况下，建立与第二集群连接的第二可信通道。

在另一个实施例中，集群管理器所管理的多个可信计算集群仍然包括第一集群和第二集群，其中，第二集群用于取代第一集群。接收单元61进一步可以配置为，接收第二心跳包。在第二心跳包中，当前通道列表提供客户端与第一集群预先建立的第一可信通道，以及客户端与第二集群预先建立的第二可信通道，当前分流策略至少包括，客户端在第一可信通道上分配的第一流量份额。此时，确定单元62进一步还可以配置为：按照预定规则，根据第一流量份额向第二可信通道转移第一份额后各个可信通道的流量份额，确定第一建议分流策略。发送单元63进一步还可以配置为，向客户端发送第二反馈包，第二反馈包中的建议分流策略为第一建议分流策略，以供客户端基于第一建议分流策略更新为各个可信通道分配的流量份额。

可选地，上述预定规则可以包括以下至少一项：第一份额；第一流量份额转移出第一份额后剩余的流量份额；第二可信通道增加第一份额后的第二流量份额。

在又一个实施例中，仍然是集群管理器所管理的多个可信计算集群仍然包括第一集群和第二集群，其中，第二集群用于取代第一集群的情况下，接收单元61进一步可以配置为，接收第三心跳包。第三心跳包中，当前通道列表提供上述第一可信通道和第二可信通道，当前分流策略包括客户端在第二可信通道上分配的第二流量份额；装置600还可以包括管理单元(未示出)，配置为：响应于基于第三心跳包确定第一可信通道的流量份额完全转移到第二可信通道，下线第一集群。

此时，在进一步的实施例中，发送单元63可以进一步配置为：向客户端发送第三反馈包，第三反馈包中的可用集群列表提供第二集群，建议分流策略包括客户端在第二可信通道上分配的第二流量份额，以供客户端在接收到第三反馈包后，删除第一可信通道。

在一个实施例中，可信计算集群包括多个可信计算单元，用于客户端的分布式可信计算。进一步可选地，可信计算单元可以为围圈Enclave。

值得说明的是，图6所示的装置600是与图4示出的方法实施例相对应的装置实施例，图4示出的方法实施例中的相应描述同样适用于装置600，在此不再赘述。

根据另一方面的实施例，还提供另一种同步可信计算集群的连接状态的装置，适用于客户端。图7示出根据一个实施例的同步可信计算集群的连接状态信息的示意性框图。如图7所示，同步可信计算集群的连接状态的装置700包括：发送单元71，配置为按照预定时间间隔向集群服务器发送心跳包，心跳包用于描述客户端与多个可信计算集群的当前连接状态，并包括当前通道列表和当前分流策略，当前通道列表提供客户端当前维持的、与多个可信计算集群中至少一个可信计算集群之间的可信通道，当前分流策略用于描述客户端当前在各个可信通道上分配的流量份额；接收单元72，配置为接收集群管理器基于心跳包返回的反馈包，反馈包用于反馈根据在线可信计算集群的集群信息确定的可用集群列表，以及针对当前通道列表提供的各个可信通道确定的建议分流策略；更新单元73，配置为根据反馈包更新当前连接状态。

在多个可信计算集群包括第一集群和第二集群，其中，第二集群用于取代第一集群的情况下，装置700中各个单元具有不同的具体配置。

在一个实施例中，发送单元71可以进一步配置为，发送第一心跳包。该第一心跳包中，当前通道列表至少提供，客户端与所述第一集群预先建立的第一可信通道，当前分流策略包括，客户端在第一可信通道上分配的第一流量份额。接收单元72可以进一步配置为，接收第一反馈包。该第一反馈包中的当前可用集群列表为，在确定第二集群上线的情况下，增加第二集群形成的第一可用集群列表。更新单元73进一步可以配置为：检测是否已配置第二集群的验证信息；若已配置第二集群的验证信息，建立与第二集群进行连接的第二可信通道。

在进一步的实施例中，更新单元73还可以配置为通过以下方式建立与第二集群进行连接的第二可信通道：向第二集群发送建立第二可信通道的连接请求，以供第二集群基于连接请求反馈连接信息；将连接信息与验证信息进行比较，并在比较结果为一致的情况下，建立第二可信通道。

在另一个实施例中，发送单元71可以进一步配置为，发送第二心跳包。该第二心跳包中，当前通道列表提供客户端与所述第一集群预先建立的第一可信通道，以及客户端与第二集群预先建立的第二可信通道，当前分流策略至少包括，客户端在第一可信通道上分配的第一流量份额。接收单元72进一步配置为，接收第二反馈包。第二反馈包中的建议分流策略为，集群管理器按照预定规则，根据第一流量份额向第二可信通道转移第一份额后各个可信通道的流量份额，确定的第一建议分流策略。更新单元73进一步配置为：按照第一建议分流策略更新为各个可信通道分配流量份额。

在又一个实施例中，发送单元71还进一步配置为，发送第三心跳包。其中，第三心跳包中，当前通道列表提供上述第一可信通道和第二可信通道，当前分流策略包括客户端在第二可信通道上分配的第二流量份额。接收单元72还进一步配置为，接收第三反馈包，第三反馈包中，可用集群列表由集群管理器在第一集群下线的情况下确定，且提供第二集群，建议分流策略包括客户端在第二可信通道上分配的第二流量份额；更新单元73还可以进一步配置为，根据第三反馈包中的可用集群列表，删除第一可信通道。

根据一种实施方式，装置700还可以包括检测单元(未示出)，配置为：检测客户端的软件开发工具包是否存在异常；在存在异常的情况下，提供异常警报。

值得说明的是，图7所示的装置700是与图3示出的方法实施例相对应的装置实施例，图3示出的方法实施例中的相应描述同样适用于装置700，在此不再赘述。

通过以上装置，实现客户端与集群管理器所管理的可信计算集群的连接状态同步，从而在集群管理器所管理的可信计算集群有变化时，客户端即使采取相应策略，提高可信计算集群为客户端提供的可信计算服务的有效性。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行结合图3或图4所描述的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现结合图3或图4所述的方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。