第三章 平台通用能力中心
平台通用能力中心的价值，是把每个产品都会重复建设的能力沉淀下来，让新业务不再从登录、上传、通知、权限、审计重新开始。
判断一个能力是否应该进入平台中心，可以看三个问题：
- 是否被两个以上产品重复使用？
- 是否有统一治理、安全或合规要求？
- 是否会影响开发效率、运营效率或商业化效率？
如果答案是肯定的，就不应该放任各产品线各自实现。
3.1 用户中心与账户体系
用户中心不是简单的 users 表，而是跨产品识别同一个人的能力。
| 对象 | 含义 | 示例 |
|---|---|---|
| Account | 平台账户主体 | 手机号、邮箱、企业账号 |
| Identity | 第三方身份 | 微信 OpenID、Apple ID、GitHub |
| Profile | 用户资料 | 昵称、头像、地区 |
| Membership | 用户与租户关系 | 企业成员、团队角色 |
在微信生态中，OpenID 通常与 App 绑定，UnionID 才适合做跨应用合并。平台要允许一个 Account 绑定多个 Identity，同时保留解绑、换绑和冲突处理流程。
典型合并规则：
| 场景 | 处理方式 |
|---|---|
| 同一手机号登录两个 App | 绑定到同一 Account |
| 同一 UnionID 首次进入新 App | 自动创建 Identity 并关联 |
| 手机号已存在但微信身份未绑定 | 二次确认后绑定 |
| 企业成员离职 | 解除 Membership，不删除 Account |
3.2 统一认证授权中心
认证解决“你是谁”，授权解决“你能做什么”。很多平台的问题，是把这两件事混在 Controller 里，最后每个接口都有一段不一样的判断逻辑。
建议认证中心提供：
| 能力 | 说明 |
|---|---|
| SSO | 管理台、多产品后台一次登录 |
| OAuth2 | 第三方应用授权访问平台资源 |
| Token Service | Access Token 与 Refresh Token 生命周期 |
| Session 管理 | 设备列表、踢下线、异常登录提醒 |
授权可以采用 RBAC + ABAC：
RBAC：角色决定基础权限，例如 admin、editor、viewer
ABAC：属性决定上下文权限，例如只能编辑本部门内容、只能查看当前租户数据
RBAC 易理解，ABAC 更灵活。平台早期可以先落 RBAC，但权限表达模型要给 ABAC 留位置。
3.3 多应用配置中心
配置中心要管理的不只是环境变量，还包括产品行为。
| 配置层级 | 示例 |
|---|---|
| 平台默认 | 默认上传大小、默认短信渠道 |
| 租户覆盖 | 企业 Logo、默认语言、套餐限制 |
| App 覆盖 | 小程序主题、入口开关 |
| 运行时灰度 | 新版编辑器、实验功能 |
配置必须有版本。一次配置变更应该记录：
- 修改前后的 diff；
- 影响租户和 App；
- 操作人和审批人；
- 发布时间；
- 回滚版本。
否则配置中心会变成一个没有历史的“在线改数据库”。
3.4 文件中心
文件中心的难点不是上传，而是生命周期。
| 阶段 | 需要处理的问题 |
|---|---|
| 上传前 | 类型限制、大小限制、权限校验 |
| 上传中 | 分片、断点续传、病毒扫描 |
| 上传后 | 缩略图、转码、元数据、CDN |
| 使用中 | 私有访问、签名链接、防盗链 |
| 废弃后 | 归档、清理、引用检查 |
文件表建议至少包含：
| 字段 | 含义 |
|---|---|
tenant_id | 租户隔离 |
bucket | 存储桶 |
object_key | 对象存储路径 |
mime_type | 文件类型 |
size | 文件大小 |
checksum | 去重和完整性校验 |
visibility | public / private |
metadata | 图片宽高、视频时长等 |
3.5 通知中心
通知中心要统一处理“什么时候通知、通知谁、用什么渠道、失败怎么补偿”。
| 渠道 | 典型用途 | 注意点 |
|---|---|---|
| 短信 | 验证码、关键告警 | 频率限制、签名模板 |
| 邮件 | 账单、邀请、报表 | 退信处理、域名信誉 |
| 订阅消息 | 小程序服务通知 | 用户授权、模板审核 |
| Webhook | 第三方系统集成 | 签名、重试、死信 |
| 站内信 | 产品内消息 | 已读状态、聚合策略 |
通知模板应支持变量、语言、渠道和版本。模板上线前要有预览和测试发送，否则一次变量名写错就会批量发出难看的消息。
3.6 日志中心
日志中心至少分三类：
| 日志类型 | 用途 | 示例 |
|---|---|---|
| 应用日志 | 排查程序异常 | error、panic、dependency timeout |
| 访问日志 | 分析接口行为 | path、status、latency、request_id |
| 业务日志 | 追踪关键动作 | order_paid、member_invited |
所有日志必须带 trace_id、tenant_id、app_id。没有这些字段，出了跨租户问题时，日志几乎无法定位。
3.7 审计中心
审计日志和普通日志不同。普通日志服务工程排障，审计日志服务合规、追责和取证。
审计记录建议包含：
| 字段 | 说明 |
|---|---|
| actor | 谁操作 |
| action | 做了什么 |
| resource | 操作对象 |
| before / after | 关键字段变化 |
| ip / user_agent | 来源信息 |
| reason | 审批或操作原因 |
审计日志不应随业务表删除而删除。对高合规场景，应采用追加写、不可变存储或冷归档。
3.8 权限与策略中心
当产品矩阵扩展到多个后台、多个团队、多个租户时，权限规则会快速膨胀。策略中心要把权限判断从业务代码中抽离出来。
权限表达可以采用：
subject: user:123
action: content:update
resource: article:456
context: tenant=acme, app=cms, department=editorial
策略判断结果不只返回允许或拒绝，还应返回原因，方便后台展示和排障。
3.9 GitOps 配置下发
平台配置不一定都要在 UI 中直接修改。对基础设施、网关路由、告警规则、K8s 配置，GitOps 更适合。
推荐流程：
graph LR
A[修改配置仓库] --> B[Pull Request]
B --> C[Review + CI 校验]
C --> D[Merge]
D --> E[ArgoCD 同步]
E --> F[集群生效]
这种流程把配置变更纳入代码审查和回滚体系，尤其适合生产环境。
3.10 通用能力中心建设顺序
不要一开始就把所有中心都做成大平台。更合理的顺序是：
| 阶段 | 优先建设 |
|---|---|
| 0 到 1 | 用户、认证、文件、通知 |
| 多产品阶段 | 配置、权限、日志、审计 |
| SaaS 阶段 | 租户、计费、Webhook、开放 API |
| 生态阶段 | 插件市场、开发者平台、策略引擎 |
平台化不是一次性工程，而是一组不断被业务验证的公共能力。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。