1. 课程导论：部署拓扑的定义、服务边界的重要性、数据传输机制在分布式系统中的角色
1.1 部署拓扑的定义
部署拓扑（Deployment Topology）描述了分布式系统中各服务实例、中间件、数据存储及网络基础设施之间的物理或逻辑布局关系。它决定了请求的流转路径、故障隔离范围以及资源利用效率。
| 拓扑维度 | 说明 | 典型示例 |
|---|---|---|
| 物理拓扑 | 服务器、机架、数据中心的地理分布 | 同城双活、异地多活 |
| 逻辑拓扑 | 服务间的调用关系与依赖层次 | 星型、树型、网格型 |
| 网络拓扑 | 子网划分、负载均衡器、网关位置 | Nginx → 网关 → 微服务集群 |
| 数据拓扑 | 数据库主从、分片、缓存层级 | Redis Cluster + MySQL 读写分离 |
关键认知：部署拓扑不是静态的架构图，而是随业务规模、容灾等级、成本约束动态演化的基础设施视图。每次拓扑变更都直接影响服务边界和数据传输路径。
1.2 服务边界的重要性
服务边界（Service Boundary）是微服务架构中最核心的设计决策。边界划分的优劣直接决定了系统的可维护性、扩展性和故障隔离能力。
- 业务内聚性：每个服务应围绕一个明确的业务领域（Bounded Context）建模，避免跨领域耦合。
- 数据所有权：服务拥有其数据的唯一写权限，其他服务只能通过 API 读取，禁止直连数据库。
- 故障隔离：边界清晰的系统可以将故障限制在单个服务内，防止雪崩效应。
- 独立部署：服务边界决定了团队能否独立发布、回滚和扩缩容。
常见反模式：将多个业务逻辑塞入同一个“上帝服务”，导致单点故障、部署耦合、团队协作冲突。边界模糊时，一次变更可能引发跨多个服务的连锁回归。
| 边界设计原则 | 正向效果 | 违反后果 |
|---|---|---|
| 按业务领域划分 | 高内聚、低耦合 | 跨服务频繁修改 |
| 数据私有化 | 数据一致性可控 | 数据竞争、脏读 |
| 接口契约化 | 兼容演进 | 接口断裂、调用失败 |
| 异步边界解耦 | 弹性伸缩 | 同步阻塞、级联超时 |
1.3 数据传输机制在分布式系统中的角色
数据传输机制（Data Transfer Mechanism）是连接服务边界的“血管”。它决定了数据如何在服务之间流动、转换和保证一致性。
- 同步传输：HTTP/gRPC 请求-响应模式，适用于实时查询和命令。优点是语义简单，缺点是调用方必须等待，容易产生级联故障。
- 异步传输：消息队列（Kafka、RabbitMQ）、事件总线，适用于解耦和削峰填谷。优点是高吞吐、松耦合，缺点是最终一致性带来的补偿复杂度。
- 流式传输：gRPC Stream、WebSocket、Kafka Streams，适用于大数据量或实时推送场景。
- 批量传输：离线数据同步（ETL、数据湖），适用于分析型场景，不要求实时性。
核心权衡：同步传输提供强一致性和简单编程模型，但牺牲可用性和弹性；异步传输提升系统韧性，但引入最终一致性和消息幂等处理成本。架构师需要根据业务场景选择混合策略。
1.4 三者关系：拓扑、边界与数据传输
部署拓扑、服务边界和数据传输机制三者构成分布式系统的“骨架-器官-血管”关系：
- 部署拓扑决定了服务实例的物理/逻辑位置，影响网络延迟、可用区分布和容灾策略。
- 服务边界定义了哪些逻辑属于同一个部署单元，决定了拓扑中节点的粒度。
- 数据传输机制是连接这些节点的“协议层”，决定了数据如何跨越边界流动。
架构师视角：设计分布式系统时，应首先划定服务边界（领域驱动设计），然后根据边界间的通信需求选择数据传输机制，最后将服务实例映射到具体的部署拓扑中。顺序不可颠倒。
| 设计步骤 | 关注点 | 输出产物 |
|---|---|---|
| 1. 划定服务边界 | 业务领域、数据所有权、团队结构 | 服务清单、Bounded Context 图 |
| 2. 选择数据传输机制 | 同步/异步、一致性级别、协议 | 接口契约、事件 Schema |
| 3. 设计部署拓扑 | 实例数、可用区、负载均衡、容灾 | 部署架构图、K8s 资源清单 |