支撑性服务 & 自动化


连载传送门:

  • 什么是云原生?
  • 云原生设计理念
  • .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版本”。

最后,发布的版本放在目标执行环境中运行。版本不可变,这意味着任何更改都必须创建一个新版本。

应用这些实践,从根本上发展了软件发布方式。许多人已经从季度发布转为按需更新。通过集成过程的一致性,团队可以更频繁地提交代码更改,从而改善协作和软件质量。

  • 分享:
评论
还没有评论
    发表评论 说点什么