14.2 云原生架构内涵 ★★★★☆

14.2.1 云原生架构定义

云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特 性(如弹性、韧性、安全、可观测性、灰度等)，具备轻量、敏捷、高度自动化的特点。由于云原生是面向“云”而设计的应用，技术部分依赖于传统云计算的3层概念，即基础设施即服务 (IaaS)、 平台即服务 (PaaS) 和软件即服 务 (SaaS)。

云原生的代码通常包括三部分：业务代码、三方软件、处理非功能特性的代码。其中

业务代码指实现业务逻辑的代码；

三方软件是业务代码中依赖的所有三方库，包括业务库和基础库；

处理非功能性的代码指实现高可用、安全、可观测性等非功能性能力的代码。

特点：

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

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

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

14.2.2 云原生架构原则

1.服务化原则

代码规模超过一定范围时，需要进行拆分，包括拆分为微服务架构、小服务 (MiniService) 架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免相互影响，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。

使用基于服务流量(而非网络流量)的控制策略

2.弹性原则

弹性则是指系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。

3.可观测原则

可观测能力是在云这样的分布式系统中，主动通过日志、链 路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见， 甚至可以下钻到每次三方软件调用、 SQL请求、节点拓扑、网络响应等，可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。

4.韧性原则

韧性代表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，异常通常包括硬件故障、硬件资源瓶颈(如 CPU/ 网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件bug、 黑客攻击等。

韧性是软件持续提供业务服务的能力，核心目标是提升软件的平均无故障时间 (Mean Time Between Failure,MTBF)。

从架构设计上，韧性包括服务异步化能力、重试/ 限流/降级/熔断/反压、主从模式、集群模式、 AZ 内的高可用、单元化、跨region 容灾、异地多活容灾等。

5.所有过程自动化原则

通 过 IaC(Infrastructure as Code)、GitOps、OAM(Open Application Model)、Kubernetes Operator和大量自动化交付工具在CI/CD 流水线中的实践，一方面标准化企业内部的软件交付 过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程， 让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。

6.零信任原则

核心思想：默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础

零信任第一个核心问题就是身份 (Identity), 赋予不同的实体不同的身份，解决是谁在什么环境下访问某个具体的资源的问题。

7.架构持续演进原则

云原生架构是一个具备持续演进能力的架构，除了增量迭代、目标选取等因素外， 还需要考虑组织层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务、实现平衡关系。

14.2.3 主要架构模式

1.服务化架构模式

构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约(例如 IDL) 定义彼此业务关系，以标准协议 (HTTP、gRPC 等)确保彼此 的互联互通，结合DDD (领域模型驱动)、 TDD (测试驱动开发)、容器化部署提升每个接口的代码质量和迭代速度。

服务化架构的典型模式是微服务和小服务模式，其中小服务可以看作是 一组服务的组合

2.Mesh化架构模式

Mesh化架构是把中间件框架(如 RPC、 缓存、异步消息等)从业务进程中分离，流量控制、安全等逻辑由Mesh 进程完成。

3.Serverless模式

Serverless 非常适合于 事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。

4.存储计算分离模式

在云环境中，推荐把各类暂态数据(如 session)、 结构化和非结构化持久数据都采用云服务来保存， 从而实现存储计算分离。

5.分布式事务模式

大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题

(1)传统采用 XA 模式，虽然具备很强的一致性，但是性能差。

(2)基于消息的最终一致性 (BASE) 通常有很高的性能，但是通用性有限。

(3)TCC模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效；但是对 业务的侵入性非常强，设计开发维护等成本很高。

(4)SAGA模式与TCC 模式的优缺点类似但没有try这个阶段，而是每个正向事务都对应 一个补偿事务，也是开发维护成本高。

(5)开源项目 SEATA 的AT模式非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制。

6.可观测架构

可观测架构包括Logging、Tracing、Metrics三个方面，其中

Logging提供多个级别 (verbose/ debug/warning/error/fatal) 的详细信息跟踪，由应用开发者主动提供；

Tracing提供一个请求从前 端到后端的完整调用链路跟踪，对于分布式场景尤其有用；

Metrics则提供对系统量化的多维度度量。

由于建立可观测性的主要目标是对服务 SLO(Service Level Objective) 进行度量，从而优 化SLA, 因此架构设计上需要为各个组件定义清晰的 SLO, 包括并发度、耗时、可用时长、容量等。

7.事件驱动架构

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

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

1.庞大的单体应用

缺乏依赖隔离，考虑通过服务化进行拆分

2.单体应用“硬拆”为微服务

小规模软件的服务不需要拆分

拆分多个服务，带来数据依赖、导致性能降低

3.缺乏自动化能力的微服务

模块、接口增多，导致开发成本提高，测试、发布困难