日历产品

工具办公软件案例ID：240621

奔跑的窗口

10 年经验· 京东

微信扫码沟通，客服可协助直接对接工程师；如当前档期不合，也可继续推荐相似案例作者。

案例介绍

日历原为单体架构，存在“循环日程”数据模型平铺导致的数据膨胀（单表数
据量过亿）、日历模型扩展性不够，日程与会议室资源强耦合等问题，导致维护
成本高、查询性能差。
核心挑战与行动：
1. DDD 领域重构：主导系统重构，重新划分业务边界。将原来的单体应用拆分为三个
服务，A 作为代理服务，负责与 Exchange 的交互细节；B 作为领域核心服
务，负责日历的管理、日程的管理、参与人的管理等，只关注领域事件；C 作为前
台服务，是比较薄的一层，负责三方业务对接以及协议转换等。
2. 会议室系统与日程系统解耦：由于历史原因，会议室和日程是同一个团队维护，两
个系统间交互很不合理。识别“日程”与“会议室”为独立聚合根，将会议室资源管理从日历服
务中剥离，对于属于会议室领域的功能和数据从大象日历拆除，解决了强耦合的痛点。
3. 存储模型优化：针对“循环日程”数据膨胀问题，设计基于 RRule（递归规则）的新
型存储模型，替代旧的平铺存储方式，大幅降低数据库存储压力。到目前为止，老表的数据
量将近 1 亿，新表数据在 3000 万左右。
4. 平滑迁移方案：设计“双写 + 异步校验 + 灰度切流”的数据迁移方案，在业务无感
知的前提下，完成了海量日程数据的底层模型切换。