1. 微服务架构与AWS云原生体系导入

在正式进入工程实践之前，需要先建立一张“全局地图”：微服务到底解决什么问题、它和传统单体架构的本质差别在哪里、AWS 上有哪些托管服务可以承接微服务的各个关注点。本章不追求把每个服务讲透，而是帮助读者形成一套可落地的判断框架——知道一个业务能力该拆成什么、放到哪里、用什么托管服务承载、又该用什么手段观测它。

一、微服务的定义与演进动因

微服务是一种将单一应用按业务能力拆分为一组小型、独立部署服务的架构风格。每个服务围绕一个明确的业务边界构建，拥有自己的进程、独立的数据存储与发布节奏，服务之间通过轻量协议（HTTP/REST、gRPC、消息）通信。它与单体架构的关键差别不在“代码量大小”，而在部署单元与数据所有权的边界：单体是一个可执行体、一个数据库；微服务是多个可独立发布的可执行体，各自持有数据。

演进动因通常来自四个方面。其一是发布耦合：单体中任何一处改动都要整体回归与发布，交付周期被最长路径拖住。其二是伸缩粒度：单体只能整体扩容，热点模块无法单独加机器。其三是故障隔离：单体中一个内存泄漏或线程池耗尽会拖垮整个进程。其四是团队自治：当研发规模增长，按业务能力划分的小团队需要独立的技术决策与发布权。需要强调的是，微服务不是默认答案——如果业务规模小、团队人数少、领域边界尚不清晰，单体反而是更理性的起点。

二、微服务的核心特征

判断一个系统是否“真的微服务化”，可以对照以下特征：围绕业务能力组织（而非按技术分层拆成 controller/service/dao 三个服务）；独立部署与独立数据（服务不共享数据库表，跨服务数据通过 API 或事件获取）；去中心化治理（允许不同服务选用不同语言与存储）；面向失败设计（超时、重试、熔断、降级是标配而非补丁）；可观测性内建（日志、指标、链路追踪三件套随服务一起交付）。

与之对应的是四类典型代价：分布式事务、跨服务调试、网络延迟放大、运维复杂度上升。这些代价正是 AWS 托管服务要替我们承担的部分。

三、AWS 托管服务全景

把微服务的关注点映射到 AWS 服务，可以形成一张清晰的分层地图：

下面这张图把上述映射组织成一条从“客户端请求”到“数据与观测”的完整链路，便于建立整体印象：

四、课程目标与实战项目

本课程的目标不是罗列 AWS 服务清单，而是让读者具备“设计—部署—观测—排障”的完整闭环能力。为此，课程围绕一个贯穿始终的实战项目展开：一个订单处理系统，包含用户服务、商品服务、订单服务、支付服务与通知服务五个微服务。

项目在 AWS 上的落地形态如下：用户与商品服务以 ECS Fargate 常驻运行，通过 ALB 暴露；订单服务接收 API Gateway 请求，写入 Aurora 并向下游发送事件；支付服务订阅 SQS 队列异步处理支付结果；通知服务由 EventBridge 触发 Lambda 发送消息。所有服务统一接入 CloudWatch 日志与 X-Ray 追踪。

课程将按“架构设计 → 服务拆分 → 容器化部署 → 数据与消息 → 可观测性 → 生产排障”的顺序推进，每一阶段都基于这个订单系统做增量改造。读者在完成课程后，应能独立完成一个可运行、可观测、可排障的微服务系统，并理解每个技术选型背后的权衡。