第十章：云原生系统规划
说明
系列文章见：2025版-系统规划与管理师-备考文章目录
学习视频：江山老师
云原生发展背景
云原生来自于 Cloud Native 的直译。
概念
CNCF 对云原生的定义发生了改变，而这也逐渐成为被大家认可的官方定义：
- 基于容器、服务网格、微服务、不可变基础设施 和 声明式API 构建的可弹性扩展的应用；
- 基于自动化技术构建具备高容错性、易管理和便于观察的松耦合系统；
- 构建一个统一的开源云技术生态，能和云厂商提供的服务解耦。
发展概述
出于协调开发和运维的"信息对称"问题，开发者又推出了一套新的方法，即 DevOps（Development Operations，开发运维一体化），DevOps可以看做开发、技术运营和质量保障 三者的交集，促进三者之间的沟通、协作与整合。云原生的容器、微服务等技术为DevOps提供了良好的前提条件。
云原生与业务场景的深度融合，不仅为各行业领域注入了发展与创新的新动能，也促使云原生技术更快发展、生态更加成熟，主要表现为以下几个方面：
- 从为组织带来的价值来看，云原生架构通过对多元算力的支持，满足了不同应用场景的个性化算力需求，并基于软硬协同架构，为应用提供极致性能的云原生算力；基于多云治理和边云协同，打造高效、高可靠的分布式泛在计算平台，并构建包括容器、裸机、虚拟机、函数等多种形态的统一计算资源；****
- DevSecOps（Development Security Operations），实现应用的敏捷开发，提升业务应用的迭代速度，高效响应用户需求，并保证全流程安全。
云原生技术架构
架构定义
云原生架构以 应用 为中心打造高效的资源调度和管理平台！
从技术角度，云原生架构旨将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰，同时具备轻量、敏捷、高度自动化的特点。
由于云原生是面向"云"设计的应用，因此，技术部分依赖于传统云计算的三层概念，即基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)。
云原生的代码通常包括三部分：业务代码、三方软件、处理非功能特性的代码。
- 业务代码指实现业务逻辑的代码；
- 三方软件是业务代码中依赖的所有三方库，包括业务库和基础库；
- 处理非功能特性的代码指实现高可用、安全、可观测性等非功能性能力的代码。
三部分中只有业务代码是核心，是真正给业务带来价值的，另外两个部分都只是附属物。
云原生架构相比传统架构有了很大进步，从业务代码中剥离大量非功能性特性到IaaS和PaaS中，从而减少业务代码开发人员的技术关注范围，通过云服务商的专业性提升应用的非功能性能力。具备云原生架构的应用可以最大程度利用云服务，提升软件交付能力，进一步加快软件开发。
代码结构发生巨大变化
云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化。
在云环境中，"如何获取存储"变成了若干服务。
云把三方软硬件的能力升级成服务，开发人员的开发复杂度和运维人员的运维工作量都得到了极大的降低。组织 在非核心业务实现上从必须的负担变成了可控支出。
这些使业务代码的开发人员不需要再掌握文件及其分布式处理技术，不需要再掌握复杂的网络技术，让业务开发变得更敏捷、更迅速。
非功能性特性大量委托
任何应用都提供两类特性：功能性特性和非功能性特性。
- 功能性特性是真正为业务带来价值的代码，比如建立客户资料、处理订单、支付等。
- 非功能性特性是没有给业务带来 直接业务价值，但通常又是必不可少的特性，如 高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
云计算虽然没有解决所有非功能性问题，但确实有大量非功能性问题被云计算解决了，特别是分布式环境下的复杂非功能性问题。
高度自动化的软件交付
软件一旦开发完成，需要在组织内外部各类环境中部署和交付，以将软件价值交给最终用户。软件交付的困难在于开发环境到生产环境的差异，以及软件交付和运维人员的技能差异，填补这些差异往往需要很多安装手册、运维手册和培训文档等。而容器则以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。
基于云原生的自动化软件交付相比于当前的人工软件交付是一个巨大的进步。
设计原则
常见的原则主要包括：服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进等。
服务化原则
服务化设计原则是指通过 服务化架构 拆分不同生命周期的业务单元，实现业务单元的独立迭代，从而加快整体的迭代速度，保证迭代的稳定性。
服务化架构采用的是面向接口编程方式，增加了软件的复用程度，增强了水平扩展的能力。
服务化设计原则还强调在架构层面抽象化 业务模块之间的关系，从而帮助业务模块实现基于服务流量(而非网络流量)的策略控制和治理，而无须关注这些服务是基于何种编程语言开发的。
当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务(Mini Service)架构等，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和提升系统稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。
分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量(而非网络流量)的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。
弹性原则
弹性原则是指系统部署规模可以随着业务量变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源。
可观测原则
大部分组织的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么离线，哪些服务违反了其定义的SLO(Service Level Objective，服务等级目标)，目前的故障影响哪些用户，最近这次变更对哪些服务指标带来了影响等问题，这些都要求系统具备更强的可观测能力。
可观测性更强调主动性。在云计算这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次App点击所产生的多次服务调用耗时、返回值和参数都清晰可见，甚至可以下钻到每次第三方软件调用、SQL请求、节点拓扑、网络响应等信息中。运维、开发和业务人员通过这样的观测能力可以实时掌握软件的运行情况,并获得前所未有的关联分析能力，以便不断优化业务的健康度和用户体验。
韧性原则
韧性代表当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵抗能力。
所有过程自动化原则
通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运
维的自动化。
零信任原则
零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新建议。其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆，引导安全体系架构从"网络中心化"走向"身份中心化"，其本质诉求是以身份为中心进行访问控制。
架构持续演进原则
云原生架构本身也必须是一个具备持续演进能力的架构，而不是一个封闭式架构。
架构模式
云原生架构有非常多的架构模式，不同的组织环境、业务场景和价值定位等，通常采用不同的架构模式。常用的架构模式主要有服务化架构、Mesh化架构、Serverless、存储计算分离、分布式事务、可观测架构、事件驱动架构等。
服务化架构模式
服务化架构是新时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约(例如IDL)定义彼此的业务关系，以标准协议(HTTP、gRPC等)确保彼此的互联互通，结合DDD(Domain Driven Design，领域驱动设计)、TDD(Test Driven Development，测试驱动开发)、容器化部署提升每个接口的代码质量和迭代速度。
服务化架构的典型模式是微服务和小服务模式，其中小服务可以看作一组关系非常密切的服务的组合，这组服务会共享数据。小服务模式通常适用于非常大型的应用系统，避免接口的颗粒度太细而导致过多的调用损耗(特别是服务间调用和数据一致性处理)和治理复杂度。
Mesh化架构模式
Mesh化架构是把中间件框架从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。
分离后在业务进程中只保留很'薄'的Client部分，Client通常很少变化，只负责与Mesh进行通信，原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。
Serverless模式
Serverless将"部署"这个动作从运维中"收走"，使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等。
从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云会自动关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行都委托给云。
Serverless并非适用于任何类型的应用。如果应用是有状态的，由于Serverless的调度不会帮助应用做状态同步，因此云在进行调度的时候可能会导致上下文丢失；如果应用是长时间后台运行的密集型计算任务，会无法发挥Serverless的优势；如果应用涉及频繁的外部IO，也会因为繁重的IO负担、时延大而不适合用Serverless。
Serverless非常适合于事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。
存储计算分离模式
分布式环境中的CAP（一致性 - Consistency；可用性-Availability；分区容错性-Partition tolerance）困难主要是针对有状态应用。因为无状态应用不存在C(一致性)这个维度，因此可以获得很好的A(可用性)和P(分区容错性)，因而获得更好的弹性。
在云环境中，推荐把各类暂态数据(如session)、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不断根据上下文重新获取等，这时可以考虑采用时间日志+快照(或检查点)的方式，实现重启后快速增量
恢复服务，减少不可用对业务的影响时长。
分布式事务模式
待补充
可观测架构模式
可观测架构包括Logging、Tracing、Metrics三个方面。
- Logging提供多个级别(verhose / debug / warning / error / fatal )的详细信息跟踪，由应用开发者主动提供；
- Tracing提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；
- Metrics则提供对系统量化的多维度度量。
架构决策者需要选择合适的、支持可观测的开源框架(比如OpenTracing、OpenTelemetry等)，并规范上下文的可观测数据规范(例如方法名、用户信息、地理位置、请求参数等)，规划这些可观测数据在哪些服务和技术组件中传播，利用日志和Tracing信息中的spanid / traceid，确保进行分布式链路分析时有足够的信息进行快速关联分析。
由于建立可观测性的主要目标是对服务等级目标(SLO)进行度量，从而优化SLA(Service Level Agreement，服务级别协议)，因此架构设计上需要为各个组件定义清晰的SLO，包括并发度、耗时、可用时长、容量等。
事件驱动架构模式
事件驱动架构(Event Driven Architecture，EDA)本质上是一种应用/组件间的集成架构模式。事件和传统的消息不同，事件具有Schema，所以可以校验 Event 的有效性，同时EDA具备QoS保障机制，也能够对事件处理失败进行响应。
架构优势
云原生架构相比传统架构具有更高的可扩展性、可用性、灵活性、安全性、成本效益和高度自动化等优势，能够更好地适应不断变化和发展的业务需求。
云原生建设规划
云原生架构体系内容众多,如果深入到微服务、容器、DevOps、服务网格(Service Mesh)、自服务敏捷基础设施、混沌工程、安全等任何一项内容都有很多工作需要做。云原生这么多的内容做不到一步到位，而且彼此之间也存在先后次序相关性，它需要通过一系列的项目持续完成相关的能力，从而实现云原生融合架构。由于云原生架构体系内容众多，需要对其有相对深入的理解并能根据组织实际做出实施顶层规划，然后以分步实施的方法边建设边交付价值，使整个体系建设具备可持续性。
根据云原生架构体系中技术之间的关系和实际经验，基于"顶层规划+分步实施"的原则，将云原生架构规划实施路线图定义为5个步骤，分别为：（1）微服务采用及运行环境容器云平台构建；（2）服务管理和治理；（3）持续交付及安全；（4）自服务敏捷响应基础设施；（5）增强生产环境韧性和安全性。每个实施步骤又可以根据实际建设需要分为若干个子项目，并可能需要多次迭代。
（1）微服务采用及运行环境容器云平台构建
云原生架构体系中，应用 是交付业务价值的载体，而微服务是构建业务应用的技术。经微服务架构分解的应用服务运行在容器中。所以第一步在采用微服务的同时需要构建容器环境支撑微服务的运行。
基于容器技术和容器调度管理技术(如Kubernetes)构建组织内私有容器云平台，支撑微服务应用系统的部署、运行和管理，实现微服务运行时的环境支持，基于容器云平台可以实现相关的自服务敏捷能力，比如弹性扩展、服务路由、分发限流、健康检查、错误隔离、故障恢复、资源调度等。
（2）服务管理和治理
在完成容器云平台运行时支撑建设之后，可以侧重实现服务的治理和API的定义，以支持高效的管理和敏捷的服务编排响应，同时实现基于API的协同。
微服务治理有多种实现的方法。基于容器云平台可以直接利用Kubernetes的能力实现服务的注册发现、配置、路由分发、负载均衡、弹性扩容等，不过容器云平台要作为组织级应用支撑平台，需要在Kubernetes之上扩展实现服务的管理和治理能力。
（3）持续交付及安全
前两个步骤完成了微服务运行、运营的基础能力，具备了支撑微服务弹性扩展、协同交互的能力。有了部署运维平台和服务管理治理能力，就可以侧重提升研发端的持续交付能力。这样，无论开发多少微服务，在服务管理和治理方面也就没有了后顾之忧。以DevOps理论为指导，构建持续集成、持续部署、持续交付、持续监控、持续反馈的闭环流程。
DevOps是一种思想和方法论，其核心是协作反馈。
认证和权限是DevOps体系中的基础安全措施。代码安全检查、镜像安全检查、系统安全、应用安全、接口安全、容器安全等都需要在DevOps工具链和流水线实施及使用过程中逐步完善，以提升云原生的整体安全性。
（4）自服务敏捷响应基础设施
基础设施大致可以划分为三个部分：基础设施资源、支撑平台和纯技术工具。
- 基础设施资源可能有很多种异构资源和云平台，需要通过统一的层次(比如多云管理平台)来封装，提供统一的基础设施资源服务，隔离底层异构资源细节，简化应用资源调度。
- 支撑平台主要是微服务开发、运行、运维的平台，例如持续交付平台,容器云平台等。
- 纯技术工具指的是和业务无关、围绕支撑平台周边的工具，比如消息平台(Rabbi tMQ、Kafka)、监控平台、权限管理平台、认证平台、人脸识别平台等。这些平台可以提取构建技术中台能力，各业务应用都可以复用这些能力。
在实施持续交付的同时，也是在部分构建 自服务敏捷响应基础设施能力，比如持续集成、持续交付流水线等。在这个步骤中，需要重点构建和完善自动化、自服务的基础设施能力，包括统一身份认证和权限服务、日志服务、配置服务、监控服务、告警服务、安全服务、AI服务(人脸识别、文字识别、图像识别、语音识别、自然语言处理、知识图谱、算法等)、消息服务、调度服务等基础服务和CI/CD研发流程服务等。实现这些服务的自服务能力是构建应用敏捷响应的关键。
基础设施资源的自服务敏捷响应是所有这些服务实现敏捷响应的前提。
在这个过程中，组织架构可以同步调整，比如基础设施资源团队来运维运营基础设施资源，为平台和工具提供资源服务；平台团队来运维运营平台；工具团队来持续研发工具和技术中台服务；支撑以应用管理为中心的架构；应用研发团队专注于业务应用微服务的研发，使用自服务的资源、平台、工具实现服务的研发、测试、部署、运行、运维等全生命周期管理。
（5）增强生产环境韧性和安全性
通过抗脆弱性试验持续增强环境的韧性。
安全能力建设也是系统抗脆弱性的一部分。安全措施是防御性的，而系统是在持续变化之中的，随时可能出现不可预知的漏洞，因此除了在开发设计时尽可能消除安全隐患，在运行时的安全措施也一样不能少，而且是持续性的，所以需要不断地改进安全举措，持续增强抗击漏洞攻击等行为。