14.1云原生架构产生背景

云原生（Cloud Native） ：Cloud就是指其应用软件是在云端而非传统的数据中心。 Native代表应用软件从一开始就是基于云环境、专门为云端特性而设计，可充分利用和发挥云平台的弹性+分布式优势，最大化释放云计算生产力

传统的 IT架构方式，将开发、 IT运营和质量保障分别设置，各自独立，开发与运营之间存在着信息“鸿沟”
DevOps可以看作是开发、技术运营和质量保障三者的交集，促进之间的沟通、协作与整合，从而提高开发周期和效率。

维度	核心内容
价值与算力优势	支持多元算力，满足个性化需求；软硬协同提供高性能算力；多云治理+边云协同打造泛在分布式平台；统一管理容器、虚机、裸机、函数等资源；以应用为中心，实现智能调度、一键部署、全面监控运维
研发与架构升级	采用 DevSecOps 实现敏捷开发、快速迭代、全流程安全；提供侵入/非侵入两种服务集成模式；新老应用协同，平滑升级
数据与智能赋能	支撑企业数据管理与运营能力；实现数据资产化与价值挖掘；结合 AI 技术赋能业务智能升级
安全与合规保障	依托云平台企业级安全服务与合规能力，保障云上应用构建与业务运行安全

14.2云原生架构内涵

14.2.1云原生架构定义

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

技术部分依赖于传统云计算的3层概念，即基础设施即服务 (IaaS)、 平台即服务 (PaaS) 和软件即服
务 (SaaS)

云原生代码组成	含义说明	定位
业务代码	实现业务逻辑的代码	核心部分，真正为业务创造价值
三方软件	业务依赖的第三方库（业务库、基础库）	附属部分
非功能特性代码	实现高可用、安全、可观测性等非功能能力的代码	附属部分

1.代码结构发生巨大变化

要点	说明
传统编程	传统编程语言依赖文件、网络、线程等，单机效率高但分布式编程复杂；需大量框架解决网络、高可用、存储、资源争用等问题
云对存储模式的改变	存储以云服务形式提供（对象存储、块存储、文件存储）；统一界面，内置高可用、自动扩缩容、安全、运维升级能力
对开发与运维的减负	开发者无需在代码中处理数据同步、存储扩容等问题；运维无需紧急升级三方存储软件，工作量大幅降低
云服务的价值	将三方软硬件能力服务化，使用越多，非核心负担越小，转为可控支出；云厂商提供高SLA服务，全行业受益
对开发者技能栈的简化	业务开发者不再需要精通分布式文件、复杂网络技术，开发更敏捷高效

2.非功能性特性大量委托

层面	高可用实现机制
虚拟机	底层硬件异常时自动热迁移，应用无需重启、无感知，持续提供服务
容器	监控进程状态，发现应用异常（Bug、资源耗尽等）自动： • 异常节点下线 • 新节点上线 • 生产流量切换
云服务	1. 有状态数据交由云服务（缓存、数据库、对象存储）托管 2. 应用轻量化、无状态化 3. 故障中断降至分钟级 4. 结合负载均衡可实现对等架构高可用

3.高度自动化的软件交付

容器以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。

14.2.2云原生架构原则

原则	核心要点
1. 服务化原则	按生命周期拆分微服务/小服务，解耦迭代；面向接口、高内聚、可复用；基于服务流量实现限流、熔断、灰度、安全治理
2. 弹性原则	随业务量自动伸缩，无需提前囤机；缩短上线周期、降低闲置成本；应对突发流量，保障业务收益
3. 可观测原则	通过日志、链路追踪、指标实现全链路透视；跨服务关联分析，数字化衡量健康度与用户体验
4. 韧性原则	提升系统抗故障能力，延长 MTBF；包含异步、重试、限流、熔断、集群、AZ 高可用、跨地域容灾等
5. 所有过程自动化原则	通过 IaC、GitOps、Operator、CI/CD 等实现交付与运维自动化；标准化流程，降低复杂度
6. 零信任原则	默认不信任任何内外主体；以身份为中心做认证授权，从网络中心化转向身份中心化
7. 架构持续演进原则	支持增量迭代与架构重构；兼顾架构治理与风险；新建应用侧重弹性敏捷，存量应用考虑迁移成本与灰度迁入

14.2.3主要架构模式

架构模式	核心思路与要点
1. 服务化架构模式	按模块拆分，接口契约+标准协议互通；支持微服务/小服务；部署与扩容独立、迭代高效；需配套自动化治理，否则管理复杂
2. Mesh化架构模式	中间件SDK与业务解耦，流量控制、安全、熔断等交由Mesh进程；业务仅保留轻量Client，中间件升级对业务透明
3. Serverless模式	无需关心部署环境，事件驱动、按需启动/释放进程；适合短耗时、事件驱动应用；不适合有状态、长时计算、频繁I/O应用
4. 存储计算分离模式	状态数据交由云服务托管，实现无状态化，提升弹性与可用性；高性能场景可用日志+快照实现快速恢复
5. 分布式事务模式	- XA：强一致、性能低 - 消息最终一致性(BASE)：高性能、通用性有限 - TCC：高效可控、侵入强、成本高 - SAGA：补偿事务、开发维护成本高 - SEATA AT：高性能、无侵入、有场景限制
6. 可观测架构	包含Logging（日志）、Tracing（链路）、Metrics（指标）；用OpenTelemetry等框架，依托TraceID/SpanID做关联分析，定义SLO优化SLA
7. 事件驱动架构(EDA)	事件带Schema、有QoS、可重试；用于服务解耦、增强韧性、CQRS、数据通知、开放接口、事件流处理、IoT数据处理

14.2.4典型的云原生架构反模式

问题类型	核心表现
庞大单体应用	代码耦合、变更影响扩散、发布难以协调；局部瓶颈需整体扩容；局部不稳定影响全局
单体“硬拆”微服务	小团队/小系统强行拆分，维护成本剧增；服务共享数据库，数据耦合严重；本地调用变远程调用，性能大幅下降
缺乏自动化的微服务	模块数量激增，人均工作量与开发成本上升；测试发布周期变长；人工运维易出错、故障难恢复；交付风险与运维成本大幅提高

14.3云原生架构相关技术

14.3.1容器技术

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

容器编排

核心能力	说明
资源调度	根据应用所需CPU、内存、GPU等资源，在集群中选择合适节点运行应用
应用部署与管理	支持自动发布、回滚、配置管理；自动化存储卷编排，与容器生命周期绑定
自动修复	监控宿主机/OS故障，自动迁移应用；支持应用自愈，简化运维
服务发现与负载均衡	通过Service暴露服务，结合DNS与负载均衡实现应用间通信
弹性伸缩	依据CPU利用率、响应时间等负载情况，对业务自动扩容

项目	内容
控制平面四大组件	APIServer、Controller、Scheduler、etcd
声明式API	聚焦应用本身，支持 Deployment、StatefulSet、Job 等负载抽象；采用 level-triggered 实现，系统更健壮
可扩展性架构	基于开放API，支持通过 CRD / Operator 进行扩展
可移植性	通过 LB Service、CNI、CSI 屏蔽基础设施差异，支持应用灵活迁移

14.3.2云原生微服务

为了解决由单体应用模型衍生的过度集中式项目迭代流程，微服务模式应运而生。

微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”,多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。
微服务模式通过分布式架构将应用水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。

设计一个优秀的微服务系统应遵循以下设计约束

设计约束	核心内容
微服务个体约束	业务域独立，合理拆分而非“为微而微”；遵循单一职责原则（SRP）；修改发布不影响其他服务；支持多技术栈，小团队高效迭代
微服务横向关系	可发现性：依靠注册中心自动感知服务变化；可交互性：使用语言无关协议（REST/IDL二进制）；元数据中心解耦接口；标配限流、熔断、隔仓等韧性机制；采用异步、反压提升吞吐
微服务与数据层纵向约束	遵循数据存储隔离（DSS），数据私有且仅通过本服务API访问；采用读写分离（CQRS）优化性能；优先无状态设计；有状态服务采用计算存储分离
全局分布式约束	全自动化CI/CD，支持蓝绿、金丝雀发布；全链路多维度可观测；中心化监控与风险防范；保障故障发现及时性与根因定位精度

微服务技术	核心特点与能力
Apache Dubbo	高性能 RPC 框架；支持智能负载均衡、服务注册发现、流量路由、服务治理；Dubbo v3 支持 Service Mesh，兼容 Envoy、Istio
Spring Cloud Alibaba	一站式微服务套件；包含 Nacos（注册/配置中心）、Sentinel（流控）、Seata（分布式事务）等，易用且高可用
Spring Cloud	通用微服务全家桶；提供配置管理、服务发现、断路器、路由、分布式会话等标准能力
Eclipse MicroProfile	Java 微服务规范；支持指标、健康检查、容错、分布式跟踪；适配云原生与服务网格
Tars	腾讯开源多语言框架（C++/Java/Go/PHP）；带完整管理平台，高性能、强服务治理
SOFAStack & MOSN	蚂蚁金融级分布式架构；MOSN 为 Go 编写的服务网格代理，兼容 Envoy、Istio
DAPR	微软可移植运行时；事件驱动、跨语言，支持云+边缘，简化无状态/有状态微服务构建

14.3.3无服务器技术

无服务器技术 (Serverless) :屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一

类别	核心内容
核心特征	1. 全托管：仅关注代码，无需运维服务器等基础设施 2. 通用性：结合云BaaS API，支持各类云上应用 3. 自动弹性伸缩：无需提前规划容量 4. 按量计费：降低成本，不支付闲置资源费用
典型形态：FaaS 函数计算	按事件驱动执行拆分后的函数；支持OSS事件、消息中间件触发；实现大规模数据/消息实时并行处理
普及难点	1. 开发习惯、架构与交付流程改变大 2. 生态不成熟，需适配企业研发流程 3. 冷启动延迟、数据库连接成本高等新问题
演进形态（容器融合）	以容器镜像为载体，可移植性强；代表产品：阿里云ECI/SAE、Google CloudRun、Knative；保留Serverless优势且无需改造代码

技术关注点	核心内容
计算资源弹性调度	基于应用负载采用白盒调度，实时智能扩缩容；实现指标收集、决策、分析、优化闭环；实例放置目标：容错、资源利用率、性能、数据驱动调优
负载均衡和流控	资源调度服务横向分片扩展，避免单点；分片管理器动态迁移/分裂/合并实现负载均衡；多租户流量隔离，保障服务质量与资源共享
安全性	从权限、网络、数据、运行时全面防护；采用轻量安全容器，实现细粒度隔离、快速启动、低开销，高效利用碎片化资源

14.3.4服务网格

服务网格 (ServiceMesh) 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。

解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。换句话说，因为大量非功能性从业务进程剥离到另外进程中，服务网格以无侵入的方式实现了应用轻量化

14.4云原生架构分析

14.4.1某旅行公司云原生改造

阶段	核心目标	关键技术与措施	遇到问题 & 解决方案	阶段成果
第一阶段	提升资源利用率、降低成本，旧系统云原生化重构	1. 合并旧系统到云原生私有云平台 2. IaaS 层：VxLAN、大二层、KVM 虚拟化 3. 容器网络：BGP、Host 模式，绑核、NUMA 4. 存储：远端 Ceph，本地块存储 5. 异构资源：GPU+CUDA 虚拟化复用 6. 基于时序数据预测的资源调度	低版本 Java 无法识别容器资源，GC 资源争抢 → 垂直扩缩容 + JVM 升级 + Kata Container 强隔离	支撑大部分在线业务，资源利用率显著提升
第二阶段	保障服务稳定性，应对集群规模扩大	1. 多云架构：公有云+私有云+离线专属云 2. 声明式 API、不可变基础设施、服务网格 3. 镜像预热、专线直连、缓存&数据云上常驻 4. 多集群智能化调度、弹性计算、Scale Zero	应用卡顿、用户体验下降 → 弹性计算改造 + Scale Zero，资源降至原 20%	服务稳定性提升，集群资源成本最低化
第三阶段	应用全面云原生化，跨云统一治理	1. 基础组件云原生改造 2. 服务依赖标准化定义 3. 跨地域、跨云自动灾备与部署 4. 向云原生 DevOps 演进	屏蔽底层资源、机房、厂商差异	实现服务跨云统一调度、自动化灾备与部署

14.4. 2云原生技术助力某汽车公司数字化转型实践

14.4.3某快递公司核心业务系统云原生改造

14.4.4某电商业务云原生改造

突出的几个挑战：
● 系统开发迭代快，线上问题较多，定位问题耗时较长；
● 频繁大促，系统稳定性保障压力很大，第三方接口和一些慢SQL存在导致严重线上故障的风险；
● 压测与系统容量评估工作相对频繁，缺乏常态化机制支撑；
● 系统大促所需资源与日常资源相差较大，需要频繁扩缩容

云原生解决方案
引入阿里云容器服务 ACK、Spring Cloud Alibaba、PTS、AHAS、 链路追踪等配套产品，对应用进行容器化改造部署，优化配套的测试、容量评估、扩缩容等研发环节，提升产研效率。

方案关键点	核心内容
容器化弹性扩容	借助阿里云容器服务实现快速弹性伸缩，应对大促流量高峰
分布式链路追踪	提前接入链路追踪，定位复杂服务调用异常，快速排障
性能压测验证	使用阿里云PTS压测，模拟真实互联网流量，保障上线稳定
限流保护	基于压测数据识别强弱依赖与瓶颈，对关键接口、第三方调用、慢SQL等限流
大促保障准备	联合阿里云团队完成ECS/RDS/安全扩容、链路梳理、缓存预热、监控大屏、资源演练

应用效益	核心说明
高可用	借助 AHAS 实现限流降级与系统防护，保障关键资源与系统水位，大促稳定运行
容量评估	通过 PTS 压测 + ARMS 监控，评估单机与整体容量，为资源规划与成本预测提供依据
大促保障机制	建立标准化大促保障流程与应急机制，实现大促保障常态化