Appearance
本模块聚焦云原生架构全景，从云原生概念到服务网格、API网关、Serverless 及架构设计原则，全面考察候选人对云原生技术体系的理解深度和架构视野。
Q1: 什么是云原生？CNCF定义的云原生技术栈有哪些？ 「🟡 中级」
考察点：考察云原生核心概念和技术全景，筛掉对云原生理解片面、只知道容器和K8s的人。
参考答案：
- 云原生（Cloud Native） 是一种构建和运行应用的方法论，充分利用云计算模型的优势（弹性、分布式、按需付费），让应用从设计之初就适应云环境，实现快速迭代、弹性伸缩和高可用。
Pivotal（云原生概念提出者）的定义 - 云原生四要素：
- 微服务（Microservices）：将单体应用拆分为小而独立的服务，每个服务独立开发、部署和扩展。
- 容器化（Containerization）：应用打包在容器中运行，提供环境一致性和轻量隔离。
- DevOps：开发和运维协同，通过自动化工具链实现持续交付和快速迭代。
- 持续交付（Continuous Delivery）：代码随时可以发布，小步快跑，快速反馈。
CNCF（云原生计算基金会）的定义：
- 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。
- 云原生的代表技术包括：容器、服务网格、微服务、不可变基础设施和声明式 API。
CNCF 云原生技术栈全景图（Landscape）主要层级：
1. 运行时层（Runtime）：
- 容器运行时：containerd、CRI-O、rkt。
- 云原生存储：Rook、Ceph、Longhorn、OpenEBS。
- 容器网络：Calico、Cilium、Flannel、Weave Net。
2. 编排与管理层（Orchestration & Management）：
- 调度与编排：Kubernetes（核心）。
- 服务网格：Istio、Linkerd、Kuma。
- 服务发现与协调：CoreDNS、etcd、Consul。
- 远程过程调用：gRPC、Apache Thrift。
- 服务代理：Envoy、HAProxy、Nginx。
- API 网关：Kong、APISIX、Traefik。
3. 应用定义与开发层（App Definition & Development）：
- 数据库：Vitess、TiDB、CockroachDB。
- 流式与消息：Kafka、RabbitMQ、NATS。
- 应用定义与镜像构建：Helm、Kustomize、Buildpacks。
- 持续集成与交付：ArgoCD、Flux、Tekton、Jenkins X。
4. 可观测性与分析（Observability & Analysis）：
- 监控：Prometheus、Grafana、Thanos。
- 日志：Fluentd、Loki。
- 追踪：Jaeger、OpenTelemetry、Zipkin。
- 混沌工程：Chaos Mesh、Litmus、ChaosBlade。
5. 平台层（Platform）：
- K8s 发行版：EKS、GKE、AKS、Rancher、OpenShift。
- PaaS / 应用平台：Cloud Foundry、KubeSphere。
6. 安全与合规（Security & Compliance）：
- 密钥管理：Vault、Cert-manager。
- 容器安全：Trivy、Falco、Harbor。
- 策略引擎：OPA/Gatekeeper、Kyverno。
云原生全景图（简化版）：
┌─────────────────────────────────────────────┐
│ 应用层 (Apps) │
│ 微服务 / Serverless / 业务应用 │
├─────────────────────────────────────────────┤
│ 应用定义与开发层 │
│ Helm / Kustomize / CI/CD / 数据库 / 消息 │
├─────────────────────────────────────────────┤
│ 编排与管理层 │
│ K8s / 服务网格 / 服务发现 / API网关 │
├─────────────────────────────────────────────┤
│ 运行时层 │
│ 容器运行时 / CNI / 存储 │
├─────────────────────────────────────────────┤
│ 基础设施层 │
│ 公有云 / 私有云 / 混合云 │
└─────────────────────────────────────────────┘
贯穿各层：可观测性、安全、混沌工程云原生的核心思想：
- 不可变基础设施：基础设施像容器镜像一样，构建后不变，更新即替换。
- 声明式 API：描述期望状态而非执行步骤，系统自动对齐。
- 弹性伸缩：根据负载自动扩缩容，应对流量波动。
- 容错设计：假设故障必然发生，设计系统来容忍故障。
追问延伸：
- 云原生和云计算是什么关系？上云就是云原生吗？
- 什么是 CNCF？它的作用是什么？有哪些毕业项目？
- 云原生对传统企业应用开发有什么影响？
- 你怎么看待云原生的"技术栈泛滥"问题？
Q2: 什么是服务网格（Service Mesh）？Istio的核心功能？ 「🔴 高级」
考察点：考察服务网格的理解深度，筛掉对服务网格只有概念、不知道原理和适用场景的人。
参考答案：
- 服务网格（Service Mesh） 是一个专门处理服务间通信的基础设施层，通过在每个服务实例旁部署一个轻量级代理（Sidecar），来实现服务间的流量管理、安全和可观测性，而无需修改业务代码。
- 服务网格的核心价值：将服务治理能力从业务代码中剥离，下沉到基础设施层。
核心模式 - Sidecar 模式：
- 每个服务实例旁边部署一个代理（Sidecar Proxy）。
- 服务间的所有入站和出站流量都经过 Sidecar。
- Sidecar 负责流量治理、安全、可观测性等横切关注点。
- 业务代码完全无感知，零侵入。
服务网格的核心能力：
- 流量管理：
- 智能路由：按比例分流、按 Header/路径路由。
- 灰度发布/金丝雀发布：精细控制流量比例。
- 流量镜像：将流量复制一份到新版本做验证。
- 超时、重试、熔断、限流。
- 安全：
- 服务间 mTLS（双向 TLS）认证加密。
- 服务级别的访问控制（授权策略）。
- 身份认证与证书自动轮换。
- 可观测性：
- 自动生成分布式追踪数据。
- 服务间调用指标（流量、错误率、延迟）。
- 访问日志。
- 弹性能力：
- 熔断（Circuit Breaking）：故障服务快速失败。
- 重试（Retry）：瞬态故障自动重试。
- 超时（Timeout）：防止慢请求拖垮系统。
- 故障注入（Fault Injection）：用于测试系统韧性。
Istio 架构：
- 数据平面（Data Plane）：
- 由一组 Envoy Sidecar 代理组成，部署在每个服务旁。
- 负责实际的流量转发、策略执行、数据采集。
- Envoy 是用 C++ 写的高性能代理，Lyft 开源。
- 控制平面（Control Plane）：
- 管理和配置 Sidecar 代理。
- 不直接处理任何流量。
- 主要组件（Istio 1.5+ 整合为 istiod）：
- Pilot：流量管理，将路由规则转换为 Envoy 配置并下发。
- Citadel：安全，证书签发和管理，mTLS。
- Galley：配置验证、摄取和分发。
Istio 架构：
┌─────────────────────────────────────────┐
│ Control Plane │
│ istiod │
│ Pilot + Citadel + Galley │
└─────────────────┬───────────────────────┘
│ xDS 协议下发配置
▼
┌─────────────────────────────────────────┐
│ Data Plane │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Envoy │ │Envoy │ │Envoy │ │
│ └──┬───┘ └──┬───┘ └──┬───┘ │
│ │ │ │ │
│ ┌──┴───┐ ┌──┴───┐ ┌──┴───┐ │
│ │Service│ │Service│ │Service│ │
│ └──────┘ └──────┘ └──────┘ │
└─────────────────────────────────────────┘服务网格的适用场景：
- 大规模微服务架构，服务数量多，治理需求复杂。
- 多语言/多技术栈，统一治理困难。
- 对安全合规要求高，需要服务间 mTLS。
- 需要精细化的流量管理（灰度、多版本、流量镜像）。
- 需要零侵入的可观测性。
服务网格的挑战：
- 性能开销：Sidecar 增加了延迟和资源消耗（约 2-5ms 延迟，内存开销）。
- 复杂度：引入了新的组件和概念，学习曲线陡峭，运维成本增加。
- 排障难度：链路中多了一层代理，问题排查更复杂。
- 适用边界：不是所有系统都需要服务网格，中小规模可能得不偿失。
追问延伸：
- Istio 和 Linkerd 有什么区别？怎么选型？
- Sidecar 模式有什么优缺点？有没有无 Sidecar 的服务网格方案？（Ambient Mesh、Proxyless）
- 服务网格和 API 网关有什么区别和联系？
- 什么是 eBPF？它对服务网格有什么影响？（Cilium、Merbridge 等）
Q3: 什么是API网关？有哪些功能？ 「🟡 中级」
考察点：考察 API 网关的理解和选型能力，筛掉对网关功能定位不清的人。
参考答案：
- API 网关（API Gateway） 是系统的统一入口，所有外部请求都经过网关，由网关进行路由、鉴权、限流、监控等处理后转发到后端服务。
- API 网关位于客户端和后端服务之间，是系统的"门户"。
核心功能：
- 路由转发：
- 根据 URL 路径、域名、Header 等将请求转发到对应的后端服务。
- 是网关最基本的功能。
- 负载均衡：
- 对后端多个服务实例进行流量分发。
- 支持多种负载均衡算法（轮询、加权、最少连接、一致性哈希）。
- 鉴权与认证：
- 统一处理身份认证（JWT、OAuth2、API Key、Basic Auth）。
- 权限校验，避免每个服务重复实现。
- 限流与熔断：
- 限制请求速率，保护后端服务不被冲垮。
- 熔断机制，后端故障时快速失败。
- 灰度发布：
- 按比例或按用户特征将流量导向不同版本的服务。
- 支持金丝雀发布、蓝绿部署。
- 协议转换：
- HTTP ↔ gRPC、HTTP ↔ WebSocket、REST ↔ SOAP。
- 适配不同客户端和后端协议。
- 可观测性：
- 访问日志、监控指标、链路追踪。
- 统一的入口观测点。
- 缓存：
- 对响应结果进行缓存，减少后端压力。
- 请求/响应转换：
- 修改请求头、请求体、响应体。
- 参数校验、格式转换。
常见 API 网关对比：
| 网关 | 开发语言 | 特点 | 适用场景 |
|---|---|---|---|
| Nginx | C | 高性能、稳定、生态成熟 | 传统反向代理、入口网关 |
| Kong | Lua + Nginx | 插件生态丰富、开源商业双版本 | API 管理、企业级网关 |
| APISIX | Lua + Nginx | 国产、性能极强、云原生友好、热更新 | 高性能场景、云原生 |
| Envoy | C++ | 云原生、xDS 动态配置、Sidecar | 服务网格、云原生网关 |
| Traefik | Go | 原生 K8s、自动服务发现、配置简单 | K8s 入口、轻量级场景 |
| Spring Cloud Gateway | Java | Spring 生态、Java 技术栈友好 | Spring Cloud 微服务 |
| Zuul | Java | Netflix 出品，已逐步被替代 | 老项目维护 |
API 网关 vs 服务网格：
- 位置不同：API 网关是南北向流量（外部→内部）的入口；服务网格主要处理东西向流量（服务→服务）。
- 功能侧重不同：网关侧重外部接入管理（认证、限流、路由）；服务网格侧重内部服务治理（熔断、重试、mTLS）。
- 两者可以共存，形成"网关 + 网格"的分层架构。
流量分层模型：
用户 → CDN → WAF → API 网关(南北向) → 服务网格(东西向) → 后端服务
│ │
接入管理 服务治理
认证/限流/路由 熔断/重试/mTLS选型建议：
- K8s 环境优先考虑 Traefik、APISIX、Envoy 等云原生网关。
- 性能要求极高选 APISIX 或 Envoy。
- Spring 技术栈可考虑 SCG。
- 需要丰富的 API 管理能力选 Kong。
追问延伸：
- API 网关和反向代理（Nginx）有什么区别？
- 网关层怎么做限流？有哪些限流算法？（令牌桶、漏桶、滑动窗口）
- 网关的鉴权一般怎么做？JWT 和 OAuth2 有什么区别？
- 网关本身的高可用怎么保证？
Q4: 什么是Serverless？有什么优缺点？ 「🔴 高级」
考察点：考察 Serverless 的理解深度和架构视野，筛掉对 Serverless 只有概念、不知道适用场景和局限的人。
参考答案：
- Serverless（无服务器架构） 是一种云计算执行模型，云服务商负责动态分配和管理服务器资源，开发者只需编写业务代码并上传，无需关心服务器的运维和管理。
- Serverless 并非"没有服务器"，而是"不用管服务器"，服务器的管理由云厂商负责。
Serverless 的两大核心形态：
FaaS（Function as a Service，函数即服务）：
- 将应用拆分为独立的函数，按事件触发执行。
- 按实际执行时间计费，空闲不收费。
- 自动扩缩容，从零到无限。
- 代表：AWS Lambda、阿里云函数计算、腾讯云 SCF、Google Cloud Functions。
BaaS（Backend as a Service，后端即服务）：
- 直接使用云服务商提供的后端能力，无需自己搭建和维护。
- 如：对象存储（OSS/S3）、数据库（DynamoDB/Firebase）、身份认证（Cognito）、消息队列等。
- 开发者通过 API/SDK 直接调用这些服务。
Serverless 的优势：
- 极低运维成本：不用管服务器、操作系统、运行时环境，专注业务逻辑。
- 按需付费：按实际执行时间和资源消耗计费，空闲时零成本。
- 自动弹性伸缩：自动应对流量洪峰，从 0 到 N 无缝扩展。
- 快速迭代：开发部署简单，函数即服务，加快交付速度。
- 高可用：底层基础设施由云厂商保障，多可用区部署。
- 事件驱动：天然适合事件驱动架构，响应各种事件源（HTTP、消息、定时、存储事件等）。
Serverless 的劣势和挑战：
- 冷启动问题：
- 函数长时间不被调用会被回收，下次调用需要冷启动（初始化运行环境 + 加载代码）。
- 冷启动延迟从几百毫秒到几秒不等，对延迟敏感的场景不友好。
- 解决方法：预留实例、预热、减少代码体积、选择更快的运行时。
- 厂商锁定：
- 不同云厂商的 FaaS 平台 API、触发器、运行环境都有差异。
- 迁移成本高，切换云厂商需要改代码。
- 缓解方案：使用 Serverless Framework 等开源框架抽象。
- 执行限制：
- 函数有执行时间限制（如 AWS Lambda 默认 3 秒，最长 15 分钟）。
- 内存、CPU、磁盘空间都有限制。
- 不适合长任务、计算密集型任务。
- 调试和测试困难：
- 本地调试环境难模拟生产环境。
- 分布式调试、链路追踪更复杂。
- 可观测性受限：
- 依赖云厂商提供的监控日志工具。
- 自定义监控和调试能力有限。
- 状态管理复杂：
- 函数是无状态的，状态需要存在外部存储中。
- 函数间协调和共享状态比较麻烦。
Serverless 适用 vs 不适用场景：
适用场景： 不适用场景：
• 事件驱动的异步处理 • 长连接/WebSocket应用
• 定时任务 • 长时间运行的计算任务
• 数据处理（ETL、图片处理） • 对延迟极其敏感的核心业务
• API 后端（低频/突发流量） • 复杂的有状态服务
• Webhook 处理 • 需要深度定制运行环境
• IoT 消息处理 • 对厂商锁定零容忍Serverless 的发展趋势：
- 容器化 Serverless：如 AWS Fargate、阿里云 ECI，支持自定义镜像，灵活性更高。
- Serverless K8s：虚拟节点（Virtual Kubelet）+ 弹性容器实例，K8s 无缝使用 Serverless 资源。
- WebAssembly：WASM 作为 Serverless 运行时，启动更快、更轻量。
- 边缘 Serverless：将函数部署到边缘节点，更低延迟。
追问延伸：
- 什么是冷启动？冷启动时间受哪些因素影响？怎么优化？
- Serverless 和 PaaS 有什么区别？
- 什么是 Serverless Framework？它解决了什么问题？
- 微服务和 Serverless 是什么关系？微服务一定要用 Serverless 吗？
Q5: 云原生时代的架构设计有哪些原则？ 「⭐ 专家」
考察点：考察架构设计的体系化思考和云原生理念深度，筛掉只会堆砌技术、没有设计原则和方法论的人。
参考答案：
- 云原生架构设计是在云原生技术栈基础上，围绕弹性、韧性、可观测、安全等核心目标形成的一整套设计原则和方法论。
1. 不可变基础设施（Immutable Infrastructure）：
- 核心思想：基础设施一旦部署就不再修改，更新时用新版本的实例替换旧版本。
- 类比：像容器镜像一样，构建后不变，要改就构建新版本。
- 实践方式：
- 用镜像/模板定义基础设施，而不是 SSH 登录改配置。
- 配置变更通过重新构建和部署完成。
- 配合 CI/CD 实现基础设施即代码（IaC）。
- 好处：环境一致性高、可追溯、回滚简单、减少配置漂移。
- 工具：Terraform、Ansible（配合模板化）、Packer、Docker。
2. 声明式 API（Declarative API）：
- 核心思想：描述"期望状态"（What），而不是描述"执行步骤"（How）。
- 命令式 vs 声明式：
- 命令式：执行 A → 然后 B → 最后 C（告诉系统怎么做）。
- 声明式：我要达到状态 X（告诉系统要什么，系统自己想办法）。
- K8s 就是声明式的典范：YAML 描述期望状态，控制器自动调谐到目标状态。
- 好处：系统自修复、幂等、自动化、更接近人的思维方式。
- 实践：所有资源用 YAML/JSON 定义，GitOps 管理配置。
3. 微服务化（Microservices）：
- 核心思想：将单体应用按业务领域拆分为小而自治的服务。
- 设计原则：
- 单一职责：每个服务只做一件事。
- 独立部署：服务之间松耦合，可独立发布和扩展。
- 故障隔离：一个服务故障不影响整个系统。
- 技术异构：不同服务可以选择最合适的技术栈。
- 不是越细越好：服务粒度过细会带来运维复杂度飙升。
- 配套能力：服务发现、配置中心、链路追踪、API 网关、服务网格。
4. 弹性伸缩（Elastic Scaling）：
- 核心思想：系统能够根据负载自动调整资源，应对流量波动。
- 弹性维度：
- 水平弹性：增加/减少实例数量（HPA）。
- 垂直弹性：调整单实例的 CPU/内存（VPA）。
- 函数级弹性：Serverless 按请求自动扩缩。
- 设计要点：
- 无状态设计，状态外置（存在数据库/缓存）。
- 优雅启动和关闭，支持快速扩缩。
- 连接池、线程池等资源合理配置。
- 弹性策略：基于 CPU/内存、基于 QPS、基于自定义指标、定时弹性。
5. 可观测性（Observability）：
- 核心思想：系统内部状态可以通过外部输出推断，问题可以被快速发现和定位。
- 三大支柱：指标（Metrics）、日志（Logs）、链路追踪（Tracing）。
- 设计原则：
- 可观测性从设计阶段就考虑，而不是事后补。
- 结构化日志、标准指标、统一追踪。
- 告警面向用户影响，行动导向。
- 落地：Prometheus + ELK + Jaeger + Grafana，OpenTelemetry 统一标准。
6. 安全左移（Shift Left Security）：
- 核心思想：将安全检查和控制前移到开发流程的早期阶段。
- 传统安全：上线前才做安全检查，问题发现晚，修复成本高。
- 安全左移：
- 代码阶段：静态代码安全扫描（SAST）、代码审查安全规范。
- 依赖阶段：依赖漏洞扫描（SCA）、签名验证。
- 构建阶段：镜像安全扫描、IaC 安全扫描。
- 部署阶段：准入控制、策略引擎（OPA）。
- 运行阶段：运行时安全监控（RASP）、合规审计。
- 目标：尽早发现安全问题，降低修复成本，安全融入 DevOps 流程（DevSecOps）。
7. 故障友好（Failure Friendly）/ 韧性设计：
- 核心思想：假设故障必然发生，设计系统来容忍和适应故障，而不是试图消除故障。
- 设计模式：
- 重试与超时：应对瞬态故障。
- 熔断：故障累积时快速失败，防止雪崩。
- 降级：非核心功能故障时关闭，保障核心功能可用。
- 限流：保护系统不被流量冲垮。
- 冗余与容错：多副本、多可用区、多地域部署。
- 故障域隔离：故障影响范围最小化。
- 验证手段：混沌工程，主动注入故障验证系统韧性。
云原生架构设计原则全景：
不可变基础设施 → 怎么部署和运维
声明式 API → 怎么定义和管理资源
微服务化 → 怎么拆分和组织服务
弹性伸缩 → 怎么应对流量波动
可观测性 → 怎么发现和定位问题
安全左移 → 怎么保障系统安全
故障友好 → 怎么应对和容忍故障云原生架构的演进方向：
- 从资源导向到应用导向：关注点从"机器"转向"应用"，开发者不用关心底层资源。
- 从手工运维到自动化自治：越来越多的运维操作由系统自动完成。
- 从集中式到分布式再到网格化：服务治理能力下沉到基础设施。
- 从单体到微服务再到 Serverless：计算粒度越来越细，运维负担越来越轻。
追问延伸：
- 不可变基础设施和 IaC 是什么关系？
- 声明式 API 的实现原理是什么？（控制循环、调谐 Reconciliation）
- 微服务拆分的粒度怎么把握？有什么经验法则？
- 你怎么看待"云原生就是 K8s"这种说法？