研发协同平台持续交付2.0架构演进

源宝导读：为了打通CI/CD环节，实现持续的端到端的交付能力，RDC平台提供了在线化的更新服务，随着业务量增长与场景的需要，我们对更新服务架构重新设计，实现了2.0版本。本文将介绍更新服务2.0的架构演进过程与实践。

一、ERP的部署架构

    在谈更新服务之前我们先了解一下ERP现存的部署架构，ERP产品以建模平台为底座，开发有成本、售楼、计划、采招等产品及对应的二开项目，同时依赖配置中心、中台服务等配套服务。依据客户的不同规模提供不同的部署方案，部署方案的复杂程度决定了更新的过程的难易程度。在RDC接入更新服务之前，产品及二开团队出包后需要联系一线进行线下更包，架构的复杂程度越高，线下更新的代价越大。更新服务1.0的出现了解决这一痛点：一线人员通过访问ERP站点更新链接即可跳转到更新页面实现一键更新。

    ERP部署架构如下图所示：

二、更新服务1.0架构

    应用层ERP产品如建模平台、成本系统、售楼系统、计划系统、采招系统及各种配套服务通过代理服务接入到RDC CD管道（Pipeline），代理服务对外输出持续交付能力：

• 客户在线状态心跳监测

• 产品注册上报

• 产品更新检查

• 产品持续部署

    那代理服务是如何做到这些的呢？

三、更新服务1.0设计

更新服务1.0更新包时序图：

    尽管1.0的更新服务完成了打通CD环节实现了端到端的持续交付但依然存在一些不足：

• 更新效率低；

• 扩展性 - 后期ERP代理服务不单是处理更新，还要能扩展处理其他业务，例如商城插件的安装、卸载、更新。扩展性已经考虑了，只是缺乏插件的定义规范；

• 稳定性 - 主要表现在现有机制下，后去下一步执行步骤出错（预先将下一步放在一个表）；

• 日志和异常 - 异常日志和异常出错指引，日志的显示要明晰；

• 设计到更新的表结构设计不合理：插件自身定义和插件步骤定义没有分开，更新包状态的维护。过程中会涉及到不少联合查询做业务的场景，互相依赖。原则：单实体职责单一，同时相应处理接口，职责也要单一；

• 代码实现数据脚本式。

功能也存在不足：

• 获取一条指令错误；

• 更新状态挂起，一直是进行中，即不成功，也不失败；

• 错误日志不明晰，出错的情况下难以快速定位到出错步骤；

• 包的更新状态没有维护，查询时得实时从多个表中计算包的状态，效率很低。

四、更新服务2.0架构

    将代理服务重构，支持动态插件加载，解决扩展性不足，实现守护插件解决稳定性不足同时重新设计了日志的采集机制解决了日志记录上的不足。
    重构了更新逻辑解决更新性能及设计上的不足：

• 重新定义了插件的设计：解决1.0中未从代码层面约定插件的定义问题；

• 解耦执行命令与更新业务**：**解决1.0中设计上扩展性不足的问题；

• 解耦更新插件对更新服务的强依赖：可实现一键离线更包解决一线线下更包时需要在服务器上进行手动盖包、执行sql、元数据同步修改mysofverion等复杂高危操作的痛点；

• 解耦更新步骤与更新步骤控制逻辑：让插件开发者只用关心插件本身的业务不用考虑负载等场景中如何对执行流程进行控制；

• 优化更新列表查询慢问题；

• 重构更新服务数据库设计及实现方案：解决1.0中表设计不合理及引发的更新性能问题；

• 重新设计了插件日志规范:解决1.0中日志设计的不足将业务日志与通用诊断日志进行区分，业务日志提供更友好的格式化日志呈现，详细的诊断日志提供线上问题分析；

• 设计超时机制及补偿机制：解决1.0中更新超时或状态异常时导致更新状态挂起的问题；

• 设计重试机制：提升更新成功率；

• 设计守护插件：提高代理服务自身的稳定性。

五、更新服务2.0设计

更新服务2.0更新包时序图：

对比时序图我们可以发现2.0在命令设计这块有以下明显区别：

1、命令设计不同：1.0一次更新过程按步骤拆分成若干步骤（如下载更新包、备份等）而2.0仅为一条命令从而减少了心跳的周期；

2、更新流程控制方式不同：1.0依据服务端运算并下发下一步的更新命令而2.0则在客户端自行控制更新流程从而效率更高；

3、设计有补偿机制：解决服务器状态异常或执行挂起时修复执行状态保证更新过程的稳定性避免过多的人工干预。

小结一下：

    对比1.0的时序图我们不难发现，2.0只需要一次心跳轮询即可完成整个更新过程，而在1.0中每一步执行都依赖于心跳轮询，负载环境更新时还需要依赖心跳轮询机制保证每台服务器执行步调一致且1.0的服务端还需要根据当前步骤执行结果计算出下一步需要分发出去的执行命令，而2.0服务端一次完成命令下发，客户端根据命令及服务端提供的执行状态自行完成更新过程所以2.0执行效率要更高，更新服务1.0单包平均更新时间约为3分钟，更新服务2.0为50秒左右效率提升大约3倍以上详见下表：

更新服务V2更新效率

六、写在最后

    更新服务2.0设计解决了1.0中暴露出来的一系列问题，更新效率也大幅提高，然而没有最好的设计只有更合适的设计。目前更新服务2.0还有一些有待提升的地方，比如更新流程未实现逐步回滚，基于更新插件扩展其他业务插件尚不够完善。展望未来更新插件将以更新插件核心框架作为更新底座，提供完善的流程控制逻辑和更新控制，各种更新业务插件以底座为依托实现自己更新业务，最终实现ERP全系产品的端到端高效交付流程。

------ END ------

作者简介

王同学： 研发工程师，目前负责RDC平台的设计与开发工作。

也许您还想看

研发协同平台持续集成Jenkins作业设计演进

研发协同平台持续交付之代理服务实践

研发协同平台持续集成2.0架构演进

链路追踪在ERP系统中的应用实践