作者|胡腾
编辑|小智
作为企业级的微信,在业务快速发展的背景下,迭代优化的要求也越发急迫。企业微信初版的全量同步方案在快速的业务增长面前已经捉襟见肘,针对其遇到的问题,怎样做好组织架构同步优化?这是又一篇来自微信团队的技术实战。
写在前面
企业微信在快速发展过程中,陆续有大企业加入使用,企业微信初版采用全量同步方案,该方案在大企业下存在流量和性能两方面的问题,每次同步消耗大量流量,且在 iPhone 5s 上拉取 10w+ 成员架构包解压时会提示 memory warning 而应用崩溃。
全量同步方案难以支撑业务的快速发展,优化同步方案越来越有必要。本文针对全量同步方案遇到的问题进行分析,提出组织架构增量同步方案,并对移动端实现增量同步方案的思路和重难点进行了讲解。
企业微信业务背景
在企业微信中,组织架构是非常重要的模块,用户可以在首页的 tab 上选择"通讯录"查看到本公司的组织架构,并且可以通过"通讯录"找到本公司的所有成员,并与其发起会话或者视频语音通话。
组织架构是非常重要且敏感的信息,企业微信作为企业级产品,始终把用户隐私和安全放在重要位置。针对组织架构信息,企业管理员具有高粒度隐私保护操作权限,不仅支持个人信息隐藏,也支持通讯录查看权限等操作。
在企业微信中,组织架构特征有:
1、多叉树结构。叶子节点代表成员,非叶子节点代表部门。部门最多只有一个父部门,但成员可属于多个部门。
2、架构隐藏操作。企业管理员可以在管理后台设置白名单和黑名单,白名单可以查看完整的组织架构,其他成员在组织架构里看不到他们。黑名单的成员只能看到自己所在小组和其所有的父部门,其余人可以看到黑名单的成员。
3、组织架构操作。企业管理员可以在 web 端和 app 端添加 / 删除部门,添加 / 删除 / 移动 / 编辑成员等操作,并且操作结果会及时同步给本公司所有成员。
全量同步方案的问题
本节大致讲解下全量同步方案实现以及遇到的问题。
全量同步方案原理
企业微信在 1.0 时代,从稳定性以及快速迭代的角度考虑,延用了企业邮通讯录同步方案,采取了全量架构同步方案。
核心思想为服务端下发全量节点,客户端对比本地数据找出变更节点。此处节点可以是用户,也可以是部门,将组织架构视为二叉树结构体,其下的用户与部门均为节点,若同一个用户存在多个部门下,被视为多个节点。
全量同步方案分为首次同步与非首次同步:
首次同步服务端会下发全量的节点信息的压缩包,客户端解压后得到全量的架构树并展示。
非首次同步分为两步:
服务端下发全量节点的 hash 值。客户端对比本地数据找到删除的节点保存在内存中,对比找到新增的节点待请求具体信息。
客户端请求新增节点的具体信息。请求具体信息成功后,再进行本地数据库的插入 / 更新 / 删除处理,保证同步流程的原子性。
用户反馈
初版上线后,收到了大量的组织架构相关的 bug 投诉,主要集中在:
流量消耗过大。
客户端架构与 web 端架构不一致。
组织架构同步不及时。
这些问题在大企业下更明显。
问题剖析
深究全量同步方案难以支撑大企业同步的背后原因,皆是因为采取了服务端全量下发 hash 值方案的原因,方案存在以下问题:
拉取大量冗余信息。即使只有一个成员信息的变化,服务端也会下发全量的 hash 节点。针对几十万人的大企业,这样的流量消耗是相当大的,因此在大企业要尽可能的减少更新的频率,但是却会导致架构数据更新不及时。
大企业拉取信息容易失败。全量同步方案中首次同步架构会一次性拉取全量架构树的压缩包,而超大企业这