课程十一：云原生

课程十一：云原生基础设施架构演进案例

目标：云原生不仅仅是容器化，更是一整套面向云环境设计的架构思想和技术栈。本课程将追踪基础设施从传统 IDC 到现代云原生架构的演进历程，带你掌握虚拟化、容器化编排、服务网格、无服务器计算、零信任安全、以及混合云管理等核心能力，理解云原生带来的效率、弹性和可靠性变革。

---

阶段 0：史前时代（物理机与 IDC 托管）

场景描述

• 部署方式：应用程序直接部署在公司自购或托管在 IDC 的物理服务器上。
• 资源管理：手动分配服务器资源，静态 IP 地址绑定。
• 运维方式：手动配置、SSH 登录操作、rsync 或脚本部署。

架构示意图

graph TD
    AppA[应用 A] --> Server1(物理服务器 1);
    AppB[应用 B] --> Server2(物理服务器 2);
    User --> AppA;
    User --> AppB;

此刻的痛点：
- 资源利用率极低：服务器资源通常只有 10-20% 被利用，大量资源闲置。
- 扩容周期漫长：需要采购、上架、配置硬件，周期长达数周甚至数月。
- 运维效率低下：环境不一致、手动部署易出错、故障恢复慢。
- 缺乏弹性：无法根据负载动态调整资源。

---

阶段 1：虚拟化引入（拥抱 IaaS）

挑战浮现

• 业务发展需要更灵活的资源调配能力，希望缩短应用上线时间。
• 需要快速创建和销毁测试环境，降低环境成本。

❓ 架构师的思考时刻：如何在不改变硬件的情况下，提高资源利用率和灵活性？

（物理机太浪费了。能不能在一台物理机上跑多个隔离的环境？虚拟机技术是答案吗？怎么管理这些虚拟机？）

✅ 演进方向：引入服务器虚拟化技术与管理平台

1. Hypervisor (虚拟机监控器)：
   • 在物理服务器上安装 Hypervisor 软件（如 KVM, VMware ESXi, Xen）。
   • Hypervisor 允许多个独立的虚拟机 (VM) 在同一台物理机上运行，每个 VM 拥有自己的操作系统和资源（CPU、内存、磁盘、网络）。
2. 虚拟化管理平台 (IaaS 基础)：
   • 引入虚拟化管理平台（如 OpenStack, VMware vSphere 或直接使用公有云的 EC2/ECS 服务）来统一管理计算 (Nova)、存储 (Cinder/EBS)、网络 (Neutron/VPC) 等虚拟资源。
   • 可以实现虚拟机的快速创建、销毁、迁移、快照等操作。

架构调整（引入虚拟化层）：

graph TD
    subgraph "物理层"
        HW1(物理服务器 1);
        HW2(物理服务器 2);
    end
    subgraph "虚拟化层 (Hypervisor)"
        Hyp1(Hypervisor on HW1);
        Hyp2(Hypervisor on HW2);
    end
    subgraph "虚拟机层 (VMs)"
        VM1(VM 1 - OS + App A) --> Hyp1;
        VM2(VM 2 - OS + App B) --> Hyp1;
        VM3(VM 3 - OS + App C) --> Hyp2;
        VM4(VM 4 - OS + App D) --> Hyp2;
    end
    subgraph "管理平台 (可选)"
        Mgmt(OpenStack/vSphere/Cloud Console) -- 管理 --> Hyp1 & Hyp2;
        Mgmt -- 创建/管理 --> VM1 & VM2 & VM3 & VM4;
    end
    User --> VM1;
    User --> VM2;
    User --> VM3;
    User --> VM4;

带来了什么：显著提升了物理资源利用率；资源交付速度从几周缩短到几分钟；具备了一定的灵活性和隔离性。
仍然存在的问题：VM 本身仍然较重（包含完整 OS），启动慢；资源隔离性不如物理机；"虚拟机 sprawl"（虚拟机数量失控）问题；应用打包和环境一致性问题仍未解决。

---

阶段 2：容器化浪潮（Docker + Kubernetes）

新的追求：更轻量、更快速、更一致的环境

• 虚拟机虽然解决了资源利用率问题，但其本身的开销（OS 启动、资源占用）仍然较大。
• 开发、测试、生产环境不一致的问题仍然突出，应用迁移和部署依然复杂。
• 需要更轻量级的隔离技术，更快的部署速度，以及标准化的应用打包和交付方式。

❓ 架构师的思考时刻：有没有比虚拟机更轻量、启动更快的隔离技术？如何标准化应用的打包和运行环境？这么多容器怎么管理？

（Docker 横空出世！容器技术是答案吗？容器和虚拟机的区别是什么？如何编排和调度成百上千的容器？）

✅ 演进方向：采用容器技术 + Kubernetes 容器编排

1. 容器化应用 (Docker)：
   • 使用 Docker 将应用程序及其所有依赖（库、运行时环境）打包成一个轻量级、可移植的容器镜像 (Image)。
   • 容器共享宿主机的操作系统内核，启动速度极快（秒级甚至毫秒级），资源开销远小于虚拟机。
   • 保证了开发、测试、生产环境的高度一致性。
2. 容器编排 (Kubernetes)：
   • 当容器数量增多时，需要一个强大的容器编排系统来自动化容器的部署、扩展、调度、服务发现、负载均衡、故障恢复等。
   • Kubernetes (K8s) 已成为事实上的行业标准。它提供了声明式的 API，用户只需描述期望的应用状态，K8s 会负责将其变为现实。
   • 核心组件包括：API Server (控制中心), etcd (分布式键值存储，保存集群状态), kubelet (节点代理，管理容器), kube-proxy (网络代理), Controller Manager (维护期望状态), Scheduler (负责 Pod 调度)。
3. 容器网络方案：
   • K8s 需要网络插件 (CNI) 来实现 Pod 之间的通信。常用方案包括 Flannel (简单，基于 VXLAN Overlay), Calico (性能好，基于 BGP/IPIP), Cilium (基于 eBPF，功能强大)。

架构调整（K8s 作为基础设施核心）：

graph TD
    subgraph "K8s 控制平面 (Control Plane)"
        APIServer(API Server);
        Etcd(etcd);
        Scheduler(Scheduler);
        ControllerMgr(Controller Manager);
        APIServer <--> Etcd;
        APIServer <--> Scheduler;
        APIServer <--> ControllerMgr;
    end
    subgraph "K8s 数据平面 (Worker Nodes)"
        Node1(Node 1);
        Node2(Node 2);
        NodeN(Node N);
        Kubelet1(kubelet) --> Node1;
        KubeProxy1(kube-proxy) --> Node1;
        CRI1(Container Runtime Docker/containerd) --> Node1;
        Kubelet2(kubelet) --> Node2;
        KubeProxy2(kube-proxy) --> Node2;
        CRI2(Container Runtime Docker/containerd) --> Node2;
        KubeletN(kubelet) --> NodeN;
        KubeProxyN(kube-proxy) --> NodeN;
        CRIN(Container Runtime Docker/containerd) --> NodeN;
        APIServer -- 管理 --> Kubelet1 & KubeProxy1;
        APIServer -- 管理 --> Kubelet2 & KubeProxy2;
        APIServer -- 管理 --> KubeletN & KubeProxyN;
        Scheduler -- 调度 Pod 到 --> Node1 & Node2 & NodeN;
        Kubelet1 -- 创建/管理 --> PodA1(App A Pod 1);
        Kubelet1 -- 创建/管理 --> PodB1(App B Pod 1);
        Kubelet2 -- 创建/管理 --> PodA2(App A Pod 2);
        KubeletN -- 创建/管理 --> PodC1(App C Pod 1);
        %% 网络通信
        PodA1 <--> PodB1;
        PodA1 <--> PodA2;
    end
    User --> K8sService(K8s Service / Ingress);
    K8sService --> PodA1 & PodA2;
    K8sService --> PodB1;
    K8sService --> PodC1;

核心突破：实现了应用的快速部署、弹性伸缩和自动化运维；资源利用率大幅提升 (通常 > 60%)；构建了标准化、可移植的应用交付平台。
新的挑战：微服务架构下，服务间的通信治理（如流量控制、安全、可观测性）变得复杂。

---

阶段 3：微服务治理的复杂度 → 服务网格 (Service Mesh)

挑战浮现：微服务之痛

• 应用被拆分成大量微服务后，服务间的调用关系变得极其复杂。
• 如何实现服务发现？如何进行细粒度的流量控制（如灰度发布、AB 测试）？如何保证服务间通信的安全？如何追踪一个跨多个服务的请求？
• 如果将这些治理逻辑都耦合在业务代码中，会大大增加业务开发的负担和复杂度。

❓ 架构师的思考时刻：如何将服务治理能力从业务代码中解耦出来，下沉到基础设施层？

（能不能用一个代理来拦截所有服务间流量，并在代理上实现治理逻辑？Sidecar 模式可行吗？）

✅ 演进方向：引入服务网格 Istio / Linkerd

服务网格 (Service Mesh) 通过在服务旁部署轻量级网络代理 (Sidecar Proxy)，将服务治理能力下沉到基础设施层：

1. 数据平面 (Data Plane)：
   • 通常使用高性能的 Envoy 或 Linkerd-proxy 作为 Sidecar 代理，部署在每个业务 Pod 中。
   • 所有进出业务容器的流量都被 Sidecar 拦截。
   • Sidecar 负责执行具体的流量规则、安全策略和遥测数据收集。
2. 控制平面 (Control Plane)：
   • 如 Istio (Pilot, Istiod) 或 Linkerd Controller。
   • 负责配置管理：从用户处获取配置（如 K8s CRD），将其转换为 Sidecar 能理解的配置。
   • 服务发现：聚合 K8s 等平台的服务信息。
   • 证书管理：为 Sidecar 动态分发 TLS 证书，保证 mTLS 通信。
   • 策略下发：将流量路由规则、安全策略、遥测配置动态下发给数据平面的 Sidecar。
3. 核心能力：
   • 流量管理：细粒度的路由规则（按 Header/Path/权重）、请求超时、重试、熔断、故障注入。
   • 安全性：自动的 Pod 间 mTLS (双向 TLS 认证加密)、基于身份的授权策略 (AuthorizationPolicy)。
   • 可观测性：自动生成服务间的 Metrics、分布式 Tracing Span、访问日志，无需修改业务代码。

架构调整（引入 Istio 服务网格）：

graph TD
    subgraph "Istio 控制平面 (Istiod)"
        Pilot(Pilot - 配置下发/服务发现);
        Citadel(Citadel - 证书管理);
        Galley(Galley - 配置验证);
    end
    subgraph "K8s Worker Node"
        subgraph "Pod A"
            AppA(App A Container);
            EnvoyA(Envoy Sidecar);
            AppA <--> EnvoyA;
        end
        subgraph "Pod B"
            AppB(App B Container);
            EnvoyB(Envoy Sidecar);
            AppB <--> EnvoyB;
        end
        EnvoyA <--> Pilot -- xDS API (动态配置); 
        EnvoyB <--> Pilot;
        EnvoyA <--> Citadel -- 证书;
        EnvoyB <--> Citadel;
        %% 服务间通信通过 Envoy
        EnvoyA -- mTLS --> EnvoyB;
    end
    User --> IngressGateway(Istio Ingress Gateway - Envoy);
    IngressGateway --> EnvoyA;

解决了什么：实现了服务治理能力与业务逻辑的解耦；提供了强大的流量控制、安全和可观测性能力。
代价：增加了系统的复杂度和资源开销（每个 Pod 都需要一个 Sidecar）。

---

阶段 4：追求极致弹性与成本 → 无服务器架构 (Serverless)

新的需求：按需付费，免运维，事件驱动

• 对于某些负载波动极大、或者偶尔执行的任务（如图片处理、数据转换、定时任务），维护常驻的容器实例可能不够经济高效。
• 希望进一步降低运维负担，开发者只需关注业务逻辑代码，无需关心服务器和容量规划。
• 很多场景是事件驱动的（如文件上传到对象存储后触发处理）。

❓ 架构师的思考时刻：能不能只在代码运行时才付费？能不能完全不用管理服务器？

（函数计算 (FaaS) 是不是个方向？它和容器有什么区别？冷启动问题怎么解决？）

✅ 演进方向：采用 FaaS 平台或 Serverless 容器

Serverless (无服务器) 并不意味着没有服务器，而是指开发者无需管理服务器等底层基础设施：

1. FaaS (Function as a Service)：
   • 开发者只需编写和上传业务逻辑函数（如 AWS Lambda, Google Cloud Functions, Azure Functions, 阿里云函数计算 FC）。
   • 平台负责根据事件触发或 HTTP 请求自动运行函数实例。
   • 按实际执行时间和资源消耗计费，不运行时不付费。
   • 平台自动处理弹性伸缩。
   • 挑战：冷启动延迟（实例首次调用时需要加载代码和环境）、函数执行时长限制、状态管理困难、供应商锁定。
2. Serverless 容器：
   • 一些平台（如 Google Cloud Run, AWS Fargate, Azure Container Instances, Knative）允许用户部署容器镜像，但由平台负责按需启动和伸缩容器实例，并按实际使用资源计费。
   • 结合了容器的灵活性和 Serverless 的弹性、免运维特性。

架构对比（Serverless vs K8s）：

特性	Kubernetes 方案 (容器)	Serverless 方案 (FaaS/容器)	说明
运维复杂度	高	低	Serverless 无需管理 OS、Runtime、实例
弹性伸缩速度	分钟级/秒级	秒级/毫秒级 (可能有冷启动)	Serverless 伸缩更迅速，但冷启动影响首调延迟
计费模式	按节点资源付费	按实际执行/请求付费	Serverless 更适合波动大或低频负载
控制粒度	高	低	K8s 可精细控制网络、存储、资源等
供应商锁定	相对较低	较高 (特别是 FaaS)	K8s 生态更开放

架构示例（事件驱动 FaaS）：

graph TD
    User -- 上传图片 --> S3(对象存储 S3/OSS);
    S3 -- 触发事件 --> EventBridge(事件总线 EventBridge/MNS);
    EventBridge -- 触发 --> Lambda(函数计算 FaaS - 图片处理函数);
    Lambda -- 处理结果存入 --> DynamoDB(NoSQL 数据库 DynamoDB/TableStore);

适用于：事件驱动的任务、API 后端、定时任务、对延迟不极其敏感的 Web 服务。

---

阶段 5：边界消失，内网不再可信 → 零信任架构 (Zero Trust)

安全挑战：传统边界防护失效

• 云原生和混合云环境下，应用和服务部署分散，传统的基于网络边界（防火墙、VPN）的安全模型变得脆弱。
• 一旦攻击者突破边界进入内网，往往可以横向移动，访问大量内部资源。
• 需要一种"从不信任，总是验证"的安全理念。

❓ 架构师的思考时刻：如何在没有明确网络边界的环境下保证安全？如何对每次访问都进行认证和授权？

（内网也不能随便信了。每次访问都要验明正身？怎么验证？基于什么授权？）

✅ 演进方向：实施零信任安全模型 (Zero Trust Architecture - ZTA)

零信任的核心原则：默认不信任任何用户、设备或网络位置，每次访问都需要经过严格的认证和授权。

1. 强身份认证 (Strong Identity Verification)：
   • 不仅仅是用户名密码，需要多因素认证 (MFA)。
   • 对设备也要进行认证（如检查设备健康状态、证书）。
   • 使用统一的身份提供商 (IdP)（如 Okta, Azure AD, Google Identity Platform）进行管理。
2. 最小权限原则与动态授权 (Least Privilege & Dynamic Authorization)：
   • 用户和设备只被授予完成其任务所必需的最小权限。
   • 权限是动态评估的，基于用户身份、设备状态、访问位置、请求上下文等多重因素。
   • 使用策略引擎 (Policy Engine) (如 OPA - Open Policy Agent) 和 策略决策点 (PDP) 来集中管理和执行访问策略。
3. 微隔离 (Micro-segmentation)：
   • 通过网络策略（如 K8s NetworkPolicy, Istio AuthorizationPolicy）或主机防火墙，限制服务之间的网络访问，即使在同一网络内部，也只允许必要的通信。
4. 访问代理 (Access Proxy)：
   • 所有对资源的访问都必须通过一个策略执行点 (PEP - Policy Enforcement Point)，通常是访问代理（如 Google 的 BeyondCorp Remote Access, Cloudflare Access, 或者 Istio Ingress/Egress Gateway 结合授权策略）。代理负责验证身份、评估策略并强制执行访问控制。

零信任架构示意图：

graph TD
    User & Device -- 1. 访问请求 --> PEP(策略执行点 Access Proxy);
    PEP -- 2. 请求认证 --> IdP(身份提供商 Okta/Azure AD);
    IdP -- 3. 返回认证结果 --> PEP;
    PEP -- 4. 请求授权 (携带身份/设备/请求信息) --> PDP(策略决策点 Policy Engine);
    PDP -- 5. 评估策略 --> PEP;
    PEP -- 6. (若授权) 代理访问 --> Resource(受保护资源 App/DB);
    PDP -- 持续获取 --> Context(上下文信息 设备状态/位置/风险);
    Admin -- 定义策略 --> PDP;
    Resource <-- 微隔离策略 --> Resource;

实现了：更精细、动态的安全控制，降低了内部威胁和横向移动的风险，适应了云原生和远程办公的趋势。

---

(可选) 阶段 6：多云与混合云的统一管理 → Anthos / Azure Arc

挑战：跨云管理复杂性

• 企业可能因为成本、容灾、技术栈等原因，同时使用多个公有云或私有云环境（混合云/多云）。
• 如何在这些异构环境中获得一致的部署、管理和运维体验？如何统一管理 K8s 集群？如何实施一致的安全策略？

❓ 架构师的思考时刻：如何屏蔽底层云的差异，实现跨云的统一控制？

（能不能用一个平台管理所有地方的 K8s？策略和配置怎么同步？）

✅ 演进方向：采用混合云/多云管理平台

一些云厂商和第三方提供了混合云/多云管理平台，旨在提供统一的控制平面：

1. 统一 Kubernetes 集群管理：
   • 如 Google Anthos, Azure Arc for Kubernetes, AWS EKS Anywhere, Rancher 等。
   • 允许将不同环境（公有云、私有云、边缘）的 K8s 集群注册到统一的管理平台。
   • 提供统一的集群生命周期管理、监控和日志视图。
2. 配置和策略的集中管理与同步：
   • 使用 GitOps 的方式（如 Flux CD, Argo CD）结合平台的配置管理功能（如 Anthos Config Management, Azure Arc GitOps）将应用配置、K8s Manifest、安全策略等存储在 Git 仓库中。
   • 平台自动将 Git 仓库中的配置同步并应用到所有纳管的集群，保证环境的一致性。
3. 跨集群服务网格：
   • 一些平台（如 Anthos Service Mesh）支持构建跨越多个 K8s 集群的服务网格，实现跨集群的服务发现、流量管理和安全策略。

混合云管理架构示意：

graph TD
    subgraph "统一控制平面 (Anthos/Azure Arc...)"
        MgmtConsole(管理控制台);
        FleetMgmt(集群注册与管理);
        ConfigSync(配置同步 GitOps);
        PolicyCtrl(统一策略管理);
        ServiceMeshCtrl(跨集群服务网格控制平面 可选);
        MgmtConsole --> FleetMgmt & ConfigSync & PolicyCtrl & ServiceMeshCtrl;
        GitRepo(Git 仓库 - 配置/策略) --> ConfigSync;
    end
    subgraph "On-Premise K8s 集群"
        K8s_OnPrem(K8s Cluster);
        Agent_OnPrem(平台 Agent) --> K8s_OnPrem;
        Agent_OnPrem <-- 连接 --> FleetMgmt & ConfigSync & PolicyCtrl;
    end
    subgraph "Cloud A K8s 集群"
        K8s_CloudA(GKE/EKS/AKS...);
        Agent_CloudA(平台 Agent) --> K8s_CloudA;
        Agent_CloudA <-- 连接 --> FleetMgmt & ConfigSync & PolicyCtrl;
    end
    subgraph "Cloud B K8s 集群"
        K8s_CloudB(GKE/EKS/AKS...);
        Agent_CloudB(平台 Agent) --> K8s_CloudB;
        Agent_CloudB <-- 连接 --> FleetMgmt & ConfigSync & PolicyCtrl;
    end
    %% 服务网格跨集群通信 (可选)
    K8s_OnPrem <-- Istio Gateway --> K8s_CloudA;
    ServiceMeshCtrl -- 控制 --> K8s_OnPrem & K8s_CloudA;

提供了：跨异构环境的一致管理体验，简化了混合云/多云场景下的运维和治理。

---

云原生技术决策考量

场景/需求	推荐技术栈/模式	考虑因素
提高资源利用率/快速部署	容器化 (Docker + K8s)	学习曲线、运维复杂度
微服务治理复杂度高	服务网格 (Istio/Linkerd)	性能开销、控制平面复杂度
事件驱动/负载波动大	Serverless (FaaS/容器)	冷启动延迟、供应商锁定、状态管理
提升安全性/适应混合云	零信任架构 (ZTA)	改造复杂度、用户体验影响
管理多云/混合云环境	混合云管理平台 (Anthos/Arc)	成本、供应商锁定、平台成熟度

---

演进路线总结：基础设施的云原生之路

阶段	代表技术	核心价值	解决的核心问题
0. 物理机	IDC 托管 / 裸金属服务器	物理隔离 (但低效)	(无，起点)
1. 虚拟化	KVM/VMware, OpenStack/vSphere	资源池化，提高利用率，初步灵活	物理资源浪费，交付慢
2. 容器化	Docker, Kubernetes	标准化交付，快速部署，弹性伸缩	VM 笨重，环境不一致，运维复杂
3. 服务网格	Istio, Linkerd, Envoy	服务治理下沉，流量/安全/可观测性	微服务治理逻辑与业务代码耦合
4. Serverless	AWS Lambda/FaaS, Cloud Run/Knative	按需付费，免运维，事件驱动	资源闲置成本，运维负担，事件处理复杂
5. 零信任	BeyondCorp, IdP, OPA, mTLS	动态授权，降低内部风险	传统边界安全失效，内网横向移动风险
6. 混合云管理	Anthos, Azure Arc, Rancher	跨云统一管理，一致性体验	多云/混合云环境管理复杂

---

深度实践与思考

1. 性能基准测试：对比 KVM 虚拟机、Docker 容器、Serverless 函数的冷启动时间、资源占用和网络性能。
2. 服务网格能力验证：使用 Istio 实现金丝雀发布、请求超时/重试、mTLS 加密，并通过 Kiali 可视化流量拓扑。
3. Serverless 场景模拟：构建一个由 API Gateway + Lambda + DynamoDB 组成的简单 Serverless 应用，测试其弹性伸缩能力。
4. 零信任策略实践：尝试使用 OPA (Open Policy Agent) 或 K8s NetworkPolicy 实现基本的微隔离策略。
5. 成本分析：估算在不同阶段（VM, K8s, Serverless）运行相同负载的成本差异。

掌握云原生基础设施的演进，核心是理解其背后的设计哲学：通过标准化、自动化、弹性化、服务化的方式，最大化地利用云的能力，提升应用交付的效率、可靠性和安全性。