CI/CD用于微服务架构

什么是CI/CD/span>

当我们谈论CI/CD时，实际上是在谈论几个相关过程：持续集成、持续交付和持续部署。

• 持续集成。代码更改经常合并到主分支中。自动化的构建和测试过程可确保主分支中的代码始终具有生产质量。
• 持续交付。通过CI流程的所有代码更改都将自动发布到生产环境中。部署到实时生产环境中可能需要手动批准，但否则会自动进行。目标是您的代码应始终准备就绪，可以部署到生产中。
• 持续部署。通过前两个步骤的代码更改将自动部署到生产中。

以下是微服务架构的健壮CI/CD流程的一些目标：

• 每个团队都可以独立构建和部署自己拥有的服务，而不会影响或破坏其他团队。
• 在将新版本的服务部署到生产中之前，会将其部署到开发/测试/QA环境中进行验证。在每个阶段都要执行质量关卡。
• 服务的新版本可以与先前版本并列部署。
• 有足够的访问控制策略。
• 对于容器化的工作负载，您可以信任部署到生产中的容器映像。

为什么强大的CI/CD管道很重要

在传统的整体应用程序中，只有一个构建管道，其输出是应用程序可执行文件。所有开发工作都将馈入此管道。如果发现高优先级错误，则必须集成，测试和发布修补程序，这可能会延迟新功能的发布。您可以通过使用结构良好的模块并使用功能分支来最大程度地减少代码更改的影响来减轻这些问题。但是，随着应用程序变得越来越复杂，并添加了更多功能，整装件的发布过程往往变得更加脆弱，并可能会破裂。

遵循微服务理念，永远不会有一个漫长的发布培训，每个团队都必须排队。构建服务“A”的团队可以随时发布更新，而无需等待服务“B”中的更改被合并，测试和部署。

CI/CD整体图

为了达到较高的释放速度，您的释放管道必须自动化且高度可靠，以最大程度地降低风险。如果您每天一次或多次发布产品，则回归或服务中断必定很少发生。同时，如果确实部署了错误的更新，则必须以可靠的方式快速回滚或前滚到服务的先前版本。

挑战性

• 许多小的独立代码库。每个团队都负责使用自己的构建管道来构建自己的服务。在某些组织中，团队可能使用单独的代码存储库。单独的存储库可能会导致以下情况：如何构建系统的知识分散到各个团队中，组织中没有人知道如何部署整个应用程序。例如，如果您需要快速部署到新集群，在灾难恢复方案中会发生什么/li>

缓解措施：建立统一的自动化管道来构建和部署服务，以使这些知识不会在每个团队中“隐藏”。

• 多种语言和框架。每个团队使用自己的技术组合，很难在整个组织中创建一个单一的构建过程。构建过程必须足够灵活，以使每个团队都可以根据其选择的语言或框架对其进行调整。

缓解措施：容器化每个服务的构建过程。这样，构建系统仅需要能够运行容器。

• 集成和负载测试。随着团队按自己的进度发布更新，设计健壮的端到端测试可能是一个挑战，特别是当服务依赖于其他服务时。而且，运行一个完整的生产集群可能会很昂贵，因此每个团队不太可能会在生产规模上运行自己的完整集群，仅用于测试。
• 发布管理。每个团队都应该能够将更新部署到生产中。这并不意味着每个团队成员都有权这样做。但是具有集中的Release Manager角色可以降低部署速度。

缓解措施：CI/CD流程自动化和可靠的程度越高，对中央机构的需求就越少。也就是说，您可能有不同的策略来发布主要功能更新与次要错误修复。权力下放并不意味着零治理。

• 服务更新。将服务更新到新版本时，它不应破坏依赖于该服务的其他服务。

缓解措施：使用部署技术（例如蓝绿色或Canary发布）进行不间断的更改。要中断API更改，请与以前的版本并排部署新版本。这样，可以对使用先前API的服务进行更新并针对新API进行测试。请参阅下面的更新服务。

Monorepo vs.多仓库

在创建CI/CD工作流之前，您必须了解代码库的结构和管理方式。

• 团队是在单独的存储库中还是在单个存储库（单个存储库）中工作/li>
• 您的分支策略是什么/li>
• 谁可以将代码推送到生产环境发布经理角色吗/li>

monorepo方法一直受到欢迎，但两者都有优点和缺点。

更新服务

有多种策略可以更新已经投入生产的服务。在这里，我们讨论三个常用选项：滚动更新、蓝绿色部署和canary发布。

滚动更新

在滚动更新中，您将部署服务的新实例，新实例立即开始接收请求。随着新实例的出现，以前的实例将被删除。

例如，在Kubernetes中，当您更新Deployment的Pod规范时，滚动更新是默认行为。部署控制器为更新的Pod创建一个新的ReplicaSet。然后，它会按比例缩放新的ReplicaSet，同时按比例缩小旧的ReplicaSet，以保持所需的副本数。在新的Pod就绪之前，它不会删除旧的Pod。Kubernetes保留更新的历史记录，因此您可以根据需要回滚更新。

例如，默认情况下，Azure Service Fabric使用滚动更新策略。此策略最适合在不更改现有API的情况下部署具有新功能的服务版本。Service Fabric通过将应用程序类型更新为节点的子集或更新域来启动升级部署。然后，它将前滚到下一个更新域，直到所有域都升级。如果升级域更新失败，则应用程序类型将在所有域中回滚到以前的版本。请注意，具有多个服务的应用程序类型（并且如果所有服务都作为一个升级部署的一部分进行更新）则很容易发生故障。如果一项服务更新失败，则整个应用程序将回滚到以前的版本，而其他服务则不会更新。

滚动更新的一个挑战是，在更新过程中，新旧版本的混合正在运行并接收流量。在此期间，任何请求都可以路由到两个版本中的任何一个。

为了打破API更改，一个好的做法是并排支持两个版本，直到更新了先前版本的所有客户端为止。请参阅API版本控制。

蓝绿色部署

在蓝绿色部署中，您将新版本与先前版本一起部署。验证新版本后，您可以一次将所有流量从以前的版本切换到新版本。切换之后，您可以监视应用程序是否存在任何问题。如果出现问题，您可以交换回旧版本。假设没有问题，则可以删除旧版本。

对于更传统的单片或N层应用程序，蓝绿色部署通常意味着预配两个相同的环境。您可以将新版本部署到暂存环境，然后将客户端流量重定向到暂存环境，例如，通过交换VIP地址。在微服务体系结构中，更新发生在微服务级别，因此您通常将更新部署到同一环境中，并使用服务发现机制进行交换。

例如，在Kubernetes中，您无需配置单独的集群即可进行蓝绿色部署。相反，您可以利用选择器。使用新的pod规范和一组不同的标签创建新的Deployment资源。创建此部署，而不删除先前的部署或修改指向它的服务。新的Pod运行之后，您可以更新服务的选择器以匹配新的部署。

蓝绿色部署的一个缺点是，在更新期间，您正在运行该服务的Pod（当前和下一个）两倍。如果Pod需要大量CPU或内存资源，则可能需要临时扩展群集以处理资源消耗。

Canary发布

在Canary版本中，您向少数客户端推出了更新版本。然后，在将新服务推广到所有客户端之前，您将监视新服务的行为。这样一来，您就可以以受控方式进行缓慢的部署，观察实际数据并在所有客户都受到影响之前发现问题。

Canary版本比蓝绿色更新或滚动更新更复杂，因为您必须将请求动态路由到服务的不同版本。

例如，在Kubernetes中，您可以将服务配置为跨越两个副本集（每个版本一个）并手动调整副本计数。但是，由于Kubernetes跨Pod负载均衡的方式，这种方法相当粗糙。例如，如果总共有10个副本，则只能以10％的增量转移流量。如果使用服务 格，则可以使用服务 格路由规则来实现更复杂的Canary发布策略。

标签：