阿里云原生架构白皮书

为什么需要云原生

计算机软件技术架构进化受到两大主要驱动因素影响：一是底层硬件升级，二是顶层业务发展需求。随着x86硬件体系的成熟，许多应用不再依赖昂贵的大型机，而是选择了价格更低廉的x86硬件，并推动了各种分布式架构的发展，如CORBA、EJB、RPC等。随后，互联网业务迅猛发展，传统IOE架构无法满足大规模并发需求，出现了互联网架构体系，如阿里巴巴Dubbo&RocketMQ、SpringCloud等。云计算已经发展了十五年，但仍有许多应用停滞在传统IDC时代，未能充分利用云的能力，导致效率、可用性和可扩展性受限。数字化转型要求业务更加敏捷，迭代速度更快，这对技术提出了更高要求。为应对挑战，企业需要新的云原生架构，以释放云计算的潜力，实现敏捷、成本效益和灵活性。

云原生架构定义

云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

上图展示了在代码中通常包括三部分:业务代码、三方软件、处理非功能特性的代码。

• "业务代码", 指实现业务逻辑的代码;
• "三方软件"是业务代码中依赖的所有三方库,包括业务库和基础库;
• "处理非功能性的代码"指实现高可用、安全、可观测性等非功能性能力的代码。

三部分中只有业务代码是核心，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂。

架构规则

云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面。

1. 服务化原则：当代码规模变大时，应考虑服务化拆分，例如微服务架构，以便分离不同模块的业务迭代，提高整体进度和稳定性。服务化架构还增加了模块间的复用程度。以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块做基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的
2. 弹性原则：弹性是指系统的部署规模可以根据业务量的变化自动伸缩，而不需要提前准备大量硬件和软件资源。这有助于缩短上线时间，降低IT成本，并确保在业务规模突然扩张时保持高可用性。
3. 可观测性原则：在分布式环境中，需要强大的可观测性来监测和分析服务的运行状况，包括故障诊断、SLO违规、故障影响、变更效果等。这种可观测性通过日志、链路跟踪和度量等方式实现，使运维、开发和业务团队能够深入了解系统性能，进行关联分析和持续优化。
4. 韧性原则：软件必须具备韧性，能够在面临各种异常情况时保持可用性，包括硬件故障、性能瓶颈、网络异常、软件漏洞、安全攻击等。韧性是确保业务不中断、用户体验良好的关键。
5. 所有过程自动化原则：云原生架构采用了容器、微服务、DevOps等技术，提高了迭代速度，但也引入了复杂性和交付难题。通过自动化工具和标准化流程，可以实现软件的自动化交付。
6. 零信任原则：零信任安全重新定义了访问控制，不信任任何人、设备或系统，默认情况下。它基于身份进行访问控制，将安全重心从网络中心化转向身份中心化，提供更灵活的访问控制机制。
7. 架构持续演进原则：云原生架构必须具备持续演进的能力，随着技术和业务的变化进行适应和重构。需要考虑组织层面的架构治理和风险控制，以在快速迭代的情况下保持架构的有效性。

这些原则有助于构建更灵活、可扩展和可管理的云原生架构。

架构模式

云原生架构涵盖多种架构模式，以下是其中一些关键模式：

1. 服务化架构模式：这是云原生应用的标准架构，要求将应用模块划分为独立的服务，并通过接口契约和标准协议确保它们之间的互联互通。微服务和小服务（MiniService）是服务化架构的典型模式，可以提高代码质量和迭代速度。小服务通常适用于大型软件系统，以避免接口颗粒度过细的问题。服务化架构还支持弹性部署和升级，但需要注意模块管理和治理的挑战。
2. Mesh化架构模式：这个模式将中间件框架（如RPC、缓存、异步消息）从业务进程中分离出来，实现业务代码与中间件的解耦。中间件的升级对业务进程没有影响，甚至可以迁移到其他平台的中间件而不影响业务。业务进程中只保留与Mesh进程通讯相关的"薄"的Client部分，而流量控制和安全等逻辑由Mesh进程处理。

1. Serverless模式

Serverless让开发者无需考虑部署细节，云平台自动管理应用的运行。Serverless更适合事件驱动、短时应答和简单任务。

1. 存储计算分离模式

在分布式环境中，有状态应用面临CAP（C一致性、A可用性、P分区容错性）问题，对于某些状态数据，如果存储在远程缓存中会导致交易性能下降，在云环境中，推荐把数据采用云服务来保存，从而实现存储计算分离。

1. 分布式事务模式

在微服务架构中，每个服务使用私有的数据源，而不是共享数据源，但这可能导致需要跨多个微服务访问大颗粒度的业务，从而引发分布式事务问题，可能导致数据不一致。架构师在不同场景下需要选择适当的分布式事务模式：

1. 可观测架构

可观测架构包括Logging、Tracing和Metrics三个方面，用于监测和分析系统性能和行为。架构决策者应选择适合的开源框架（如OpenTracing、OpenTelemetry）并规范可观测数据的传播方式，以满足服务水平目标（SLO）的度量需求，从而优化服务水平协议（SLA）。这包括规划可观测数据的传递方式，确保在分布式链路分析时有足够的信息进行快速关联分析。

1. 事件驱动架构

事件驱动架构(EDA,EventDrivenArchitecture)本质上是一种应用/组件间的集成架构模式

事件驱动架构（EDA）与传统消息不同，它具有schema，可验证事件的有效性，同时具备QoS保障机制，可处理事件处理失败。EDA不仅用于(微)服务解耦，还可应用于以下场景：

• 增强服务韧性：由于服务间是异步集成的，下游的处理失败不会影响上游。
• CQRS(Command Query Responsibility Segregation)：使用事件发起对服务状态的影响命令，而对服务状态没有影响的查询使用同步调用的API接口。
• 数据变化通知：一个服务中的数据变化可以通知其他感兴趣的服务，例如用户订单完成后通知积分服务和信用服务。
• 构建开放式接口：事件提供者无需关心订阅者，保持接口的开放性。
• 事件流处理：应用于大量事件流的数据分析场景，例如基于Kafka的日志处理。
• 基于事件触发的响应：适用于IoT时代的传感器数据处理应用，无需等待处理结果的返回。

这些架构模式有助于构建云原生应用，提高可维护性和灵活性。

云原生架构主要云原生技术

容器

容器作为标准化软件单元,它将应用及其所有依赖项打包,使应用不再受环境限制,在不同计算环境间, 快速、可靠地运行。

容器化的三个核心价值：敏捷（着企业可以更快速的迭代产品，更低成本进行业务试错。）、弹性（通过容器技术，企业可以充分发挥云计算弹性优势，降低运维成本。）可移植性（将应用与底层运行环境进行解耦，帮助应用平滑运行在不同基础设施上）。

容器编排-Kubernetes:

Kubernetes是容器编排的事实标准，用于自动部署、扩展和管理容器化应用。它提供以下核心能力：

• 资源调度：根据应用的资源需求（如CPU、内存、GPU等），选择适当的节点运行应用。
• 应用部署与管理：支持自动发布、回滚以及相关配置的管理，还可以自动化存储卷的管理。
• 自动修复：监测宿主机和操作系统状态，自动进行应用迁移和自愈操作，简化运维管理。
• 服务发现与负载均衡：通过Service资源，支持容器化应用之间的通信，结合DNS和多种负载均衡机制。
• 弹性伸缩：根据负载情况，自动扩容业务，提高应用的性能和可用性。

Kubernetes的控制平面包括四个主要组件：APIServer、Controller、Scheduler和etcd。分别负责处理API请求、管理控制器和维护副本数量、资源调度以及持久化数据存储，四个组件共同工作，以确保Kubernetes集群的稳定性、可伸缩性和高可用性。

云原生微服务

1. 微服务背景

过去，主要使用单体模式来开发后端应用，即将所有服务整合到一个单一后端应用中。但随着业务增长和需求增加，单体应用变得复杂，导致开发效率下降。为解决这个问题，引入了微服务模式。

微服务模式将单体应用拆分成多个松耦合的子应用，每个子应用负责特定功能，这些子应用称为"微服务"，构成独立但完整的分布式微服务体系。微服务相互独立，通过解耦开发、测试和部署流程，提高整体迭代效率。同时，微服务通过分布式架构实现了应用的水平扩展和冗余部署，解决了单体应用在拓展性和稳定性方面的问题。

然而，微服务模型也面临分布式系统挑战，如高效调用远程方法、预测系统容量、建立负载均衡、进行集成测试以及管理大规模复杂应用的部署和运维。

在云原生时代，云原生微服务充分利用云资源的高可用性和安全性，提供弹性、可用性和安全性。应用构建在云基础设施和服务上，降低了架构复杂性，提升了可观测性、可控性和容错性。

1. 设计约束

对于优秀的微服务系统应当遵循以下设计约束：

• 微服务应用所完成的功能在业务领域划分应该是相互独立的。
• 处理好微服务之间的横向关系

包括可发现性和可交互性，其中可发现性是指如何使一个微服务自动感知其他微服务的变化。这通常通过服务注册中心来实现，特别是在大规模微服务集群中，服务注册中心的推送和扩展能力非常关键。可交互性指微服务之间如何相互调用。由于微服务要求使用与编程语言无关的远程调用协议，比如REST，以实现标准化和语言无关性。在高性能场景下，也可以考虑使用基于IDL的二进制协议。此外，微服务通常需要通过事先约定的接口来完成调用。为了更好地实现微服务之间的解耦，需要一个独立的元数据中心来存储服务的元数据信息，以便服务了解调用的细节。

• 微服务与数据层之间的纵向约束

在微服务架构中，数据存储隔离原则很重要，数据应该被视为微服务的私有资产，只能通过提供API的微服务来访问。这有助于保持高内聚和低耦合。此外，为了提高性能，通常采用读写分离（CQRS）策略。

另外，微服务的设计原则之一是尽量遵循无状态设计，以减少与底层基础设施的耦合。有状态的微服务通常将数据存取与计算分开，将数据存储在分布式存储中，以实现一定程度的无状态性。

• 微服务的分布式约束

全局视角下的微服务分布式约束包括以下方面：

高效运维：确保系统的高效运维是关键。这包括建立全自动化的CICD流水线，以提高开发效率，并支持不同的发布策略，如蓝绿部署和金丝雀发布，以确保业务发布的稳定性。

可观测性：面对复杂的微服务系统，需要具备全链路、实时和多维度的可观测能力。这意味着需要收集和分析来自多种事件源的数据，并在集中的监控系统中展现多维度信息。及时发现故障和准确找到根本原因对于开发和运维人员至关重要。

1. 云原生微服务典型架构

典型的架构模式按顺序共分为四代：

第一代微服务架构中，应用不仅需要处理业务逻辑，还需要自己解决与上下游服务的通信、定位和容错等问题。随着微服务规模的增加，处理服务定位逻辑变得复杂，即使是使用相同编程语言的另一个应用，也需要重新实现这些基础微服务功能。这导致了功能的重复实现。

第二代微服务架构中，引入了旁路服务注册中心作为协调者，以完成服务的自动注册和发现。服务之间的通信和容错机制开始模块化，并形成独立的服务框架。然而，随着服务框架内功能不断增加，跨不同编程语言的基础功能重复实现变得困难。这也导致微服务的开发者被限制在特定编程语言上，违反了微服务的灵活迭代原则。

在2016年出现了第三代微服务架构，即服务网格。这一架构将原本模块化到服务框架中的微服务基础能力进一步演进，变成了独立的进程，称为边车（Sidecar）。这个变化完全解决了第二代架构中的多语言支持问题，实现了微服务基础能力和业务逻辑的完全解耦。在这个云原生时代的微服务架构中，边车进程接管了微服务应用之间的流量，并承载了第二代架构中的功能，包括服务发现、调用容错，以及丰富的服务治理功能，如权重路由、灰度路由、流量重放、服务伪装等等。

近两年，随着AWS Lambda等Serverless计算服务的出现，一些应用开始尝试使用Serverless来构建微服务，这被称为第四代微服务架构。在这个架构中，微服务被进一步简化为微逻辑（Micrologic），更多可重用的分布式能力不再集成在应用中，而是下沉到边车中，这些能力包括状态管理、资源绑定、链路追踪、事务管理、安全等等。同时，在开发方面，提倡了面向localhost编程的理念，通过提供标准API来屏蔽底层资源、服务和基础设施的差异，进一步降低了微服务开发的难度。这就是目前业界提出的多运行时微服务架构（Multi-Runtime Microservices）。

serverless

1. 技术特点

Serverless（无服务器计算）是一种云原生技术，将应用构建与服务器基础设施的开发、运维、安全和高可用等工作分离，使开发人员能够将更多精力用于业务逻辑设计与实现。它的主要特征包括：

• 全托管的计算服务。只需关编写代码构建应用，无需关注服务器等基础设施的开发运维。
• 通用性。支持云上各种类型的应用。
• 自动的弹性伸缩。让用户无需为资源使用提前进行容量规划。
• 按量计费。让企业使用成本得有效降低，无需为闲置资源付费。

函数计算（Function as a Service）是Serverless中最典型的形式，它通过将应用逻辑拆分为多个函数，每个函数由事件触发执行。例如，当对象存储中发生上传或删除对象等事件时，FaaS函数会自动触发并处理，具有弹性和高可用性。此外，通过与消息中间件和函数计算的集成，用户可以快速实现大规模消息的实时处理。

尽管Serverless计算在普及方面面临一些挑战，如应用架构的变化、函数编程的生态不够成熟、函数冷启动导致应用响应延迟等问题，但它仍在不断发展。一些云厂商提供了容器和Serverless的融合创新，使容器化应用能够无缝运行在各种环境中，从而加快了Serverless的交付。例如，阿里云的弹性容器实例（ECI）和Serverless应用引擎（SAE），以及Google的Cloud Run服务都帮助用户专注于容器化应用构建，而不必担心底层基础设施。Google 也开源了基于 Kubernetes 的 Serverless 应用框架 Knative。

1. 常见场景

近年来，serverless呈现发展趋势，主要常见场景有：

• 小程序/Web/Mobile/API后端服务

这些领域的业务逻辑通常复杂多变，需要快速的迭代和上线速度，而且资源利用率相对较低（通常小于30%甚至低于10%），特别是对于小程序等长尾应用来说。Serverless的特点包括无需运维和按需付费，非常适合用于构建这些应用的后端系统。

• 大规模批处理任务

通过将对象存储和Serverless计算平台集成，可以实现以对象存储为中心的大规模数据处理。用户可以实时响应对象的创建和删除等操作，并以对象存储为基础，进行增量处理新增数据，或者创建多个函数实例来并行处理存量数据。这种集成方式使大规模数据处理更加高效和灵活。

• 基于事件驱动架构的在线应用和离线数据处理

典型的Serverless计算服务采用事件驱动的方式，可以轻松地与各种云端服务集成，无需用户管理底层服务器或编写复杂的"胶水"代码，从而构建松耦合的、基于分布式事件驱动架构的应用。

通过与事件总线的集成，不论是来自云上的BaaS云服务、第三方的SaaS服务，还是用户自行建立的系统，所有的事件都可以快速便捷地被函数计算处理。例如，通过与API网关的集成，外部请求可以转化为事件，触发后端函数进行处理。通过与消息中间件的事件集成，用户可以高效地处理大量消息。这种事件驱动的方式使得应用能够灵活、高效地与各种服务互操作。

• 开发运维自动化

通过定时触发器，用户用函数的方式就能够快速实现定时任务，而无须管理执行任务的底层服务器。通过将定时触发器和监控系统的时间触发器集成，用户可以及时接收机器重启、宕机、扩容等 IaaS 层服务的运维事件，并自动触发函数执行处理

1. 技术关注点

• 计算资源弹性调度

•   为了实现精准、实时的实例伸缩和放置，必须把应用负载的特征作为资源调度依据，使用“白盒”调度策略，由Serverless 平台负责管理应用所需的计算资源。平台要能够识别应用特征，在负载快速上升时，及时扩容计算资源，保证应用性能稳定；在负载下降时，及时回收计算资源，加快资源在不同租户函数间的流转，提高数据中心利用率。因此更实时、更主动、更智能的弹性伸缩能力是函数计算服务获得良好用户体验的关键。通过计算资源的弹性调度，帮助用户完成指标收集、在线决策、离线分析、决策优化的闭环。

• 负载均衡和流控

•   资源调度服务是 Serverless 系统的关键链路。为了支撑每秒近百万次的资源调度请求，系统需要对资源调度服务的负载进行分片，横向扩展到多台机器上，避免单点瓶颈。分片管理器通过监控整个集群的分片和服务器负载情况，执行分片的迁移、分裂、合并操作，从而实现集群处理能力的横向扩展和负载均衡。
•   在多租户环境下，流量隔离控制是保证服务质量的关键。由于用户是按实际使用的资源付费，因此计算资源要通过被不同用户的不同应用共享来降低系统成本。这就需要系统具备出色的隔离能力，避免应用相互干扰。

• 安全性

•   Serverless 计算平台的定位是通用计算服务，要能执行任意用户代码，因此安全是不可逾越的底线。系统应当从权限管理、网络安全、数据安全、运行时安全等各个维度全面保障应用的安全性。

开放应用模型

2019年末，阿里云和微软联合发布了Open Application Model（OAM）开源项目，其主要目标是解决从Kubernetes到"以应用为中心"的平台之间最关键的问题——标准化应用定义。

OAM的定义旨在弥补现有容器技术的不足，Kubernetes没有引入"应用"这个概念，而是提供了更细粒度的"工作负载"原语，如Deployment或DaemonSet。实际中，一个应用通常由多个独立组件组成，比如电商网站由"PHP应用容器"和"数据库实例"组成，微服务应用由"Deployment+StatefulSet+HPA+Service+Ingress"等组成。

OAM的首要设计目标是引入"应用"这一概念，建立对应用及其所需的运维能力的标准规范。换句话说，OAM既是标准的"应用定义"，也有助于封装、组织和管理Kubernetes中各种"运维能力"。具体而言，OAM的描述模型基于Kubernetes API的资源模型构建，强调了现代应用是多个资源的集合，而不仅仅是一个简单的工作负载。

OAM的三个概念：

• 组件依赖： OAM定义和规范了构成应用的各个组件（Component）。例如，一个应用可能包括前端WebServer容器、数据库服务、后端服务容器等组件。
• 应用运维特征： OAM定义和规范了应用所需的运维特征（Trait）的集合。这些特征描述了应用需要的运维能力，如弹性伸缩和Ingress等。
• 应用配置： OAM定义和规范了应用实例化所需的配置机制，从而能够将上述描述转化为具体的应用实例。运维人员可以使用应用配置（Application Configuration）来组合组件和相应的特征，以构建可部署的应用实例。

例如，一个由PHP容器和Redis实例组成的应用，在OAM框架和规范下，可以用以下示意图来表示：

OAM模型还强调整个模型的关注点分离特性。业务研发人员负责定义和维护组件（Component），用以描述服务单元，而运维人员则负责定义运维特征（Trait），并将其附加到组件上，从而构建OAM可交付物，即Application Configuration。这种分离的关注点使得开发和运维团队能够分别专注于他们的核心任务，同时保持对应用的整体控制和灵活性。这也有助于降低了应用定义的复杂性，使其更易于管理和维护。

Service mesh 技术

1. 技术特点

Service Mesh是在微服务软件架构之上发展起来，旨在将微服务之间的通信、安全、流量控制和监测等通用功能下沉为平台基础设施，从而实现应用与基础设施的解耦。这种解耦意味着开发人员无需担心微服务相关的治理问题，而可以专注于业务逻辑的开发，提高了应用开发效率，加速了业务的探索和创新。

1. 行业状况

ServiceMesh目前仍然处于市场的早期采用阶段（Early Adoption）。除了Istio之外，Google和AWS分别推出了自己的云服务Traffic Director和App Mesh，这两个ServiceMesh产品与Istio有一些不同之处，但与Istio一样都采用Envoy作为数据平面。此外，阿里云、腾讯云和华为云也都推出了自己的ServiceMesh产品，同样采用Envoy技术作为数据面，处理微服务之间的流量路由、负载均衡、故障恢复和安全性。并在此基础上提供了应用发布、流量管控、应用性能监测（APM）等能力。

1. 主要技术

17年推出的Istio服务网格项目，明确定义了数据平面（由Envoy开源软件支持）和管理平面（Istio自身的核心功能）。Istio提供了微服务架构的流量管理机制，还为其他增值功能（如安全性、监控、路由、连接管理和策略等）提供了基础。

由于Istio构建在Kubernetes技术之上，因此天然适用于提供Kubernetes容器服务的云厂商环境，并已成为大多数云厂商默认使用的服务网格解决方案。

除了Istio，还有一些较小众的Service Mesh解决方案，如Linkerd和Consul。

Devops

1. 概述

DevOps是一系列理念和实践，旨在提高软件研发效率、快速应对变化、实现持续交付价值。它强调持续部署（CD），以缩短软件系统变更的发布时间。

实现持续部署（CD）需要端到端的业务分析，优化所有相关部门的操作，整合可用的技术和方法，以实现资源整合。DevOps理念已经深刻影响了软件开发过程，打破了开发、测试和运维之间的壁垒，通过技术手段实现自动化和智能化，提高了软件生产效率、安全性，缩短了软件发布周期，推动了IT技术的发展。

1. 原则

要实施DevOps，需要遵循一些基本原则，这些原则被简写为CAMS，分别代表以下四个英文单词的缩写：

• 文化（Culture）

要实施 DevOps，就首先要让开发和运维人员认识到他们的目标是一致的，只是工作岗位不同，需要共担责任。这就是 DevOps 需要首先在文化层面解决的问题。只有解决了认知问题，才能打破不同团队之间的鸿沟，实现流程自动化，把大家的工作融合成一体。

• 自动化（Automation）

实施 DevOps，首先就要分析已有的软件开发流程，尽量利用各种工具和平台，实现开发和发布过程的自动化。

• 度量（Measurement）

通过数据可以对每个活动和流程进行度量和分析，找到工作中存在的瓶颈和漏洞，以及对于危急的情况及时报警等。通过分析，可以对团队工作和系统进行调整，让效率改进形成闭环。

• 共享（Sharing）

知识共享，团队进步。

1. 云原生时代的Devops

容器技术和Kubernetes服务编排技术的结合解决了应用部署的自动化、标准化和配置化问题，成为云上平台的标准，简化了多云部署。微服务将巨大的应用拆分为独立的单功能服务，减少了耦合性，提高了开发和部署的灵活性，缩短了开发周期。ServiceMesh解耦了中间件升级和应用系统升级，提高了运维和管控的灵活性。Serverless使运维对开发透明，自动伸缩应用所需资源。FaaS简化了开发和运维的流程，集成开发环境覆盖了从开发到测试上线的全过程。无论哪种场景，后台运维平台的工作都是必不可少的，只是通过技术手段使扩容和容错等工作对开发人员透明化，提高了效率。

云原生中间件

云原生中间件旨在充分利用云计算的特性，如弹性伸缩、自动化管理、容器化、微服务架构等，以满足现代应用程序开发和部署的需求。

云原生中间件最大的技术特点是中间件技术从业务进程中分离，变成与开发语言无关的普惠技术，只与应用自身架构和采用的技术标准有关，比如一个 PHP 开发的 REST 应用也会自动具备流量灰度发布能力、可观测能力，即使这个应用并没有采用任何服务化编程框架。

随着 Kubernetes 的流行，Kubernetes 提供的基础部署运维和弹性伸缩能力已经可以满足多数中小企业的微服务运维要求。微服务与 Kubernetes 集成会是一个大趋势。

阿里巴巴云原生架构

ACNA（Alibaba Cloud Native Architecting）是阿里巴巴提供的架构设计方法，用于帮助各行各业的企业客户实现数字化转型，充分利用阿里云服务和云原生技术。ACNA方法结合了企业的核心关注点、组织文化、工程实施能力以及架构技术，形成了一套独特的云原生架构设计方法。

ACNA方法采用了4+1的架构设计流程，其中4代表了架构设计的关键视角，包括企业战略视角、业务发展视角、组织能力视角和云原生技术架构视角。另外，1表示云原生架构持续演进闭环的部分。这四个架构视角和架构持续演进闭环之间的关系如下图所示：

• 企业战略视角：这个视角关注企业的战略目标和愿景，确定数字化转型的战略方向。
• 业务发展视角：在这个视角下，重点关注业务需求和发展计划，确定如何通过云原生架构来支持业务增长和创新。
• 组织能力视角：考虑组织文化、工程实施能力和团队协作等因素，以确保架构设计能够成功实施。
• 云原生技术架构视角：这个视角涵盖了云原生技术和架构的具体设计，包括服务化、弹性、无服务器、可观测性、韧性、自动化等能力。
• 架构持续演进闭环：表示架构设计不是一次性的工作，而是一个持续改进和演进的过程，以适应不断变化的需求和技术。

ACNA方法旨在帮助企业客户以云原生的方式设计和实施架构，以提高业务的灵活性、可伸缩性和可靠性，实现数字化转型的目标。它强调了架构设计的多个关键方面，从战略到技术，以确保整个过程的成功。

阿里云原生产品介绍

云原生产品家族包括：容器产品家族、微服务产品家族、Serverless产品家族、ServiceMesh产品家族、消息产品家族、可观测产品家族、云原生技术中台CNStack，详见《阿里云原生架构白皮书》第四十六页。阿里云原生产品家族如下：

Vivo AI 计算平台的ACK混合云实践

在2018年底，vivoAI研究院为了解决高性能训练环境、大规模分布式训练和计算资源高效利用等问题，开始建设AI计算平台。经过两年多的迭代，该平台已成为vivoAI领域的核心基础平台，并包含VTraining、VServing、VContainer三大模块，提供模型训练、模型推理和容器化能力。平台拥有庞大的容器集群，数千个节点，超过数百PFLOPS的GPU算力，同时运行多个训练任务和在线服务。

混合云是将私有云和公有云服务结合使用的解决方案，目前各大云厂商都提供了相应的混合云方案。vivoAI选择建设混合云的原因包括：公有云的弹性资源可满足临时算力需求，公有云具有高级特性如高性能存储和网络，而私有云尚不具备这些特性。

通过混合云，vivoAI能够灵活满足业务的算力需求，同时降低成本，还可以利用公有云的高级特性提高计算性能。这些举措使vivoAI计算平台能够更好地支持其AI研究和开发工作。

混合云的实现方案：

混合云的整体架构：

混合云的整体架构如下图所示。K8s集群的管理平面部署在公司自建机房,工作平面包含了机房的物理机和阿里云的云主机。机房和阿里云间通过专线打通了网络,物理机和云主机可以相互访问。方案对上层平台透明,比如VTraining训练平台不需要改动即可使用云主机的算力。

落地实践：

• 注册集群

首先需要将自建的集群注册到阿里云。

注册成功后，部署ACKAgent。作用是主动建立从机房到阿里云的长链接,接收控制台的请求并转发给apiserver。对于没有专线的环境,此机制可以避免将apiserver暴露在公网。

控制台到apiserver的链路如下:

阿里云ACK控制台<<-->>ACKStub(部署在阿里云)<<-->>ACKAgent(部署在K8s)<<-->>K8s apiserver

控制台到集群的请求是安全可控的。Agent连接Stub时,会带上配置的token和证书;链接采用了TLS1.2协议,保证数据加密;可以通过ClusterRole来配置控制台对K8s的访问权限。

• 容器网络配置

K8s的容器网络要求Pod和Pod、Pod和宿主机之间通讯正常,平台采用了Calico+Terway的网络方案。机房内的工作节点采用CalicoBGP,RouteReflector会将Pod的路由信息同步给交换机,物理机和云主机都能正常访问PodIlP。

阿里云上的工作节点会采用Terway共享网卡模式,Pod会从Pod虚拟交换机配置的网段中分配到IP,该IP在机房内可以访问。

平台给云主机打上标签,配置calico-node组件的nodeAffinity,不调度到云主机上;同时配置Terway组件的nodeAffinity,让其只运行在云主机上。

• 云主机加入集群

将云主机加入集群的流程和物理机基本一致。

首先通过公司云平台申请云主机,然后通过VContainer的自动化平台将云主机初始化并加到集群中。最后给云主机打上云主机专有的标签。关于自动化平台的介绍,可以参见VivoAl计算平台云原生自动化实践。

• 降低专线压力

机房到阿里云的专线是公司所有业务共用的,如果平台占用过多专线带宽,会影响到其他业务的稳定性。在落地时发现深度学习训练任务从机房的存储集群拉取数据,确实对专线造成压力,为此平台采取了以下措施:

1、监控云主机的网络使用情况,由网络组协助监控对专线的影响。

2、使用tc工具对云主机eth0网卡的下行带宽进行限流。

3、支持业务使用云主机的数据盘,将训练数据进行预加载,避免反复从机房拉取数据。

落地效果：

数个业务方临时需要大量的算力用于深度学习模型的训练。通过混合云的能力,平台将数十台GPU云主机加入到集群,提供给用户在VTraining训练平台上使用,及时满足了业务的算力需求。用户的使用体验和之前完全一致。这批资源根据不同业务的情况,使用周期在一个月到数个月。经过估算,使用费用大大低于自行采购物理机的费用,有效降低了成本。

未来展望：混合云的建设和落地取得了阶段性的成果,在未来持续完善功能机制和探索新特性。

云原生架构未来发展趋势

容器技术发展趋势

1. 无处不在的计算催生新一代容器实现

随着互联网的发展和新技术的涌现，计算需求变得无处不在。不同计算场景需要不同的容器运行时技术。一些新的容器运行时技术，如KataContainer、Firecracker、gVisor和Unikernel，分别解决了安全隔离性、执行效率和通用性等不同方面的需求。出现了OCI（Open Container Initiative）标准，使各种技术都能以一致的方式进行容器生命周期管理，推动了容器引擎技术的不断创新。未来的趋势包括：

• 基于MicroVM的安全容器：这一领域的份额将逐渐增加，提供更强的安全隔离能力。虚拟化技术和容器技术的融合已经成为未来的重要趋势，例如阿里云容器服务已经支持了基于KataContainer的安全容器引擎。
• 基于软硬一体设计的机密计算容器。比如阿里云安全、系统软件、容器服务团队以及蚂蚁金服可信原生团队共同推出了面向机密计算场景的开源容器运行时技术栈inclavare-containers,支持基于IntelSGX机密计算技术的机密容器实现,如蚂蚁金服的Occlum, 开源社区的Graphene等LibaryOS。它极大降低了机密计算的技术门槛，简化了可信应用的开发交付和管理。
• WebAssembly作为新一代可移植、轻量化、应用虚拟机,在IoT,边缘计算,区块链等场景会有广泛的应用前景。WASM/WASI将会成为一个跨平台容器实现技术。近期Solo.io推出的WebAssemblyHub就将WASM应用通过OCI镜像标准进行统一管理和分发,从而更好地应用在stio服务网格生态中。

1. 云原生操作系统开始浮现

Kubemetes已经成为云时代的操作系统。对比Linux与Kubernetes的概念模型,他们都是定义了开放的、标准化的访问接口;向下封装资源,向上支撑应用。

它们都提供了对底层计算、存储、网络、异构计算设备的资源抽象和安全访问模型,可以根据应用需求进行资源调度和编排。Linux的计算调度单元是进程,调度范围限制在一台计算节点。而Kubernetes的调度单位是Pod,可以在分布式集群中进行资源调度,甚至跨越不同的云环境。

1. Serverless容器技术成为市场主流

Serverless和容器技术也开始融合得到了快速的发展。通过Serverless容器,一方面根本性解决Kubemetes自身复杂性问题,让用户无需受困于Kuberetes集群容量规划、安全维护、故障诊断等运维工作;一方面进一步释放云计算能力,将安全、可用性、可伸缩性等需求下沉到基础设施实现。

1. 动态混合分布式的云环境成为新常态

基于云原生的新一代应用编程界面

Kubernetes已经成为云原生的操作系统，容器则成为了操作系统调度的基本单元，并定义了应用交付的标准。尽管对应用开发者来说，这些变化还没有深入到应用的架构，但这一变革正在悄然发生，而且呈加速态势。

• Sidecar架构彻底改变了应用的运维架构。通过Sidecar架构的支持，应用容器可以在运行时隔离于其他容器，这意味着原本与应用容器一起的大量运维和管控工具，都被独立容器化并由云平台进行统一管理。应用只需按需声明使用运维能力，而能力的实现成为了云平台的职责。
• 应用生命周期得到全面托管。借助容器技术，应用可以清晰地描述自身状态，弹性指标以及通过ServiceMesh和Serverless技术将流量托管给云平台。云平台将全面管理应用的生命周期，包括服务的上下线、版本升级、流量调配、容量管理等，以确保业务的稳定性。
• 云原生应用使用声明式配置方式使用云服务。云原生应用通常依赖各种云服务（如数据库、缓存、消息队列等）来实现快速交付。这些服务的配置本质上是应用的一部分，因此应用逐渐以基础设施即代码的方式使用云服务，以便在混合云环境中无缝运行。
• 语言无关的分布式编程框架变得更加普及。为解决分布式系统的挑战，传统中间件需要客户端SDK编写大量逻辑以管理分布式状态。然而，通过Sidecar架构，许多项目将这些功能下沉到Sidecar中，并通过语言无关的API（基于gRPC/HTTP）提供给应用，进一步简化了应用代码逻辑和研发职责。

综上所述，生命周期管理、运维管理、配置范围和扩展、语言无关的编程框架等因素共同构成了全新的应用与云之间的编程界面。这一变革的核心逻辑在于将与业务无关的逻辑和职责剥离到云服务中，并在这个过程中形成标准，使应用开发者能够在专有云、公有云或混合云的场景中获得一致的研发和运维体验。

Serverless发展趋势

近年来，Serverless一直在高速发展，具有越来越大的影响力。主流云服务提供商不断丰富其产品体系，提供更便捷的开发工具、高效的应用交付流水线、更完善的可观测性以及更多的产品集成。以下是关于Serverless未来趋势的一些观点：

趋势一：Serverless将无处不在

Serverless将不仅限于云产品，还包括合作伙伴和第三方服务，将通过API和Serverless来体现其能力。对于以API作为功能透出方式的平台型产品或组织来说，Serverless将成为其平台战略的关键组成部分。

趋势二：Serverless将通过事件驱动连接云及其生态中的一切

通过事件驱动和云服务的连接，Serverless能力将扩展到整个云生态系统，无论是用户自己的应用还是合作伙伴的服务，无论是on-premise环境还是公有云，都可以以Serverless的方式处理所有事件。云服务和其生态系统将更紧密地连接，成为构建弹性和高可用应用的基础。

趋势三：Serverless计算将持续提高计算密度，实现最佳的性能功耗比和性能价格比

虚拟机和容器是两种取向不同的虚拟化技术，前者安全性强、开销大，后者则相反。Serverless 计算平台一方面要求兼得最高的安全性和最小的资源开销，另一方面要保持对原有程序执行方式的兼容，比如支持任意二进制文件，这使得适用于特定语言 VM 的方案不可行。以 AWS FireCracker 为例，其通过对设备模型的裁剪和 kernel 加载流程的优化，实现百毫秒的启动速度和极小的内存开销，一台裸金属实例可以支持数以千计的实例运行。结合应用负载感知的资源调度算法，虚拟化技术有望在保持稳定性能的前提下，将超卖率提升一个数量级。

当 Serverless 计算的规模与影响力变得越来越大，在应用框架、语言、硬件等层面上根据 Serverless 负载特点进行端对端优化就变得非常有意义。新的 Java 虚拟机技术大幅提高了 Java 应用启动速度，非易失性内存帮助实例更快被唤醒，CPU 硬件与操作系统协作对高密环境下性能扰动实现精细隔离，所有新技术正在创造崭新的计算环境。

实现最佳性能功耗比和性能价格比的另一个重要方向是支持异构硬件。长期以来，x86 处理器的性能越来越难以提升。而在 AI 等对算力要求极高的场景，GPU、FPGA、TPU（Tensor Processing Units）等架构处理器的计算效率更具优势。随着异构硬件虚拟化、资源池化、异构资源调度和应用框架支持的成熟，异构硬件的算力也能通过 Serverless 的方式释放，大幅降低用户使用门槛。