在上篇《研发协同平台持续集成实践》一文中我们分享了为什么要做持续集成,技术选型,工作原理以及实践落地。今天我们从架构上来分享一下架构层面的设计和演进。
持续集成1.0
在最开始设计的过程中,本着一切从需求出发,一切以实现业务为原则,我们对主要的业务需求进行了梳理:
开发人员希望能快速交付需求
测试人员希望在开发人员完成开发后,能够快速根据新的代码集构建独立的环境进行测试验证
不同需求的交付互不影响
为ERP产品服务
一个ERP站点,一个数据库
对上述需求进行整理和挖掘后,我们在设计上整理出以下几点:
一个需求,创建一个新的分支进行开发交付,以需求为最小单元进行交付。
一个分支,构建一个独立的ERP站点进行测试,这里一个ERP站点就是一个测试环境。
一个ERP站点,对应一个独立的数据库
需求、分支、ERP站点、数据库是一一对应的关系
在业务上以需求为出发点,在使用上以分支为操作单元,这样做的优点是:
用户使用便捷:
创建分支,绑定需求
拉取分支代码开发、自测
提交分支,以分支为单元构建环境测试
能快速实现,进行发布验证
在上面的设计中,以分支出发来构建站点,那么一个ERP站点包含什么,如何构建以及销毁呢?
ERP站点组成- 一个可运行ERP站点包括站点程序集、配置和数据库
站点程序集- 通过代码仓库中的分支代码编译产生
配置- 包括本地开发默认配置、测试环境默认配置和自定义配置。默认配置从代码仓库模板中来;自定义配置,按照约定放在代码仓库中的自定义配置目录下,由用户自行选择配置目录来确定。
数据库- 在创建分支时,创建数据库,从最新测试基准库还原而来,基准库每天会定时备份
站点构建
站点销毁
在需求交付以后,平台会自动销毁需求对应的开发分支,同时也会销毁分支对应的ERP站点。
销毁构建记录
销毁站点容器
销毁对应的数据库
持续集成1.x
持续集成1.0版本在上线以后,可以覆盖核心业务场景,但是随着应用的深入,场景也越来越多,其中两个主要需求场景是:
需求测试除了ERP站点,还依赖其它服务:
ERP系统中的文档上传,浏览等功能依赖文档服务
ERP系统中的审批相关功能依赖工作流服务
ERP系统和其他系统之间的集成依赖集成服务
1.0版本一个分支只能构建一个站点, 这一些场景下需要从一个代码分支构建出多个站点,做不同需求的测试
上面的两个需求中,出现了两个比较大的变化:
一个完整的测试环境,不单单包含一个ERP站点,还包括其他应用服务。这打破原有的一个站点,一个环境的设计
一个代码分支,可构建出多个对应的站点(多个环境),这打破原有的的一个分支一个站点的设计
这时的需求,原有的设计本质上已不能满足,有两个核心要素缺失:
原有的设计是构建一个ERP站点,但更合理的是要构建一个可供测试的环境,这个环境可以只包括一个ERP站点,也可以包括其他的应用服务
原有的设计师一个分支构建一个站点(一个环境),但合理的是环境应该可灵活定义。一个环境即可以从一个分支构建而来,也可以从多个分支构建而来。多个不同的环境也可以从相同的分支构建而来。
按照更加合理的设计,在构建的架构设计上是需要做比较大的改动的。但是基于当时正在做持续集成1.0的推广,一旦进行大的改动,影响面比较大。综合评估影响面,资源方面的因素,最终决定不对架构做重构,只在功能上实现做改进来实现需求。
进一步分析新的需求场景:
ERP站点锁依赖的服务,是都为ERP系统功能服务的,我们定义它们为配套服务。并且这些配套服务(文档服务、工作流服务、集成服务)都是现有的直接可运行的服务,并不需要从代码构建而来。所以可以直接准备好可运行的服务镜像,启动容器即可。不过这里有两个需要注意的点是:
ERP的版本和服务镜像的版本是有匹配关系的,并不能完全做到向下兼容
ERP所依赖的这些应用服务和ERP耦合都还比较紧,在这些应用服务部署完成后,还需要修改ERP的配置,这里包括文件配置和数据库配置都要做调整
针对一个分支构建多个环境的需求,我们当时的策略是克隆分支,再从克隆分支上部署一个站点(环境)
针对上述需求,重点是要实现配套服务的持续构建。那么配套服务包含什么,如何构建和销毁呢?
配套服务的组成-配套服务包括服务容器镜像和配置服务镜像- 由相应的服务团队提供可运行程序集,研发系统平台团队依此构建服务镜像以及维护服务镜像和ERP版本之间的关系
配置-在ERP系统的配置文件和数据库中,添加相应的配套服务配置信息。在配置服务中,添加ERP系统配置信息
配套服务构建
配套服务销毁
在删除配套服务时,会销毁配套服务:
销毁配套服务容器
删除ERP系统中的配套服务配置信息
持续集成2.0
持续集成1.x版本在功能上已能很好的满足用户需求,但是随着ERP2.0的发布,ERP产品提供了更加灵活的部署架构来支撑万亿级客户。主要包括集中部署不分库,分离部署分库和分离部署不分库。
分离部署 - ERP的各个子系统分开部署为各个独立的子站点
集中部署 - 所有的ERP子系统部署在一起,一个ERP站点
分库 - ERP的各子系统独立使用各自的数据库
不分库 - ERP的子系统都使用一个数据库
集中部署不分库:ERP(包含售楼、成本、计划系统)部署在一起,一个站点,使用一个数据库
分离部署分库:售楼系统部署为主站,成本系统和计划系统部署为从站。主站使用一个数据库,从站使用另外一个数据库
分离部署不分库:售楼系统部署为主站,成本系统和计划系统部署为从站。主站和从站都使用同一个数据库
客户如果是分离部署,这就要求原有的ERP产品开发必须拆分成各个子系统,因为各个子系统的系统是分离的,它们的需求需要分开独立交付。尽管在开发模式上各个子系统是独立的,但ERP系统作为一个完整的产品,各子系统之间是需要频繁的集成在一起测试的。并且在分库的场景下,一个环境也不在只对应一个数据库。
分离部署 - 要求一个环境包含多个站点(服务)
集中部署 - 要求一个站点(服务)可以从多个代码分支构建
分库 - 要求一个环境可同时使用多个数据库
针对上述支撑ERP2.0产品持续集成新的需求,结合1.X中配套服务的实现,我们对持续集成的整体架构设计做了重构
环境 - 一切以环境为核心,在持续集成中我们要构建的是可用的、针对不同用途的测试环境。环境可随时新增、删除,也可灵活配置。这样,用户可以随时新增、配置、构建一个用户想要的环境。
服务 - 一个测试环境由一个或多个服务组成,ERP站点是一个服务,文档服务也是一个服务,工作流还是一个服务。环境中的服务可灵活新增、配置、删除
数据库 - 数据库独立创建、删除,不再和分支绑定。在环境中灵活配置要使用的数据库,可配置一个或多个
持续集成管道 - 一种服务类型对应一个持续集成管道,ERP站点可定义自己的持续集成管道,工作流服务也可以定义自己的持续集成管道。每个持续集成管道由不同的作业组成。
作业 - 不同的作业相互组合构建成一个持续集成管道。一个作业又由不同的命令组合而成
命令 - 命令是持续集成过程的最小执行单元。研发协同平台定义了一批默认的命令集。不同命令可组合成不同功能的作业。
重构后,环境、服务、数据库即互相独立,又可以通过灵活的组合不同的服务和数据库来构建不同的环境,经过2.0的重构后,平台已经能全场景支撑用户的持续集成需求了。
写在最后
虽然当前的设计已经能很好的支撑当前的用户持续集成需求,但是ERP2.0产品还在不断进化,进化则带来更多的变化,协同平台也在持续支撑和改进,架构上也要持续的进行优化演进。
------ END ------
作者简介
陆同学: 架构师,负责研发协同平台产品的架构规划与设计工作。
也许您还想看