【摘要】大部分人对云原生的认识仅限于容器、微服务、DevOps等内容，把容器、微服务、 DevOps就等同于云原生，这显然是不对的。本文梳理了云原生架构体系内容并对重点概念进行了解读，希望对读者有所帮助。

云原生（Cloud-Native）的概念在国内提及的越来越多，但大部分人对云原生的认识仅限于容器、微服务、DevOps等内容，把容器、微服务、 DevOps就等同于云原生，这显然是不对的。CNCF从其自身的角度定义了云原生技术：云原生技术使企业能够在现代动态环境中构建和运行可扩展的应用程序，如在公共云、私有云和混合云环境中。包括容器、服务网格、微服务、不变的基础设施和声明式API等。采用这些技术可实现系统的松散耦合性、弹性、可管理性和可观察性等。也可以与自动化相结合，实现以最少的工作量频繁地、可预测地进行重大影响的功能的变更。

云计算提供了敏捷的、自服务的、不变的基础设施等内容，使业务应用上云逐渐成为一种共识，但不进行云原生架构重构而直接上云可能是危险的，传统业务应用架构无法在云上进行弹性扩展和敏捷响应，无法有效利用云计算的特性赋能企业。所以这可能需要对传统架构的业务系统进行分布式微服务分拆重构，部署运行在容器云平台等之中，使用DevOps思想，通过CI、CD等持续提升交付效率，等等。使应用从一开始被创建就具备云的特性，为云而生，它是为了充分利用云计算的分布式和弹性扩展等特征，使其具备或适应云上部署运行的要求，或者直接用云的思想、方法、工具在云中创建，天生具备云的特性。所以云原生可以认为是一种基于云来构建和运行云应用程序的方法论和技术体系，使用云原生技术和方法论来构建和运行管理云应用。

Matt Stine在2015年发表《迁移到云原生架构》一书中定义了符合云原生架构的特征：12要素应用、微服务、自服务敏捷基础设施、基于API协作、扛脆弱性等。云原生体系内容没有明确的定义，不过通常认为云原生技术体系和方法论包括微服务、容器、DevOps、持续交付、ServiceMesh、不可变基础设施、声明式API、混沌工程、安全、基于移动的客户体验等内容 。

图 1 云原生技术体系

十二个要素应用为云原生应用的设计提供了原则指导；微服务架构为云原生应用架构设计、分布式部署、敏捷变更等提供了方案；容器则为云原生应用提供了弹性伸缩、一致性环境等能力，和微服务结合，支撑应用随需扩展；自服务敏捷基础设施则提供了云原生应用持续交付的基础设施资源等保障，可以和容器化PaaS平台共同支撑云原生应用的自动化弹性扩展、可视化监控、自动化智能化运维运营等，使用户无需关注基础设施资源，无需运维基础设施资源，无需关注应用部署位置等；服务网格支撑着服务的管理和治理；混沌工程则持续增强系统的韧性和稳定性；DevOps优化组织间的协同，满足彼此的关切，指导C ICD的落地和持续交付，实现应用全生命周期管理；声明式 A PI则实现了服务标准化发布和服务之间的协同；安全则涉及云原生架构体系的方方面面，比如 D evOps安全 D evSecOps、容器镜像安全、网络安全、应用安全、 A PI安全、认证授权、访问控制等等；所有这些技术和方法、原则满足客户随时随地随需的需求，简化客户操作，提升客户体验。

基于对云原生架构体系的学习和理解，笔者觉得一个相对完整的云原生架构体系内容包括如图中的内容：

图 2 云原生架构体系

随着移动通信技术的发展和移动设备的普及，人们的工作、生活、社交、投资等方式发生了显著的变化。当前人们通过手机基本上可以随时随地满足需求。用户可能在不同的时间（ 7x 24）通过不同终端、不同操作系统、不同版本、不同地方等访问业应用系统，这就要求不仅仅是APP客户端操作便利、交互友好，也要求后端服务和系统能够敏捷响应。手机 App 应用 的体验好坏可能直接决定着用户是否继续使用它。在移动互联时代，用户移动化体验需求是应用设计的 关键驱动因素 。

云应用12要素描述了一种云应用原型，是一种云应用（可独立部署的单元）设计原则和方法论。它通过强调声明式配置、水平扩展的无状态/无共享进程，以及与部署环境的整体松耦合，来关注速度、安全性和可扩展性。Kevin Hoffman 于《Beyond the 12-factor App》中重新描述并扩展了云原生应用的12因素并增加API优先 、遥测、认证和授权三个要素。新增的要素糅合了API协同、可视化监控、安全性等内容，在指导云原生应用的设计方面更加完善。

微服务架构是一种应用分布式架构方式，它将单体巨石应用拆分为若干个单一能力的可独立部署的服务，就是微服务。通常一个微服务代表一种业务能力，或是提供业务价值的最小的“原子”服务单元。它解决了紧耦合的单体巨石系统难以变更难以更新的问题，实现轻量、敏捷变更。

图 3 单体架构演化到微服务架构

中台本质也是一种架构方式，其核心是实现复用。中台一直被当作是一种企业架构，没有很明确讨论复用的粒度，所以其落地没有明确的方式方法和标准。从应用架构角度来说，中台和应用的前、中、后端层次划分没有本质区别，算不上一种新的架构方式。微服务分解架构从横向将系统进行分解，中台分层架构从纵向将系统分层，从而实现微服务在不同层次的复用和共享。从单个应用系统扩展到企业所有的系统，最终可以融合成一个分层分解的企业级系统，这就是笔者一直所提的 “ 系统融合 ” 思路。

容器是一种内核轻量级的操作系统层虚拟化技术，在流程级别提供隔离，为单一的应用程序提供运行一致的运行环境。每个应用程序及其环境都可以在隔离的环境中运行。容器特性和微服务架构非常契合，因此微服务通常部署在容器中，实现敏捷部署、自动化弹性伸缩、环境一致性等能力。但容器依然是相对底层的运行单元，众多容器的管理和治理是个难题。Kubernetes（也称为K8s）是一个开源容器管理和调度框架，用于自动化容器应用程序的部署、扩展和管理。它将构成应用程序的容器分组到逻辑单元中，以便于管理和发现。容器云平台是采用容器和容器管理及调度技术而构建的应用管理部署运行平台，支持不同租户的容器应用管理和治理能力。基于容器云而把日志、监控、认证、权限、配置、中间件、工具平台，以及算法等统一部署维护，提供企业级平台服务能力，构建轻量化P aaS平台，结合自动化、智能化实现自服务敏捷响应基础设施能力。

图 4 容器云架构

云原生的核心是云原生应用。自服务敏捷响应基础设施为云原生应用的自动化环境准备、构建、部署、监控、反馈、健康检查、故障自愈、资源调度、弹性伸缩、动态路由和负载均衡等提供支撑， 实现自主服务平台进行云原生应用的部署和运行，使配置管理自动化、基础设施资源透明，无需关注应用运行在什么地方；将IaaS和PaaS最终融合在一起，提供更流畅的、一致的体验；企业内部可通过基础设施资源管理（多云管理平台）实现异构资源的管理，统一的资源服务；实现持续交付，提升可用性、可扩展性、可管理性。

DevOps是一种理念和方法论，目的是为了协调和理顺开发和运维团队之间的关切，提升协作效率。DevOps旨在实现开发运维一体化，通过自动化、智能化等工具实现应用全生命周期管理和组织之间的高效协同。基于D evOps方法论和理念所构建的平台也称为 D evOps平台，通常要用自动化流水线等实现持续集成 C I、持续交付CD等能力。Google SRE是DevOps的一种具体实践，它通过系统工程的思想来解决软件工程的问题， 使运维自动化和智能化。运维人员不低于 5 0%的时间做运维工具的研发，让研发人员专注于业务应用的研发。Google SRE使用错误预算来协调研发和运维之间的关切，一旦错误预算用尽，则运维将拒绝业务应用的发布部署，从而使研发要关注业务应用的稳定性和健壮性。

服务网格（ServiceMesh ）实现微服务东西向流量的管理和治理。其区别于API网关对服务南北向流量的管理和治理。其通常应用于容器环境，以sidecar的方式代理流量管理、可观测性和安全能力。服务网格总体架构由流量代理组件和管理组件组成， 代理组件被称为数据平面，直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。管理组件被称为控制平面，负责与代理通信，下发策略和配置。笔者一直跟踪着服务网格发展但一直没有采用，原因在于一方面感觉其不够成熟，另一方面其加层的方式会带来延迟，和笔者推崇的简单方式解决复杂问题思路有悖。

抗脆弱性由Naasim Taleb在《Antifragile》书中提出，将故障随机注入到生产环境中，目的是为了识别和消除架构中的缺陷，找到应用架构中的弱点，并强制进行修复，架构会随着时间的推移而变得强壮，提升其稳定性、可用性、耐久性等。在国内也称之为混沌工程（Chaos Engineering）。中国信通院于2 020年开始组织 进行混沌工程技术研究，提出了应用混沌工程方法来验证云原生系统的韧性架构，同时成立混沌工程项目组。2 021年 发布《混沌工程测试平台能力》标准纲要，并发布行业标准《混沌工程平台能力要求》。

云原生应用之间的交互是通过已发布和版本化的API来实现的，通常采用HTTP Rest 风格序列化JSON数据。通过API 可以提供一层可重用接口层。同时API封装了业务逻辑内部细节，消费者不能直接访问API服务内部数据，也在一定程度上增强了数据安全。

安全是任何系统不可或缺的部分。风险无处不在，云原生架构体系中内容众多，每个组件每个服务都可能带来风险和安全问题（因此要通过 “ 减层 ” 方法最小化组件和服务，严格遵循 “ 非必要不采用原则 ” ）。从云原生应用生命周期过程来说，云原生安全可以简单分为 “ 设计时安全 ” 和 “ 运行时安全 ” 两段。设计时以静态检测分析为主，比如代码分析、镜像漏洞扫描等；运行时以动态和交互式检测、防护、分析为主，比如入侵检测、病毒查杀、网络微隔离等。云原生安全可以利用传统的安全技术和方法，比如认证授权、访问控制、加密解密、合规检测、静态安全检测、动态安全检测、网络隔离等等，重点是通过可用的安全机制增强云原生安全能力。虽然我们提倡安全左移，尽可能将安全风险消除在设计时段，但运行时安全一样不可少，安全漏洞随时都可能出现，采用微服务、容器的云原生架构也为运行时带来了更多的风险点，安全防控更加不易。需要不断提升系统可见性、错误隔离等能力提升安全管控能力。云原生安全和传统网络安全的分安全域模式不同，它需要动态的自动化和智能化的管控能力。云原生未来可能逐渐通过软件定义边界、增强的身份认证、微隔离等技术实现动态的网络安全管控。

云原生架构体系内容比较庞大，深入到每一个部分都有很多的工作。不过在对云原生体系架构和体系内容有全面的了解之后，认识到彼此之间的联系和局限，才能真正构建满足客户需求、支持移动化随时随地随需的服务、具备云计算特性弹性扩展、敏捷响应、安全稳定的云原生应用。