容量架构：将流量打到不同的单元，每个单元各自承载流量
容量架构不是设计出来的，而是真真切切被逼出来的
第一步：找到自己的业务拆分维度
钉钉业务的3个主要维度：
- UID
- 会话 CID
- 消息：量级最大，且和会话绑定
钉钉最终选择的业务路由维度：“会话”
路由系统
钉钉场景下，包含会话维度、房间维度、企业维度，需要构建一个全局业务路由系统实现流量的精确路由 。以会话为例，发送的每条消息，都会经过 receiver 系统的路由服务。这样路由服务就会成为比较大的瓶颈
解决方案：端到端路由。具体方案：
- 客户端缓存用户最热门的 N 个会话路由
- 服务端 SDK 校验路由的合法性以及续约
- 客户端路由缓存更新机制：
- 客户端本地基于返回结构是否有新的路由信息，来更新本地的路由缓存
- 如果遇到问题，可以发起主动推送更新路由的方式
多单元涉及到数据同步的问题，采用的方案为：存储系统维护，多数派写入成功即返回
容灾能力
钉钉的容灾主要确保：最终一致性，可以短暂允许部分环节失败。
某单元完全不可用时，用户消息发送降级为 local 模式，直接在其他单元通过回放推送非对应单元的数据。
第二阶段：成本与体验的权衡
混合云架构：
- 云下作为基本盘，保障核心流量的问题
- 云上应对高涨异常的流量，借助云的弹性能力应对不确定的用户流量变化
混合云架构的两个明显变化：
- 云原生技术：
- 使用 DDD 分层，对外提供的接口和依赖都收拢
- Sidecar: 实现应用和中间件解耦
- 互通网关：双向的ingress 和 egress, 支持 rpc 的多个协议
