技术领域
[0001] 本
发明属于计算机处理技术的服务发现领域，具体涉及一种基于zookeeper的智能代码发布告警系统。
背景技术
[0002] ZooKeeper是一个分布式的，开放源码的
分布式应用程序协调服务，是Google的Chubby一个开源的实现，用于为分布式应用提供一致性服务。zookeeper是基于内存同步数据，即集群内的
节点在内存中的数据结构是完全相同的，应用于具体的分布式环境中，能保证客户端在设定的时间间隔内获得
服务器更新信息或服务器失效信息，突破网络延迟的限制，提高客户端消息获取实时性。
[0003] 随着互联网网购需求的急剧增大，各种大型互联网网上销售平台频频上架，而各大平台的产品及业务不断更新壮大，三天一小改，一周一版本成为各大平台吸引网民主流手段之一。因而能确保线上稳定、容错率高的代码发布系统在版本频繁更新过程中就起到了至关重要的作用。
[0004] 传统的代码发布系统需要人工参与,仍停留在纯人工发布的阶段。当平台上的业务有开发上线的需求时，将业务划分为多个子模
块分配给多个技术人员，由各个技术人员负责对各子模块的代码
修改整合，最终各子模块的代码合并后进行发布更新。技术上的实现方式是通过Master主支下拉出多个代码分支，由多个技术人员负责各分支上的代码编制和修改，各分支代码编制完毕后合并至master主枝，如图1所示。然而这种开发上线模式存在两种
缺陷：
[0005] 其一，开发与开发、分支与分支之间存在代码
覆盖。在开发1和开发2同属于一个分支的情况下，若两个开发者同时对某java文件进行修改，将会在合并到分支时,容易造成因人为审查疏漏而导致的代码覆盖或者程序处理紊乱的问题，为合并后修复bug带来不必要的工作量。此外，如果分支1负责编制版本1，分支2负责编制版本2，当这两个紧急版本同时上线时，将会造成不必要的bug频频出现，影响生产环境的正常运行；
[0006] 其二，没有有效的告警及通知方案。紧急修复漏洞时通常不会走正常流程，而是在没有通知所有技术人员的情况下，直接通过修改某一发布文件的方式修补漏洞，修改后的文件将覆盖原始文件，但由于这一紧急修复过程未及时通知所有技术人员，将导致所有技术人员仍旧会继续在原始文件中做内容更新，进一步造成原始漏洞在系统再上线时出现故障；。
[0007] 区别于传统的代码发布系统，智能代码发布告警系统因“智能判断”和“智能告警”的特征，越来越引起互联网企业的重视。所谓智能代码发布告警系统是指通过各模块代码发布节点进行智能筛选判断后，及时准确的进行告警，从而降低手工发布带来的代码覆盖、代码丢失造成的问题，提高资源的利用率，增强系统的整体
稳定性。虽然现如今各大公司在投入成本改进传统的代码发布系统，但他们始终没有跳出“人为参与代码的合并、代码容错”这一过程。
[0008] 综上所述，如何减少人工干预，增强代码发布过程的智能型是值得我们技术人员思考和解决的问题。
发明内容
[0009] 为解决上述的问题，本发明的目的是提供一种能用于解决因多分支或多人员开发而造成的代码覆盖问题频繁出现的问题，以提高应用系统版本更新的效率和稳定性。
[0010] 一种基于zookeeper的智能代码发布告警方法，通过利用zookeeper高效的实时同步性，将某个开发项目主支和分支的所有文件进行节点注册，当某一节点发生变化时，zookeeper能高效地检索到某节点对应的某文件被某一技术人员或在某一分支进行修改，实时推送检索结果给相关技术人员进行及时处理。本技术方案具体如下：
[0011] 步骤1：依据ZooKeeper的主从架构，构建主支和与之相连的分支，其中主支上存放处于生产环境中的应用系统发布文件，分支数量根据应用系统研制任务的细化进行划分，每个分支上存放从主支上复制下来的系统发布文件；
[0012] 步骤2：将分布在主支和分支上的应用系统发布文件均注册为文件节点，形成多套节点配置结构；具体为：为分布在主支上应用系统发布文件建立节点，形成主节点；为从主支复制在各分支上的系统发布文件建立节点，形成
子节点；
[0013] 步骤3：将子节点已更新的应用系统发布文件继续上传至上一层主节点；上一层主节点更新当前的应用系统发布文件，并将已更新的应用系统发布文件联合变更文件名、变更子节点标识名、变更人标识名，打包成一个消息包传到该主节点下其他所有子节点；如若在同一时间内，有多个子节点上传新的应用系统文件至上一层主节点，上一层主节点将根据预先设定的处理规则，有顺序地接收已更新的应用系统文件；
[0014] 步骤4：当主节点下其他所有子节点收到消息包时，根据消息包中的变更文件名，与自身负责编制的应用系统发布文件比对，以判定消息包中的应用系统发布文件和子节点处的应用系统发布文件是否存在修改冲突，如若不存在冲突，各子节点按照消息包中的变更文件标识名更新应用系统发布文件，至此从主节点到子节点，再到子节点下各分支的应用系统发布文件保持一致性；如子节点存在修改冲突，一方面存在冲突的子节点根据消息包中的变更子节点标识名和变更人标识名，与变更子节点下的变更人联系确认；一方面及时告警给变更子节点下的变更人；
[0015] 特别地，所述步骤2中还包括：
[0016] 步骤2-1：根据任务的细分，子节点继续分化为多个子分支，每个子分支复制子节点上的应用系统发布文件，并将应用系统发布文件分配给本地环境内多个技术人员；多个技术人员能同时对获取到的应用系统发布文件进行修改和补充；
[0017] 步骤2-2：同一个子节点下的多个技术人员按照各自的编制任务对应用系统发布文件编制和修改，待修改完成后，上报修改的文件
位置，并将新的应用系统发布文件上传至上一层的子节点；上一层子节点更新当前的应用系统发布文件，并将已更新的应用系统发布文件联合变更文件名、变更人信息，打包成一个消息包传到该子节点下所有子分支的技术人员；如若在同一时间内，有多个技术人员上传新的应用系统文件至上一层子节点，上一层子节点将根据预先设定的处理规则，有顺序地接收已更新的应用系统文件；
[0018] 步骤2-3：当同一子节点下所有子分支的技术人员收到消息包时，根据消息包中的变更位置信息，与自己当前对应用系统发布文件修改位置进行比对，以判定消息包中的应用系统发布文件和技术人员自己的应用系统发布文件是否存在修改冲突，如若不存在冲突，技术人员按照变更位置更新应用系统发布文件，转步骤6；如若存在冲突，一方面告警技术人员根据消息包中变更人信息，与变更人联系确认；另一方面告警应用系统发布文件的变更人；
[0019] 特别地，一个应用系统的编制对应唯一的主从架构；所述主支代表一个应用系统从编制到发布这一过程的
时间线；所述分支代表在应用系统编制过程中对系统发布文件的编辑和修改时间点；
[0020] 特别地，一个应用系统发布文件涉及到多个文件，在注册节点时，将应用系统发布所涉及到的所有文件注册为一个文件节点；
[0021] 特别地，从主支分化的分支数量(即主节点下的子节点数量)、以及每个子节点下分化的子分支数量根据应用系统编制过程中涉及到的实际编制任务决定；每个子节点及子节点下各个分支承担不同的编制任务，负责编制和修改的发布文件会存在交集；
[0022] 特别地，主节点和子节点、及子节点下分的各个子分支均具备唯一的标识名，用于各自身份的区分；
[0023] 特别地，所述多套节点配置结构是指主节点与相连子节点、以及子节点下的各个分支形成的结构；
[0025] (1)本发明通过利用zookeeper各节点之间高效的统一性，当单个文件存在由多个人员或在多个分支上共同修改时，及时且高效地识别修改冲突并报警，减少人为纠错环节,保证技术人员提交代码后，能即时知道同时执行修改操作的其他人，有效避免开发合并代码和分支合并时引发的代码冲突和代码覆盖问题；
[0026] (2)本发明通过为各节点配有唯一标识名，区分多套节点配置中的主节点和子节点，当冲突报警发生时能根据存在问题的节点标识名准确
定位，有利于问题的快速排查，并及时处理问题。
附图说明
[0027] 图1为现有技术中传统代码发布系统的技术实现示意图；
[0028] 图2为本发明
实施例中基于Zookeeper的智能代码发布告警方法实现的系统结图；
[0029] 图3为本发明实施例中基于Zookeeper的智能代码发布告警方法实现流程。具体实施例
[0030] 为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。
[0031] 图2为本发明实施例中基于Zookeeper的智能代码发布告警方法实现的系统结构图，当前有一个名为“Apollo”应用系统(简称为Apollo系统)要发布上线，涉及到的系统发布文件有：index.html、style.css、index.js，按照Zookeeper的主从架构构建主支和分支，其中，一条主支代表特定某一个应用系统的发布线；分支则代表在某一特定应用系统发布文件从编制、修改到正式发布这一过程中的某一个时间点；
[0032] 根据Apollo系统发布的研制任务，现有如下3个任务，即在首页增加搜索功能、首页注册登录功能、会员中心页修改头像大小，因而主支下分为3个分支；分别为分布在主支和分支的系统发布文件(具体含有index.html、style.css、index.js、member.css[0033] )注册文件节点，形成主节点index.code.master(下文简称为：master)、多个子节点index.code.node1，负责首页增加搜索功能的任务；index.code.node2，负责首页注册登录功能的任务、index.code.node3，负责会员中心页修改头像大小的任务；子节点下的子分支是否继续细化取决于应用系统编制任务是否继续细化；在本发明实施例中，各子节点下分为各个分支index.code.node1-1(附图中简称为node1-1)，负责index.html的文件编制；index.code.node1-2(附图中简称为node1-2)，负责style.css的文件编制，index.code.node1-3(附图中简称为node1-3)，负责index.js和style.css的文件编制；
index.code.node2-1(附图中简称为node2-1)、index.code.node3-1(附图中简称为node3-
1)、index.code.node3-2(附图中简称为node3-2)，每个子节点下的各个分支均由本地环境中的技术人员代表；
[0034] 主节点与相连子节点、以及子节点下的各个分支形成多套节点配置结构，即指主节点与相连子节点、以及子节点下的各个分支形成的结构；在告警阶段，按照主节点和相连子节点的主从结构、子节点与子节点下各个分支的主从结构，形成多阶段的告警；且主节点、子节点及子节点下的各个分支均有唯一的标识名，用于各自身份的区分；
[0035] 基于图2的本发明实施例中的Zookeeper结构，本发明实施例中基于Zookeeper的智能代码发布告警方法实现流程参阅图3所示，通过利用zookeeper高效的实时同步性，按照任务划分，形成用于研制Apollo系统的多套节点配置结构；在这一结构中，通过分布在主支和分支的所有文件进行节点注册，形成一个主节点和多个子节点，当某一节点发生变化时，zookeeper能高效地检索到某节点对应的某文件被某一技术人员或在某一分支进行修改，实时推送结果给相关技术人员进行及时处理；具体步骤包括：
[0036] 步骤301：依据ZooKeeper的主从架构，构建主支和与之相连的分支，其中主支上存放处于生产环境中的应用系统发布文件，分支数量根据Apollo系统研制任务的细化进行划分，每个分支存放从主支上复制下来的系统发布文件；其中，本发明实施例中Apollo系统发布文件由index.html、style.css、index.js、member.css组成；
[0037] 按照本发明实施例分任务划分，主支下分化为3个分支，分别负责Apollo系统中首页增加搜索功能、首页注册登录功能、会员中心页修改头像大小这三个任务；
[0038] 步骤302：注册文件节点，包括在主支和分支上注册文件节点，形成多套节点配置结构；具体为：为主支上系统发布文件建立节点，形成主节点index.code.master(下文简称为：master)；为复制在各分支上的系统发布文件建立节点，形成子节点index.code.node1(简称为node1)、index.code.node2(简称为node2)、index.code.node3(简称为node3)；
[0039] 步骤303：根据任务的细化，子节点将继续分化为多个子分支，比如index.code.node1分化为index.code.node1-1(简称为node1-1)、index.code.node1-2(简称为node1-1)、index.code.node1-3(简称为node1-1)，每个子分支复制子节点上的系统发布文件，包括index.html、style.css、index.js、member.css，并将这4个文件分配给处于本地环境内的多个技术人员；多个技术人员能同时对获取到的系统发布文件进行修改和补充；
[0040] 以index.code.node1-1的任务细分为例，首页增加搜索功能的任务细分为编制文件index.html、编制文件style.css、编制文件index.js和style.css，子节点index.code.node1-1根据上述3个任务，向下分化为3个子分支，每个子分支由一个技术人员负责；其中node1-1负责编制文件index.html，node1-2负责编制文件style.css，node1-3负责编制文件index.js和style.css。
[0041] 步骤304：同一个子节点下的多个技术人员(.node1-1、node1-2、node1-3)按照各自的编制任务对文件编制和修改，待某一个技术人员编制完成后，比如.node1-2的技术人员完成对style.css的编制和修改，上报修改的文件，并将新的应用系统发布文件上传至上一层的子节点node1；上一层子节点node1更新Apollo系统发布文件，并将已更新的应用系统发布文件联合变更文件名、变更人信息，打包成一个消息包传到该子节点下其他所有子分支的技术人员，比如将node1-2编制完成的Apollo系统发布文件传给node1-1、node1-3；
[0042] 如若在同一时间内，node1-1和node1-2上传新的应用系统文件至上一层子节点，上一层子节点node1将根据预先设定的处理规则，有顺序地先接收和处理node1-1上传的Apollo系统发布文件，再接收和处理node1-2的上传Apollo系统发布文件；
[0043] 步骤305：当同一子节点下所有子分支的技术人员收到消息包时，根据消息包中的变更文件名，与自己负责修改的应用系统发布文进行比对，以判定消息包中的应用系统发布文件和技术人员自己的应用系统发布文件是否存在修改冲突，如若不存在冲突，技术人员按照变更位置更新应用系统发布文件，转步骤6；如若存在冲突，一方面告警技术人员根据消息包中变更人信息，与变更人联系确认；另一方面告警应用系统发布文件的变更人；
[0044] 比如：当node1-1、node1-3收到消息包时，根据消息包中的变更文件名，与自己当前对应用系统发布文件的编制和修改进行比对：node1-1的技术人员编制文件index.html与node1-2编制的style.css不存在任何修改冲突，node1-1直接按照node1-2的修改更新自己的Apollo系统发布文件；而node1-3编制的index.html和style.js和node1-2编制的style.css存在文件交集，node1-2的修改将会影响node1-3的文件编制，同时向node1-2技术人员和node1-3技术人员发出告警信息，提醒双方技术人员联系确认；
[0045] 步骤306：将子节点已更新的应用系统发布文件继续上传至上一层主节点，比如node1将修改文件index.html的信息传给主节点master；主节点master更新Apollo系统发布文件，并将已更新的应用系统发布文件联合变更文件名、变更子节点标识名、变更人标识名，打包成一个消息包传到该主节点下所有子节点；比如将node1编制后的Apollo系统发布文件传给node2、node3；
[0046] 步骤307：当主节点下其他所有子节点收到消息包收到消息包时，比如node2、node3，根据消息包中的变更文件名，与自身当前对应用系统发布文件的编制和修改进行比对，如若不存在冲突，各子节点按照消息包中的变更文件名更新应用系统发布文件，至此从主节点到子节点，再到子节点下各分支的应用系统发布文件保持一致性；如子节点存在修改冲突，一方面存在冲突的子节点根据消息包中的变更子节点标识名和变更人标识名，与变更子节点下的变更人联系确认；比如：node3负责编制的文件member.css与node1已完成编制的index.html不存在任何修改冲突，node3直接按照node1的修改更新自己的Apollo系统发布文件；node2负责编制的index.html、style.css、index.js和node1已完成编制index.html存在文件交集，同时向node1和node3发出告警信息，提醒双方负责index.html编制的技术人员联系确认；
[0047] 所属领域的普通技术人员应当理解：以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
