钉钉的设计理念方面，我可以学习
除了“5 张基座表 + 权限模型”，钉钉在「基座设计理念」层面还有 7 条值得直接抄作业的“底层思想”。
它们大部分不会出现在 ER 图里，却是让钉钉能扛 10w 级组织和亿级并发仍能横向扩容、纵向加功能的核心原因。
一、Identity-First 设计（一切从身份出发）
- 全局唯一 ID 格式 =
uid@tenant_id@idp_type（含身份源） - 任何 URL、日志、MQ 事件里先出现身份，再出现业务
- 好处：跨云、跨合并、跨收购时永不重号；审计可直接 grep
抄：Day-0 就在 JWT 里预埋
idp字段，以后接 SAML/社交登录无需改表
二、「IM-Core + Biz-Skin」两层架构
- Core 层：只负责“消息/通道/序列表”——万年不动
- Skin 层：审批、日历、打卡等业务微服务通过事件挂到 Core
- 结果：班级群、客户群、政府钉共用同一套 IM 引擎，却出现完全不同的交互
抄：把“实时消息”单独一个 schema，其他业务只许订阅消息表不许改它
三、多级缓存 = 体验护城河
- L1 客户端（群成员 5k 人以下全量缓存）
- L2 Redis（at 列表、群卡片）
- L3 本地内存（Guava 缓存 30s）
- 万人群拉列表仍 <200ms，DB 0 命中
抄：Day-1 就给群成员/在线列表加
Cache-Aside + Redis + 客户端增量 diff三板斧
四、冷热分离 + 单元化 = 成本腰斩
- 近 7 天消息 SSD 热库（MySQL）
- 历史消息 高压缩冷库（自研盘古 + ZSTD，>5× 压缩比）
- 按 tenant_id 做单元化（Unit-Based Sharding）→ 单单元故障只影响 1/64 租户
抄：消息表按时间分区 +
tenant_id HASH 64子分区，归档时直接 drop partition
五、Feature-Flag > Code-Branch
- 任何功能（甚至 IM 的“已读”）都先上租户级开关 → 灰度 → 全量
- 开关位不在代码里，而在配置中心；发版与发布解耦
- 紧急回滚 = 1 条 SQL 改
perm_tenant_feature.status='off'
抄：Day-0 就把“打卡”做成 featureCode，默认 off；演示时现场
UPDATE SET status='on'就能亮功能
六、安全左移 + 零信任通道
- 链路全加密（TLS1.3 + 国密 SM4 可选）
- 租户密钥独立轮换 → 即使全局证书泄露也拆不散单组织数据
- 客户端定期极限压测（4k 视频+万人群刷屏）→ 发现热点提前扩容
抄：把“证书/密钥”放进 KMS，每租户一条主密钥；压测脚本 CI 每晚跑
七、PaaS 优先，SaaS 其次
- 钉钉自己只保“IM + 通讯录 + 文档”核心，其余用 aPaaS/bPaaS 让生态填
- 提供小程序容器 + 事件总线 + 统一身份→ 第三方等于“插拔式微服务”
- 结果：功能无限扩张，Core 却永不动
抄：Day-30 就把“审批/打卡/项目”做成独立小程序 runtime，基座只给 SDK 和身份事件
八、如何“学以致用”清单（可直接落地）
| 钉钉理念 | 你的落地动作 | 时间 |
|---|---|---|
| Identity-First | JWT 含 tenant+idp+region | Day-0 |
| IM-Core 独立 | message 表禁止业务外键 | Day-0 |
| 多级缓存 | 群成员 Redis+客户端缓存 | Day-7 |
| 冷热分离 | 消息按时间分区，>30 天迁冷 | Month-1 |
| Feature-Flag | perm_tenant_feature 表+配置中心 | Day-0 |
| 单元化 | tenant_id HASH 64 子分区 | Month-2 |
| PaaS 化 | 提供小程序 runtime & 事件总线 | Month-3 |
一句话总结
钉钉基座真正值钱的不是表，而是“身份先行、core/skin 分离、缓存多级、冷热单元、开关优先、安全零信任、生态 PaaS”七条设计哲学；
把它们抄进你的 Day-0 规范，后续加功能就像给乐高加积木——只插拔，不拆地基。