单体和微服务的流水线有哪些不同？
作者：Tracy Ragan，DeployHub首席执行官，CD基金会董事会成员
微服务流水线与传统流水线不同。俗话说……
“变化越多；越多的东西保持不变。”
“The more things change; the more things stay the same.”
（“万变不离其宗。”）
随着软件开发演进过程中的每一步，我们的基本软件实践也在随着Kubernetes和微服务而改变。但是将软件从设计转移到发布的基本要求是相同的。他们的外表可能会改变，但所有的步骤仍然在那里。为了适应新的微服务架构，DevOps团队只需要了解我们的底层流水线实践需要如何改变和改变形状。
理解微服务流水线的不同之处
理解微服务的关键是思考“功能”。在微服务环境中，‘应用程序’的概念消失了。它被一组松散耦合的服务替代，这些服务在运行时通过API连接，在容器、节点和pod中运行。微服务被跨团队重用，这增加了对改进组织（域驱动设计）、协作、通信和可见性的需求。
微服务流水线中最大的变化是让多个应用程序团队在生命周期中独立地移动使用单个微服务。同样，人们必须停止思考“应用”，而是思考“功能”，以充分理解即将到来的转变。请记住，微服务的多个版本可以同时在你的环境中运行。
微服务是不可变的（immutable）。你不是“复制”旧版本，而是部署一个新版本。当你部署一个微服务时，你将创建一个Kubernetes部署YAML文件，该文件定义了标签和镜像的版本。
在上面的例子中，我们的标签是dh-ms-general。当微服务标签被重新用于新的容器镜像时，Kubernetes将停止使用旧镜像。但是在某些情况下，可能会使用第二个标签来允许两个服务同时运行。这是由你的入口控制的。我们的新流水线必须结合我们现代架构的这些新特点。
比较单体和微服务流水线
当我们管理小功能与运行在现代架构中的单体应用程序时，你的生命周期流水线是什么样子的？下面是每个类别的比较和它们支持微服务流水线的潜在变化。
变更请求
单体：
记录基于应用程序的用户问题单、增强请求或异常。
微服务：
在微服务流水线中，这个过程将保持相对不变。用户将继续为bug和增强打开票券。区别在于哪些微服务需要更新，以及票券是针对哪个版本的微服务打开的。由于微服务可以被多个应用程序使用，因此依赖项管理和影响分析对于帮助确定问题所在将变得更加重要。
版本控制
单体：
跟踪源代码内容中的更改。分支和合并更新允许多个开发人员处理单个文件。
微服务：
虽然对微服务的源代码进行版本控制仍然可以完成，但是你的源代码将更小，只有100-300行代码，而不是1000-3000行代码。这影响了分支和合并的需要。“合并回主干”的概念更像是一个整体概念，而不是微服务概念。你多久会将几百行的代码进行一次分支？
工件库
单体：
工件库（artifact repository）最初是围绕Maven构建的，它为发布jar文件、node JS包、Java脚本包、docker镜像、python模块提供了一个中心位置。在运行构建包时，包管理器（maven、NPM、PIP）将执行依赖项管理，以跟踪传递依赖项。
微服务：
同样，这些工具支持单体构建并解决了依赖项管理来解决编译/链接步骤。我们不再使用单体构建，但仍然需要构建容器并解决依赖项。这些工具将通过确定容器运行所需的传递依赖项来帮助我们构建容器。
构建
单体：
执行调用编译器和链接器的串行过程，将源代码转换成二进制文件（Jar、War、Ear、.exe、.dll、docker镜像）。支持构建逻辑的通用语言包括Make、Ant、Maven、Meister、NPM、PIP和Docker Build。构建调用工件库，根据构建脚本指定的库版本来执行依赖项管理。
微服务：
在大多数情况下，构建在微服务流水线中看起来会非常不同。微服务的构建将涉及创建容器镜像和解决容器运行所需的依赖项。可以将容器镜像看作是新的二进制文件。这是一个相对简单的步骤，不涉及整个应用程序的编译/链接。它只涉及一个微服务。链接是在运行时通过编码到微服务本身的restful API调用完成的。
软件配置管理（Software Configuration Management，SCM）
单体：
构建过程是执行配置管理的中心工具。开发人员设置他们的构建脚本（POM文件）来定义他们希望在编译/链接过程中包含哪些版本的外部库。构建通过从基于“主干”或“分支”的版本控制中提取代码来执行配置管理。可以创建一个软件材料清单来显示用于创建应用程序的所有工件。
微服务：
我们用来配置应用程序的大部分操作都发生在软件的构建阶段。但我们所知道的“构建”会通过微服务流水线消失。在这里，我们非常谨慎地决定要使用什么版本的源代码和库来构建单体应用程序的版本。在大多数情况下，版本和构建配置通过微服务转移到运行时。虽然容器镜像有一个配置，但是配置的总体情况是通过API在集群的运行时发生的。
此外，我们的SCM将开始引入域驱动设计（Domain Driven Design）的概念，你可以在其中管理基于微服务的问题空间的架构。新的工具将进入市场，以帮助管理你的域，你的应用程序的逻辑视图，并跟踪应用程序的版本到服务的版本。一般来说，SCM将变得更具挑战性，因为我们将不再在编译/链接步骤中解决所有依赖项，而必须在整个流水线中跟踪更多的依赖项。
持续集成（Continuous Integration，CI）
单体：
CI是从版本控制中提取代码和库并根据定义的“安静时间”执行构建的触发过程。这个过程通过确保尽可能频繁地集成代码变更来改进开发，从而避免了破碎的构建，因此被称为持续集成。
微服务：
最初采用持续集成是为了让我们尽可能频繁地重新编译和链接代码，以防止构建中断。我们的目标是达到一个干净的“10分钟构建”或更短。使用微服务，你只是在构建一个单一的“功能”。这意味着不再需要集成构建。CI最终会消失，但是通过创建容器的步骤，管理持续交付流水线的过程仍然很重要。
代码扫描
单体：
代码扫描器已经从查看内存问题和bug的编码技术发展到扫描开源库的使用、许可和安全问题。
微服务：
代码扫描器在微服务流水线中仍然很重要，但它将更多地扫描容器镜像而不是源代码。有些将在容器构建过程中使用，重点是扫描开源库和许可，而其他的将更多地关注运行时扫描的安全问题。
持续测试
单体：
持续测试诞生于测试自动化工具。这些工具允许你在整个应用程序上执行自动化测试，包括数据库事务的计时。这些工具的目标是提高由CD工作流驱动的测试工作的质量和速度。
微服务：
测试始终是生命周期过程中的一个重要部分。微服务的不同之处在于理解影响和风险水平。测试人员需要知道什么应用程序依赖于微服务的一个版本，以及应该跨应用程序进行什么级别的测试。测试自动化工具需要了解微服务的关系和影响。测试将超越对单个应用程序的测试，而是转向对集群中的服务配置的测试。
安全
单体：
安全解决方案允许你定义或遵循一组特定的标准。它们包括代码扫描、容器扫描和监控。这个领域已经发展成为DevSecOps运动，其中更多的安全活动是由持续交付驱动的。
微服务：
安全解决方案将进一步“左移”，在容器的创建过程中增加更多的扫描。随着容器的部署，安全工具将开始关注Kubernetes基础结构中的漏洞，因为它们与容器的内容有关。
持续交付编排（Continuous Delivery Orchestration，CD）
单体：
持续交付是基于软件应用程序触发“构建作业”或“工作流”的持续集成的演化。它自动执行开发、测试和生产之间的工作流过程，协调外部工具来完成工作。持续交付要求生命周期过程中的所有参与者以正确的顺序执行，并集中他们的日志。
微服务：
让我们从微服务流水线和单体流水线之间的第一个也是最明显的区别开始。由于微服务是独立部署的，所以大多数迁移到微服务架构的组织告诉我们，它们对每个微服务使用单一的流水线工作流。此外，大多数公司告诉我们，他们从6-10个微服务开始，然后发展到每个传统应用程序20-30个微服务。这意味着你将拥有数百个（如果不是数千个）工作流。CD工具将需要包含模板工作流的功能，允许将共享模板中的修复应用于所有子工作流。管理数百个单独的工作流是不实际的。此外，插件需要被封装起来，并与CD工具的版本解耦。最后，寻找事件驱动的操作，使CD引擎能够侦听多个事件、并行运行事件并通过流水线处理数千个微服务。
持续部署
单体：
这是一个将工件（二进制文件、容器、脚本等）以高频率的方式移动到物理运行时环境的过程。此外，部署工具跟踪工件的部署位置，以及为价值流管理提供核心数据的审计信息（谁、哪里、什么）。持续部署也被称为应用程序发布自动化。
微服务：
部署整个应用程序的概念将会消失。相反，部署将混合跟踪Kubernetes部署YAML文件和管理应用程序配置的能力，在每次向集群引入一个新的微服务时。重要的是跟踪应用程序的“逻辑”视图的能力，方法是关联组成应用程序的微服务的版本。这是一个巨大的转变。部署工具将开始生成Kubernetes YAML文件，并将其从开发人员的待办事项列表中删除。部署工具将自动跟踪微服务源的版本、容器镜像、集群和相关应用程序，以提供所需的价值流报告和管理。
总结
随着我们从管理单体应用程序转向管理微服务，我们将需要创建一个新的微服务流水线。从需要管理我们的CD流水线中的数百个工作流，到需要对微服务及其消费应用程序版本进行版本控制，将会有很多不同。虽然有一些变化，但我们在传统的CD中定义的核心能力仍然很重要，即使它只是我们现在正在独立地跨越流水线推送的一个简单功能。
关于作者
Tracy Ragan是DeployHub的CEO，持续交付基金会董事会成员。她是微服务的布道者，精通软件配置管理、构建和发布。在1995年共同创建OpenMake软件之前，Tracy曾在华尔街公司担任7年的构建和发布管理顾问。她是Eclipse组织的创始成员，并在董事会工作了5年。她是一位公认的领导者，曾在多个行业出版物上发表过文章，并在行业会议上向听众发表过演讲。Tracy在2018年与他人共同创建了DeployHub，服务于微服务开发社区。