「产品矩阵平台」总体架构蓝图

第一章 总体架构蓝图

1.1 平台化战略与多产品矩阵目标

一、从“单体应用”到“产品矩阵”的必然趋势

企业在初期往往以一个核心产品起家：

• 一个小程序，一个 Web 站点，一个用户系统；
• 后端采用单体服务，业务逻辑写在同一个代码仓；
• 每次上线更新，全部服务同时发布。

当业务增长后：

• 产品线拆分：工具类、媒体类、电商类；
• 数据割裂：用户重复注册、支付系统重复接入；
• 成本上升：每个应用都要独立部署、独立维护。

此时企业面临第二阶段转型：平台化。
即从「单点业务支撑」转向「统一底座 + 多产品矩阵」。

二、平台化的核心定义

平台化不仅是代码复用，更是一个系统能力体系。

三、平台化的收益模型

四、战略目标总结

1.2 架构哲学与技术思维模型

平台架构不仅是技术产物，更是“组织战略的物化形式”。

一、系统设计哲学：从抽象到可操作的系统观

1. 抽象共性（Abstraction）
   提炼共通模块：用户、文件、通知、支付、配置等。
2. 隔离差异（Isolation）
   不同App拥有独立配置、主题、行为逻辑。
3. 组合复用（Composition）
   模块以“组合”方式装配，不通过继承或耦合。
4. 可观察性（Observability）
   每个模块都有日志、指标、事件。
5. 演进性（Evolvability）
   平台支持持续迭代和灰度扩展，不冻结架构。

二、架构的“三维模型”

架构设计的核心，就是在这三维之间找到平衡。

三、平台型系统的复杂性来源

1.3 平台总体蓝图与分层结构

平台采用“四层十域架构模型（4-Layer / 10-Domain Architecture）”。

一、四层架构

二、十个核心领域（Domain）

三、分层交互关系图

graph TD
    A[前端应用层] --> B[API Gateway]
    B --> C[服务层（Service Modules）]
    C --> D[数据访问层（Repository）]
    D --> E[基础设施层（Infra）]
    E --> F[监控、日志、部署、缓存、队列]

四、模块边界定义原则（DDD 思维）

每个模块是一个独立的限界上下文（Bounded Context），具备：

• 独立路由命名空间 /api/v1/{module}/...
• 独立的表结构（附带 tenant_id）
• 独立的事件定义与订阅规则
• 独立的 Provider 初始化生命周期

1.4 技术栈选型与决策原则

平台选型遵循以下四项原则：

一、核心语言与框架选型

二、数据库与缓存设计模式

三、服务通信模式

1.5 系统内核设计哲学（Kernel Architecture）

平台的内核（Kernel）是所有模块的「心脏」。

它负责：

• 模块注册与生命周期管理；
• 全局依赖注入；
• 事件与任务调度；
• 全局上下文（Tenant、User、Request）的统一注入。

一、模块注册机制

// Kernel 模块注册
func RegisterModule(m Module) {
    modules = append(modules, m)
    m.Boot()
}

模块需实现统一接口：

type Module interface {
    Name() string
    Boot() error
    RegisterRoutes(r *gin.Engine)
    InitModels(db *gorm.DB)
}

系统启动时，自动加载所有 app/modules/*/module.go 文件。

二、生命周期控制

三、事件调度系统（Event Dispatch）

模块间解耦通过事件系统完成：

Event.Emit("user.created", user)
Event.On("user.created", commerce.HandleNewUser)

四、配置与依赖注入（DI）

平台使用 Provider 模式自动注入依赖：

container.Bind("payment.gateway", func() PaymentGateway {
    return NewWxPayGateway(config)
})

模块调用：

gateway := container.Get("payment.gateway").(PaymentGateway)
gateway.Charge(...)

1.6 模块化与微内核模式（Microkernel Architecture）

一、核心思想

平台采用微内核 + 插件化模块结构：

• Kernel (内核) 负责系统生命周期、事件总线、依赖注入、配置加载。
• Module (模块) 承载独立业务逻辑。
• Plugin (插件) 扩展内核或模块功能，例如日志采集、AI 任务。

Kernel
 ├─ Core Services (DI、EventBus、Config)
 ├─ System Modules (User、Tenant、File、Notify)
 └─ Plugins (Analytics、AI、Payment、Form)

二、模块通信机制

1. 接口化通信（Interface Driven）

每个模块暴露 Interface 接口，禁止直接引用内部结构体。

// commerce/interface.go
type OrderService interface {
    CreateOrder(ctx context.Context, u *User, itemID string) (*Order, error)
}

其他模块通过 DI 调用：

orderService := container.Get("commerce.order").(commerce.OrderService)
orderService.CreateOrder(...)

2. 事件驱动（Event Driven）

模块通过 EventBus 异步协作：

Event.Emit("order.created", order)
Event.On("order.created", analytics.RecordOrder)

3. RPC 内部调用（gRPC / Local RPC）

适用于跨进程模块通信（微服务拆分后）。

三、插件系统设计

插件清单存储于 plugins 表：

四、热插拔与动态加载

内核监听 plugins 配置变化事件：

Event.On("plugin.enabled", func(p Plugin) {
    loader.Load(p)
})

支持运行时加载 .so 动态库或 Go Module 热注册（使用 plugin 包或 wasm 沙箱）。

五、模块依赖可视化

graph LR
    A[Kernel]
    A --> B[User]
    A --> C[Tenant]
    A --> D[File]
    A --> E[Commerce]
    B --> E
    C --> E
    E --> F[Notify]
    E --> G[Analytics]
    G --> H[AI Plugin]

1.7 多租户与多应用体系设计

一、Tenant 模型层级

二、租户上下文注入

每个请求经 Middleware 解析 Tenant/App：

func TenantMiddleware(c *gin.Context) {
    appID := c.Request.Header.Get("X-App-ID")
    tenant := tenantRepo.FindByAppID(appID)
    c.Set("tenant", tenant)
    c.Next()
}

GORM Hook 自动附加 tenant_id：

db.Callback().Create().Before("gorm:create").Register("add_tenant", func(db *gorm.DB) {
    if tenant := GetTenantFromCtx(db.Statement.Context); tenant != nil {
        db.Statement.SetColumn("tenant_id", tenant.ID)
    }
})

三、隔离策略

四、配置继承层次

系统默认配置
   ↓
租户层覆盖（Tenant Config）
   ↓
应用层覆盖（App Config）
   ↓
运行时动态调整（Feature Flag）

五、租户注册生命周期

sequenceDiagram
    participant Dev as 开发者
    participant Platform as 平台API
    participant DB as Database
    Dev->>Platform: POST /api/tenant/register
    Platform->>DB: Insert tenant, create app
    Platform-->>Dev: 返回 AppID + Secret

1.8 平台级通用中台能力

一、用户中心 (User Center)

• 支持 WeChat/Apple/Email 登录；
• UnionID 跨App合并；
• 用户画像（Profile + 行为埋点）；
• Token / RefreshToken 统一管理。

二、内容中心 (CMS)

• 富文本 / 视频 / 文章 / 评论；
• 多语言、多主题；
• 内容审核与工作流。

三、文件中心 (File Service)

• 上传、裁剪、缩略、版本；
• 多云支持（OSS/S3/MinIO）；
• 签名下载与访问统计。

四、通知中心 (Notification)

• 短信、邮件、订阅消息、Webhook；
• 模板化变量 + 条件触发；
• 异步队列 + 重试机制。

五、支付中心 (Payment)

• 聚合微信、支付宝、Stripe；
• 分账、退款、风控；
• 异常对账与账单导出。

六、配置中心 (Config Center)

• Feature Flag 灰度发布；
• 环境变量、动态参数；
• YAML/JSON 远程同步。

1.9 数据流与消息流架构

一、核心理念

数据分三类：

1. 交易数据（Transactional） → MySQL；
2. 行为数据（Behavioral） → Kafka → ClickHouse；
3. 配置数据（Config） → Redis Cache。

二、同步与异步协同

三、Outbox Pattern 实现

确保消息与事务一致：

// 事务中写入 Outbox
tx.Create(order)
tx.Create(Outbox{Event: "order.created", Payload: order})
// 异步守护进程扫描 Outbox 表并发布到 Kafka

四、消息流可视化

graph LR
    A[API Gateway] --> B[Kafka Topic]
    B --> C[Worker]
    C --> D[ClickHouse]
    C --> E[Notify Center]
    C --> F[AI Engine]

1.10 高可用与弹性扩展机制

一、可用性设计目标

二、限流与熔断策略

limiter := rate.NewLimiter(rate.Every(100*time.Millisecond), 10)
if !limiter.Allow() { return 429 }

熔断采用 Netflix Hystrix 思想封装。

三、分布式锁与一致性

使用 Redis RedLock：

lock := redsync.New(pool).NewMutex("order_lock")
lock.Lock(); defer lock.Unlock()

四、健康检查与自愈

• /healthz 接口；
• 自动重启策略；
• 灰度 Traffic Shifting 控制。

1.11 安全、合规与数据主权

一、核心安全域

二、隐私与合规

• 遵守 GDPR / CCPA；
• PII 字段（手机号、邮箱）加密存储；
• 数据主权：租户数据可导出、可销毁。

三、API 签名机制

stringToSign = method + path + timestamp + body_md5
signature = HMAC-SHA256(secret, stringToSign)

1.12 架构演进路线与未来展望

一、阶段化路线

二、组织与架构匹配模型

三、未来五年演进目标

1. 平台 → SaaS → PaaS 生态；
2. DSL 驱动配置化；
3. AIOps 自动治理；
4. 全球化多节点部署；
5. 自研 “Platform Kernel 2.0”。

下一步计划

第二章：核心技术架构层
将深入：

1. API Gateway 设计与请求流；
2. 服务注册与依赖注入内核源码；
3. 事件驱动 + 异步任务框架；
4. Goravel ORM Hook 与多租户封装；
5. 缓存一致性与事务模型；
6. 高性能通信通道（gRPC、WebSocket）。