【2025-系统规划与管理师】第十章：云原生系统规划

---

说明

系列文章见：2025版-系统规划与管理师-备考文章目录

学习视频：江山老师

---

1.云原生技术架构

1.1.架构定义

从技术角度，云原生架构旨将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰，同时具备轻量、敏捷、高度自动化的特点。

由于云原生是面向“云”设计的应用，因此，技术部分依赖于传统云计算的三层概念，即基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)。

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

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

三部分中只有业务代码是核心，是真正给业务带来价值的，另外两个部分都只是附属物。

云原生架构相比传统架构有了很大进步，从业务代码中剥离大量非功能性特性到IaaS和PaaS中，从而减少业务代码开发人员的技术关注范围，通过云服务商的专业性提升应用的非功能性能力。具备云原生架构的应用可以最大程度利用云服务，提升软件交付能力，进一步加快软件开发。

代码结构发生巨大变化

云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化。

在云环境中，“如何获取存储”变成了若干服务。

云把三方软硬件的能力升级成服务，开发人员的开发复杂度和运维人员的运维工作量都得到了极大的降低。组织 在非核心业务实现上从必须的负担变成了可控支出。

这些使业务代码的开发人员不需要再掌握文件及其分布式处理技术，不需要再掌握复杂的网络技术，让业务开发变得更敏捷、更迅速。

非功能性特性大量委托

任何应用都提供两类特性：功能性特性和非功能性特性。

• 功能性特性是真正为业务带来价值的代码，比如建立客户资料、处理订单、支付等。
• 非功能性特性是没有给业务带来 直接业务价值，但通常又是必不可少的特性，如 高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。

高度自动化的软件交付

软件一旦开发完成，需要在组织内外部各类环境中部署和交付，以将软件价值交给最终用户。软件交付的困难在于开发环境到生产环境的差异，以及软件交付和运维人员的技能差异，填补这些差异往往需要很多安装手册、运维手册和培训文档等。而容器则以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。

基于云原生的自动化软件交付相比于当前的人工软件交付是一个巨大的进步。

1.2.设计原则

常见的原则主要包括：服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进等。

服务化原则

服务化设计原则是指通过 服务化架构 拆分不同生命周期的业务单元，实现业务单元的独立迭代，从而加快整体的迭代速度，保证迭代的稳定性。

服务化架构采用的是面向接口编程方式，增加了软件的复用程度，增强了水平扩展的能力。

服务化设计原则还强调在架构层面抽象化 业务模块之间的关系，从而帮助业务模块实现基于服务流量(而非网络流量)的策略控制和治理，而无须关注这些服务是基于何种编程语言开发的。

当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务(Mini Service)架构等，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和提升系统稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。

分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量(而非网络流量)的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。

弹性原则

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

可观测原则

大部分组织的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么离线，哪些服务违反了其定义的SLO(Service Level Objective，服务等级目标)，目前的故障影响哪些用户，最近这次变更对哪些服务指标带来了影响等问题，这些都要求系统具备更强的可观测能力。

可观测性更强调主动性。在云计算这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次App点击所产生的多次服务调用耗时、返回值和参数都清晰可见，甚至可以下钻到每次第三方软件调用、SQL请求、节点拓扑、网络响应等信息中。运维、开发和业务人员通过这样的观测能力可以实时掌握软件的运行情况,并获得前所未有的关联分析能力，以便不断优化业务的健康度和用户体验。

韧性原则

韧性代表当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵抗能力。

所有过程自动化原则

通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运
维的自动化。

零信任原则

零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新建议。其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以身份为中心进行访问控制。

架构持续演进原则

云原生架构本身也必须是一个具备持续演进能力的架构，而不是一个封闭式架构。

1.3.架构模式

云原生架构有非常多的架构模式，不同的组织环境、业务场景和价值定位等，通常采用不同的架构模式。常用的架构模式主要有服务化架构、Mesh化架构、Serverless、存储计算分离、分布式事务、可观测架构、事件驱动架构等。

服务化架构模式

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

服务化架构的典型模式是微服务和小服务模式，其中小服务可以看作一组关系非常密切的服务的组合，这组服务会共享数据。小服务模式通常适用于非常大型的应用系统，避免接口的颗粒度太细而导致过多的调用损耗(特别是服务间调用和数据一致性处理)和治理复杂度。

可观测架构模式

可观测架构包括Logging、Tracing、Metrics三个方面。

• Logging提供多个级别(verhose/debug/warning/error/fatal)的详细信息跟踪，由应用开发者主动提供；
• Tracing提供一个请求从前端到后端的完整调用链路跟踪,对于分布式场景尤其有用；
• Metrics则提供对系统量化的多维度度量。

架构决策者需要选择合适的、支持可观测的开源框架(比如OpenTracing、OpenTelemetry等)，并规范上下文的可观测数据规范(例如方法名、用户信息、地理位置、请求参数等)，规划这些可观测数据在哪些服务和技术组件中传播，利用日志和Tracing信息中的spanid/traceid,确保进行分布式链路分析时有足够的信息进行快速关联分析。

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

2.云原生建设规划

根据云原生架构体系中技术之间的关系和实际经验，基于“顶层规划+分步实施”的原则，将云原生架构规划实施路线图定义为5个步骤，分别为：微服务采用及运行环境容器云平台构建、服务管理和治理、持续交付及安全、自服务敏捷响应基础设施、增强生产环境韧性和安全性。每个实施步骤又可以根据实际建设需要分为若干个子项目，并可能需要多次迭代。

微服务采用及运行环境容器云平台构建

云原生架构体系中，应用 是交付业务价值的载体，而微服务是构建业务应用的技术。经微服务架构分解的应用服务运行在容器中。所以第一步在采用微服务的同时需要构建容器环境支撑微服务的运行。

基于容器技术和容器调度管理技术(如Kubernetes)构建组织内私有容器云平台，支撑微服务应用系统的部署、运行和管理，实现微服务运行时的环境支持，基于容器云平台可以实现相关的自服务敏捷能力，比如弹性扩展、服务路由、分发限流、健康检查、错误隔离、故障恢复、资源调度等。

以云原生12要素为指导设计微服务。当前微服务分拆的方式通常是基于领域驱动设计(DDD)方法。不过DDD对业务领域的划分往往难以清晰定义领域边界，存在着领域划分不合理、数据同时存在于不同领域的问题，为每个服务选择合适的责任级别及其范围是困难的，需要极深的经验和对业务的理解。因此Martin Fowler建议可以先建一个传统的大一统系统,在对领域知识有更好的了解以后，再通过重构将其改造成微服务。笔者觉得DDD通过领域划分可以在一定程度上简化业务关系，从而简化微服务设计，但领域划分也使每个领域缺乏全局认识，所以DDD更像是一种分类简化的设计方法,这会造成多次重复迭代，造成浪费。而Martin Fowler的建议则使DDD有了全局的视角，能够从上到下，从全局看到领域划分和设计，但这个大一统系统并不容易建设。

笔者基于实践提出了“主数据驱动设计”的微服务设计方法，主数据本来就是系统间共享的高价值数据，基于组织主数据设计的微服务天然具备系统间的可重用性。而且基于行业通用数据模型(Common Data Model，CDM)则很容易定义并完善主数据微服务，减少重复的迭代设计和实现。

服务管理和治理

在完成容器云平台运行时支撑建设之后，可以侧重实现服务的治理和API的定义，以支持高效的管理和敏捷的服务编排响应，同时实现基于API的协同。

微服务治理有多种实现的方法。基于容器云平台可以直接利用Kubernetes的能力实现服务的注册发现、配置、路由分发、负载均衡、弹性扩容等，不过容器云平台要作为组织级应用支撑平台，需要在Kubernetes之上扩展实现服务的管理和治理能力。

持续交付及安全

前两个步骤完成了微服务运行、运营的基础能力，具备了支撑微服务弹性扩展、协同交互的能力。有了部署运维平台和服务管理治理能力，就可以侧重提升研发端的持续交付能力。这样，无论开发多少微服务，在服务管理和治理方面也就没有了后顾之忧。以DevOps理论为指导，构建持续集成、持续部署、持续交付、持续监控、持续反馈的闭环流程。

DevOps是一种思想和方法论，其核心是协作反馈。

认证和权限是DevOps体系中的基础安全措施。代码安全检查、镜像安全检查、系统安全、应用安全、接口安全、容器安全等都需要在DevOps工具链和流水线实施及使用过程中逐步完善，以提升云原生的整体安全性。

自服务敏捷响应基础设施

基础设施大致可以划分为三个部分：基础设施资源、支撑平台和纯技术工具。

• 基础设施资源可能有很多种异构资源和云平台，需要通过统一的层次(比如多云管理平台)来封装，提供统一的基础设施资源服务，隔离底层异构资源细节，简化应用资源调度。
• 支撑平台主要是微服务开发、运行、运维的平台，例如持续交付平台,容器云平台等。
• 纯技术工具指的是和业务无关、围绕支撑平台周边的工具，比如消息平台(Rabbi tMQ、Kafka)、监控平台、权限管理平台、认证平台、人脸识别平台等。这些平台可以提取构建技术中台能力，各业务应用都可以复用这些能力。

在实施持续交付的同时，也是在部分构建 自服务敏捷响应基础设施能力，比如持续集成、持续交付流水线等。在这个步骤中，需要重点构建和完善自动化、自服务的基础设施能力，包括统一身份认证和权限服务、日志服务、配置服务、监控服务、告警服务、安全服务、AI服务(人脸识别、文字识别、图像识别、语音识别、自然语言处理、知识图谱、算法等)、消息服务、调度服务等基础服务和CI/CD研发流程服务等。实现这些服务的自服务能力是构建应用敏捷响应的关键。

基础设施资源的自服务敏捷响应是所有这些服务实现敏捷响应的前提。

在这个过程中，组织架构可以同步调整，比如基础设施资源团队来运维运营基础设施资源，为平台和工具提供资源服务；平台团队来运维运营平台；工具团队来持续研发工具和技术中台服务；支撑以应用管理为中心的架构；应用研发团队专注于业务应用微服务的研发，使用自服务的资源、平台、工具实现服务的研发、测试、部署、运行、运维等全生命周期管理。

增强生产环境韧性和安全性

通过抗脆弱性试验持续增强环境的韧性。

安全能力建设也是系统抗脆弱性的一部分。安全措施是防御性的，而系统是在持续变化之中的，随时可能出现不可预知的漏洞，因此除了在开发设计时尽可能消除安全隐患，在运行时的安全措施也一样不能少，而且是持续性的，所以需要不断地改进安全举措，持续增强抗击漏洞攻击等行为。