1. 课程导入与云原生全景
欢迎进入《AWS云原生应用架构与生产环境建设》。在动手写第一行 Kubernetes YAML 或 Terraform 之前，我们需要先建立一张"全景地图"：云原生到底由哪些核心概念构成，AWS 提供了哪些托管服务来承载这些概念，以及它们在真实生产环境中各自站在什么位置。本章的目标不是让你立刻会部署，而是让你在后续 29 章中，每遇到一个组件都能回答三个问题——它解决什么问题、它替代了什么、它和相邻组件如何协作。
一、云原生的四个核心概念
云原生（Cloud Native）不是某一款工具的名字，而是一组相互支撑的设计原则。业界普遍引用 CNCF 的定义，落到工程实践上，可以收敛为四个关键词。
容器（Container）：把应用及其运行时依赖打包成不可变的镜像，实现"一次构建、处处运行"。容器解决的是环境一致性问题——开发机、测试环境、生产集群跑的是同一个镜像摘要（image digest），而不是"我这能跑"的玄学。在 AWS 上，镜像通常存放在 Amazon ECR，运行时由 ECS、EKS 或 Fargate 承载。
微服务（Microservice）：把单体应用按业务边界拆分为独立部署、独立扩缩、独立故障的小服务。微服务带来的不是"更少的复杂度"，而是"复杂度从代码内部转移到了服务之间"——于是服务发现、流量治理、可观测性成为必需品，这正是 App Mesh、Cloud Map、X-Ray 存在的理由。
声明式 API（Declarative API）：你描述"期望状态"（desired state），系统负责把"实际状态"（actual state）收敛过去。Kubernetes 的 Deployment、ECS 的 Service、Terraform 的资源块都是声明式的。它与命令式（"先执行 A，再执行 B"）的关键区别在于：声明式系统具备自愈能力，控制器会持续对比期望与实际并纠偏。
不可变基础设施（Immutable Infrastructure）：服务器或容器实例一旦部署就不再原地修改，任何变更都通过替换新版本实现。这消除了"配置漂移"（configuration drift），让回滚变成"切回上一个镜像版本"这样确定性的操作。
二、AWS 云原生技术栈的定位
AWS 的云原生服务数量庞大，容易让人迷失。我们可以按"计算—编排—网络—集成—可观测"五个层次来归类，每一层都有明确的职责边界。
计算层决定应用以什么形态运行。Lambda 是事件驱动的函数计算，适合短时、无状态、突发流量的任务；Fargate 是 Serverless 容器，你只提供镜像和 CPU/内存规格，无需管理节点；ECS 与 EKS 则是容器编排控制面，前者是 AWS 原生、学习曲线平缓，后者是托管 Kubernetes、生态兼容性最强。选择逻辑通常是：能函数化就 Lambda，需要长期运行容器但不想管节点就 Fargate，需要完整 Kubernetes 能力就 EKS。
编排与调度层负责副本数、滚动发布、健康检查与自愈。EKS 的 Deployment/ReplicaSet 控制器、ECS 的 Service 调度器都属于这一层。
网络与流量层处理服务间通信。App Mesh 提供服务网格能力（流量路由、重试、熔断、mTLS），Cloud Map 提供服务注册与发现，ALB/NLB 处理南北向流量，VPC 与安全组处理网络隔离。
集成层连接服务与事件，包括 SQS、SNS、EventBridge、Step Functions，用于解耦与异步编排。
可观测层由 CloudWatch（指标与日志）、X-Ray（分布式追踪）、CloudWatch Logs Insights（日志查询）组成，是判断"系统是否健康"的依据。
三、从概念到生产：一条请求的完整路径
把上面的分层串起来，我们看一个具体例子。假设一个电商应用部署在 EKS 上，用户发起"下单"请求，路径大致如下：请求先到 ALB，ALB 转发到 EKS 中的 order-service Pod；order-service 通过 Cloud Map 解析到 inventory-service 的地址，调用其扣减库存接口；扣减成功后，order-service 向 SQS 投递一条"订单已创建"消息，由下游的支付服务异步消费。整个链路中，App Mesh 负责服务间重试与超时控制，X-Ray 记录每个 span 的耗时，CloudWatch 收集各服务的日志与指标。
这条路径里，每个组件都有明确的失败模式：ALB 健康检查失败会导致 Pod 被摘除；Cloud Map 注册延迟会导致调用到已下线的实例；SQS 消息积压会导致支付延迟。理解全景图的价值，就在于当故障发生时，你能快速定位到"是哪一层的哪个组件出了问题"，而不是盲目重启。
四、本课程的学习路径
后续章节将沿着"概念 → 单服务部署 → 多服务协作 → 生产加固"的路径推进。你会先掌握容器镜像构建与 ECR 推送，再学习 EKS 与 ECS 的部署方式，然后进入服务网格、服务发现、异步集成，最后覆盖可观测性、安全、成本与故障演练。每一章都会给出可执行的配置片段与判断依据，而不是停留在概念介绍。
现在，请先记住这张分层图。它是本课程所有后续内容的坐标系——无论我们讨论的是 Fargate 的任务定义、EKS 的 Ingress 控制器，还是 App Mesh 的虚拟节点，你都能在图中找到它的位置，并理解它为什么必须存在。