asp 网站后台,html网站开发中的应用,建立网站免费,建筑工程公司资质在上篇《研发协同平台持续集成实践》一文中我们分享了为什么要做持续集成#xff0c;技术选型#xff0c;工作原理以及实践落地。今天我们从架构上来分享一下架构层面的设计和演进。持续集成1.0在最开始设计的过程中#xff0c;本着一切从需求出发#xff0c;一切以实现业务… 在上篇《研发协同平台持续集成实践》一文中我们分享了为什么要做持续集成技术选型工作原理以及实践落地。今天我们从架构上来分享一下架构层面的设计和演进。持续集成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 ------作者简介陆同学 架构师负责研发协同平台产品的架构规划与设计工作。也许您还想看研发协同平台持续集成实践如何解决大批量数据保存的性能问题【复杂系统迁移 .NET Core平台系列】之界面层【复杂系统迁移 .NET Core平台系列】之迁移项目工程
