1. 课程导入与微服务通信全景
在单体应用时代，模块之间的调用往往只是一次进程内的方法调用，编译器帮你检查参数，调用栈帮你定位问题。当系统被拆分为几十甚至上百个微服务后，一次业务请求可能横跨多个服务、多个进程、多个网络跳点，通信从"函数调用"变成了"网络调用"，随之而来的是一整套新的治理问题。本课程围绕 Azure 平台上的微服务治理与服务通信展开，本章先建立全景认知：微服务通信到底难在哪里、有哪些通信模式、治理要解决什么问题，以及我们将用什么样的实战项目把后续 29 章的知识串起来。
为什么微服务通信需要"治理"
先看一个具体场景。假设有一个电商系统，拆分为订单服务、库存服务、支付服务、通知服务四个微服务，部署在 Azure Kubernetes Service（AKS）上。用户下单时，订单服务需要依次调用库存服务扣减库存、调用支付服务完成扣款、调用通知服务发送短信。这条链路看起来清晰，但一旦放到生产环境，问题会成倍出现：
- 网络不可靠：库存服务所在节点重启，订单服务收到的是超时还是连接拒绝？重试会不会导致库存被扣两次？
- 服务发现：库存服务的 Pod IP 随时在变，订单服务怎么知道该调用哪个地址？
- 流量治理：新版本库存服务上线，如何只让 5% 的流量进入灰度版本？
- 安全：支付服务凭什么相信调用方真的是订单服务，而不是被伪造的请求？
- 可观测性：一次下单失败，到底是库存超时、支付拒绝，还是通知服务拖垮了整条链路？
- 弹性：支付服务响应从 50ms 涨到 3s，订单服务的线程池会不会被耗尽，进而引发雪崩？
这些问题不是某一个服务能独立解决的，它们属于"服务之间"的问题，因此需要一层独立于业务逻辑的治理能力。所谓微服务治理，就是把这些横切关注点——服务发现、负载均衡、重试与超时、熔断限流、流量切分、认证授权、链路追踪——从业务代码中抽离出来，用统一的基础设施或框架来承载。在 Azure 上，这层能力可以由 Azure Service Fabric、AKS + Istio/Linkerd、Azure API Management、Dapr 等多种技术组合提供，本课程会重点对比并落地其中主流方案。
通信模式的分类
微服务之间的通信，可以从两个维度来划分，理解这两个维度是后续选型的基础。
第一个维度是同步与异步。同步通信指调用方发出请求后阻塞等待响应，典型协议是 HTTP/REST 和 gRPC。它的优点是语义直观、调试方便、能立即拿到结果；缺点是调用方与被调用方在时间上强耦合，被调用方变慢或不可用会直接传导给调用方。异步通信指调用方发出消息后不等待处理结果，典型载体是消息队列（Azure Service Bus、Event Hubs、Storage Queue）。它解耦了时间，天然适合削峰填谷和事件驱动，但代价是最终一致性、消息幂等、顺序保证等复杂度上升。
第二个维度是请求—响应与事件驱动。请求—响应是"我让你做一件事，并告诉我结果"；事件驱动是"我宣布一件事发生了，谁关心谁处理"。前者是命令式，调用方知道被调用方是谁；后者是发布—订阅式，发布者不需要知道订阅者存在，新增一个消费者不影响发布者。二者不是互斥的，一个系统里往往同时存在：下单走同步的 gRPC 调用扣库存，库存扣减成功后发布一个 InventoryDeducted 事件，通知服务和数据分析服务异步订阅。
下面这张图把本节的核心关系梳理出来：左侧是通信模式的两条主轴，中间是它们对应的典型 Azure 技术载体，右侧是这些通信方式共同引出的治理能力。图中同时标出了同步链路与异步链路在"耦合点"上的差异，便于对照理解。
本课程要解决的核心问题
把上面的全景收拢，本课程围绕四个递进的问题展开。第一，怎么通：服务之间用什么协议、什么序列化格式、同步还是异步，如何做服务发现和负载均衡。第二，怎么通得稳：超时设多少、重试几次、什么条件下熔断、如何做限流和隔离，避免一个慢服务拖垮整条链路。第三，怎么通得安全可控：服务身份如何认证、流量如何灰度、配置和密钥如何集中管理。第四，怎么知道通得好不好：如何用分布式追踪把一次跨服务请求串起来，如何用指标和日志定位瓶颈。
这四个问题对应到 Azure 的具体技术，就形成了后续章节的主线：AKS 与 Service Fabric 的部署形态、Istio 与 Dapr 的治理机制、Service Bus 与 Event Hubs 的异步通信、API Management 的入口治理、Application Insights 与 OpenTelemetry 的可观测性，以及贯穿始终的安全与配置管理。
实战项目介绍
为了让知识不停留在概念层面，本课程设计了一个贯穿始终的实战项目：一个基于 Azure 的在线图书商城微服务系统。它包含五个服务，规模适中，足以暴露真实的治理问题，又不至于让环境搭建成本过高。
| 服务 | 职责 | 通信方式 | 关键治理点 |
|---|---|---|---|
| Gateway | 统一入口，路由与鉴权 | HTTP（南北向） | API Management 限流、JWT 校验 |
| Catalog | 图书查询与检索 | gRPC（被调用） | 缓存、只读副本、超时 |
| Order | 下单与订单状态 | gRPC 调用 Catalog/Inventory | 重试、熔断、幂等键 |
| Inventory | 库存扣减与回滚 | gRPC + 发布事件 | 并发扣减、消息幂等 |
| Notification | 短信与邮件通知 | 订阅 Service Bus 事件 | 重试队列、死信处理 |
项目会分阶段推进：先让五个服务在 AKS 上跑起来并完成基本调用，再逐步引入服务网格做流量治理，接着用 Dapr 简化发布订阅，最后接入可观测性并做一次故障演练。每个阶段都有可观察的验收标准，例如"库存服务注入 2 秒延迟后，订单服务的 P99 延迟不超过 800ms 且错误率低于 1%"，这样你能明确判断治理是否真正生效。
学习路径建议
如果你刚接触微服务，建议按章节顺序推进，先把通信模式和服务发现打牢，再进入熔断限流等弹性话题；如果你已有 Kubernetes 经验，可以快速浏览基础章节，把精力放在 Istio、Dapr 与 Azure 托管服务的对比选型上。无论哪条路径，都建议边学边在实战项目里动手验证——治理能力只有在真实调用链路上才能被真正理解。接下来，我们从微服务架构在 Azure 上的部署形态开始，逐步展开这套治理体系。