📚 课程目录第4章服务边界定义

4. 服务边界定义：微服务架构下，如何基于DDD划分可观测性服务的边界

在多租户可观测性系统中，服务边界的定义直接决定了数据隔离的粒度、传输的效率以及系统的可维护性。领域驱动设计（DDD）提供了一套成熟的战略设计工具，帮助我们将复杂的可观测性领域拆解为高内聚、低耦合的限界上下文（Bounded Context）。本节将演示如何将DDD的核心模式应用于可观测性服务的边界划分。

4.1 可观测性领域的核心子域分析

首先，我们需要对可观测性领域进行通用语言（Ubiquitous Language）梳理，识别出核心子域、支撑子域和通用子域。

子域类型	可观测性领域对应模块	业务价值
核心子域	指标聚合、链路追踪、日志索引、告警规则引擎	差异化竞争力，决定系统核心能力
支撑子域	租户管理、数据采样策略、元数据管理	支撑核心流程，但非核心壁垒
通用子域	用户认证、通知发送（邮件/钉钉）、对象存储	可采购现成方案，无需自研

实践建议： 在多租户场景下，租户管理往往从支撑子域升级为与核心子域紧密交互的关键模块。租户身份必须贯穿所有可观测性数据的写入与查询路径，因此建议将租户上下文作为独立的限界上下文，而非简单的一个字段。

4.2 从事件风暴到限界上下文

通过事件风暴（Event Storming）工作坊，我们可以识别出可观测性领域的核心领域事件、命令和聚合。以下是一个简化的可观测性数据流事件风暴结果：

领域事件： 指标数据已接收、链路Span已存储、告警规则已触发、日志索引已刷新。
命令： 写入指标点、查询Trace、创建告警规则、检索日志。
聚合： 指标时间序列、Span树、告警规则实体、日志流。

基于这些事件和聚合的依赖关系，我们可以划分出以下限界上下文：

数据采集上下文（Data Ingestion Context）： 负责接收来自各种Agent和SDK的遥测数据，进行初步的格式校验、租户识别和采样决策。
存储与索引上下文（Storage & Indexing Context）： 负责将数据持久化到时序数据库、搜索引擎或对象存储中，并维护索引结构。
查询与分析上下文（Query & Analytics Context）： 负责处理用户的查询请求，跨存储引擎进行数据聚合、关联和可视化。
告警与通知上下文（Alerting & Notification Context）： 负责评估告警规则，生成告警事件，并协调通知发送。
租户与元数据上下文（Tenant & Metadata Context）： 负责管理租户信息、数据保留策略、采样配置等全局元数据。

  边界划分原则： 每个限界上下文拥有独立的数据库实例或至少独立的表空间/索引前缀。上下文之间仅通过发布-订阅事件或防腐层（ACL）进行通信，禁止直接共享数据库或内部领域对象。

4.3 服务边界与数据传输的映射关系

下图展示了基于DDD划分后的可观测性服务边界，以及数据在上下文之间的流转路径。注意，租户上下文作为全局路由信息，被注入到所有数据写入和查询的请求头中。

4.4 上下文映射与集成模式

确定了限界上下文后，我们需要定义它们之间的协作关系。在多租户可观测性系统中，最常用的上下文映射模式包括：

模式	适用场景	多租户注意事项
防腐层（ACL）	查询上下文需要适配底层不同的存储引擎（如Prometheus vs. VictoriaMetrics）	在ACL中注入租户ID过滤条件，防止跨租户数据泄露
发布-订阅事件	数据采集完成后，通知告警上下文进行规则评估	事件负载中必须携带租户ID，消费者按租户隔离处理
开放主机服务（OHS）	采集上下文对外提供统一的gRPC Ingestion API	API网关层解析Token并提取租户ID，通过gRPC Metadata传递
共享内核	多个上下文共享租户模型定义	严格限制共享内核的范围，仅包含租户ID、基础配置等不可变值对象

避坑指南： 避免在上下文之间使用“共享数据库”模式。即使只是读取，也会导致上下文之间的隐式耦合。一旦存储Schema变更，所有依赖方都需要同步调整，这在多租户场景下极易引发数据隔离事故。

4.5 代码示例：基于DDD的租户感知数据采集服务

以下是一个简化的Go代码片段，展示了如何在数据采集上下文中，通过防腐层隔离租户逻辑与核心写入逻辑。

// 定义租户上下文的值对象
type TenantContext struct {
    TenantID   string
    PlanTier   string // 如: "free", "pro", "enterprise"
    SampleRate float64
}

// 防腐层接口：隔离外部存储实现
type MetricsRepository interface {
    Write(ctx context.Context, tenant TenantContext, points []MetricPoint) error
}

// 采集服务的核心领域服务
type IngestionService struct {
    repo MetricsRepository
}

func (s *IngestionService) Ingest(ctx context.Context, rawPoints []RawMetric) error {
    // 1. 从gRPC Metadata中提取租户信息
    tenant := extractTenantFromContext(ctx)

    // 2. 应用租户级别的采样策略
    sampledPoints := applySampling(rawPoints, tenant.SampleRate)

    // 3. 转换为领域对象
    metricPoints := convertToDomain(sampledPoints)

    // 4. 通过防腐层写入，防腐层内部处理租户隔离
    return s.repo.Write(ctx, tenant, metricPoints)
}

// 防腐层实现示例（适配不同的后端）
type VictoriaMetricsRepo struct {
    client *vm.Client
}

func (r *VictoriaMetricsRepo) Write(ctx context.Context, tenant TenantContext, points []MetricPoint) error {
    // 在写入时，将租户ID作为标签注入
    for i := range points {
        points[i].Labels["tenant_id"] = tenant.TenantID
    }
    return r.client.Write(ctx, points)
}

4.6 边界划分的最终检查清单

在完成服务边界定义后，建议使用以下清单进行验证：

✅ 租户隔离性： 每个限界上下文是否都能独立验证租户身份？是否存在绕过租户检查的路径？
✅ 数据所有权： 每个数据实体（指标、日志、链路）是否只有一个明确的归属上下文？
✅ 通信契约： 上下文之间的API或事件契约是否已经版本化？是否支持向后兼容？
✅ 独立演进： 修改一个上下文的内部实现（如更换存储引擎），是否不需要修改其他上下文？
✅ 部署独立性： 每个限界上下文是否可以被独立部署、扩缩容和故障隔离？

通过DDD的战略设计，我们将原本混沌的“可观测性大泥球”拆解为职责清晰、边界明确的多个微服务。这不仅为后续的数据传输优化（如基于租户的分区路由、采样策略）奠定了架构基础，也确保了系统在支撑成千上万个租户时，仍能保持高度的可维护性和数据安全性。