微服务持续交付的研究

2020-02-25

福建质量管理 2020年3期

(长江大学湖北荆州 434023)

一、什么是微服务

开发经验的积累以及新技术的出现，使得微服务发展的十分迅速。它有异构特性，不局限于特定技术，它的实现细节变化的速度比它的理念要快得多。微服务，简单的来说，麻雀虽小，五脏俱全，它一般不是单独的服务，通常是多个服务相互协调工作。然而服务有一定的边界，根据领域驱动设计来说，领域的边界，也就是服务的边界，和服务的业务相关联。每个服务只专注于领域之内业务，这就使得代码避免过于臃肿，重构也十分方便。但是也因为服务的数量会很多，就考虑持续集成和持续交付的问题，尤为重要。

二、持续集成与持续交付

持续集成不是新的概念，但是它的基本用法因地制宜，需要研究。微服务的版本控制如今有很多方案，但有一定的相同点。当有代码提交时，需要让新提交的代码与代码库的代码进行合并，共享代码库保持同步。接着会检测到已提交的代码，验证代码是否能编译，测试能否通过。之后生成构建物，不同的打包方式统称为构建物，它是用于部署的。为了可以减少不必要的重复事情，还能确保，线上的和测试通过的构建物是同样的一个。通常把构建物存在仓库中来实现，大家共享，同时能看见。而我们常说的持续交付，它其实是持续集成的后续发展，需要将整个流程自动化，从构建测试一直到部署到生产环境，呈现给客户使用。所以想要完成持续交付流程，其核心就是构建流水线，下面开始简述构建流水线。

三、构建流水线

构建流水线是把代码从编写完成，上传到版本管理的代码库后，构建、部署、测试到发布的一个流程，并且要实现自动化。它的实现的效果就是，程序的源代码、配置(包含环境和数据源等)发生变化，便会出发构建流水线的过程。流水线的第一步就是编译得到二进制文件，有些情况需要得到安装包，后续步骤大致上就是在此基础上做相关的测试，确保程序在不同的环境和配置的可用性，这是非常重要的。当程序通过了测试，它就可以发布了。需要满足这样的过程，就要满足两点要求，即自动化和高频交付。不满足自动化，没法高效，不能重复利用。程序和配置以及发布不同，这样的结果可能都会有所不同。而且手工操作容易出错，还不容易定位错在了哪里，这样这个流程就不再高效失去了使用价值。另外，需要做到高频发布，即发布周期很短，细小的差异都是一种版本升级，这样做的版本控制很容易定位错误，回退版本。另外也很容易即使反馈给使用者，满足客户的需求，及时改正。那么，如何去实现一个构建流水线呢？为系统创建一个自动化的流水线，不是一蹴而就的，应该使用增量方式来实现部署流水线。

(一)建立流程图

第一步就是画出从提交到发布整个过程的流程图，一且有了流程图，就可以用持续集成和发布管理工具对流程建模了。每当有人提交代码，就应该触发提交阶段，合并代码。接着就是用最新的二进制包进入验收测试。同时测试环境和生产环境应该能够手动操作选择具体的版本部署对应的二进制包，这应该需要授权，流水线系统管理角色能够承担这个责任。

(二)自动化构建和部署过程

持续集成服务器监视版本控制系统，发现有新提交的代码时，更新源代码，运行自动化构建流程，并将生成的二进制包放在文件系统，使整个团队都能通过持续集成服务器获取。持续构建流程建立并运行起来了，接下来就是要实现部署的自动化。首先，要找到能够部署应用程序的一台机器。如果项目复杂庞大，可能就需要找几台专用机器了。这个部署环节也需要自动化流程，虽然此时还只是测试环境。部署包含为程序打包，如果程序的不同模块需要部署在不同的机器上，就得分别打包；安装和配置过程实现自动化；写自动化部署测试脚本验证部署是否成功。部署流程是自动化验收测试的前提条件.一且将部署流程自动化后，接下来就要一键式部署了。配置一下持续集成服务器，做到能自由挑选应用版本，并做到通过手动操作来触发一个流程，即获取作为构建输出的二进制文件，运行部署脚本，再运行部署测试。在这个过程中，每次只构建一个二进制文件，在不同环境使用不同的配置文件即可，只需要将配置文件从程序中剥离，单独修改配置即可。测试环境部署和生产环境部署的流程相同，不同的地方也只能是环境配置信息不同。

(三)自动化单元测试和验收测试

单元测试不和数据库和其他文件系统交互，这个过程很快，能够快速直观找到错误。所以写好功能就应该进行单元测试，改进程序。随着程序不断变得复杂，单元测试也越来越多。测试时间过长，就应该分开，并行测试。

验收测试分为功能测试和非功能测试。非功能需求测试一般在项目初期，这样做可以获得一些数据，通过数据分析，来验证可行性，从而进行合理的调整。验收测试和性能测试同一个阶段里接连运行。当然可以将它们分开确定哪里出错。自动化验收测试追查随机问题和难以重现的问题，如竞争条件、死锁，以及资源争夺，这些问题在程序发布之后就很隐蔽了。当然，在部署流水钱中，提交测试阶段和验收阶段需要运行哪些测试取决于你的测试策略。在项目初期，至少有每种测试的一到两个测试可以自动化运行，并把它们放到部署流水线中。初步框架就建好了，随着项目的进展，就比较容易新增测试。

(四)持续改进构建流水线

流水线有两个常见的外延：组件和分支。大型应用程序由多个组件拼装而成，每个组件都应该有一个对应的小型流水线，再用一个流水线把所有组件拼装在一起，并运行整个验收测试集，再部署到测试环境、试运行环境和生产环境中。实现了构建流水线后，需要注意三个重点。第一，不需要一次实现整个流水线，应该增量实现。流程中有手工操作部分，流水线中为它创建一个占位符。当开始和结束手工任务时，确保部署流水线记录下这两个时间点，可以计算每个手工过程消耗了多少时间，并估计会在什么程度上成为流程中的瓶颈。第二，构建流水线是最重要的统计数据来源。这个过程需要记录各个阶段的修改内容，以及修改后的每次的运行时间。之后，可以使用这些数据计算从提交开始到将其部署到生产环境的周期时间，以及花在每个阶段上的时间。分析这些时间段，可以找到耗时较长的阶段和修改细节，去优化，缩短时间，从而减少整个流程所耗时间。最后，构建流水线应该随着系统不断迭代而改进交付流程，不断变化，持续改善和重构。