1. 课程导入与全景认知
在单体应用时代，一个电商系统往往被打包成一个巨大的 WAR 或 JAR，部署在一台或几台 EC2 上。订单、库存、支付、用户、通知全部耦合在同一个进程里，一次发布要全量上线，一个模块的内存泄漏会拖垮整个系统。当业务增长到数百人协作、每天上百次发布时，这种架构的代价变得不可承受。微服务正是对这一困境的回应：把系统按业务能力拆成一组小而自治的服务，每个服务独立开发、独立部署、独立扩缩容，通过轻量级协议通信。
AWS 上的微服务演进大致经历了三个阶段。第一阶段是"EC2 + 自建注册中心"：服务跑在 EC2 或 Auto Scaling 组里，用 Eureka、Consul 做服务发现，用 Nginx 或 ALB 做入口。这一阶段控制力强，但运维负担重，扩缩容、健康检查、证书轮换都要自己写。第二阶段是"容器化 + 编排"：ECS 或 EKS 承载服务，任务定义和 Deployment 描述副本数，服务发现交给 AWS Cloud Map，配置交给 Parameter Store 或 AppConfig。第三阶段是"Serverless 与托管集成"：Lambda、Fargate、API Gateway、EventBridge、Step Functions 让团队把精力从"管服务器"转向"管业务边界"，通信从同步调用扩展到事件驱动。
架构演进并没有消灭复杂性，只是把复杂性从"机器"转移到了"服务之间"。这正是微服务治理要解决的问题。治理挑战可以归纳为四类。其一是服务发现与流量入口：服务实例的 IP 是动态的，调用方不能硬编码地址，需要注册、发现、健康检查和负载均衡。其二是弹性与容错：一个下游服务变慢，如果调用方无限等待，线程池会被耗尽，故障沿调用链向上蔓延，这就是级联失败。其三是可观测性：一次用户请求可能穿过五六个服务，没有统一的 Trace ID、结构化日志和指标，排障就像在黑箱里摸索。其四是安全与配置：服务间调用需要身份认证和授权，密钥不能写进代码，配置变更要能灰度生效。
服务通信是治理的核心战场，它要回答几个具体问题。第一，用什么协议：同步的 REST/HTTP、gRPC，还是异步的消息与事件？同步调用简单直观，但会形成强耦合和阻塞；异步解耦更好，但引入了最终一致性和消息重复的复杂度。第二，怎么找到对方：是客户端发现（调用方查注册表再直连），还是服务端发现（调用方只访问负载均衡器）？第三，失败了怎么办：超时设多少、重试几次、是否要熔断、降级返回什么？第四，数据怎么传：请求响应式的一问一答，还是事件流式的发布订阅？
下面这张图把本课程的知识地图与通信决策路径放在一起，帮助你在后续章节中定位每个知识点所处的位置。
把这张图读成一条主线：架构演进决定了通信形态，通信形态决定了治理重点，治理重点决定了你要在 AWS 上选哪些托管服务。例如，当你选择事件驱动架构时，治理重点就从"熔断降级"转向"消息幂等、死信队列和顺序保证"；当你选择 gRPC 时，服务发现和负载均衡的实现方式又与 REST 不同。
为了让你在动手前有明确的判断依据，下面给出一份通信方式选型参考表。表中的延迟、吞吐为典型量级的合理估计，实际值取决于实例规格、网络路径和负载特征，需以压测结果为准。
| 通信方式 | 典型延迟量级 | 耦合程度 | 适用场景 | AWS 常用组件 |
|---|---|---|---|---|
| REST / HTTP+JSON | 毫秒级 | 中（接口契约） | 对外 API、简单查询、团队技术栈统一 | API Gateway、ALB、ECS/EKS |
| gRPC / HTTP2+Protobuf | 亚毫秒至毫秒级 | 中高（强契约） | 内部高频调用、流式传输、多语言 | ECS/EKS、Cloud Map、ALB(gRPC) |
| 消息队列 | 毫秒至秒级 | 低（时间解耦） | 削峰填谷、异步任务、可靠投递 | SQS、Amazon MQ |
| 事件总线 | 毫秒至秒级 | 极低（空间解耦） | 多消费者广播、领域事件、跨服务编排 | EventBridge、SNS |
本课程后续章节会沿着这条主线展开：先讲清楚服务发现与流量入口如何在 AWS 上落地，再进入同步通信的容错设计，然后扩展到异步消息与事件驱动，最后补齐可观测性、安全与配置治理。每一章都会给出可运行的配置片段、参数取值依据和结果判读方法，而不是停留在概念层面。
在开始之前，建议你先建立两个习惯。第一，为每个服务定义清晰的边界和契约：输入是什么、输出是什么、失败时返回什么，契约稳定了，通信方式才有讨论的基础。第二，把可观测性当作一等公民：从第一个服务开始就注入 Trace ID、输出结构化日志、暴露关键指标，否则等到系统复杂后再补，成本会高得多。
接下来，我们将从最基础的服务发现开始，看看一个请求是如何从入口找到目标服务实例的。