跳至主要內容

云原生架构

云原生是以容器化、微服务、服务网格为核心的技术体系，通过 Kubernetes 实现基础设施的声明式管理，让应用具备弹性伸缩、故障隔离、快速迭代的能力。

提示

容器、Kubernetes、服务网格的云原生技术体系

核心组件

┌─────────────────────────────────────────────────────┐
│  容器化          │  Kubernetes          │  服务网格   │
│  Docker          │  容器编排            │  Istio      │
├─────────────────────────────────────────────────────┤
│  微服务          │  声明式 API          │  可观测性   │
│  Spring Boot     │  YAML 配置           │  Prometheus │
└─────────────────────────────────────────────────────┘

容器

容器是轻量级、可移植的运行时环境，包含应用及其依赖。

特性说明
隔离性进程级别隔离，环境一致
轻量共享宿主机内核，秒级启动
可移植Build Once, Run Anywhere
快速迭代容器镜像版本化管理

Kubernetes（K8s）

Kubernetes 是 Google 开源的容器编排系统，负责容器的部署、扩缩容、负载均衡。

核心概念

概念说明
Pod最小调度单元，一个 Pod 可包含多个容器
Service统一入口，负载均衡 + 服务发现
Deployment声明式部署，管理 Pod 副本数
Namespace资源隔离
ConfigMap/Secret配置管理

核心能力

能力说明
自愈节点故障时自动重启/迁移 Pod
水平扩缩容HPA 根据 CPU/内存自动调整副本
滚动更新零宕机部署，支持回滚
服务发现DNS 自动注册，无需手动配置
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

服务网格

服务网格通过 Sidecar 代理接管服务间通信，实现连接、安全、控制、观测。

服务A → [Envoy Sidecar] → 网络 → [Envoy Sidecar] → 服务B
                      ↓
              自动处理：熔断、重试、负载均衡、mTLS加密

Istio 架构

组件职责
EnvoySidecar 代理，数据面，拦截流量
Pilot控制面，服务发现、流量管理
Citadel证书管理，mTLS 加密

核心能力：流量管理（金丝雀发布、A/B 测试）、安全（mTLS 双向认证）、可观测性（分布式追踪）。

Ambient 模式（2024+）

无需 Sidecar 注入，降低资源开销。Ztunnel 代理节点级流量，Waypoint 处理 L7 策略。

演进路径

单体 → 微服务（Spring Cloud）→ Kubernetes → 服务网格（Istio）
阶段解决的问题遗留问题
Spring Cloud服务治理、配置中心非业务代码占比高
Kubernetes基础设施自动化无法精细化治理
Istio透明的网络治理资源开销、学习成本

云原生架构的服务网格与 流量治理 紧密相关，Istio/Envoy 天然支持限流、熔断、灰度发布。

适用场景

场景推荐方案原因
新建微服务项目Kubernetes + Spring Cloud基础设施自动化 + 应用层治理
已有微服务迁移Kubernetes 逐步容器化降低迁移风险
多团队多服务治理服务网格（Istio）透明治理，无需修改业务代码
资源敏感型项目纯 Kubernetes避免 Sidecar 额外开销

FAQ

Q: Spring Cloud 和 Kubernetes 是替代关系吗？ A: 不是。Spring Cloud 在应用层解决服务治理（配置中心、熔断、网关），Kubernetes 在基础设施层解决部署、扩缩容、服务发现。两者可以共存：用 Kubernetes 管理基础设施，用 Spring Cloud 处理应用层治理。当引入服务网格后，Spring Cloud 的部分能力可以被 Istio 替代。

Q: 什么时候该引入服务网格？ A: 当微服务数量超过 50 个、团队超过 3 个、需要统一的流量治理策略时，服务网格的价值开始显现。小规模项目直接用 Spring Cloud 即可，引入服务网格会增加运维复杂度和资源开销。

Q: 容器和虚拟机有什么区别？ A: 虚拟机通过 Hypervisor 虚拟化整套硬件，每个 VM 运行独立的操作系统，启动时间分钟级；容器共享宿主机内核，通过 Namespace 和 Cgroup 实现隔离，启动时间秒级，资源开销更小。容器更适合微服务场景，虚拟机更适合需要强隔离的场景。