2. 边界类型与适用场景
组件化架构的第一步不是划分代码目录，而是确定边界的性质。边界性质决定了模块间的信任链路、数据流模型、故障隔离半径与运维成本。本章系统解析四种核心边界——逻辑边界、进程边界、物理边界与网络边界——的特征、适用场景与选择依据。
在开始阅读之前，请将本章视为一个“边界的决策沙盘”：每个边界定义都直接对应一组分层职责、数据流与控制流约束，以及特定的风险模式。没有的优劣，只有基于场景的权衡。
2.1 逻辑边界：模块内部的契约与依赖
定义：逻辑边界是代码组织的最小宏观结构，由编译时依赖和命名空间定义。组件间通过接口或抽象基类通信，处于同一进程地址空间。
- 数据流与控制流：同步函数调用、回调、事件总线。控制流严格遵循调用栈。
- 信任链路：完全信任。任意组件可直接调用其他组件，依赖管理因此成为核心挑战。
- 选型权衡：重构成本低，迭代速度快，但缺乏运行时隔离。一个模块的内存泄漏可能拖垮整个进程。
- 风险识别：边界退化——模块间非公共 API 泄漏，演变为紧耦合。
- 落地与验收：强制使用显式接口，通过静态代码检查禁止内部类跨模块访问。验收标准为纯 API 契约测试。
逻辑边界是架构演进的起点。只有当“独立发布”或“故障隔离”成为刚性需求时，才应考虑升级到更强的边界类型。
2.2 进程边界：操作系统的硬隔离
定义：进程边界通过操作系统强制内存隔离。组件运行在独立进程中，通过 IPC（如 Unix 域套接字、gRPC、消息队列）交换数据。
- 数据流与控制流：序列化消息、信号量、消息队列。控制流包含明确的连接建立与断开。
- 信任链路：半信任。OS 提供基础隔离，进程崩溃不会污染其他进程内存，但共享文件或资源可能成为隐患。
- 选型权衡：强隔离性 vs 性能开销。上下文切换与序列化/反序列化带来明显延迟。
- 风险识别：死锁、IPC 链路耗尽、版本协议不兼容。
- 落地与验收：配置健康检查与看门狗，监控 IPC 延迟抖动。验收标准为进程级故障恢复测试。
2.3 物理边界：机器级的故障域
定义：物理边界意味着组件部署在不同的物理或虚拟服务器上，通过网络通信。
- 数据流与控制流：基于 TCP/IP 的 RPC、消息代理（Kafka、RabbitMQ）。控制流引入复杂的重试、超时和负载均衡策略。
- 信任链路：低信任。必须假设网络不可靠，节点可能随时宕机。采用断路器与隔舱模式。
- 选型权衡：物理边界是实现高可用的必要条件，但引入了最终一致性和分布式事务的挑战。
- 风险识别：网络分区、机器宕机、DNS 缓存污染。
- 落地与验收：调用方必须配置超时与重试，具备熔断能力。验收标准为混沌工程实验。
过度工程陷阱：在只有一个团队维护时采用微服务（进程/物理边界），会导致分布式复杂性失控，而业务并未受益。始终以“团队自治”和“发布频率”作为是否引入更强边界的核心依据。
2.4 网络边界：跨越地理与行政域
定义：网络边界覆盖数据中心、公有云区域或 CDN 边缘节点。数据主权和监管合规成为首要考量。
- 数据流与控制流：API 网关、全局负载均衡、事件流同步。控制流通常退化为主导-跟随或基于策略的路由。
- 信任链路：最低信任模型。所有通信必须加密（mTLS），执行严格的身份验证与授权。
- 选型权衡：主要驱动因素是用户地理位置与数据驻留法律。成本急剧上升。
- 风险识别：区域级故障、监管罚款、异步数据丢失。
- 落地与验收：启用 mTLS 与区域级故障演练。验收标准为合规审计与故障转移测试。
2.5 选择框架：从逻辑出发，按需演进
架构决策应遵循“最简必要边界”原则。以下场景选择表提供快速参考：
| 业务/技术场景 | 推荐边界类型 | 决策理由 |
|---|---|---|
| 早期产品，快速验证 | 逻辑边界 | 最低开发开销，便于迭代 |
| 模块需独立发布 | 进程边界 | 独立部署与版本控制 |
| 模块独立扩容需求 | 物理边界 | 独立资源分配与故障域 |
| 数据主权法规 | 网络边界 | 数据物理隔离与合规 |
验收标准检查清单
针对每种边界类型，团队应在架构设计评审中逐项确认：
- 逻辑边界：是否存在显式的公共 API 契约？是否通过静态分析阻止内部类跨模块访问？
- 进程边界：进程退出后是否自动恢复？监控系统能否感知 IPC 延迟抖动？
- 物理边界：调用方是否配置了超时与重试？是否具备熔断与降级能力？
- 网络边界：跨区域通信是否启用 mTLS？区域级故障演练是否定期执行？