CN117193855A - 代码管理方法、装置、存储介质及电子设备 - Google Patents

Abstract

本申请公开了一种代码管理方法、装置、存储介质及电子设备。其中，该方法包括：响应于目标对象的操作指令生成可视化编程对象；将可视化编程对象转换为预定格式的元数据；将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性。本申请解决了由于相关技术中基于关系型数据库管理代码存在运维管理复杂，集群成本高，无法快速弹性扩容等技术问题。

Description

代码管理方法、装置、存储介质及电子设备

技术领域

本申请涉及代码开发领域，具体而言，涉及一种代码管理方法、装置、存储介质及电子设备。

背景技术

在软件设计和开发领域，低代码开发平台，通过可视化进行应用程序开发，使具有不同经验水平的开发人员可以通过图形化的用户界面，使用拖拽组件和模型驱动的逻辑来创建业务对象、实现业务逻辑。无需编码或通过少量代码就可以快速生成应用程序。

通过可视化配置生成的应用程序、***模块、业务对象、任务对象、***编码等要素，在保存时，会将以上对象转化成半结构化的元数据，做持久化处理。在最终进行应用程序发布时，平台再将元数据通过规则转化为可执行的代码文件。元数据即为由可视化编程对象到可执行代码文件的一种中间状态的数据。

相关技术中是将元数据保存在关系型数据库中。大型软件开发企业，有众多的产品线、大量的子***和模块需要管理；在***向微服务架构转型的技术背景下，业务应用也面临大量的服务拆分。以上情况导致了大型企业软件开发在使用低代码开发平台时，元数据的内容迅速增加，扩容成为常态，以往使用关系型数据库管理元数据的方案就暴露了部署、运维、管理较复杂，集群方案成本高，以及无法快速弹性扩容等诸多弊病。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种代码管理方法、装置、存储介质及电子设备，以至少解决由于相关技术中基于关系型数据库管理代码存在运维管理复杂，集群成本高，无法快速弹性扩容等技术问题。

根据本申请实施例的一个方面，提供了一种代码管理方法，包括：响应于目标对象的操作指令生成可视化编程对象；将可视化编程对象转换为预定格式的元数据；将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性。

可选地，集群服务管理器中的多个分布式节点在同一时刻只能存在一个主节点，客户端的操作请求由该主节点执行，并由该主节点向从节点复制日志；且集群服务管理器由主节点还用于向从节点发起心跳连接，并在接收到超过预设数量的从节点的响应的情况下，对日志状态进行变更。

可选地，将元数据通过日志形式存储至集群服务管理器中，包括：接收客户端的数据请求，其中，数据请求至少用于向集群服务管理器中写入元数据；将元数据转换为有序的日志文件，通过主节点向多个从节点复制日志文件，在得到预设数量的从节点响应的情况下，更新当前的提交索引值，得到目标提交索引值，并将目标提交索引值发送至从节点，以用于将从节点的日志文件应用到状态机；控制状态机解析日志文件中的实体对象元数据信息，从解析结果中获取全局唯一的对象编码以及对象属性字段；以对象编码为标识信息，对象属性字段为属性值构建键值对，对键值对进行缓存。

可选地，集群服务管理器的多个分布式节点之间通信的消息类型至少包括：选举,在多个分布式节点之间通信的消息类型为选举的情况下，多个分布式节点中的每个节点将生命周期划分为连续的多个任期，多个任期中的每个任期内只有一个主节点，其中，任期包括：选举期与运行期。

可选地，选举的过程包括：检测主节点是否发生故障；在确定主节点发生故障的情况下，在确定各个从节点中的任意一个节点失去心跳的第一时长大于预设时长后，确定待发起选举请求的目标从节点；将目标从节点确定为候选人节点。

可选地，集群服务管理器的多个分布式节点之间通信的消息类型至少还包括：日志复制,日志复制通过如下方式实现：主节点接收到客户端的数据请求，将数据请求对应的数据确定为最新的日志数据；将日志数据加载至日志集合中的末位，并向多个从节点广播日志复制请求；在接收到超过预设数量的从节点的响应的情况下，将提交索引更新为当前已确认的日志数据的目标索引，并将目标索引发送至从节点；控制从节点将目标索引为止的所有未执行的日志条目加载到状态机中执行。

可选地，多个分布式节点中的各个分布式节点的日志文件采用分段保存的方式持久化在本地文件中，其中，各分段日志通过元数据维护当前日志段的基本信息，基本信息包括：当前任期、起始日志编号，已提交的最新日志编号。

根据本申请实施例的另一方面，还提供了一种代码管理装置，包括：响应模块，用于响应于目标对象的操作指令生成可视化编程对象；转换模块，用于将可视化编程对象转换为预定格式的元数据；存储模块，用于将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性。

根据本申请实施例的另一方面，还提供了一种非易失性存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述代码管理方法。

根据本申请实施例的另一方面，还提供了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行指令，以实现上述代码管理方法。

在本申请实施例中，采用日志存储的方式，通过响应于目标对象的操作指令生成可视化编程对象；将可视化编程对象转换为预定格式的元数据；将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性，达到了将元数据通过日志形式的进行存储的目的，从而实现了对相关技术中代码管理方案进行优化，实现代码快速部署，弹性扩容，实现元数据集群化，高可用的技术效果，进而解决了由于相关技术中基于关系型数据库管理代码存在运维管理复杂，集群成本高，无法快速弹性扩容等技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种可选的代码管理方法的流程示意图；

图2是根据本申请实施例的一种可选的元数据服务的设计框架示意图；

图3是根据本申请实施例的一种可选的平台整体设计方案的框架示意图；

图4是根据本申请实施例的一种可选的任期机制示意图；

图5是根据本申请实施例的一种可选的选举流程示意图；

图6是根据本申请实施例的一种可选的快照的原理展示示意图；

图7是根据本申请实施例的一种可选的集群因网络分区导致的服务不可用的场景示意图；

图8是根据本申请实施例的一种可选的代码管理装置的结构示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于本领域技术人员更好的理解本申请相关实施例，现对本申请相关实施例可能涉及的技术术语或者部分名词解释如下：

1、低代码开发平台：低代码开发平台是无需编码或通过少量代码就可以快速生成应用程序的开发平台。它的强大之处在于，允许终端用户使用易于理解的可视化工具开发自己的应用程序，而不是传统的编写代码方式。构建业务流程、逻辑和数据模型等所需的功能，必要时还可以添加自己的代码。完成业务逻辑、功能构建后，即可一键交付应用并进行更新、部署。

2、分布式***：分布式***(distributed system)是建立在网络之上的软件***，具有高度的内聚性和透明性。分布式***具有以下特性：(1)分布性：分布式***由多台计算机组成，它们在地域上是分散的，整个***的功能是分散在各个节点上实现的，因而分布式***具有数据处理的分布性。(2)自治性：分布式***中的各个节点都包含自己的处理机和内存，各自具有独立的处理数据的功能。(3)并行性：一个大的任务可以划分为若干个子任务，分别在不同的主机上执行。(4)全局性：分布式***中必须存在一个单一的、全局的进程通信机制，使得任何一个进程都能与其他进程通信，并且不区分本地通信与远程通信。

3、Raft协议：一种分布式一致性协议。

4、CAP原则：指在分布式***中，需要解决的一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)问题。而通常情况下，三者无法同时满足。

5、一致性：一致性(Consistency)是指多副本(Replications)问题中的数据一致性。强一致性具有以下特点：1)任何一次读都能读到某个数据的最近一次写的数据。 2)***中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。

6、write-ahead-log：预写式日志(Write-ahead logging，缩写WAL)是关系数据库***中用于提供原子性和持久性(ACID属性中的两个)的一系列技术。在使用WAL 的***中，所有的修改在提交之前都要先写入log文件中，log文件中通常包括redo 和undo信息，通过日志记录描述好数据的改变后(redo和undo)，再写入缓存，等缓存区写满后，最后再往持久层修改数据。

根据本申请实施例，提供了一种代码管理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本申请实施例的代码管理方法的流程示意图，如图1所示，该方法包括如下步骤：

步骤S102，响应于目标对象的操作指令生成可视化编程对象；

在本申请上述步骤S102提供的技术方案中，可响应于目标对象的操作指令生成可视化编程对象，需要说明的是，可视化编程对象，包括：可视化编程语言(VPL)，可视化编程语言是允许用户通过图形化来操作程序元素而不是通过文本指定来创建程序的任何编程语言。VPL允许使用视觉表达式，文本和图形符号的空间排列进行编程，用作语法元素或辅助符号。例如，许多VPL(称为数据流或图解编程)基于“框和箭头”的概念，以框或其他屏幕对象为实体，通过表示关系的箭头、直线段或弧线连接

步骤S104，将可视化编程对象转换为预定格式的元数据；

在本申请上述步骤S104提供的技术方案中，可将可视化编程对象转换为预定格式的元数据，容易注意到的是，元数据即为由可视化编程对象到可执行代码文件的一种中间状态的数据。需要说明的是，上述预定格式包括但不限于：json格式。

步骤S106，将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性。

在本申请上述步骤S106提供的技术方案中，可将元数据通过日志形式存储至集群服务管理器中，需要说明的是，元数据管理服务内部分布式节点之间可通过raft协议进行通信达成共识，完成数据的复制、一致性确认。

通过步骤S102至步骤S106的技术方案，可采用日志存储的方式，通过响应于目标对象的操作指令生成可视化编程对象；将可视化编程对象转换为预定格式的元数据；将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性，达到了将元数据通过日志形式的进行存储的目的，从而实现了对相关技术中代码管理方案进行优化，实现代码快速部署，弹性扩容，实现元数据集群化，高可用的技术效果，进而解决了由于相关技术中基于关系型数据库管理代码存在运维管理复杂，集群成本高，无法快速弹性扩容等技术问题。

作为一种可选的实施方法，集群服务管理器中的多个分布式节点在同一时刻只能存在一个主节点，客户端的操作请求由该主节点执行，并由该主节点向从节点复制日志；且集群服务管理器由主节点还用于向从节点发起心跳连接，并在接收到超过预设数量的从节点的响应的情况下，对日志状态进行变更。

本申请一些可选的实施例中，将元数据通过日志形式存储至集群服务管理器中，可通过如下方式实现，具体的：接收客户端的数据请求，其中，数据请求至少用于向集群服务管理器中写入元数据；将元数据转换为有序的日志文件，通过主节点向多个从节点复制日志文件，在得到预设数量的从节点响应的情况下，更新当前的提交索引值，得到目标提交索引值，并将目标提交索引值发送至从节点，以用于将从节点的日志文件应用到状态机；控制状态机解析日志文件中的实体对象元数据信息，从解析结果中获取全局唯一的对象编码以及对象属性字段；以对象编码为标识信息，对象属性字段为属性值构建键值对，对键值对进行缓存。

可选地，集群服务管理器的多个分布式节点之间通信的消息类型至少包括：选举；其中，集群服务管理器包括：选举，以及心跳。

本申请一些可选的实施例中，在多个分布式节点之间通信的消息类型为选举的情况下，多个分布式节点中的每个节点将生命周期划分为连续的多个任期，多个任期中的每个任期内只有一个主节点，需要说明的是，任期包括：选举期与运行期。

可选地，选举的过程包括：检测主节点是否发生故障；在确定主节点发生故障的情况下，在确定各个从节点中的任意一个节点失去心跳的第一时长大于预设时长后，确定待发起选举请求的目标从节点；将目标从节点确定为候选人节点。

需要说明的是，集群服务管理器的多个分布式节点之间通信的消息类型至少还包括：日志复制。

本申请一些可选的实施例中，日志复制可通过如下方式实现：具体的，主节点接收到客户端的数据请求，将数据请求对应的数据确定为最新的日志数据；将日志数据加载至日志集合中的末位，并向多个从节点广播日志复制请求；在接收到超过预设数量的从节点的响应的情况下，将提交索引更新为当前已确认的日志数据的目标索引，并将目标索引发送至从节点；控制从节点将目标索引为止的所有未执行的日志条目加载到状态机中执行。

需要说明的是，多个分布式节点中的各个分布式节点的日志文件采用分段保存的方式持久化在本地文件中，其中，各分段日志通过元数据维护当前日志段的基本信息，基本信息包括：当前任期、起始日志编号，已提交的最新日志编号。

下面对该实施例的上述技术方案进行进一步地举例介绍。

本申请的元数据服务的设计方案如图2所示，用户通过低代码开发平台，使用可视化、组态式的方法，配置创建***、模块、对象等实体模型，低代码开发平台将实体模型抽象化后，转换为json格式的元数据，并将元数据通过日志形式向元数据管理服务集群进行提交。元数据管理服务内部分布式节点之间通过raft协议，达成共识，完成数据的复制、一致性确认。

图3是平台整体设计方案，元数据服务对外向低代码开发平台提供实体对象的存取服务，对客户端体现数据强一致性；对内通过raft协议保证数据一致性。

元数据服务节点(Node)之间使用raft协议实现分布式一致性，其中Leader选举、日志复制、状态机是核心逻辑。

元数据服务集群内部节点有三种角色、四种状态。三种角色分别是leader、follower、 candidate；四种状态分别是leader、follower、pre_candidate、candidate。节点间严格遵循strong leader机制，即集群中同一时间只能存在一个leader，所有客户端的写操作请求只能由leader执行，并由leader向follower复制请求日志；同时整个集群由leader 负责维护通信、向follower发起心跳，接收来自follower的应答，判断多数派(超过半数)的响应结果，并提交日志状态变更。

服务节点接收到客户端的数据读写请求后，首先将业务数据转化成有序的日志(write-ahead-log)，通过leader向follower做日志的全网复制，在得到多数派节点的确认响应之后(commit index)，将commitindex的值更新。follower节点在得到leader 的最新commitindex值后，会将最新的已得到全局确认的日志条目内容，应用到状态机中(apply)。本地状态机会解析日志中的实体对象元数据信息(data)，将全局唯一的对象编码作为key值，将对象属性字段为主要内容的json数据作为value值，持久化到KV缓存。需要说明的是，本申请中的状态机持久化介质采用开源软件RocksDB，该软件是一种基于文件IO的KV缓存，具有嵌入式部署、轻量级、内存占用少等优点。

节点间的通信消息可分为4种类型，具体的，可包括选举(election)、心跳(heartbeat)、日志数据(segment_log)以及快照(snapshot)。其中客户端的数据读、写请求都会转换成日志格式，由leader节点统一维护一个连续的、单调递增的索引(index)，每条日志严格按照index的顺序commit，日志的顺序执行机制是节点间实现数据线性一致性读的保障措施之一。

以下将对选举(election)、日志复制(log replicate)、状态机(state machine)、快照(snapshot)的实现方案做详细介绍：

在选举机制中，每个元数据节点(node)将生命周期划分为连续的任期(term)，任期机制如图4所示，服务节点的生命周期，每个任期分为两个阶段，选举和运行；没有选出leader的任期会直接跳过，不对外提供任何服务。任期在时间线上是一个从 0开始，单调递增的数值。每个任期的时间又划分为两部分，分别是选举期和运行期，在每个任期中，整个集群只能有一个leader。

选举通过超时机制触发，选举流程如图5所示，选举由超时机制驱动，为避免碰撞，各节点在默认超时时间基础上，增加了随机的时间戳。元数据服务集群在日常运行的过程中，由leader向各follower节点维护心跳，各节点(node)在本地维护统一的配置信息(configuration)，configuration中包含了集群各节点的编号、地址、端口等服务器信息，也包括了心跳时间(heartbeat)和选举超时时间(election timeout)等信息，其中心跳时间远小于超时时间。在leader节点发生故障或者出现网络故障后，各节点在本地判断失去心跳并且时长超过超时时间后，即向全网发起选举请求。

发起选举请求时，发起节点会将自身的角色变为candidate，并将任期term+1，为了尽量避免多个节点同时发起选举事件，产生碰撞，***会在选举超时时间的基础上，增加一个随机的时间戳。

候选人在发送选举请求时，会在日志中带上本地节点的commit index和term，其他节点在接收到候选人的请求后，会将本地的commit index、term与候选人的请求值做比较，若本地的更新，则会发出拒绝的响应。该机制保证了选举产生的leader日志内容是最新的。

一个任期中，若没有选出leader，则集群可以没有leader，该任期不存在运行期，在term+1后，继续新一轮的选举。

选举结束后，成为leader的节点将节点角色变更为leader，并开始执行运行期的任务；其他的候选人将角色变更为follower，继续在运行期接收来自leader的请求。

分段日志文件中，保存着日志明细(logEntries)，每一条日志由term+index保证唯一性，日志对象(logEntry)包含任期(term)，索引(index)，类型(type：data|configuration)，数据(data)四个关键属性，其中数据字段保存了实体对象元数据的完整内容。

leader节点接收到客户端发出的请求后，将请求数据作为最新的一条日志，加入到日志集合的末位，并向follower节点广播日志复制请求(appendLogEntries)，在得到多数派的节点回执确认后，leader会将commit_index更新为当前已确认的日志index，并再次向所有节点通知执行结果。follower节点在接收到commit_index更新消息后，会将到commit_index为止的所有未执行的日志条目，加载到状态机中执行(apply)，状态机在执行完成后，将已执行索引(apply_index)也更新到最新值。对于未响应的 follower节点，leader会一直尝试发送日志复制的请求，直到follower节点执行，并响应为止。

日志复制的操作，由唯一leader来完成，保证了不同的两个日志条目如果有相同的索引和任期号,那么他们包含的数据一定是相同的。需要说明的是，leader节点发送日志复制请求时，会带着上一条日志的任期和索引(pre_index)，follower节点会检查是否与本地日志中的索引和任期号相匹配,如果不匹配则会拒绝。可以理解的， leader节点的日志只会增加，不能覆盖和删除，leader节点通过强制follower有序复制自身日志，可保证集群节点的数据强一致性。

leader节点为每一个follower维护了一个next_index,用来表示将要发送给该follower的下一条日志索引。follower在接收到leader的日志复制请求后，可先做一致性校验，如果本地最新日志的index和leader的next_index不一致,则返回失败结果。 leader收到失败响应之后，会将next_index递减然后重试，最终leader的next_index会递减到和follower的index一致，而leader会从匹配后的位置重新发送日志复制请求，最终使follower的数据保持一致性。

状态机有序的将日志数据做实际应用，其中核心的方法是StateMachine.apply，本案中采用KV缓存的方案将日志数据持久化，本实施例中的状态机采用开源的嵌入式 KV缓存软件RocksDB作为数据落盘的工具，元数据服务的各节点都维护有本地的状态机，负责将日志数据应用到状态机中，最终将数据落盘。

可选地，leader节点生成日志条目或follower节点完成日志复制后，日志数据并不会马上应用到状态机，而是通过commit index的机制，保证日志数据能被正确的使用。需要说明的是，commit index机制是一种多数派机制，即在leader节点向follower发送日志复制请求时，会先统计所有follower已复制的日志索引(match_index)，并计算出多数派(N/2+1)的最大索引值(max(index))。计算完成后，将最新的索引与本地的 commit_index做比对，如果new_index>commit_index，则将commit_index更新，完成 commit_index的推进工作，同时将最新的commit_index通过日志复制请求，发送到各 follower节点。follower在接收到最新的commit_index后，即可通过状态机将 commit_index之前的所有未应用的日志条目(apply_index)，应用到状态机中。

状态机的应用操作，是真正将实体对象元数据落盘的操作。本实施例中的状态机会解析日志条目中的数据字段(data)，将code元素作为key，data本体作为value，通过RocksDB.put方法，持久化到KV缓存中。

图6是快照的工作流程示意图，如图6所示，图中总共有7条日志，快照位置在index:5。新增节点后，leader向follower发送快照文件，文件内容经过压缩，只保留了数据的最终值，忽略了冗余的日志数据。follower在安装完成后，继续append index:6-7 的日志数据，最终完成日志的追赶。容易注意到的是，快照的目的是为了压缩日志容量，节点重新加入集群，或新增节点是快照的典型使用场景。在实体对象元数据的管理过程中，日志数量往往远远大于实际的元数据数量。低代码开发人员在针对同一实体对象做反复修改操作时，会产生多条日志。而在新增节点或节点重新加入集群的场景中，如果需要重放执行所有的日志，以达到节点数据追上leader、同步日志的目的，会造成大量的网络、IO开销，耗费大量时间。

快照的创建：本实施例通过快照机制，压缩日志容量、降低节点初始化时的服务器资源开销、达到快速装载、新增节点的目的。各节点在本地维护快照执行时间 snapshot_period，并开启任务线程，每隔一段时间在本地执行一次快照动作。快照的内容分为两部分，分别是配置信息快照metadata_snapshot、数据文件快照 data_file_snapshot。配置信息快照用来保存当前节点的lastIncludedIndex、 lastIncludedTerm、以及当前集群的节点信息servers等，数据文件快照用来保存当前已应用到状态机的数据文件,通过RocksDB.checkPoint操作来实现数据文件的备份。

快照的状态：leader在新节点申请加入到集群后，会向该节点发出快照装载的指令installSnapshot(peer)，并发送最新的快照文件。新节点在接收到快照文件后，首先加载metadata数据，接着加载数据文件datafile，状态机通过RocksDB.open实现数据文件的加载。

快照数据加载完成后，新节点会从快照数据的最大日志索引开始，到leader最新的commit index为止，批量复制剩余的日志数据，并应用到状态机，完成数据的追赶。

分布式***面临的CAP问题，即一致性、可用性、分区容忍性，三者无法同时满足；在分布式场景下，多节点部署导致应用分区的情况一定存在，本实施例作为分布式存储的应用场景，选择牺牲可用性，满足数据强一致性的需求，即集群能接受在短时间内的不可用状态。

本实施例基于strong leader的机制，leader election需要多数派(N/2+1)达成一致，因此集群能在N/2-1个节点失效的情况下，保证整体服务仍然可用。

图7展示了集群因网络分区导致的服务不可用情况，如图7所示，发生服务分区时，follower尝试成为leader，一直发起选举投票，term无限增长；分区恢复后，因term 差距过大导致持续的选举事件，leader处于stepdown状态，集群服务不可用。即在集群发生网络分区时，节点1会不断发起选举操作，导致本地term一致增加，在网络恢复后，由于节点1的term领先太多，而内容落后，会导致集群内长时间的处于选举状态，本实施例通过pre_vote的机制来避免类似问题。

选举分为两个阶段，在正式的vote之前，候选人会先将自己的身份变更为 pre_candidate，发起pre_vote请求，并等待其他节点的响应结果。如果本地任期小于响应节点的任期，则本地节点降级为follower；当得到半数以上的节点投票以后，才会转换状态为candidate，并发起真正的vote请求。pre_vote机制保证了节点1在无法得到多数派投票，无法发起正式的vote请求，从而保证了分区恢复后leader节点的正常运行。

需要说明的是，分布式一致性协议有多种实现方式，如Paxos、Raft、ZAB、Gossip等，分别用于实现强一致性、弱一致性等不同需求。另外，公链、联盟链、私链的共识机制也有多种，可分别在不同的应用场景中处理共识、一致性、身份伪造、共识成本等相关问题。本申请主要用于处理分布式***中的数据一致性问题，对一致性协议的选择以及共识机制所采用的具体技术不作具体限制。

图8是根据本申请实施例的一种代码管理装置的结构示意图，如图8所示，该装置包括：

响应模块40，用于响应于目标对象的操作指令生成可视化编程对象；

转换模块42，用于将可视化编程对象转换为预定格式的元数据；

存储模块44，用于将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性。

该代码管理装置中，响应模块40，用于响应于目标对象的操作指令生成可视化编程对象；转换模块42，用于将可视化编程对象转换为预定格式的元数据；存储模块44，用于将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性，达到了将元数据通过日志形式的进行存储的目的，从而实现了对相关技术中代码管理方案进行优化，实现代码快速部署，弹性扩容，实现元数据集群化，高可用的技术效果，进而解决了由于相关技术中基于关系型数据库管理代码存在运维管理复杂，集群成本高，无法快速弹性扩容等技术问题。

根据本申请实施例的另一方面，还提供了一种非易失性存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述代码管理方法。

根据本申请实施例的另一方面，还提供了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行指令，以实现上述代码管理方法。

具体地，上述存储介质用于存储以下功能的程序指令，实现以下功能：

响应于目标对象的操作指令生成可视化编程对象；将可视化编程对象转换为预定格式的元数据；将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性。

在本申请相关实施例中，采用日志存储的方式，通过响应于目标对象的操作指令生成可视化编程对象；将可视化编程对象转换为预定格式的元数据；将元数据通过日志形式存储至集群服务管理器中，其中，集群服务管理器包括多个分布式节点，多个分布式节点之间满足数据状态的一致性，达到了将元数据通过日志形式的进行存储的目的，从而实现了对相关技术中代码管理方案进行优化，实现代码快速部署，弹性扩容，实现元数据集群化，高可用的技术效果，进而解决了由于相关技术中基于关系型数据库管理代码存在运维管理复杂，集群成本高，无法快速弹性扩容等技术问题。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种代码管理方法，其特征在于，包括：

响应于目标对象的操作指令生成可视化编程对象；

将所述可视化编程对象转换为预定格式的元数据；

将所述元数据通过日志形式存储至集群服务管理器中，其中，所述集群服务管理器包括多个分布式节点，所述多个分布式节点之间满足数据状态的一致性。

2.根据权利要求1所述的方法，其特征在于，所述集群服务管理器中的多个分布式节点在同一时刻只能存在一个主节点，客户端的操作请求由该主节点执行，并由该主节点向从节点复制日志；且所述集群服务管理器由所述主节点还用于向从节点发起心跳连接，并在接收到超过预设数量的从节点的响应的情况下，对日志状态进行变更。

3.根据权利要求2所述的方法，其特征在于，将所述元数据通过日志形式存储至集群服务管理器中，包括：

接收客户端的数据请求，其中，所述数据请求至少用于向所述集群服务管理器中写入所述元数据；

将所述元数据转换为有序的日志文件，通过所述主节点向多个从节点复制所述日志文件，在得到预设数量的从节点响应的情况下，更新当前的提交索引值，得到目标提交索引值，并将所述目标提交索引值发送至从节点，以用于将所述从节点的日志文件应用到状态机；

控制所述状态机解析所述日志文件中的实体对象元数据信息，从解析结果中获取全局唯一的对象编码以及对象属性字段；

以所述对象编码为标识信息，所述对象属性字段为属性值构建键值对，对所述键值对进行缓存。

4.根据权利要求3所述的方法，其特征在于，所述集群服务管理器的多个分布式节点之间通信的消息类型至少包括：选举；

在所述多个分布式节点之间通信的消息类型为所述选举的情况下，所述多个分布式节点中的每个节点将生命周期划分为连续的多个任期，所述多个任期中的每个任期内只有一个主节点，其中，所述任期包括：选举期与运行期。

5.根据权利要求4所述的方法，其特征在于，所述选举的过程包括：

检测主节点是否发生故障；

在确定所述主节点发生故障的情况下，在确定各个从节点中的任意一个节点失去心跳的第一时长大于预设时长后，确定待发起选举请求的目标从节点；

将所述目标从节点确定为候选人节点。

6.根据权利要求1所述的方法，其特征在于，所述集群服务管理器的多个分布式节点之间通信的消息类型至少包括：日志复制，所述日志复制通过如下方式实现：

主节点接收到客户端的数据请求，将所述数据请求对应的数据确定为最新的日志数据；

将所述日志数据加载至日志集合中的末位，并向所述多个从节点广播日志复制请求；

在接收到超过预设数量的从节点的响应的情况下，将提交索引更新为当前已确认的日志数据的目标索引，并将所述目标索引发送至从节点；控制所述从节点将所述目标索引为止的所有未执行的日志条目加载到状态机中执行。

7.根据权利要求6所述的方法，其特征在于，所述多个分布式节点中的各个分布式节点的日志文件采用分段保存的方式持久化在本地文件中，其中，各分段日志通过元数据维护当前日志段的基本信息，所述基本信息包括：当前任期、起始日志编号，已提交的最新日志编号。

8.一种代码管理装置，其特征在于，包括：

响应模块，用于响应于目标对象的操作指令生成可视化编程对象；

转换模块，用于将所述可视化编程对象转换为预定格式的元数据；

存储模块，用于将所述元数据通过日志形式存储至集群服务管理器中，其中，所述集群服务管理器包括多个分布式节点，所述多个分布式节点之间满足数据状态的一致性。

9.一种非易失性存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行权利要求1至7中任意一项所述代码管理方法。

10.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至7中任一项所述的代码管理方法。