支撑性服务 & 自动化
连载传送门：
- 什么是云原生？
- 云原生设计理念
- .NET 微服务
- 谈到云原生，绕不开“容器化”
Backing services
云原生系统依赖于许多不同的辅助资源，例如数据存储、消息队列、监视和身份服务。这些服务统称为支撑性服务。
下图显示了云原生系统使用的许多常见支撑性服务
支撑性服务帮助实现了“十二要素应用”中的Statelessness原则
要素6提到：“每个微服务应在独立隔离的进程中执行，将所需状态信息作为外部支撑性服务，例如分布式缓存或数据存储”
最佳实践是将支撑性服务视为附加资源，并使用外部挂载的方式将配置(URL和凭据)动态绑定到微服务。
要素4指出： “支撑性服务“应通过可寻址的URL公开，这样做解耦了将资源与应用”
要素3指出： “将配置信息从微服务中移出并外挂”
Stateless和支撑性服务，这样松散的设计使你可以将一项支撑性服务换成另一项支撑性服务，或将您的代码移至其他公有云，而无需更改主线服务代码。
支撑性服务将在第5章“云原生数据模式”和第4章“云原生通信模式”中详细讨论。
自动化
如你所见，云原生依赖(微服务、容器和现代设计理念)来实现速度和敏捷性。
但是，那只是故事的一部分，你如何配置运行这些系统的云环境？你如何快速部署应用程序功能和更新？
被广泛认可的作法是基础设施即代码(IaC)
借助IaC，你可以自动化平台配置和应用程序部署,你将诸如测试和版本控制之类的软件工程实践应用于您的DevOps实践。你的基础架构和部署是自动化，一致且可重复的。
Automating infrastructure
在底层，IaC是幂等的，这意味着你可以一遍又一遍地运行相同的脚本，而不会产生副作用。
如果团队需要进行更改，可以编辑并重新运行脚本，(仅)需要更新的资源受到影响。
在《基础架构即代码》一书中，作者Sam Guckenheimer指出：“实施IaC的团队可以大规模、快速、稳定地交付。团队不用手动配置环境，通过代码表示的所需环境状态，来增强交付预期。使用IaC进行基础架构部署是可重复的，可防止由于配置差异或缺少依赖关系而导致运行时问题”。
Automating deployments
“十二要素应用”指出了从代码开发到交付落地的原则
要素5指出：“严格区分构建、发行和运行阶段。每个发行阶段都应标有唯一的ID，并支持回滚功能。”
现代CI/CD实现了这一原则。它们提供的独立部署步骤，确保将一致的、高质量的代码交付给用户。
下图演示了独立的部署过程：
在上图中，要特别注意任务分离。
开发人员在其开发环境中创建feature分支，反复迭代“inner loop”(运行和调试)。
完成后，该代码将被推送到代码存储库中，例如GitHub，Azure DevOps或BitBucket。
推送触发自动构建，构建阶段将代码转换为二进制产物。这项工作是通过持续集成（CI）管道实现的，它会自动生成，测试和打包应用程序。
发布阶段拾取前面的二进制产物，加上外部应用程序和环境配置信息，产生不可变更的发行版。该版本将会部署到指定的环境。这项工作是通过持续交付（CD）管道实现的。每个版本都应该是可识别、可追溯的。你可以说：“这次部署的是应用程序的Release 2.1.1版本”。
最后，发布的版本放在目标执行环境中运行。版本不可变，这意味着任何更改都必须创建一个新版本。
应用这些实践，从根本上发展了软件发布方式。许多人已经从季度发布转为按需更新。通过集成过程的一致性，团队可以更频繁地提交代码更改，从而改善协作和软件质量。
