1. 云原生基础
1.1 发展背景与十二要素
云原生依托云计算发展而生，定义应用标准化构建、运行、运维规范，包含十二核心要素：
- 基准代码：一份代码，多环境部署
- 依赖：显式声明所有依赖项
- 配置：配置信息存放于运行环境，与代码分离
- 后端服务：将数据库、中间件等后端服务作为外部资源调用
- 构建 / 发布 / 运行：三个阶段严格分离，流程解耦
- 进程：以无状态进程运行应用，数据外置
- 端口绑定：通过端口对外暴露服务
- 并发：依靠进程横向扩容实现并发能力
- 易处理：快速启动、优雅终止，提升系统健壮性
- 环境等价：开发、测试、预发、生产环境尽量保持一致
- 日志：以事件流形式统一采集、处理日志
- 管理进程：后台运维管理任务以一次性进程执行
1.2 DevOps 理念
- 定位：开发、运维、质量保障三者融合模式，融合安全理念
- 核心：安全责任全员化，安全贯穿应用全生命周期，覆盖研发、测试、运维、安全团队
2. 云原生技术架构
2.1 代码组成结构
- 业务代码：核心，实现业务逻辑，直接创造业务价值
- 三方软件：各类依赖第三方库、组件
- 非功能代码：实现高可用、安全、可观测等非业务能力
- 设计思路：非功能性特性尽量外部委托，剥离出业务代码
2.2 核心设计原则
- 服务化：面向接口编程，提升复用性与水平扩展能力
- 弹性：资源随业务量自动扩缩容，无需固定资源规划
- 可观测：依托日志、链路追踪、指标，主动监控分布式系统全链路状态
- 韧性：组件异常时系统具备故障抵御、容错能力
- 全流程自动化：交付、运维、管控全流程自动化
- 零信任：不以网络、IP、地理位置作为信任依据，以身份为核心做访问控制
- 架构持续演进：架构动态迭代，保持开放性与适配性
2.3 主流架构模式
- 服务化架构：微服务、小服务（适配超大型系统，减少调用损耗）
- 服务网格（Mesh）架构
- 无服务（Serverless）架构
- 存储计算分离架构
- 分布式事务架构
- 可观测架构：日志 Logging、链路追踪 Tracing、指标 Metrics，支撑 SLO/SLA 管控
- 事件驱动架构（EDA）：基于事件 Schema 校验，具备 QoS 与失败重试能力
- 补充：分布式系统遵循 CAP 理论（一致性、可用性、分区容错性）
2.4 云原生架构优势
- 高可扩展性：服务独立扩缩容，适配业务波动
- 高可用性：多节点部署、负载均衡、容错，规避单点故障
- 灵活性：服务可选用不同技术栈，独立部署运维
- 安全性：容器隔离降低漏洞风险，自动化减少人为失误
- 成本效益：提升资源利用率，降低整体运维成本
- 高度自动化：依托 PaaS 实现资源、部署、运维自动化
3. 云原生建设规划（五步实施路线）
整体思路：顶层规划 + 分步实施 + 迭代优化
3.1 第一步：微服务改造 + 容器云平台搭建
完成应用微服务拆分，搭建容器运行环境，支撑微服务落地。
3.2 第二步：服务管理与治理
完善 API 规范、服务注册发现、服务编排、服务监控等治理能力。
3.3 第三步：持续交付与安全体系建设
- 以 DevOps 为核心，搭建 CI/CD 闭环流水线
- 全链路安全管控：代码、镜像、容器、应用、接口、系统安全；完善身份认证与权限体系
3.4 第四步：自服务敏捷基础设施建设
统一封装异构资源，搭建技术中台，提供自服务能力：
- 基础设施资源：多云管理、资源统一调度
- 支撑平台：容器平台、持续交付平台
- 通用技术组件：日志、监控、告警、消息、AI、认证授权等公共服务
3.5 第五步：强化生产环境韧性与安全
- 引入混沌工程（抗脆弱性试验），主动注入故障挖掘隐患并修复
- 持续迭代安全策略，动态防御各类攻击与漏洞
4. 云原生实践案例
4.1 整体解决方案
应用容器化、业务微服务改造、引入云原生数据库，基于 Kubernetes 构建云原生 PaaS 平台。
4.2 PaaS 平台核心优势
- 打通 DevOps 全流程闭环
- 多环境统一，环境一致性高
- 容器天然隔离，硬件资源利用率高
- 精细化流量管控
- 集成日志、链路追踪、指标监控能力
- 接口统一，支持多云 / 混合云部署
4.3 落地效益
降本增效、提升系统稳定性、提升研发运维效率、全面赋能业务发展。
云原生发展背景，概念，要素名称（简介）基准代码（一份基准代码、多份部署）依赖（显式生命依赖关系）配置（在环境中存储配置）后端服务（把后端服务当作附加资源）构建、发布、运行（严格分离构建、发布和运行）进程（以一个或多个无状态进程运行应用）端口绑定（通过端口绑定提供服务）并发（通过进程模型进行扩展）易处理（快速启动和优雅终止，最大化健壮性）开发环境与线上环境等价（尽可能保持开发、预发布、线上环境相同）日志（把日志当做事件流）管理进程（把后台管理当作一次性进程运行）
发展概念，devops可以看作开发、技术运营和质量保障三者的交集，devops是一种融合了开发、安全和运营理念的全新的安全管理模式，其核心理念是在业务应用生命周期的每个环节（尤其在软件开发周期的每个阶段）都需要为安全负责，安全是整个IT团队（包括开发、测试、运维及安全团队）所有成员的责任，并且需要贯穿从研发到运营的全过程
云原生技术架构，架构定义，云原生的代码通常包括三部分，业务代码，三方软件、处理肺功能特性的代码，其中业务代码是指实现业务逻辑的代码，三方软件是业务代码中依赖的所有三方库，包括业务库和基础库，处理非功能特性的代码指实现高可用、安全、可观测等非功能性能力的代码，三部分中只有业务代码是核心，是真正给业务带来价值的，另外两个部分只是附属物。非功能性特性大量委托，任何应用都提供两类特性，功能性特性和非功能性特性，功能性特性是真正为业务带来价值的代码比如建立客户资料、处理订单、支付等，即使是一些通用的业务功能特性，比如组织管理、业务字典管理、搜索等也是紧贴业务需求的，非功能性特性是没有给业务带来直接业务价值，但通常又是必不可少的特性，比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布功能等
设计原则，常见的原则主要包括服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进等，服务化原则，服务化架构采用的是面向接口编程方式，增加了软件的复用程度，增强了水平扩展的能力，弹性原则，弹性原则是指系统部署规模可以随着业务量变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源，可观测原则，可观测性更强调主动性，可观测性是在云这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次第三方软件调用、sql请求、节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化，韧性原则，韧性代表当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，所有过程自动化原则，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整体软件交付和运维的自动化，零信任原则，其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证，零信任对访问控制进行了范式上的颠覆，引导安全体系架构从网络中心化走向身份中心化，其本质诉求是以身份为中心进行访问控制，零信任的第一个核心问题就是身份，架构持续演进原则，云原生架构本身也必须是一个具备持续演进能力的架构，而不是一个封闭式架构，软件世界是不断变化的，它是动态而非静态的存在
架构模式，常用的架构模式主要有服务化架构、mesh化架构、serverless、存储计算分离、分布式事务、可观测架构、事件驱动架构等，服务化架构模式，服务化架构的典型模式是微服务和小服务模式，其中小服务可以看作一组关系非常密切的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的应用系统，避免接口的颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度，存储计算分利模式，CAP（一致性，consistency，可用性，availability，分区容错性，partition tolerance）可观测架构模式，可观测架构包括logging、tracing、metrics三个方面，logging提供多个级别（verbose/debug/warning/error/fatal）的详细信息跟踪，由应用开发者主动提供，tracing提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用，metrics则提供对系统量化的多维度度量。由于建立可观测性的主要目标是对服务等级目标（slo）进行度量，从而优化sla（服务级别协议）因此架构设计上需要为各个组件定义清晰的slo，包括并发度、耗时、可用时长、容量等，事件驱动架构模式，事件和传统的消息不同，事件交由schema，所以可以校验event的有效性，同时eda具备qos保障机制，也能够对事件处理失败进行响应
架构优势，云原生架构相比于传统架构具有更高的可扩展性、可用性、灵活性、安全性、成本效益和高度自动化等优势，高可扩展性，云原生架构的微服务可以独立部署和扩展，可以根据业务需求快速增加或减少服务实例，这种可扩展的架构模式可以满足业务快速发展的需求，提高应用程序的可靠性和性能，高可用性，云原生架构的微服务可以分布在多个节点上，可以实现负载均衡和容错处理，这种可用的架构模式可以提高应用程序的稳定性和可用性，减少单点故障的风险，灵活性，云原生架构的微服务可以独立部署和管理，可以使用不同的编程语言和技术栈，这种灵活的架构模式可以满足不同业务场景和需求的要求，提高应用程序的适用性和可维护性，安全性，云原生架构使用容器化技术来隔离不同的微服务，可以减少安全漏洞的风险， 同时，云原生架构使用自动化工具来管理和部署微服务，可以提高安全性和可靠性，减少人为错误的风险，成本效益，云原生架构可以提高应用程序的可靠性、可扩展性和安全性，同时可以减少运维成本和时间，这种成本效益的架构模式可以为组织带来更高的roi和竞争优势，高度自动化，云原生架构可以与基础设施深度整合优化，将计算、存储、网络资源管理以及自动化部署和运维能力交给云上paas来落地，如此应用本身会更灵活，具备弹性和韧性，降低技术管理成本
云原生建设规划，根据云原生架构体系的技术之间的关系和实际经验，基于顶层规划+分步实施的原则，将云原生架构规划实施路线图定义为五个步骤，分别为微服务采用及运行环境容器云平台构建，服务管理和治理，持续交付及安全，自服务敏捷响应基础设施，增强生产环境韧性和安全性，每个实施步骤又可以根据实际建设需要分为若干个子项目，并可能需要多次迭代，1微服务采用及运行环境容器云平台构建，云原生架构体系中，应用是交付业务价值的载体，而微服务是构建业务应用的技术，经微服务架构分解的应用服务运行在容器中，所以第一步在采用微服务的同时需要构建容器环境支撑微服务的运行，服务管理和治理，在完成容器云平台运行时支撑建设之后，可以侧重实现服务的治理和api的定义，以支持高效的管理和敏捷的服务编排响应，同时实现基于API的协同，持续交付及安全，以devops理论为指导，构建持续集成、持续部署、持续交付、持续监控、持续反馈的闭环流程，认证和权限是devops体系中的基础安全措施，代码安全检查，镜像安全检查，系统安全、应用安全、接口安全、容器安全等都需要在devops工具链和流水线实施及使用过程中逐步完善，以提升云原生的整体安全性，自服务敏捷响应基础设施，基础设施大致可以划分为三个部分，基础设施资源、职场平台和纯技术工具，基础设施资源可能有很多种异构资源和云平台，需要通过统一的层次（比如多云管理平台）来封装，提供统一的基础设施资源服务，隔离底层异构资源细节，简化应用资源调度，支撑平台主要是微服务开发、运行、运维的平台，例如持续交付平台、容器云平台等，纯技术工具指的事和业务无关、围绕支撑平台周边的工具，比如消息平台（rabbitmq，kafka）、监控平台、权限管理平台、认证平台、人脸识别平台等，这些平台可以提取构建技术中台能力，各业务应用都可以复用这些能力，在实施持续交付的同时，也是在部分构建自服务敏捷响应基础设施能力，比如持续集成、持续交付流水线等，在这个步骤中，需要重点构建和完善自动化、自服务的基本设施能力，包括统一身份认证和权限服务、日志服务、配置服务、监控服务、告警服务、安全服务、ai服务（人脸识别、文字识别、图像识别、语音识别、自然语言处理、知识图谱、算法等）消息服务、调度服务等基础服务和CI/CD研发流程服务等，实现这些服务的自服务能力是构建应用敏捷响应的关键，基础设施资源的自服务敏捷响应式所有这些服务实现敏捷响应的前提，增强生产环境韧性和安全性，脆弱性的反面是健壮性、韧性，抗脆弱性（反脆弱性，antifragility）的目的就是持续定时或不定时通过在运行环境中注入故障的方式来主动找到弱点，并强制修复这些弱点，从而提升环境的健壮性和韧性，通过抗脆弱性试验持续增强环境的韧性，安全能力建设也是系统抗脆弱性的一部分，安全措施是防御性的，而系统是持续变化之中的，随时可能出现不可预知的漏洞，因此除了在开发设计时尽可能消除安全隐患，在运行时的安全措施也一样不能少，而且是持续性的，所以需要不断地改进安全举措，持续增强抗击漏洞攻击等行为
云原生实践案例，解决方案，引入云原生数据库，应用容器化，微服务改造，架构确立，平台层，基于kubernetes打造的云原生paas平台优势明显，主要包括，打通devops闭环，统一测试、集成、预发、生产环境，天生资源隔离，机器资源利用率搞，流量接入可实现精细化管理，集成了日志、链路诊断，metrics平台，统一APIserver接口和扩展，支持多云及混合云部署，应用效益，该公司通过使用云原生架构，其应用效益主要体现在成本、稳定性、效率、赋能业务等方面
典型四层架构（自上而下）：界面交互层（表现层）、业务处理层（逻辑层/应用层）、数据处理层（数据访问/服务层）、数据存储层（持久层）
云资源规划的基本流程，确定云资源需求、预算分配、购买资源、资源分配、监控和维护
