3. 服务边界定义：服务边界的内涵、服务粒度、服务间依赖关系建模

在DAG任务调度系统中，服务边界是决定数据传输效率与调度复杂度的核心设计维度。本节从边界的内涵出发，逐步深入到粒度控制与依赖建模，为后续的数据传输机制设计奠定理论基础。

3.1 服务边界的内涵

服务边界并非简单的代码模块划分，而是数据、计算、状态与通信责任的逻辑隔离域。一个定义良好的服务边界应满足以下三个特征：

• 数据自治性：服务内部维护其所需的数据状态，外部仅通过明确定义的接口（API/消息）访问。
• 计算封闭性：服务的业务逻辑在边界内完成，不依赖外部服务的内部实现细节。
• 通信显式性：跨边界的数据流动必须通过显式的网络调用或消息传递，而非隐式的内存共享。

3.2 服务粒度：从粗到细的权衡

服务粒度是边界定义中最具挑战性的决策。下表对比了不同粒度级别在DAG任务调度中的典型表现：

粒度选择的核心矛盾在于：粗粒度减少通信次数但增加单次传输量，细粒度提升并行度但放大通信开销。实际工程中，建议采用分层粒度策略：在宏观层面按业务领域划分中粒度服务，在微观层面允许服务内部拆分为细粒度任务。

3.3 服务间依赖关系建模

依赖关系是DAG调度的骨架。一个完整的依赖模型需要同时表达数据依赖与控制依赖两种语义。

3.3.1 依赖类型定义

• 数据依赖（Data Dependency）：下游任务必须等待上游任务的数据输出就绪后才能启动。这是DAG中最常见的依赖类型。
• 控制依赖（Control Dependency）：下游任务的启动条件取决于上游任务的执行状态（成功/失败/跳过），而非具体数据内容。
• 资源依赖（Resource Dependency）：多个任务共享同一临界资源（如GPU、锁），需通过调度器协调访问顺序。

3.3.2 依赖建模方法

业界主流的依赖建模方式分为显式图结构与隐式规则引擎两类。下表对比了它们的核心差异：

3.4 服务边界与依赖关系的联合设计

服务边界与依赖关系并非独立决策，二者存在强耦合。下图展示了边界划分如何影响依赖图的拓扑复杂度：

上图直观展示了：当服务边界从粗粒度（3个服务）细化为细粒度（7个原子任务）时，依赖边的数量从3条增长到8条，增长了约2.7倍。这意味着调度器需要处理更多的依赖检查与数据传输协调。

3.5 依赖建模的工程实践

在代码层面，依赖关系通常通过声明式配置或编程式API来定义。以下是一个基于YAML的显式DAG依赖定义示例：

# dag_workflow.yaml
version: "1.0"
services:
  - name: data_ingestion
    image: "ingestion:v2.1"
    outputs: ["/data/raw"]
    
  - name: data_transform
    image: "transform:v1.8"
    inputs: ["/data/raw"]
    outputs: ["/data/processed"]
    depends_on:
      - service: data_ingestion
        type: data
        condition: success
        
  - name: model_train
    image: "trainer:v3.2"
    inputs: ["/data/processed"]
    outputs: ["/models/prod"]
    depends_on:
      - service: data_transform
        type: data
        condition: success
      - service: data_ingestion
        type: control
        condition: skipped  # 控制依赖：即使ingestion被跳过也继续

3.6 边界定义对数据传输的影响

服务边界直接决定了数据传输的协议选择与序列化策略。下表总结了不同边界类型下的典型传输模式：

从表中可以看出，服务边界越粗、物理距离越近，数据传输的延迟越低、一致性越强。但粗粒度也意味着更少的并行机会。因此，在DAG调度设计中，需要根据业务对时效性与吞吐量的要求，在边界粒度与传输效率之间找到平衡点。