1.4 云原生堆栈

云原生堆栈是基于云原生技术的全新生态系统，其核心原则是将应用程序和基础设施作为一个整体来设计与管理，以更好地支持云计算环境中应用程序的部署、管理和运行。

云原生堆栈包含各种不同的技术和工具，旨在帮助企业更好地利用云计算环境中的资源，提高应用程序的可靠性、可伸缩性和安全性。这些技术和工具包括微服务、容器、Serverless、服务网格、开放式应用模型、DevOps等，如图1-5所示。

1.4.1 微服务

随着云计算技术的不断进步，微服务架构由于其所能提供的高可用性、灵活性和可扩展性等优势，已经成为许多企业的首选。

1.微服务的概念

微服务是云原生开发中最基础的技术之一，是一种通过独立、松耦合的服务构建应用程序的设计方法，它基于多个独立部署和运行的服务，构建一个完整的应用程序。所有这些服务一起工作以确保即使一个服务停止运行，应用程序也能继续工作。这种容器化的开发风格使应用程序具有高可扩展性、高弹性和低运维成本。

与之相对的是，单体架构将应用程序的所有流程紧密耦合在一起作为单一服务运行。这意味着如果应用程序的某个进程遇到需求高峰，则必须扩展整个架构。随着代码库规模的扩大，添加或改进单体应用程序中的进程变得非常复杂。这种复杂性限制了试验并使实施新想法变得困难。此外，单体架构提高了应用程序可用性的风险，因为许多相互依赖且紧密耦合的进程增大了单个进程故障的影响。

单体架构与微服务架构的对比可参考图1-6。

图1-6 单体架构与微服务架构的对比

与依赖性强的单体架构相比，微服务架构通过将不同服务打包到不同的容器，以实现服务独立。这些容器（亦称微服务）通过API互通，相连实现整个应用程序。

不同于单体架构，微服务架构允许轻松添加、编辑、删除和扩展服务，而不会破坏整体。这种灵活性使小团队可以专注他们的微服务而无须考虑兼容性问题。

此外，微服务架构支持混合技术栈，这意味着不同团队可以使用不同的编程语言、库及依赖，自主进行开发及部署，从而提高效率。微服务具有充分利用云资源的优势，可提供更高弹性、可用性及安全性。

2.微服务的好处

那么，使用微服务到底有哪些好处？

（1）高可扩展性

可扩展性是微服务架构的亮点，这使其成为不断发展的企业的理想选择。借助微服务架构，企业可以轻松根据需要增加或减少服务数量。与单体架构不同，微服务架构允许遇到高流量时进行服务扩展，确保系统可以处理高流量请求而不影响整体性能。借助微服务架构，企业可以更好地使基础设施适应业务需要，提高敏捷性和交付效率。

（2）高弹性

相较于单体架构，微服务架构具有高弹性。基于庞大的微服务集群，一个服务发生故障不会影响整体，这是因为故障局限于该服务内，而其他服务可持续运行。

此外，由于每个服务可独立部署，企业可以轻松更新服务而不影响其他服务。这使得修复Bug、添加新功能或部署新版本更容易实现而无须停机。

（3）高灵活性

微服务架构非常灵活，允许企业为每项服务选择它们想要使用的技术栈，这意味着技术团队可以使用不同的编程语言和框架创建不同的服务。而且，技术团队可以轻松地对服务进行更改，而不必担心影响应用程序的其他部分。

除此之外，每个服务都是独立的，开发人员更容易识别系统故障或错误的来源，更容易修复故障并提高系统的整体性能。

（4）更敏捷

归根结底，微服务架构能让开发流程变得更敏捷。通过模块化设计，企业可以快速采用新功能或服务，快速测试并快速上线，从而缩短开发周期，在竞争激烈的市场中抢占先机。

此外，微服务架构能激发技术团队探索新技术和框架的热情，让其紧跟技术前沿。

3.微服务架构

自2011年微服务架构理念诞生以来，基于不同的业务场景，典型的微服务架构先后经历4个发展阶段。

（1）轻量级SOA

在此阶段，针对各应用，我们不仅要实现各应用的业务逻辑，还需解决各应用与上下游服务的调用、通信及容错等问题。

随着业务规模的扩大，微服务数量快速增多，导致服务寻址逻辑日趋复杂且低效。即使是使用同一编程语言开发的应用，也仍需重复实现基础能力，导致交付延迟，影响效益。

第一代轻量级SOA如图1-7所示。

图1-7 第一代轻量级SOA示意图

（2）引入服务治理

第二代微服务架构引入注册中心作为协调者来自动化注册和发现服务。服务间通信和容错机制开始模块化，形成独立的服务框架。

然而，随着服务框架功能的不断增多，使用不同编程语言复用基础能力逐渐变得困难。这意味着开发者被迫绑定某一特定语言，违背了微服务快速迭代的初衷。

第二代引入服务治理的微服务架构可参考图1-8。

图1-8 第二代引入服务治理的微服务架构

（3）引入服务网格

直到2016年服务网格概念出现，微服务基础能力从服务框架演进到独立Sidecar进程。这一变化彻底解决了第二代微服务架构中多语言支持问题，微服务基础能力和业务逻辑实现完全解耦。

Sidecar进程开始处理微服务间通信，承担第二代微服务框架的功能，包括服务发现、调用容错，甚至细粒度的服务治理（如权重路由、灰度发布、流量回放、端点伪装等）。

第三代引入服务网格的微服务架构如图1-9所示。

图1-9 第三代引入服务网格的微服务架构

（4）Serverless架构

随着组织及技术生态的发展，管理架构成为一个重大挑战。为了应对这一挑战，Serverless架构成为一种新兴解决方案。

Serverless是一种新的应用程序架构模式，允许开发者创建和运行应用程序而无须管理服务器。其主要思想是将应用程序的逻辑划分为小型函数，这些函数可以在需要时自动触发并执行。选择Serverless架构不仅可以简化应用程序开发流程，还可以促进企业在DevOps和敏捷实践方面的优化。

在此架构中，微服务被进一步简化为微逻辑，从而对Sidecar模式提出了更高要求。更多可复用的分布式能力，例如状态管理、资源绑定、链路追踪、事务管理等从应用中剥离，被下沉到Sidecar中。同时，在开发侧开始提倡面向localhost编程的理念，提供标准API以屏蔽底层资源、服务、基础设施的差异，进一步降低微服务开发难度。这便是目前业界提出的多运行时微服务架构。

Serverless架构的优点主要在于简化了应用程序的开发和部署流程，降低了成本，提高了可伸缩性和可靠性。随着Serverless架构的不断发展，越来越多的云服务提供商也开始提供Serverless服务，例如AWS Lambda、Azure Functions、Google Cloud Functions等。云服务提供商为开发者提供简单、快速、可靠的方式来构建和部署应用程序，让开发者能够专注于应用程序的业务逻辑和功能，而不必担心基础设施的管理和维护。

作为当前最为流行的架构模式，Serverless架构可参考图1-10。

图1-10 Serverless架构

4.常用的微服务技术框架

随着微服务架构的不断普及和应用，市场上出现了许多微服务技术框架。从开发语言角度来看，微服务技术框架目前主要涉及两大生态体系，分别是基于Java生态的技术框架和基于Go生态的技术框架。

（1）基于Java生态的技术框架

1）Spring Cloud。Spring Cloud是目前最为流行的Java微服务框架之一，基于HTTP（HTTPS）的REST服务构建微服务体系，为开发者提供了一套完整的微服务架构技术生态链，其中包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、全局锁、决策竞选、分布式会话与集群状态管理等。

2）Apache Dubbo。Apache Dubbo是阿里巴巴开发的高性能RPC框架，具有基于接口的RPC、智能负载均衡、自动注册和发现以及高可扩展性等特性，可以实现实时流量管理和服务治理。多年来，Dubbo已经成为国内使用最广泛的微服务框架，并形成了庞大的生态体系。

为了打造生态竞争力，阿里巴巴开源Spring Cloud Alibaba、Nacos、Sentinel、Seata和Chaosblade等项目。

Dubbo 3.0版本加入了服务网格特征，Dubbo协议得到Envoy支持。除此之外，Dubbo仍在不断完善服务发现、负载均衡和服务治理能力，以进一步提升在微服务架构中的应用价值。

3）Quarkus。Quarkus是Red Hat专为OpenJDK HotSpot和GraalVM设计的Kubernetes原生Java开发框架，提供了反应式和命令式编程模型，以应对微服务开发中的挑战。Quarkus的优势之一是易于集成开发HTTP微服务、反应式服务、消息驱动微服务和Serverless架构。同时，Quarkus具备极简的特性和直观的系统设计，使开发者可以更专注于业务方面的开发，大幅提高了开发者的生产力。此外，Quarkus还具有统一配置、实时编码、DEV UI和持续测试等特性，为开发者提供了极佳的微服务开发体验。

（2）基本Go生态的技术框架

1）GoMicro。GoMicro是使用Go语言开发微服务的最简单的工具之一。作为一个可插入的PRC库，GoMicro提供了微服务应用程序开发的基本构建块。尽管GoMicro本身不是框架，但基于其开箱即用的模块，可以快速应对分布式架构的挑战，并为开发人员提供通用的、易于理解和使用的简单抽象。

从本质上而言，GoMicro的核心是服务抽象，即一个用于创建微服务并与微服务交互的通用接口。服务由名称、版本、可选的元数据映射和公开服务功能的端点列表组成。除此之外，服务抽象还提供了注册处理程序、订阅者和客户端以便与其他服务通信的方法。处理程序主要负责处理来自客户端的传入请求，订阅者从发布者接收关于给定主题的消息，客户端负责向其他服务发送请求或作为向主题发布消息的接口。

2）Go Kit。作为一种流行的开源工具包，Go Kit专门用于帮助开发人员基于Go语言构建可扩展、模块化和可维护的微服务。Go Kit专注于3个主要的抽象：服务、传输和中间件。通过将服务逻辑与传输和中间件问题分离，开发人员可以构建可测试、解耦和可重用的微服务。此外，Go Kit还提供了内置支持，如服务发现、熔断、指标监测等，以提高微服务的可靠性、性能和可观测性。Go Kit的模块化架构允许开发者根据需要部分替换或扩展框架，因此，它成为一个灵活的工具包。

3）Go Dubbo。Go Dubbo是一个基于Apache Dubbo框架的开源RPC框架，专门用于构建可伸缩、可靠、高性能的微服务，使用Protocol Buffers定义服务接口，实现服务之间的高效通信，并可以方便地与其他语言集成。Go Dubbo提供了一套包和工具，帮助开发者构建服务接口定义、服务发现、负载均衡、服务调用、服务治理、服务网格等。此外，Go Dubbo的配置包提供对服务治理的内置支持，并允许对服务到服务的通信和可观测性进行细粒度控制，使其成为构建分布式系统和微服务架构的热门选择之一。

1.4.2 容器

在过去几年，云计算和虚拟化技术得到了广泛应用，这使技术团队可以更加高效地管理和部署应用程序。然而，虚拟化技术存在一些缺点，例如启动时间长、占用资源多等。为了解决这些问题，容器技术应运而生。

1.容器的概念

容器是一种虚拟化技术。应用及其依赖可以打包到独立的运行环境（即容器）。与虚拟机相比，容器更轻量，启动更快，且易于在环境间移动。每个容器化应用运行在单个操作系统上，共享内核但在进程、网络和文件系统方面与其他容器隔离。

Kubernetes已经成为容器编排领域的事实标准，具有卓越的开放性、可扩展性，屏蔽了基础设施层的差异，并基于优良的可移植性，让应用在不同的环境中运行。企业可以通过Kubernetes，结合自身业务特征来设计自己的云架构，以更好地支持多云、混合云，避免被云厂商锁定。

随着容器技术的标准化，生态社区开始构建上层的业务抽象，例如服务网格Istio、机器学习平台Kubeflow和Serverless应用框架Knative等。这些业务抽象进一步促进了容器生态的分工和协同，帮助企业更好地构建自己的云架构。

2.容器技术的3个核心价值

近年来，容器技术在云计算和数字化转型中的应用越来越广泛，容器技术的3个核心价值——敏捷、高弹性和可移植性——也受到企业的广泛关注。

（1）敏捷

容器技术不仅提高了企业IT架构的敏捷性，还能加速业务迭代，为创新探索提供坚实的技术保障。据统计，使用容器技术可以获得3～10倍的交付效率提升，这意味着企业可以更快速地迭代产品，以更低的成本进行业务试错。容器技术的快速启停业务、高度可移植性及资源隔离等特性，使企业可以更灵活地部署和管理应用程序，从而更快地响应市场变化和客户需求。

（2）高弹性

在互联网时代，企业IT系统经常需要应对各种预期之外的爆发式流量增长，例如促销活动、突发事件等带来的流量增长。容器技术可以帮助企业应对这些挑战，充分发挥云计算的弹性优势，同时降低运维成本。

通常情况下，利用容器技术，企业可以提高部署密度并降低弹性需求，从而降低计算成本。这意味着企业可以更有效地利用云计算资源，满足业务需求。

（3）可移植性

容器将应用程序与底层运行环境解耦，已经成为应用程序分发和交付的标准技术。Kubernetes是一个容器编排系统，屏蔽了底层基础设施之间的差异，帮助应用程序在不同基础设施上平滑运行。

为了进一步保障不同Kubernetes实现之间兼容，CNCF（云原生计算基金会）推出了Kubernetes一致性认证。这项认证确保了Kubernetes实现的一致性，使企业更加放心地采用容器技术来构建云时代的应用基础设施。

3.容器编排与Kubernetes

容器编排已经成为现代IT基础架构中不可或缺的一部分。随着越来越多的组织采用容器技术，对容器的管理和扩展需求也越来越高，从而推动了容器编排工具的发展和应用。

容器编排是指在容器化环境中管理和扩展容器的过程，涉及跨主机集群自动部署、管理和扩展容器化应用程序。容器编排工具提供了一个抽象层，使开发人员可以专注于编写代码，而无须担心基础设施问题。

（1）容器编排的生态意义

在实际的项目开发中，容器编排工具可以给团队带来以下好处。

❑可扩展性：容器编排工具允许根据需求变化向上或向下扩展容器化应用程序。这意味着团队可以根据业务需求灵活调整应用程序规模，确保应用程序始终能够可靠地响应用户请求。

❑高可用性：容器编排工具支持跨主机集群部署应用程序，即使其中一台主机故障也可以保证应用程序可用，从而降低硬件故障或网络故障导致应用程序不可用的风险，提高应用程序可用性。

❑自动化：容器编排工具自动执行许多任务，包括应用程序部署、应用程序扩展和负载均衡等，从而减少手动干预工作，降低出错风险，使IT团队能够将更多时间和精力放在其他关键任务上，提高工作效率。

❑灵活性：容器编排工具允许团队在各种环境（包括本地、云和混合环境）中部署应用程序，这意味着团队可以依据不同的业务需求和场景选择最适合的部署环境，从而提高应用程序的灵活性。

（2）容器编排产物——Kubernetes

Kubernetes已经成为事实标准，被广泛用于自动部署、扩展和管理容器化应用程序。作为一种分布式应用程序管理工具，Kubernetes提供了以下核心能力。

❑资源调度：Kubernetes可以根据应用程序对CPU、内存、GPU等资源的需求，在集群中选择合适的节点运行应用程序，从而实现资源的优化分配和利用。

❑应用程序部署与管理：Kubernetes支持应用程序的自动发布和回滚，以及管理与应用程序相关的配置。同时，它还可以自动编排存储卷，将存储卷与容器化应用程序的生命周期相关联，从而提高应用的可靠性和可管理性。

❑自动修复：Kubernetes监测集群中所有宿主机的状态，当宿主机或操作系统出现故障时，自动启动节点健康检查。此外，Kubernetes还支持应用自愈，从而大大简化运维管理。

❑服务发现与负载均衡：Kubernetes提供了各种应用服务，结合DNS和多种负载均衡机制，支持容器化应用之间相互通信，提高了应用程序的可用性和可靠性。

❑弹性伸缩：Kubernetes能够实时监控工作负载所承受的压力，如果当前业务的CPU使用率过高或响应时间过长，自动对该业务负载进行扩容，从而提高应用程序的可扩展性和性能。

Kubernetes是一款高度可扩展的容器编排平台，控制平面包含4个主要组件：API Server、Controller、Scheduler及Etcd。这些组件共同协作，为Kubernetes集群提供可靠的管理和运维支持。Kubernetes架构如图1-11所示。

作为一个流行的容器编排平台，Kubernetes的设计理念主要包括以下关键点。

1）声明式API：Kubernetes提供多种资源类型，如Deployment（无状态应用）、StatefulSet（有状态应用）、Job（任务类应用）等，以实现对不同类型工作负载的抽象。开发者可以使用声明式API关注应用自身，而无须关注系统执行细节。采用基于声明式API的条件触发可以构建更加健壮的分布式系统，相较于边缘触发更可靠。

2）可扩展性：Kubernetes的所有组件都是基于一致的、开放的API实现和交互。开发者可以使用Kubernetes中的自定义资源（CRD）和操作符（Operator）等进行相关扩展，从而提升Kubernetes的能力。这种可扩展架构使Kubernetes可以轻松适应各种应用场景，满足各种业务需求。

图1-11 Kubernetes架构

3）可移植性：Kubernetes通过一系列抽象层，如负载均衡服务、容器网络接口（CNI）、容器存储接口（CSI）等，屏蔽底层基础设施的实现差异，从而实现容器灵活迁移。这种可移植设计使Kubernetes能够在不同的基础设施中高效运行，从而降低应用开发和部署的复杂度。

1.4.3 Serverless

随着组织规模及技术生态的持续扩大，技术团队在管理架构方面面临着巨大挑战。由于他们需要将时间和资源集中在应用程序的开发与优化上，基础设施管理往往成为制约发展的瓶颈。Serverless作为一种新兴技术，有助于技术团队专注于核心业务，避免因基础设施管理而分散精力，进而提升开发效率。

1.Serverless简介

随着Kubernetes成为云原生技术的代表，被视为云计算的新一代操作系统，面向特定领域的后端即服务（BaaS）成为该操作系统的服务接口。数据库、中间件、大数据、AI等领域的大量产品开始提供全托管的云服务。如今越来越多的用户已经习惯使用云服务，而不是自己搭建存储系统、部署数据库软件。

当这些BaaS产品日趋完善时，Serverless技术因为降低了服务器运维复杂度，让开发人员可以将更多精力集中于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。

作为一种云计算执行模型，Serverless架构能够根据客户需求提供应用程序部署基础架构的主要组件，例如服务器和机器资源。这意味着开发人员不再负责确保端到端的服务器扩展、维护和配置。

在FaaS中，应用程序代码是不同功能实现的集合，每个功能旨在执行不同的操作。这些功能必然会被某些事件触发，例如电子邮件或HTTP请求转发。开发人员必须在部署应用之前对这些功能进行基本测试（具体需要测试功能及其各自的触发器），然后将其部署到服务提供商账户上。

服务提供商需要实现一个新功能时，通常有两种方法可以选择。

❑利用当前正在运行、可用的服务器来实现该功能。

❑调用一个新的服务器来实现该功能。

这两种操作都是以远程方式进行的，开发人员不需要亲自参与其中，可以专注于编码工作。

传统架构和Serverless架构的对比如图1-12所示。

图1-12 传统架构和Serverless架构的对比

2.Serverless架构特点

Serverless架构强调使用基于云的服务和技术来构建和部署应用程序，而无须开发者关注服务器和基础设施的管理。Serverless架构的特点如下。

（1）FaaS

FaaS是Serverless架构中最重要的功能之一。基于FaaS功能，开发者在构建、运行、部署和维护应用程序时无须考虑服务器和基础设施的管理。

（2）安全令牌

Serverless用户通过提供商提供的API登录系统并使用服务。因此，Serverless架构应该设计为在触发API访问之前为每个用户生成一个安全令牌。

（3）数据库

尽管应用程序是在无服务器计算架构上开发和管理的，但其中的数据仍需要存储在数据库中。因此，具备高稳定性和高可靠性的数据库仍然是Serverless架构的重要组成部分。

3.Serverless架构的价值

Serverless架构的价值主要体现在以下几方面。

（1）节省成本

Serverless架构的最大优势之一是可以大幅削减基础设施管理工作和降低运维成本。Serverless服务是按需计费的，而不是像传统计算架构那样需要购买和维护服务器，这样可以显著节省成本，并且更容易做预算和控制支出。

（2）提高开发效率

Serverless架构可以使开发人员更专注于业务逻辑的编写，而不必花费时间和精力来管理服务器和基础设施。此外，Serverless架构还支持自动扩展和管理资源，从而减轻开发人员的负担。这样可以提高开发效率，缩短产品上市时间。

（3）提高服务的稳定性和可用性

在Serverless架构中，运维任务交给云服务提供商，这样开发人员有更多的精力来确保服务的稳定性和可用性。此外，Serverless架构还可以自动处理错误和故障，从而降低应用程序中断风险。

（4）提高应用可扩展性

Serverless架构可以根据需求自动扩展资源，从而提高应用可扩展性。这使应用程序可以在高峰期保持高性能，而在低峰期减少资源使用量，从而节省成本。

（5）提高应用安全性

Serverless架构可以通过多层安全措施来保护应用程序和数据。此外，Serverless架构还可以自动更新安全补丁，保护应用程序免受网络攻击。

1.4.4 开放式应用模型

1.开放式应用模型（OAM）简介

在云原生技术的推动下，负载均衡器和网络基础设施等可以通过API控制，基础设施可以像管理应用一样由代码管理。应用开发人员可以将基础设施管理融入代码，即构建包括基础设施在内的应用环境。这也意味着应用开发人员需要掌握更多的基础设施知识，增加了他们的学习成本和工作负担。

为了解决这个问题，微软和阿里云提出了一个开源项目——开放式应用模型（Open Application Model，OAM）。OAM提供了一种标准方法来描述和部署云原生应用，即通过为应用及其组件提供声明式规范，简化云原生环境中应用的部署和管理。

2.OAM的优势

OAM为构建和部署云原生应用的开发人员、运营商和组织提供了方便，具有以下优势。

（1）简化应用部署和管理

OAM通过声明的方式来描述应用及其组件，从而简化云原生应用的部署和管理，尤其在处理多个组件和依赖项时。

（2）与平台无关

OAM与平台无关，这意味着OAM可以与任何云原生平台一起使用，包括Kubernetes、OpenShift和Cloud Foundry。基于OAM的灵活性，技术团队可以根据业务需求选择最适合的平台。

（3）易于应用管理

基于声明式规范，应用程序中组件之间的关系和依赖项得到了清晰定义，使开发人员和运维人员能够更容易地管理应用。

（4）简化多云部署

基于声明式规范，开发人员可以将应用中的组件和依赖项定义为一组相互关联的资源，使得应用能够更加简单、可靠地在不同的云环境中部署和运行。

3.OAM工作原理

OAM提供了一种声明式规范。依据此规范，我们可以利用YAML文件来描述云原生应用及其组件、依赖项、相关配置和资源。通过YAML文件描述，应用架构及组件关系更加清晰，同时也更易于实现版本控制和管理。

OAM架构如图1-13所示。

图1-13 OAM架构

OAM规范包括应用配置、组件原理和特征定义。

❑应用配置：设置云原生应用的首要规则，定义了应用名称、版本、描述、组件及依赖。

❑组件原理：定义了构成云原生应用的组件及其配置、资源和依赖。每个组件可使用定义属性和资源的YAML文件进行描述。

❑特征定义：定义了可应用于云原生应用组件的特征，为组件提供附加功能，例如缩放、指标监控。

OAM还提供了应用部署控制器（Application Deployment Controller，ADC），该组件负责根据OAM规范来部署和管理云原生应用。ADC读取OAM规范，并将应用及其组件部署到底层的基础设施或平台上。

对于在分布式计算环境中构建和部署云原生应用的开发人员、运维人员和组织来说，OAM是一个非常重要的工具，可以帮助他们以一致和可重复的方式来定义、部署和管理应用。

1.4.5 服务网格

服务网格是分布式应用在微服务架构之上发展起来的新技术，旨在将微服务间连接、流量控制和可观测等通用功能下沉到基础设施层，实现应用与基础设施的解耦。这个解耦意味着开发者无须关注微服务相关治理问题，而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。

服务网格通过在应用之外引入专用的数据平面和控制平面，将大量非功能性需求从业务进程剥离到其他进程，实现了应用轻量化。

图1-14展示了服务网格的典型架构，其中数据平面和控制平面密切配合，共同实现服务网格功能。

图1-14 服务网格典型架构

除了Istio，市场上还有一些相对小众的服务网格解决方案，如Linkerd和Consul。Linkerd在数据平面上采用Rust语言实现代理，而在控制平面上与Istio一样采用Go语言编写。最新的性能测试数据显示，Linkerd在时延和资源消耗方面比Istio更具优势。在Consul的控制平面可以直接使用服务，在数据平面可以选择性地使用Envoy。Linkerd和Consul的功能均不如Istio完整。

除了基于Sidecar代理模式的网格外，市场上逐渐流行基于节点、主机的代理模式，例如Traefik。无论选择哪种模式，作为云原生生态体系的一部分，服务网格在管理东西向流量方面都有重要意义。

1.4.6 DevOps

DevOps是一种组织和实践方法论，旨在通过协调开发团队和运营团队之间的合作，高效创建和交付应用程序和服务。

1.DevOps概念

随着项目周期延长、协作减少，长期增量交付对业务产生负面影响。DevOps提出在组合的管道中持续开发和交付。通过协作，开发和运营团队可以消除障碍，并专注于改进创建、部署和持续监控软件的方式。

借助云原生技术、开源解决方案和敏捷API，团队可以比以往更高效地交付和维护代码，将开发、运维和支持过程整合，以满足不断变化的需求。

对于开发团队而言，目标是将创建代码的过程视为一个持续的循环而不是一条直线。与运营团队合作或整合开发有助于将敏捷开发的原则——基于优先级的快速、小规模的改进——应用于整个软件生命周期（包括初始设计、概念验证、测试、部署和最终修订）。

对于运营团队而言，与开发团队合作可以将敏捷流程从软件扩展到平台和基础架构，有助于分析IT架构中所有层的详细信息和上下文。通过将设计思维应用于交付系统，运营团队可以将他们的注意力从管理基础架构转移到提供出色的用户体验上。

DevOps通过重新定义工作流和方法链的范式，改变了IT行业的运作方式。随着DevOps进入第二个十年，DevOps应用范围和重点正在扩展到产品交付之外。

2.DevOps成熟度模型

为了评估组织在DevOps之旅中的位置并制定改进路线，我们提出DevOps成熟度模型。DevOps成熟度模型重点关注组织流程的有效性，例如通过某些业务实践，实现更高级别的成熟度和提高绩效。

下面总结了4个关键原则，作为DevOps实践成熟度的评估基准。

（1）文化

DevOps实践不仅代表着技术转变，还代表着文化转变。要充分发挥DevOps的潜力，需要有效地跨职能协作，并且要求组织层面普遍接受失败并反复试错，让所有利益相关方参与进来，以确保DevOps实践不会以任何形式被破坏或阻碍。

据Gartner的一份报告，预计四分之三的DevOps计划无法实现，原因是组织无法打造准备好接受变化的文化。该报告指出，不切实际的期望、忽视业务成果、协作不足及员工抗拒变革是DevOps实践失败的关键因素。以下是为了确保DevOps实践成功而制定的文化准则。

❑为每个产品创建一个专门的团队。

❑消除开发和测试团队之间的界限。

❑每个团队都有自己的待办事项。

❑团队负责将管理的产品一直交付至生产阶段。

❑明确要求和预期结果。

❑依据发布需求确定工作流和流程的优先级。

（2）持续测试

随着应用程序在驱动业务流程中扮演的角色越来越重要，企业现在比以往任何时候都更加重视在速度和准确性之间取得平衡。任何性能或构建质量问题都会影响最终的用户体验。同时，延误交付也会直接导致失去竞争优势。这些问题仍然是实施持续测试的主要障碍。

DevOps高成熟度可以帮助我们最大限度利用持续测试，从中获取最大价值。就持续测试而言，DevOps成熟度主要在以下流程和实践中评估。

❑为每个产品创建专门的测试环境。

❑实施一系列测试模型。

❑自动对所有提交的更改进行安全和单元测试。

❑持续分析和验证单元测试覆盖率。

❑定义和自动化回归测试。

❑进行风险分析，为探索性测试提供基础。

（3）自动化

自动化在DevOps流程中起着关键作用，但必须基于已定义的流程才能产生理想的结果。将糟糕的流程或未定义的流程自动化只会妨碍DevOps按照最佳方式实施。

就自动化而言，DevOps成熟度可从以下方面评估。

❑构建过程的高效性。基于历史工件、日志以及每次代码提交和构建结果，可以快速分析问题。

❑标准化的部署管道。可以满足所有环境（如开发、测试、生产）的需求。

❑快速迭代。通过频繁发布软件来实现高效的代码管理。

❑完全自动化。通过版本控制系统中存储的脚本，将数据库变更作为部署流程的一部分，以减少人为失误。

（4）架构

一个组织能否成熟地实施DevOps流程，取决于基础架构的稳健性。应用程序架构是决定因素之一，决定组织是否能够利用DevOps实现快速发布。

不同的架构支持不同的目标实现。我们必须选择适合自身需求、符合自身目标、与开发技术和基础设施兼容的架构。

就架构而言，DevOps成熟度可从以下方面评估。

❑在系统内设置模块，边界清晰。

❑每个模块都具备独立运行能力。

❑明确定义所需的质量属性。

❑快速、频繁地测试每个应用程序组件。

❑防止断路或级联故障。

3.DevOps成熟度模型划分

（1）应用程序维度的DevOps成熟度模型

应用程序维度的DevOps成熟度是根据从开发到生产阶段的代码开发过程的安全性来评估的。在评估过程中，我们需要全面进行构建、测试、安全扫描、代码覆盖检查，以及对部署管道中的自动化元素进行持续监控。

（2）数据维度的DevOps成熟度模型

要从数据维度衡量DevOps成熟度模型，我们必须关注DataOps能力，即自动执行数据变更的能力和自动验证功能的能力。

（3）基础设施维度的DevOps成熟度模型

基础设施维度的DevOps成熟度模型关注处理基础设施问题的相关技能，以及在商店环境中的自助服务能力，特别是与其他业务相关的能力。

4.DevOps工作原理

（1）DevOps生命周期定义

DevOps生命周期描述了整个应用程序生命周期中不同阶段各团队的协作方式和过程，以及在各阶段各团队使用的工具和技术方案。

DevOps生命周期如图1-15所示。

图1-15 DevOps生命周期

（2）DevOps工作流

在每个阶段，DevOps实践如下。

1）规划阶段：在这个阶段，技术团队确定业务需求并结合最终用户反馈，根据创建的产品路线图最大化业务价值，并为交付所需的产品做好准备。

2）编码阶段：开发团队利用工具（如Git）简化开发过程，避免安全问题和低效的编码，着手进行代码输出。

3）构建阶段：一旦代码开发完成，开发者利用构建工具（如Maven和Gradle）将代码提交至共享代码库。

4）测试阶段：测试人员将软件部署到测试环境，利用JUnit、Selenium等工具进行用户测试、安全测试、集成测试和性能测试，确保软件质量。

5）发布阶段：测试通过后，运营团队根据组织要求安排发布或将多个版本同时部署到生产环境。

6）部署阶段：运营团队基于基础设施即代码原则构建生产环境，随后利用不同工具以及基于特定的流程规范进行构建版本的发布。

7）运营阶段：软件正式上线，供最终用户使用。运营团队利用相关自动化工具配置和维护服务器资源。

8）监控阶段：在这个阶段，DevOps管道对客户行为、应用程序性能等进行监控。监控整个环境有助于找到影响开发和运营团队生产力的瓶颈。

（3）DevOps生命周期的7C

DevOps是一个持续性的软件开发方法论，覆盖了从规划到监控的整个软件生命周期。为了强调这种持续性，该方法论将整个生命周期分解为7个以持续性为核心的阶段，即TC。

1）持续开发（Continuous Development）。持续开发是整个软件开发周期中至关重要的阶段，在描绘愿景方面起着关键作用。在这个阶段，开发团队通过与利益相关者讨论和收集项目需求来规划项目。同时，根据客户反馈不断更新产品待办列表，以实现持续的软件开发。开发团队会根据业务需求编写代码，并持续优化与改进代码以应对需求变化和性能问题。

为了支持持续开发，开发团队需要使用一些代码维护工具，如GitLab、Git、TFS、SVN、Mercurial、Jira、BitBucket、Confluence和Subversion等。许多公司更喜欢采用敏捷协作方法，如Scrum、Lean和Kanban等。在这些工具和方法中，Git和Jira是最受欢迎的，它们可用于复杂项目中开发团队之间的协作。

2）持续集成（Continuous Integration）。这是生命周期中的另一个关键阶段，在这个阶段，更新的代码、功能和程序被集成到现有代码中。同时，单元测试也会在每一次变更中检测和识别错误，并相应地修改源码。

为了支持持续集成，有许多DevOps工具可供选择，例如Jenkins、Bamboo、GitLab CI、Buddy、TeamCity、Travis和CircleCI等。这些工具旨在使工作流程更加顺畅和高效。例如，Jenkins是一款被广泛使用的开源工具，用于自动化构建和测试。在持续集成时，我们应根据业务和项目需求选择工具。

3）持续测试（Continuous Testing）。在持续集成之前还是之后执行持续测试，团队可以自主决定。在这个阶段，质量分析师使用工具不断测试软件，如果发现问题，返回到集成阶段进行代码修改。自动化测试可以帮助团队节省时间和精力，同时降低交付低质量软件的风险。此外，持续测试还可以修正测试评估结果，以最大限度地减少测试环境的配置和维护成本。

为了支持持续测试，有许多DevOps工具可供选择，例如JUnit、Selenium、TestNG和TestSigma等。Selenium是最流行的开源自动化测试工具，支持在多平台使用。TestSigma是一个AI驱动的测试自动化平台，可以通过AI降低测试复杂性。

4）持续部署（Continuous Deployment）。持续部署是DevOps生命周期中最关键和最活跃的阶段之一，最终代码将部署在生产服务器上。在这个阶段，配置管理是非常重要的，以确保代码在服务器上部署准确、顺畅。开发团队将代码发布到服务器并更新服务器，以在整个生产过程中保持配置一致。容器化工具可以帮助部署，并确保开发、测试、生产和暂存环境的一致性。这使得在生产环境持续交付新功能成为可能。

为了支持持续部署，有许多DevOps工具可供选择，例如Docker、Vagrant、Spinnaker、Argo CD等。Docker和Vagrant是广泛用于持续部署的可扩展性工具。Spinnaker是一个用于发布软件变更的开源持续交付平台。Argo CD是用于Kubernetes原生CI/CD的开源工具。

5）持续反馈（Continuous Feedback）。为了有效地分析和改进应用程序代码，持续反馈活动应运而生。在这个阶段，定期评估每个版本下的用户行为，以改进版本。企业可以选择结构化或非结构化方法来收集反馈。在结构化方法中，反馈是通过调查和问卷收集的。非结构化方法是通过社交媒体平台等收集反馈。总体来说，持续反馈使得持续交付成为可能。

通过持续反馈，团队可以了解用户的需求和意见，并及时进行改进，有助于提高用户满意度和应用程序质量。此外，持续反馈还可以帮助团队预测和解决存在的问题，从而降低修复成本和风险。

6）持续监控（Continuous Monitoring）。在持续监控阶段，应用程序的功能和特性会被持续监控，以发现问题，例如内存不足、无法访问服务器等。持续监控有助于团队快速识别与应用程序性能相关的问题及其根本原因。团队发现任何关键问题，应用程序将再次经历整个DevOps周期以找到解决方案。此外，持续监控工具可以自动监测并解决安全问题。

为了支持持续监控，有许多DevOps工具可供选择，例如Nagios、Kibana、Splunk、PagerDuty、ELK Stack、New Relic和Sensu等。这些工具可以监控应用程序的各种指标，并提供实时警报和分析，以便团队及时采取行动。

7）持续运营（Continuous Operation）。在DevOps生命周期的最后阶段，持续运营对于最大限度缩短停机时间至关重要。通常，更新可能会使得服务器下线，从而延长停机时间，甚至可能给公司造成重大损失。持续运营是利用Kubernetes和Docker等容器管理系统完全消除停机时间。这些容器管理工具有助于简化在多个环境中构建、测试和部署应用程序的过程。这一阶段的最终目标是最大限度延长应用程序的正常运行时间，以确保提供流畅的服务。通过持续运营，开发人员可以节省时间，加快应用程序上市。

为了支持持续运营，有许多DevOps工具可供选择，如Kubernetes和Docker Swarm等。这些工具可以自动处理容器的创建、扩展、负载均衡等任务，从而显著提高应用程序的可靠性和稳定性。