企业数字化转型-云原生架构规划和设计

人月聊IT

发布于 2025-08-24 11:26:31

3600

大家好，我是人月聊IT，在这里分享下我做云原生架构设计培训的一个材料分享。

接下来，我们将正式探讨企业云原生架构设计与平台建设的思路。本次演讲分为四个部分：云原生概述、云原生整体架构规划、云原生平台建设，以及基于多年云原生平台、微服务、容器云和DevOps实际项目经验的关键问题与解决方案分享。

首先，我们需要明确云原生的基本概念。根据业界标准定义，云原生是由Marty Sting提出的概念，它是一系列云计算技术与企业治理方法的集合，涵盖DevOps、持续交付、微服务、敏捷基础设施和康威定律等技术与管理实践。这些实践可分为两大类：

技术实践：包括微服务、服务网格、无服务器架构和敏捷基础设施
管理实践：包括持续交付、DevOps、康威定律和敏捷研发

然而，仅了解这些概念仍难以把握云原生的核心本质。我们需要厘清云原生与传统云计算、PaaS等概念的关系。简单地将云原生理解为"微服务+DevOps+容器云"是片面的。

要深入理解云原生的本质特征，必须从云计算的分层架构谈起。云计算的发展过程是从资源层到服务层，再到应用层的完整抽象过程：

IaaS（基础设施即服务）：主要实现弹性计算与存储能力，解决资源层的虚拟化问题，将资源能力作为服务共享
PaaS（平台即服务）：不仅实现资源虚拟化，更注重平台层能力的服务化，包括中间件资源池、数据库资源池和运行时环境等核心组件

通过上述讲解，您可能仍对IaaS和PaaS的区别感到困惑。下面我们通过一个具体示例来阐明两者的核心差异。

对于IaaS，其本质在于实现物理资源到逻辑资源的抽象。在使用IaaS时，用户无法直接看到物理服务器，而是通过虚拟机来使用计算资源。例如，当您申请资源时，数据中心运维团队提供的是虚拟机实例而非物理服务器，这就是IaaS的核心功能。

而PaaS则实现了更高层次的抽象——从资源到服务的抽象。在PaaS环境中，用户不仅看不到物理服务器，甚至连虚拟机也不可见。取而代之的是可直接调用的技术服务能力，如中间件、消息队列、安全服务等。举例来说，当开发项目需要使用Redis缓存服务时：

在IaaS模式下，需先申请虚拟机，然后手动安装部署Redis组件
在PaaS模式下，只需向平台云服务中心申请缓存服务即可，无需关心底层实现细节

由此可见，IaaS与PaaS的根本区别在于抽象层次：IaaS实现物理资源到逻辑资源的抽象，PaaS则实现资源到服务的进一步抽象。

理解这一区别后，我们再来探讨云原生的本质。

华为在云原生2.0概念中提出"从长在云上到生在云上"的理念。为更好理解，可以类比"云生家庭"的概念：真正的原生意味着从规划、孕育到诞生的全过程都在可控环境中完成。同理，企业上云要真正实现云原生，需要从架构设计之初就充分考虑云环境特性，而非简单地将现有应用迁移到云平台。这就是云原生的核心要义。

在完成软件开发并编译打包成部署包后，才考虑是选择华为云还是阿里云申请弹性计算资源来部署应用，这种模式与生育后才从福利院领养孩子并无本质区别。真正的云原生理念在于"生于云上"——从开发团队萌生构建新IT系统的想法伊始，就立足于云平台。

云原生平台能够提供全生命周期的支持：从开发框架和环境搭建（包括本地开发环境、低代码服务平台和云端IDE），到开发完成后的编译构建打包（通过DevOps CI/CD持续集成流程），直至测试通过后的生产环境发布（基于Kubernetes的容器云编排能力）。这种模式的核心价值在于从项目构思阶段就提供全方位的基础能力支撑。

云原生与传统云计算的核心差异体现在两个维度：

抽象化：关注点从基础设施资源转向服务能力
过程化：不仅管理最终产出，更贯穿整个应用生命周期各阶段

华为云原生2.0白皮书提出了企业IT架构演进的三个阶段：

服务器阶段：传统物理服务器架构
云化阶段：提供弹性计算和存储的虚拟化资源池（IaaS云数据中心）
云原生化阶段：实现从资源到服务的抽象，完成从资源中心化到应用中心化的转变

云原生的本质是将业务通用能力下沉至平台层，通过平台化手段加速应用开发交付，简化后期运维管理。其核心理念是所有基础设施平台都应以应用支撑和能力赋能为根本目标，这标志着企业技术架构演进的关键转折。

中国信通院此前发布了企业数字化IOMM成熟度模型，该模型涵盖服务运营与云化管理两大领域，划分为四大象限、六大能力与六大价值。其中，六大能力包括服务产品化、能力平台化、数据价值化、管理精益化、运营体系化及风险可控化。能力平台化的核心实现，正是本次要探讨的云原生平台建设——这已超越传统基础设施平台化范畴，演进为整体能力的平台化。

接下来通过企业IT架构演进图示说明：从单体烟囱式架构向云原生平台的转型可分为三个阶段。

第一阶段特征明显：虽已采用云数据中心统一虚拟化资源池，实现弹性计算与存储能力的统一供给，但上层应用仍为单体竖井式架构。各IT系统独立拥有数据库与中间件平台层，即便业务子系统划分模块，模块间仍呈紧耦合状态。 第二阶段为传统PaaS平台阶段，典型案例如2011-2012年某集团大型私有云PaaS建设项目。此阶段在IaaS云平台基础上构建传统PaaS技术平台（如早期基于虚拟机调度的Cloud Foundry/Cloudify）。此时数据库中间件已纳入PaaS平台，但各应用开发仍需独立集成消息、安全、缓存、4A系统管理等共性技术组件，形成业务无关的独立技术平台层。 第三阶段即云原生阶段呈现两大显著变革：底层PaaS平台从虚拟机调度转向更轻量的容器云及编排体系；上层单体系统完成深度解耦，实现彻底的微服务化转型，形成独立微服务应用组件。这一演进标志着企业IT架构的成熟度跃升。第三个变化是上层已完成微服务拆分，同时构建了底层的容器云技术资源平台。每个微服务应用仍涉及从需求、设计、开发、测试、编译、部署到交付的完整软件生命周期过程。如何更好地支撑这一过程，实现上层微服务应用开发与底层容器云平台的高度融合与集成？为此，我们构建了以CI/CD为核心的DevOps能力支撑平台。

最终架构可清晰划分为三层：

底层为容器云平台
中间层是DevOps平台
上层是微服务架构

回顾云原生的关键技术实践，正是微服务、DevOps和容器云三大要素。通过观察云原生技术的演进过程，可以更清楚地理解这些核心技术实践是如何随着企业IT架构的演变而逐步发展成熟的。云原生技术并非凭空产生，而是随着企业架构的变革逐步演进而来。

正如传统单体架构向微服务架构的转型过程一样，这种演进是循序渐进、逐步发展的。

对于这个问题，我们需要从开发态和部署运行态两个层面来分析。在传统IT架构中，大单体系统虽然上层划分为多个业务子系统模块，但底层仍共享同一个数据库。各业务模块之间存在紧密耦合关系。若需单独部署客户管理子系统，则难以实现，这是传统大单体架构的固有特征。

在部署运行态方面，传统架构通常采用大型数据库集群（如RAC集群或读写分离集群），应用层则部署为集群形式，可通过物理服务器或虚拟机实现。但存在明显问题：应用服务器集群较易实现水平弹性扩展，而数据库层随着业务量和并发量增长，水平扩展变得极为困难。例如，十多年前在大型集团项目中采用Oracle RAC集群时，当节点增至4-6个后即遭遇性能瓶颈，继续增加节点已无法提升性能。

微服务架构在开发态即带来显著变化：要求数据库与逻辑层严格纵向拆分，如订单管理使用专属订单数据库，产品管理使用产品数据库，上层应用对应订单中心、产品中心等。此时可能产生疑问：各中心间如何进行横向集成？微服务架构的关键要求是：所有跨服务集成必须通过轻量级RESTful API接口实现。

在运行态，微服务架构的最大变革体现在应用集群部署方式上。每个微服务组件不再通过虚拟机部署，而是采用更轻量化的容器技术，借助Kubernetes实现容器编排和弹性调度。传统单体应用的部署包往往达数百兆，不适合容器化部署；而经过微服务拆分后，每个服务的部署包可控制在百兆左右，显著提升了部署灵活性。

这种规模的部署包非常适合部署到容器中，这是微服务架构的一种演进。

在介绍完微服务与云原生的基本概念后，我们将进一步探讨云原生架构的整体规划。对于云原生架构的规划，其核心指导思想仍应以平台加应用为核心。平台体现云计算的核心思想，应用则遵循SOA的横向分层理念。

基于这一原则，采用企业架构规划方法，其中包含两种主要模式：一是TOGAF的企业架构，即4A架构；二是更早期的ARIS流程建模与流程架构设计。完成企业架构规划后，基于SOA思想，将企业级应用开发划分为平台层与应用层的横向分层结构。

云原生平台作为核心平台，涵盖容器云平台、DevOps平台、技术平台等能力。在应用开发层面，既可采用微服务开发框架进行手工组件开发，也可基于成熟的低代码平台产品实现微服务应用组件开发。

由此可见，云原生在企业架构规划中的定位更加明确，其引入对传统企业架构规划思想进行了优化与调整。

对于企业架构规划思想，我之前已有大量文章和视频进行阐述。简而言之，该规划可分为准备阶段、现状分析、业务与数据架构设计、应用与技术架构设计，最终形成实施路线规划。

在准备阶段，我们主要进行资料收集，包括业界最佳实践和参考标准的对标研究。现状分析则分为两条主线：业务调研和IT调研。业务调研通常从端到端流程梳理入手，逐步分解为一级、二级、三级流程，直至五到七级的操作级流程。完成流程梳理后，借助业务能力地图识别相关业务能力和业务单元，进而构建业务架构。

在流程分析过程中，我们会识别流程的输入输出，其中包含核心业务单据，这些单据即潜在的业务对象。完成业务对象建模后，将其转化为数据对象，纳入详细的数据架构规划设计，包括概念模型、逻辑模型和物理模型。

完成业务架构和数据架构设计后，下一步是应用架构设计。如前所述，应用架构设计需引入云原生思想，采用"平台+应用"的构建方式。底层实现依托于核心云原生技术架构。值得注意的是，传统4A架构主要关注IT基础设施技术架构，而当前我们进行了重大调整，将云原生平台层技术架构也纳入4A架构的总体规划。

应用架构规划设计完成后，进入集成架构规划设计阶段。通过集成形成应用组件能力的组合与编排，最终适配上层端到端流程需求。完成整个4A架构规划设计后，将过渡到项目组合管理、项目群管理及IT系统建设实施落地计划。

基于上述企业架构规划设计方法论，其核心可概括为"业务场景驱动的能力设计V模型"。在讨论V模型前，还需提及4A架构设计中常用的Y模型，该模型主要应用于业务架构规划设计阶段。

在业务架构规划设计中，基于4A架构规划思想，核心在于业务价值链与业务流分析。完成业务价值流分析后，通常会形成两条主线：一条围绕业务能力地图进行业务能力分解，另一条围绕端到端流程进行逐级分解。无论是业务能力线还是业务流程线，在细化至5-7级操作级流程后，都会实现融合统一。此时进入细粒度流程建模阶段。

在业务架构设计中，特别是在最细粒度的流程建模环节，应引入传统软件架构设计中的业务对象建模思路，以优化流程建模工作。这一内容在传统企业架构规划设计中较少展开讨论，即业务架构中的V模型。V模型的核心在于阐述4A架构中业务架构与应用架构的映射关系。

在架构设计中，数据架构被置于横向基础底座位置。传统4A架构将架构分为业务架构和IT架构两大类，其中IT架构包含应用架构、数据架构和技术架构。当前4A架构存在不合理之处，即数据架构规划设计过于滞后，不符合数字化转型中数据驱动的核心理念。将数据架构移至底层后，需重点考虑业务架构与应用架构的映射关系。

业务架构中的端到端业务流程、业务能力组件、业务能力及底层业务组件，均可一对一映射至应用架构。业务组件对应应用组件，业务能力与服务对应API接口服务，端到端流程则通过应用组件或API接口的灵活组装实现。理解业务架构与应用架构的映射关系，才能真正打通企业架构的核心集成与协同机制。

回到企业架构元模型，简化后的模型着重体现4A架构间的集成与协同关系。通过核心价值流形成的两条主线（业务能力与流程）在5-7级后聚合，展开业务对象建模。业务对象建模包含数据对象、业务行为活动、业务规则与角色，这些对应数据架构中的概念模型，进而发展为逻辑模型和物理模型，最终过渡至技术架构，解决应用部署与数据存储问题。

在业务域中，我们定义了相关的业务对象和业务组件。这些业务组件需要映射到应用域中的应用组件。基于高内聚、低耦合的原则，应用组件将进一步抽象为上层的应用系统。构建应用系统后，还需考虑如何通过接口实现系统间的集成与编排。通过应用组件或其暴露的API接口的编排，可以实现业务域中完整的端到端业务流程。

由此可见，应用域与业务域实现了完整的匹配。在技术域层面，正如前文所述，这涉及到云原生架构中的容器云技术服务能力。现代应用开发不再构建单体架构，而是采用松耦合的应用组件，这正是微服务架构的核心理念。应用组件的开发过程包括编译、构建、打包、部署和集成，这体现了DevOps的实践流程。

综上所述，这些要素共同构成了云原生架构的核心特征。理解这一逻辑后，就能明白为何在讨论云原生架构时，通常会与企业架构和业务架构相结合进行阐述。云原生架构规划设计的关键前提，正是基于企业架构和业务架构的指导原则。

云原生对企业架构起到核心作用。从事企业架构规划的专业人士可能已经意识到，许多企业在完成架构设计后，往往难以有效指导后续IT建设、平台实施和落地工作。实际上，云原生技术为企业架构规划提供了坚实的落地支撑。

在我的架构图中，右上角部分恰好弥补了传统4A架构的不足，特别是应用架构中容易被忽视的内容。传统应用架构往往只关注单一应用，而忽略了在云原生环境下如何构建"平台+应用"的松耦合架构体系。这包括：

应用间的集成方式
应用接口的组合编排
端到端业务流程的适配

这些关键要素的缺失会导致业务架构与应用架构脱节，无法形成有机整体。理解并重视这些概念，对企业构建完整的数字化架构至关重要。云原生技术正是解决这些问题的关键支撑。

在梳理了云原生架构规划设计的指导思想及其与企业架构规划之间的关系后，我们可以探讨云原生架构规划项目的核心思路和方法论。这一过程可分为四个关键阶段：

现状分析 基于企业现状与行业最佳实践，重点围绕微服务、容器云和DevOps三大领域，对现有业务和IT系统进行全面调研，涵盖业务功能、开发框架、技术架构及运维等方面。
蓝图设计 包括架构蓝图和规范蓝图两部分：

架构蓝图涵盖云原生技术中台架构、微服务架构等整体设计
规范蓝图涉及DevOps流程规范、容器云管理规范、微服务开发治理规范等

路径规划 通过对比理想的云原生成熟度模型，为企业制定详细的实施路线图，包括阶段性目标设定、关键项目识别和资源投入规划。
验证测试 通过小型POC项目验证规划设计的可行性，包括技术选型、项目设计、执行和评估等环节。

业界参考架构方面：

华为云原生2.0架构采用分层设计：
- 底层为容器云平台及调度编排平台
- 上层为云原生应用赋能层，包含技术中间件、集成平台、DevOps平台、数据平台和低代码开发平台
- 信通院发布的《应用架构现代化》白皮书也提供了相关参考标准

在信通院的应用架构现代化研究中，详细阐述了六大关键技术，包括组装式交付、数据驱动、研发数字化、服务化架构、安全可信和韧性。在这六大技术中，诸如低代码、研发数字化、DevOps、微服务以及底层容器技术，均属于云原生的核心关键技术实践范畴。因此，云原生架构本身也是推动应用架构现代化转型的关键实践。

众所周知，应用架构现代化转型经历了从单体架构到垂直架构，再到SOA架构，最终演进至微服务架构的过程。特别是在微服务架构阶段，需注意微服务架构不仅涉及微服务本身。将单体应用拆分为微服务后，仅解决了开发态的问题。拆分后，如何实现集成、打包部署以及敏捷交付，才是关键考量。当这些因素被纳入考虑时，微服务与容器云、DevOps之间便形成了协同与关联关系。所有这些最佳实践的综合，正是云原生平台需要实现的目标。

在完成云原生整体架构规划设计的讲解后，我们将进一步探讨如何构建一个云原生平台。

接下来，我们分析业界主流厂商在云原生领域的最新动态。

首先以阿里云为例，该公司早在七八年前就发布了《云原生白皮书》。该白皮书虽未详细展开，但明确提出了云原生技术架构的六大核心视角：服务化能力、弹性能力、无服务器化程度、可观测性、韧性能力以及自动化水平。值得注意的是，这些观点与信通院提出的应用架构简化理念高度契合。

在产品层面，阿里云构建了完整的云原生产品矩阵，主要包括：云原生数据库家族、消息中间件产品（如RocketMQ）、微服务产品家族、DevOps平台（如阿里云效）、容器云服务（ACK）等，共同构成了其云原生技术平台体系。

接下来我们分析网易轻舟云原生平台。该平台提供了一个完整的云原生解决方案，被命名为"网易一站式云原生软件生产力平台"。该平台覆盖了软件开发全生命周期，包括开发构建、发布上线、运行治理和运维等环节。其设计理念源于网易内部大型互联网应用的工程实践。平台架构主要包含以下核心组件：

底层基础设施：容器云平台NCS
开发运维工具链：持续集成与持续交付平台(CICD)
微服务框架：包括微服务开发框架NSF、API网关APIGateway
可观测性平台：全链路应用监控APM
中间件技术服务能力平台
上层应用开发平台：低代码快速开发平台(LCAP)

通过这个案例可以看出，一个完整的云原生平台通常都包含这些关键组成部分。

我们自2016年起便参与了中国电信“云道”DevOps平台的建设工作，同时对中国联通的上层集成平台和能力开放平台，以及中国移动的SOA集成平台也有深入参与。这些项目涵盖了从规划到建设实施的全过程。通过对阿里云、华为云、中国电信、中国移动和中国联通等云原生平台的对比分析，可以发现其核心架构大同小异。

基于行业主流实践，我们规划了远行科技的云原生平台整体架构设计。该设计覆盖了云原生的管理实践和技术实践，贯穿微服务应用开发的全生命周期流程和后期的管控治理。通过DevOps最佳实践，有效衔接了上层应用开发和底层容器托管、资源托管，再通过API网关或能力开放平台实现共享能力的开放，从而为企业构建“平台+应用”的敏捷应用新模式。

远行科技的云原生架构设计分为三个层次：

最底层：基于Kubernetes和Docker的容器平台
中间层：研发过程管理和持续集成的DevOps平台
最上层：覆盖微服务应用开发全生命周期（开发态、运行态、运维态）的完整技术底座平台

具体包括：

开发态：微服务开发框架和低代码开发平台
运行态：技术中台、业务中台和容器融合的服务总线网关
运维监控态：覆盖从资源到服务、从服务到应用的全面运维监控治理体系，提升可观测性

这一架构完整地体现了云原生平台应具备的核心功能。

最后，我们来看一个案例。该案例源于前年为某大型企业提供的云原生技术架构规划服务。我们输出的云原生总体技术架构规划覆盖了SaaS层，而云原生的核心能力仍集中在PaaS层。该技术规划包含以下内容：

底层容器云平台和容器编排调度能力
中间层的技术平台服务
上层的DevOps过程支撑
微服务开发框架和低代码平台
右侧的低代码开发完成后涉及的API网关、融合集成平台及能力开放

除上述技术平台支撑系统外，我们还提供两项关键内容：

标准规范体系：涵盖云原生微服务、DevOps等规范
统一运维监控体系：包括监控体系、运维体系及容灾备份体系

这是一个完整的云原生技术架构体系，可供参考。

在规划云原生技术架构体系后，还需制定相应的演进路线规划。通常采取横向围绕微服务、云平台、运维监控三个维度展开，纵向划分为基础能力建设、能力提升和能力融合三个阶段。每个阶段都需要完成相应的工作，构建底层技术组件或标准规范体系。

以我们前年为某甲方客户实施的案例为例：

在基础能力建设阶段，我们建议首先统一技术组件选型清单，制定微服务开发框架和标准规范，引入低代码平台和API网关，部署DevOps研发管理平台。对于云平台，建议采用容器云平台；运维监控方面，则需建立统一的运维监控平台。这些方案都需结合企业实际业务和IT建设现状，确保可验证、可落地。

在云原生架构规划设计的客户交流过程中，我们发现一个关键问题：

虽然企业普遍了解云原生架构包含容器云、DevOps和微服务等技术，但实际应用中往往停留在小规模尝试阶段。例如在DevOps方面，企业可能未采用商用工具，而是使用Jenkins实现基础的CI/CD流程，或采用开源工具如Kubernetes进行简单的持续集成和发布。这反映出企业在云原生架构实践中的真正挑战所在。

在集成与协同方面，云原生技术涵盖众多实践，包括微服务、低代码开发、容器云技术、DevOps工具链，以及消息服务、安全认证、缓存等核心组件。如何将这些技术要素有机整合为统一体系？目前许多企业在实施云原生架构时，这一环节的处理仍存在明显不足。

因此，我始终强调云原生平台建设的核心重点并非单个技术组件能力的构建，而在于如何实现各技术组件间的集成与协同。这才是最关键的问题。

例如，在构建低代码开发平台时，需要考虑以下方面：

该平台如何与微服务开发框架及规范相融合；
开发的应用是否基于DevOps流程支撑；
应用能否平滑部署到容器技术底座上；
开发过程中若使用消息缓存等能力，是否采用平台提供的消息服务和缓存服务；
以及开发成果是否符合平台加应用前后端分离的构建模式。

这些问题都无法通过单一技术组件解决，必须从系统整体视角来规划云原生架构，才能全面厘清。 云原生架构的另一核心是支撑应用快速开发和上云，这可分为两方面内容：

全新应用可通过低代码开发平台构建，完成对象建模、表单建模、流程建模、规则和权限建模后，快速发布至企业级应用门户。需注意的是，低代码应用开发应采用前后端分离模式——后端开发形成业务组件并构建企业业务能力中心，通过组件API接口的组合编排，最终形成上层SaaS应用门户中的微服务应用。
采用传统方式基于微服务开发框架构建新应用时，必须遵循微服务开发框架规范及**持续集成/持续交付（CI/CD）**规范，并通过自动化流程将开发的微服务组件托管至容器云平台。

这些都是构建完整云原生架构体系必须考虑的关键要素。

因此，这里涉及多个技术底座。首要的是iPaaS融合集成平台，其核心在于底层整合了ESB总线引擎、API网关引擎、消息引擎、文件传输引擎以及大数据集成引擎等多种集成引擎。

在上层，我们构建了融合的服务管控平台，实现对各类集成引擎的统一管理。关于该平台的详细内容，我计划于下周或下下周进行专题直播讲解。

第二个是分布式容器云加技术服务，其核心仍基于Kubernetes加容器实现。然而，熟悉Kubernetes的用户可能注意到，Docker容器未来可能会被废弃。因为在Kubernetes 1.24版本后，引入了符合OCI规范的新容器运行时形式。这一技术底座正是我们所说的DevOps过程平台。

实现完整的CI/CD持续集成、持续部署与持续发布流程，同时整合敏捷研发、敏捷项目管理及技术运营。关于DevOps的具体内容，后续将开设专题直播进行详细讲解。此外，微服务开发框架及其治理机制已为业界所熟知。

基于SpringCloud的微服务开发和治理体系近期进行了多项提升。众所周知，SpringCloud的许多组件已不再维护，因此目前更多采用基于SpringCloud Alibaba的整合框架。该框架集成了Nexus服务注册中心和Sentinel的限流熔断能力，具体细节在此不做展开。