黑少微服务工具店测试及镜像化提测全流程实践

产品的技术架构从单体服务进行微服务化改造，解决了独立构建、更新、运维等一系列问题，但这也对微服务化项目的测试提出了更高的要求和挑战。目前黑少微服务工具店以DevOps的方式管理着诸多微服务，如图所示，容器服务项目微服务化特征明显、层次划分清晰：业务的微服务化改造提升了各模块部署上线的效率，但对微服务项目的测试团队带来了新的要求和挑战。从第一个葫芦岛SEO层面来讲，线上及线下环境多样化和复杂性决定了构建部署次数的频率。好的构建、部署工具可以提高构建部署时间效率从而节约开发人员和测试人员的时间，达到快速交付的目的。因此找到好的构建、部署工具和平台的重要性和优先级都是第一位的。另一个层面，容器化服务在提测模式，上线模式、分支管理上跟之前都有很大的不同，测试团队需要针对容器化服务特点在提测模式、分支管理、质量评价方面做出一些适配和优化，以适应容器化及微服务架构的特点，将完整的容器化持续集成流水线模式引入，以及将镜像质量评价打入元数据的实践探索。第三个层面，微服务化的项目对测试的要求更高，具体体现在测试范围更广、测试深度也要更深。从主工程平滑拆分出用户服务，一次拆分等于之前关于用户服务内部调用的流程都变成 facade + http 接口调用。也就是说接口个数会翻倍增长(内部逻辑拆分成http接口)，分层测试的模式进一步体现出来，这样就使得测试范围更广了。其次，不同的微服务场景和特点不同，需要测试分析更加深入，测试策略更加有针对性，才能全面覆盖微服务架构下的多种服务类型。对测试人员的能力、测试平台及工具、测试效率要求都更高，在这方面的深入探索很有必要，目标是更好地进行质量 + 效率的全方位保障工作。IronCloud 服务部署时代：IronCloud 是黑少微服务工具店自研的一套部署管理平台。容器服务的大部分Web服务还是使用IronCloud自动部署平台进行机器构建并远程部署至目标机器。用户通过 UI 去创建部署任务，并且触发构建和部署动作完成命令下发，构建机器得到命令后按照集成模板生成工程文件，下载源码、编译并且打包上传 nos;目标机器通过Agent服务获取部署安装包并且替换模板属性，启动服务。这个系统在微服务架构不明显的项目中还是比较好用的，但是一旦服务数量增长较多，或涉及到多团队多人员去同时构建部署就会鞍山网站优化暴露一些弊端。比如构建机器多任务并行时延，nos上传和下载时延在服务数量同时构建更新时效率会变低。另外多人同时操作同一个服务的构建和部署，有可能会造成冲突导致构建失败。最重要的一点，构建部署环境强依赖于目标机上的环境配置，例如JDK和Tomcat的版本，这样在线上线下多环境复杂场景下，会导致多环境下同一服务表现有可能不一致。也由此引入了容器化服务时代。