使用 CI/CD 促进微服务开发
什么是持续集成、交付和部署
CI/CD 包含几个整体流程：
- 持续集成：
开发人员频繁地将代码合并到主分支，所有的构建和测试都会每天自动执行，以确保主分支代码每天都是可以就绪发布的。 - 持续交付：
所有通过 CI 流程的代码会自动发布到预生产环境，通常情况下，发布到真实的生产环境前需要流程审批，这一步的目的是为了确保代码始终是就绪发布状态的。 - 持续部署：
所有通过集成和交付的最新代码可以自动部署到生产环境。
单体应用的常规流水线
从历史上看，单体应用的 CI/CD 流程有一个相同的特征，每个项目都有一个单一的，相当复杂的流水线，不同的项目之间的流水线又截然不同，每个单体应用的流水线几乎总是连接到一个单独的 Git 仓库。
每个管道的独特复杂性使其很难长久维持，此外，每条流水线通常都仅由一小部分既熟悉应用内部结构、同时又对部署环境相当熟悉的人控制。对于每个项目来说，运维人员维护流水线结构，而开发人员只关注源代码，这与 Devops 理念是完全相反的，应该是所有人对基础设施共同承担责任，共同解决常见的问题。
CI/CD 流水线的重要性
在常规的单体应用开发工作中，只有一条流水线，并且将可执行文件作为最终输出。所有的开发工作产品都会融入到这条流水线中，当团队发现一个严重的错误时，必须编码，集成，测试和发布，如果多几个问题，会导致发布新功能和新特性延迟。在某种程度上，开发团队可以通过适当分解模块并采用特性分支的做法最大程度地降低改动代码所带来的影响。但是，当应用程序不可避免的复杂性增加时，单体应用发布版本的过程会变得越来越脆弱。
为了实现更快的发布速度并最大程度降低风险，CI/CD 流水线必须高度自动化的。如果团队希望每天执行一次或多次生产发布，则必须将回归和服务中断保持在最低限度，而且流水线还需要具有足够的弹性，可以抵御部署失败，并可以快速向前向后回滚。
持续交付的主要目标是最小化编码-测试-交付-测量的迭代周期，通过优化此周期来提高可交付的吞吐量是生产力和更高质量代码的关键。如果用户不熟悉这些概念，似乎是违反直觉的，但是在此过程中可以修复和完善代码。最终，花在部署上的时间会越来越少，团队可以将重心放到设计和项目质量上。
CI/CD 流水线的复杂性
不起眼的 CI/CD 流水线的大小和复杂性很容易成为一个巨大的痛点，尽管有许多工具可用于持续集成单体应用的不同组成部分，但持续部署却有所不同。CD 已迫使需要公司创建大量的自定义脚本来管理部署。
随着组织内应用程序数量的增长，所有对应流水线的管理成为了一种负担。我们通常会发现，流水线大部分都是一些配置管理工具，Python 脚本和 bash 脚本的集合。
在尚未开始采用微服务的组织中，这些混乱由为商检，这种情况持续存在的主要原因是，大多数开发人员的工作范围仅限于项目本身，他们不会感到流水线维护起来很麻烦，这项工作通常是由运维人员完成的，他们会花费大量时间维护现有的流水线并创建新的流水线。
并非所有团队都准备好微服务
尽管微服务有很多好处，但有些组织还没有准备好这一块旅程。主要考虑因素是团队规模，如果团队很小（1到3人），则使用微服务开发可能会增加不惜要的额外开销。微服务对于扩展操作和管理成千上万的请求特别有用。微服务最适合由较大的团队使用，而较大的团队又分为组成不用特性和功能的较小团队。
当架构要求在多个集群和数据中心之间分布式负载时，微服务也是必需的。如果组织没有这种明确的需求，那么可能没必要转变成微服务开发。如果组织希望随着微服务开发的发展而前行，那么考虑持续集成和自动化交付来管理此类开发的复杂性就很重要。
微服务的 CI/CD
针对微服务架构的健壮的 CI/CD 流程有主要几个优点：
- 每个团队可以独立构建、集成和部署自己的微服务，而不会影响或破坏其他团队；
- 在将新版本的微服务部署到生产之前，它将首先部署到开发、测试和 QA 环境，在集成的每个环境都有质量管控；
- 可以非常容易并排部署新版本和之前的多个版本，以此来评估新版本的微服务；
- 易于建立分段且易于管理的访问控制。
在微服务开发团队中，绝不应该让每个团队都需要经过漫长的排队才能发布，建立一个微服务的团队可以随时发布更新，不需要等待另外一个或多个微服务集成、测试和部署。
微服务开发中 CI/CD 的挑战
尽管它可能对微服务开发工作更加有益，但 CI/CD 也带来了很多挑战：
- 安全、快速并持续发布新功能：
管理频繁发布的功能需要保持警惕，尤其是当这些功能涉及到多个微服务的更改 - 管理复杂技术栈之间的部署：
用户可能会遇到微服务应用在包含不同技术栈的环境中，这将面临许多繁琐的挑战 - 维护复杂分布式系统的完整性：
如果项目涉及到将单体应用分解为较小的微服务，则系统整体复杂性将增加，可将将面临分布式系统的问题
微服务 CI/CD 的伸缩性
微服务的开发和部署提供很多优势，同时也带来了许多可伸缩性的挑战。这很好理解，随着团队扩大，所支持的应用程序和服务数量也增加，微服务流水线和存储仓库变的更加难以管理。
一个典型的开发组织可能不得不处理一到五个流水线来管理一组单体应用程序（对应大致5个项目），但是如果将单体应用划分为5个微服务，则流水线数量会增加到25条，甚至更多。当然，这些数字因组织而异。微服务架构通常会使用10个或更多微服务，考虑一家拥有50多个应用程序的公司，其运维团队需要管理500多条流水线。如此庞大的数目意味着这样的公司必须找到一种方法来自动化管理如此多的流水线。
至此，我们来到了微服务流水线管理中最大的陷阱。共享微服务流水线细分领域已有了一些创新，这听起来很吸引人，但让我们关注一下工作流程细节。首先，运维人员必须在应用程序中找到流水线的公共部分，接下来，建立共享的流水线段注册表以容纳所有这些公共部分，然后重建现有项目中的流水线，以便它们依赖于公共段，最后新项目必须检查常见的流水线段库中是否有适合的，并直接使用。结果是，一条流水线实际上由公共的流水线段和该项目专有的段组成。
这导致了一些新的解决方案兴起，这些解决方案试图将流水线的通用部分集中起来，并在组成软件项目中将它们作为库重用，这里最大的挑战是，这种方式需要付出巨大的努力，并且需要一支训练有素的团队，下列所有方面需要沟通和合作：
- 仔细检查流水线哪些部分是公用的；
- 维护公用库；
- 禁止复制粘贴任何流水线；
- 根据需要开发新流水线；
- 每个项目启动时初始化流水线。
实际上，微服务应用程序的数量将持续增长，并且许多团队会发现在创建一系列新的微服务项目时将很难遵循所有这些原则。
微服务 CI/CD 的最佳实践
这里有5种可靠的实践，可以帮助用户团队设计 CI/CD 流水线来管理微服务开发
1.制定可靠的测试策略
微服务的测试和验证系统比测试传统的单体应用要复杂得多，有效的测试策略必须考虑对单个微服务的隔离测试，而且也需要验证整个系统的行为。
常规方法依然适用于微服务的上游测试，尤其是隔离测试。测试金字塔对于团队在保持各种类型的测试之间的平衡方面也很有用。但是这种方法在同时测试多个服务时有局限性，造成这种情况的主要原因是，用户无法模拟许多错误。这样的示例包括高度分布式系统中的不一致性或因为硬件/网络故障而导致的系统问题。
由于这些挑战，有必要采用轻量级 UAT，综合用户测试和故障注入测试等技术来补充常规测试。
2.精心设计环境
环境计划概述了用户如何使用各种环境，以及在各种环境中移动或促进所有组件的策略。首先，考虑团队在各种环境中需要处理的用例非常重要，请记住，组织中不同小组有不同的需求，因此环境规划需要考虑所有这些不同的需求。
考虑团队如何利用云基础架构也很重要，以便后期可以动态创建这些环境。另外，用户需要制定一种策略，可以将所有组件从一个环境升级到另一个环境。由于 CD 流水线会不断生成很多组件，所以需要仔细考虑需要管理多少组件以及需要多少资源仓库。
3.重温 CI 实践
在任何成功的 CD 策略中，持续集成都是至关重要的做法，这超出了有关构建定义和构建服务器的考虑范围。基于主干开发和特性功能开关模式是两个非常好的实践，它们对于建立可靠的 CI 流程非常有效。
通过基于主干开发，开发人员可以一起在主干分支中修改代码，这样做的目的是避免各分支中产生偏差，从而避免合并代码而带来的挫败感，基于主干的开发还需要用于实现特性功能开关控件。
通过特性功能开关控件，可以对正在进行的工作和已完成的工作都进行提交，这些开关可以使团队在不完整的功能投入生产后暂时禁用它们。通常，特性功能开关保留在代码库附近的配置或规范文件中，CD 流水线自动化机制将在相关环境中根据需要启动或禁用这些开关。
同样，用户可以使用其他类型的开关，例如使用发布开关（release toggle）对不完整的代码限制访问权限。其他还包括通过行为开关（ops toggle）改变生产代码的访问权限、实验性开关（experimental toggle）用于多变量进行 AB Test，以及权限开关（permissions toggle）对特定用户启用特定的行为。
4.管理好配置
应用程序的配置包含与部署相关的所有内容，因此应使配置文件与代码保持不同，可以想象，管理一个或多个微服务组的部署时，配置是不同的。
一种有效的方法是使用集中管理存储库（如 Vault 或 Consul）。另一种方式是标准化配置的分发方式，无论服务使用什么技术栈，通过这种方法，服务本身将通过自身的技术栈挑选配置。
最后，团队需要建立一个流程来保护证书等机密信息，以确保对他们进行适当的管理。通常，这个流程是手动的，但至关重要的是及早考虑将将其设置到位。
5.为失败做准备
在微服务系统开发中，多个服务不断且频繁地发生更新，当服务部署过程中引入错误或者不稳定时，最佳的响应是什么？
在许多情况下，最好的补救措施是前滚，这意味着确定故障的根本原因，然后迅速修复程序。请记住，前滚的一项要求是团队已经设置了将修补程序分支发布到生产的功能，由于时间和协调原因，最好不要通过流水线解决生产问题。
相比之下，回滚在生产系统中通常是有问题的。大多数情况下，回滚很容易，更改粒度可以满足其他服务。但是，如果部署中包含更多复杂的更改，例如数据库表结构更改，则有必要将数据库的更改与代码更改分开部署，这需要单独来部署，以确保数据库更改和早期代码版本的兼容性。
总结
在本书中，我们已经了解到，缩短发布周期、使发布更加灵活是我们追求微服务架构的两个主要优势，但是，缺乏持续集成和持续交付流程会使团队无法拥有支持微服务开发和交付所必需的的敏捷性。我们研究了挑战，并提出了一些将 CI/CD 实践与微服务应用程序开发相结合的方法和建议。
