03｜云原生中有哪些核心技术栈？（下）

你好，我是孔令飞。

上一节课，我们学习了云原生技术栈中的微服务、容器、容器编排、Serverless 技术栈。本节课，我们继续来学习下云原生技术栈中的其他技术：持续集成和持续交付（CI/CD）、DevOps、服务网格、不可变基础设施、声明式 API。

持续集成和持续交付（CI/CD）

CI/CD 技术是通过自动化的手段，来快速执行代码检查、测试、构建、部署等任务，从而提高研发效率，确保我们的应用可以快速迭代升级。

CI/CD 包含了 3 个核心概念：

CI：Continuous Integration，持续集成
CD：Continuous Delivery，持续交付
CD：Continuous Deployment，持续部署

CI 容易理解，但两个 CD 很多开发者区分不开。这里，我来详细说说这 3 个核心概念。

首先是持续集成。它的含义为：频繁地（一天多次）将开发者的代码合并到主干上。它的流程为：在开发人员完成代码开发，并 push 到 Git 仓库后，CI 工具可以立即对代码进行扫描、（单元）测试和构建，并将结果反馈给开发者。持续集成通过后，会将代码合并到主干。

CI 流程可以使应用软件的问题在开发阶段就暴露出来，这会让开发人员交付代码时更有信心。因为 CI 流程内容比较多，而且执行比较频繁，所以 CI 流程需要有自动化工具来支撑。

其次是持续交付，它指的是一种能够使软件在较短的循环中可靠发布的软件方法。

持续交付在持续集成的基础上，将构建后的产物自动部署在目标环境中。这里的目标环境，可以是测试环境、预发环境或者现网环境。

通常来说，持续部署可以自动地将服务部署到测试环境或者预发环境。因为部署到现网环境存在一定的风险，所以如果部署到现网环境，需要手工操作。手工操作的好处是，可以使相关人员评估发布风险，确保发布的正确性。

最后是持续部署，持续部署在持续交付的基础上，将经过充分测试的代码自动部署到生产环境，整个流程不再需要相关人员的审核。持续部署强调的是自动化部署，是交付的最高阶段。

我们可以借助下面这张图，来了解持续集成、持续交付、持续部署的关系。

持续集成、持续交付和持续部署强调的是持续性，也就是能够支持频繁的集成、交付和部署，这离不开自动化工具的支持，离开了这些工具，CI/CD 就不再具有可实施性。持续集成的核心点在代码，持续交付的核心点在可交付的产物，持续部署的核心点在自动部署。

持续集成和持续交付的优势如下：

避免重复性劳动，减少人工操作的错误：自动化部署可以将开发运维人员从应用程序集成、测试和部署等重复性劳动环节中解放出来，而且人工操作容易犯错，机器犯错的概率则非常小。
提前发现问题和缺陷：持续集成和持续交付能让开发和运维人员更早地获取应用程序的变更情况，更早地进入测试和验证阶段，也就能更早地发现和解决问题。
更频繁的迭代：持续集成和持续交付缩短了从开发、集成、测试、部署到交付各个环节的时间，中间有任何问题都可以快速“回炉”改造和更新，整个过程敏捷且可持续，大大提高了应用程序的迭代频率和效率。
更高的产品质量：持续集成可以结合代码预览、代码质量检查等功能，对不规范的代码进行标识和通知；持续交付可以在产品上线前充分验证应用可能存在的缺陷，最终提供给用户一款高质量的产品。

云原生应用通常包含多个子功能组件，DevOps 可以大大简化云原生应用从开发到交付的过程，实现真正的价值交付。

提示：在讨论“持续集成”和“持续交付”这一概念时，常见的缩写是 CI/CD。虽然有些地方也会使用连写的方式（如 CICD），但这种用法并不是行业的标准表述。连写可能会导致概念不够清晰，尤其是在涉及不同团队与技术堆栈讨论时。

DevOps

CI/CD 技术的成熟，加速了 DevOps 这种应用生命周期管理技术的成熟和落地。

DevOps（Development 和 Operations 的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。这 3 个部门的相互协作，可以提高软件质量、快速发布软件。如下图所示：

要实现 DevOps，需要一些工具或者流程的支持，CI/CD 可以很好地支持 DevOps 这种软件开发模式，如果没有 CI/CD 自动化的工具和流程，DevOps 就是没有意义的，CI/CD 使得 DevOps 变得可行。

听到这里是不是有些晕？你可能想问，DevOps 跟 CI/CD 到底是啥区别呢？其实，这也是困扰很多开发者的问题。这里，我们可以这么理解：DevOps！= CI/CD。DevOps 是一组过程、方法和系统的统称，而 CI/CD 只是一种软件构建和发布的技术。

DevOps 技术之前一直有，但是落地不好，因为没有一个好的工具来实现 DevOps 的理念。但是随着容器、CI/CD 技术的诞生和成熟，DevOps 变得更加容易落地。也就是说，这几年越来越多的人采用 DevOps 手段来提高研发效能。

随着技术的发展，目前已经诞生了很多 Ops 手段（例如：GitOps、ChatOps、AIOps 等），来实现运维和运营的高度自动化。

服务网格（Service Mesh）

随着微服务逐渐增多，应用程序最终可能会变为成百上千个互相调用的服务组成的大型应用程序，服务与服务之间通过内部或者外部网络进行通信。如何管理这些服务的连接关系以及保持通信通道无故障、安全、高可用和健壮，就成了一个非常大的挑战。

服务网格（Service Mesh）可以作为服务间通信的基础设施层，解决上述问题。

服务网格是一种用于管理和监控微服务架构的网络基础设施层。它提供了一种透明的方式来处理微服务之间的通信，包括服务发现、负载均衡、安全认证、流量控制和故障恢复等功能。Servic Mesh 通过将这些功能从应用程序中抽象出来，并将其作为一个独立的网络层来管理，简化了微服务架构的复杂性。

在传统的微服务架构中，每个微服务都需要处理与其他微服务的通信，包括服务发现、负载均衡和故障恢复等。这些功能通常需要在每个微服务中手动实现，导致了大量的重复代码和复杂性。而 Servic Mesh 通过将这些功能从应用程序中分离出来，使得微服务可以专注于业务逻辑，而不需要关注网络通信的细节。

所以，Service Mesh 是致力于解决服务间通讯的基础设施层，它具有下面这几个特点：

应用程序间通讯的中间层；
轻量级网络代理；
非侵入式，应用程序无感知；
可以将服务治理功能，例如重试、超时、监控、链路追踪、服务发现等功能，以及服务本身解耦。

Service Mesh 目前的发展比较火热，社区有很多优秀的 Service Mesh 开源项目，例如 Istio、Linkerd 等。当前最受欢迎的开源项目是 Istio。

Istio 是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用程序里，提供服务治理等功能。它也是一个平台，拥有可以集成任何日志、遥测和策略系统的 API 接口。

Istio 的大概实现原理是：每个服务都会被注入一个 Sidecar（边车）组件，服务之间通信是先通过 Sidecar，然后 Sidecar 再将流量转发给另一个服务。因为所有流量都经过一个 Sidecar，所以可以通过 Sidecar 实现很多功能，比如认证、限流、调用链等。同时还有一个控制面，控制面通过配置 Sidecar 来实现各种服务治理功能。

目前 1.8 版本的 Istio 架构图如下：

从图中你可以看到，Istio 主要包含两大平面。一个是数据平面（Data plane），由 Envoy Proxy 充当的 Sidecar 组成。另一个是控制平面（Control plane），主要由三大核心组件 Pilot、Citadel、Galley 组成。下面，我来分别介绍下这三大核心组件的功能。

Pilot：主要用来管理部署在 Istio 服务网格中的 Envoy 代理实例，为它们提供服务发现、流量管理以及弹性功能，比如 A/B 测试、金丝雀发布、超时、重试、熔断等。
Citadel：Istio 的核心安全组件，负责服务的密钥和数字证书管理，用于提供自动生成、分发、轮换及撤销密钥和数据证书的功能。
Galley：负责向 Istio 的其他组件提供支撑功能，可以理解为 Istio 的配置中心，它用于校验进入网络配置信息的格式内容正确性，并将这些配置信息提供给 Pilot。

与微服务架构相比，服务网格具有 3 个方面的优势：

可观测性：所有服务间通信都需要经过服务网格，所以在此处可以捕获所有调用相关的指标数据，如来源、目的地、协议、URL、状态码等，并通过 API 供运维人员观测。
流量控制：服务网格可以为服务提供智能路由、超时重试、熔断、故障注入和流量镜像等控制能力。
安全性：服务网格提供认证服务、加密服务间通信以及强制执行安全策略的能力。

不可变基础设施（Immutable Infrastructure）

在应用开发测试到上线的过程中，应用通常需要被频繁部署到开发环境、测试环境和生产环境中。在传统的可变架构时代，通常需要系统管理员保证所有环境的一致性，而随着时间的推移，这种靠人工维护的环境一致性很难维持，环境的不一致又会导致应用越来越容易出错。这种由人工维护、经常被更改的环境就是我们常说的“可变基础设施”，与可变基础设施相对应的是不可变基础设施。

不可变基础设施的构想，是由 Chad Fowler 于 2013 年提出的。具体来说就是：一个应用程序的实例，一旦被创建，就会进入只读的状态，后面如果想变更这个应用程序的实例，只能重新创建一个新的实例。

不可变基础设施的核心思想是将基础设施视为代码，并使用自动化工具进行配置和管理。通过使用版本控制系统来管理基础设施的代码，可以确保配置的一致性和可追溯性。每次对基础设施进行更改时，都会生成一个新的版本，并通过自动化流程进行部署和验证。通过这种模式，可以确保应用程序实例的一致性，这使得落地 DevOps 更加容易，并可以有效减少运维人员管理配置的负担。

不可变基础设施的具体优点包括：

能提升应用交付效率：基于不可变基础设施的应用交付，可以由代码或编排模板来设定，这样就可以使用 Git 等控制工具来管理应用和维护环境。基础设施环境一致性能保证应用在开发测试环境、预发布环境和线上生产环境的运行表现一致，不会频繁出现开发测试时运行正常、发布后出现故障的情况。
能快速、可靠地水平扩展：基于不可变基础设施的配置模板，我们可以快速创建与已有基础设施环境一致的新基础设施环境。
能保证基础设施的快速更新和回滚：基于同一套基础设施模板，若某一环境被修改，则可以快速进行回滚和恢复，若需对所有环境进行更新升级，则只需更新基础设施模板并创建新环境，将旧环境一一替换。
提高了应用的可靠性：由于基础设施不会发生手动修改，因此减少了人为错误的风险，提高了系统的可靠性和稳定性。
提高了应用的安全性：由于不可变基础设施的配置是固定不变的，因此减少了潜在的安全漏洞和攻击面。

声明式 API（Deciarative API）

声明式 API 是一种编程模型，其中开发人员通过描述所需的结果来定义系统的状态，而不需要指定如何实现这些结果。相比于命令式 API，声明式 API 更关注于“做什么”而不是“如何做”。

在声明式 API 中，开发人员使用一种描述性的语言或格式来定义他们想要的结果。这可以是一种特定的编程语言、配置文件、DSL（领域特定语言）或其他形式的声明。开发人员只需描述所需的结果，而不需要编写详细的步骤或指令。系统或框架负责解析和执行这些声明，以实现所需的结果。系统会根据声明的描述，自动推导出实现的步骤和逻辑。这种方式使得开发人员可以更专注于定义目标和结果，而不需要关注底层的实现细节。

声明式 API 具有以下优点：

简洁性：通过描述性的语言或格式，开发人员可以更简洁地定义他们想要的结果，减少了繁琐的编码工作。
可读性：声明式 API 使代码更易于理解和阅读。开发人员可以更清晰地了解代码的意图和目标。
可维护性：由于声明式 API 更关注于结果而不是实现细节，因此代码更易于维护和修改。开发人员可以更轻松地更新和改进系统，而无需担心破坏现有的实现。
可扩展性：声明式 API 使系统更易于扩展。通过简单地修改声明，可以添加、删除或修改所需的功能，而无需重新编写大量的代码。
高可靠性：采用声明式 API 开发的应用，当应用状态跟声明的不一致时，系统会自动进行调谐，以重新达到期望的在状态，所以采用声明式 API 开发的应用，天然具备业务级别的自愈能力，可靠性很高。

声明式 API 在许多领域都有应用，特别是在配置管理、用户界面开发、数据查询和处理等方面。例如，Ansible 和 Terraform 是两个常用的配置管理工具，它们使用声明式语法来定义和管理基础设施和应用程序的配置。React 框架使用声明式组件模型来构建用户界面，开发人员只需描述组件的结构和行为，而不需要手动操作 DOM。GraphQL 是一种声明式的数据查询语言，开发人员可以通过声明式查询来获取所需的数据。

分布式架构的王者——Kubernetes，几乎所有的能力都是通过声明式 API 来实现的。例如，我们在创建 Deployment 时，在 Kubernetes YAML 文件中声明应用的副本数为2，即设置replicas: 2，Deployment Controller 就会确保应用的副本数一直为2。也就是说，如果当前副本数大于2，Deployment Controller 会删除多余的副本；如果当前副本数小于2，会创建新的副本。

课程总结

这节课我们详细介绍了云原生中的核心技术栈的微服务、容器、Kubernetes、Serverless 技术栈。

持续集成和持续交付（CI/CD）：持续集成和持续交付是一种软件开发实践，通过自动化测试、构建和部署流程，实现快速、频繁地交付高质量的软件。CI/CD 可以加速软件开发周期，降低发布风险，提高团队的生产力和效率。
DevOps：DevOps 是一种软件开发和运维的文化和实践，旨在通过协作、自动化和持续反馈，实现开发团队和运维团队之间的协作和沟通，从而提高软件交付速度、质量和稳定性。DevOps 强调团队间的合作、自动化工具的使用和持续改进的精神。
服务网格（Service Mesh）：服务网格是一种基础设施层，用于管理微服务之间的通信。通过服务网格，可以实现服务发现、负载均衡、安全性、监控和故障恢复等功能，从而简化微服务架构中的通信和管理。
声明式 API（Declarative API）：声明式 API 是一种描述系统状态和期望结果的方式，而非具体步骤和操作；通过声明式 API，可以定义系统的期望状态，由系统自行决定如何实现这种状态，提高系统的可维护性和可扩展性。
不可变基础设施（Immutable Infrastructure）：不可变基础设施是指将基础设施视为不可修改的状态，而通过替换整个环境来实现更新和变更。不可变基础设施提供了一种可靠、一致和可重复的部署方式，减少了配置错误和系统漂移的风险。

课后练习

CI/CD、DevOps 的区别和联系是什么？
声明式编程和声明式 API 的区别是什么？

欢迎你在留言区与我交流讨论，如果今天的内容让你有所收获，也欢迎转发给有需要的朋友，我们下节课再见！