钉钉架构设计
钉钉架构设计方案
万人群高流量支撑
IM场景下万人群的高流量支撑是非常有挑战的事情。为了解决这个问题，钉钉进行了以下优化：
降低存储扩散量
- 最初使用的是写扩散模型，一条消息需要写一万次收件箱。
- 优化成读扩散模型后，只需要写一次收件箱，扩散量降低到万分之一。
智能限流
- 当总体消息量超过系统阈值时，智能限流机制可以根据当前流量情况对群进行限制，防止误杀。
万人群成员多级缓存
- 在钉钉客户端和服务端做群成员的多级缓存，提高了at列表和查看群成员等场景的体验，并降低了DB的读写压力，提高了系统稳定性。
端到端体验保障
- 客户端定期进行极限压测，在群消息大规模刷屏时，保障用户体验流畅不卡顿。
历史消息可回溯
在ToB场景下，数据是企业的资产。企业对于历史消息有查询需求，而微信的离线消息是存在客户端的，清空就没有了。钉钉通过将近时消息推送到客户端本地，历史消息在服务端进行处理，保证消息无遗漏地同步下来。
场景化支持
ToC IM产品场景化都比较通用，但钉钉针对不同场景体验做了不同支持。这带来了以下挑战：
- 系统模型必须扩展性强：可以灵活、快速支持业务场景化需求。
- 在保障支持业务快速的情况下，保持IM核心系统高可用。
以钉钉班级群为例，使用小程序开发，可以不发版做bugfix，实现业务需求迭代。服务端切分为业务层和Im Core层，实现了新需求不改动Im Core层，从而达到业务和技术共同迭代的目的。
单元化
单元化满足了多层需求：
- 高可用：钉钉保障vip用户的地域级别容灾能力，设计了一套基于单元化异地容灾方案。
- 国际化：海外地区对于数据有合规要求，当地部署应用，提供流畅的用户体验。
- 支持大客户及特殊行业：钉钉不仅承接了中小企业沟通办公需求，还承接不少政企用户，需要具备云部署能力。
- 容量：随着业务发展，扩展性差，把流量分散到多个地域是一个必然选择。
钉钉通过一套代码部署、一套运维体系实现了单元化，满足了上层多种需求。技术团队开发了一系列基础设计，如动态路由、业务层数据同步组件等，可以将钉钉部署在任一国家、地区，甚至用户的自有机房。
