云原生持续交付的模式和实践

RIO（大众汽车公司的一个品牌）首席架构师Christian Deger最近在 伦敦Continuous Lifecycle大会 上分享了一系列实现云原生持续交付的模式和实践。Deger的演讲内容涵盖了用于独立部署管道的模式（得益于容器化）、拥有交付所有权（包括流程和基础架构两个方面）的产品团队，以及动态、不可变性和可组合的基础架构（避免单体，区分宏观和微观基础设施）。

持续集成（CI）和持续交付（CD）对于经常要将独立服务部署到动态创建的基础设施中的自主团队来说至关重要。按照Deger的话说，将 云原生概念 和现代基础设施即代码应用于软件交付系统可以“为已经准备好介入到平台的新服务快速创建的解耦管道，并且所有内容都由代码驱动”。

拥有一个可靠的交付系统，能够承受灾难并且无需等待就能提供反馈，这已成为现代软件交付的先决条件。对CI/CD基础设施进行容器化可以：

• 进行独立的构建：创建带有必要代理配置文件的干净容器（例如，一个应用程序可能需要Java 8，而另一个应用程序仍在Java 7上运行），并且仅在构建期间存在。
• 带来弹性：每个构建有自己的容器代理，消除等待时间并提高资源使用率。

将此基础设施定义为代码可以从零开始恢复交付过程（例如发生灾难时），并避免出现 CI/CD雪花服务器 （snowflake server），也就是说，通过UI进行且未被版本控制系统捕获的变更会导致配置的漂移。

Deger强调了将快速且可预测地设置新管道（对于新服务）作为项目第一要务的重要性（否则团队就会为了避免较长的启动时间，对现有服务负起更多的责任）。将管道（阶段、任务、依赖关系、构件等）定义为代码/配置，可以快速从灾难中恢复，因为这样可以快速重新创建管道，并且可以以最短的延迟交付服务变更。大多数管道编排工具都支持 管道即代码 （尽管具有不同的实现）。

Deger建议对管道定义和相应的服务代码进行版本控制，因为自治团队需要拥有完整的交付管道。实际上，Deger建议每个服务都应该有自己的代码库和实际的服务代码，以及管道定义和基础设施代码。对后者的变更应像通常的应用程序变更一样，都要流经管道，让它们变得可追踪和可重复。这意味着基础设施创建或更新需要通过管道进行动态触发。

在Deger看来，避免出现基础设施单体（包含所有服务定义的单个仓库或者按层进行分组的定义，如如数据库、计算实例或中间件）才是最根本的。他建议创建与服务边界（微基础设施）相一致的独立基础设施栈，并在全局栈（宏基础设施）中留下一小组交叉、缓慢变化的非服务特定方面，如网络和安全）。服务从它们共享的宏基础设施中导入参数，以便能够在其中运行。



图片由Christian Deger提供

另一个主要想法是解耦（或控制）多层服务之间的依赖关系，而不仅仅是应用程序代码。除了每个服务的独立管道之外，其他的依赖关系——例如服务的基础映像（AMI、Docker等）——应该是静态的（针对特定版本），避免一个镜像更新同时触发多个管道，导致重新部署生产系统的风险。

也许Deger提出的最有争议的建议是移除管道中的staging环境。由于服务的变化率很高（至少每小时），Deger声称几乎不可能在staging环境中针对所有其他服务的当前版本测试新服务。这可能会导致等待时间变长，因为staging环境将成为瓶颈，或者变成发布单体，因为多个服务的变更在staging环境耦合在一起，然后通过测试后一起发布。

相反，通过依靠 基于消费者驱动的合约测试 以及将生产中的修复时间（MTTR）降至最低，可以独立部署服务变更并对其进行监控，以确保它们在生产中按照预期运行。为进一步降低影响，部署策略应依赖 金丝雀发布 （特别是密切监控新实例的错误率、延迟和负载）、 功能开关 （快速关闭发生故障的功能）和 蓝绿部署 （如果没有数据库变更的话，可快速回滚到之前的环境）。在某些特定情况下（例如重大代码重构），可能可以考虑使用 黑暗启动 。部署新版本，并发出与生产环境相同的请求，从功能性上面判断响应消息是否正常，新实例是否可以处理负载。

在整个演讲中，Deger几次强调了团队拥有服务的重要性，从交付（团队负责他们自己的管道和CI实例）到基础设施（团队定义服务运行的微堆栈）以及运行时（微堆栈包括可操作性特性，如日志和监控）。他建议共享模式、实践和指南，但不要将这些工作集中化，因为这样的话团队将失去自主权，并且对其他团队的依赖会降低交付速度。

 

图片由Christian Deger提供

查看英文原文： Patterns and Practices for Cloud Native Continuous Delivery