作者｜胡腾

编辑｜小智

作为企业级的微信，在业务快速发展的背景下，迭代优化的要求也越发急迫。企业微信初版的全量同步方案在快速的业务增长面前已经捉襟见肘，针对其遇到的问题，怎样做好组织架构同步优化？这是又一篇来自微信团队的技术实战。

写在前面

企业微信在快速发展过程中，陆续有大企业加入使用，企业微信初版采用全量同步方案，该方案在大企业下存在流量和性能两方面的问题，每次同步消耗大量流量，且在 iPhone 5s 上拉取 10w+ 成员架构包解压时会提示 memory warning 而应用崩溃。

全量同步方案难以支撑业务的快速发展，优化同步方案越来越有必要。本文针对全量同步方案遇到的问题进行分析，提出组织架构增量同步方案，并对移动端实现增量同步方案的思路和重难点进行了讲解。

企业微信业务背景

在企业微信中，组织架构是非常重要的模块，用户可以在首页的 tab 上选择"通讯录"查看到本公司的组织架构，并且可以通过"通讯录"找到本公司的所有成员，并与其发起会话或者视频语音通话。

组织架构是非常重要且敏感的信息，企业微信作为企业级产品，始终把用户隐私和安全放在重要位置。针对组织架构信息，企业管理员具有高粒度隐私保护操作权限，不仅支持个人信息隐藏，也支持通讯录查看权限等操作。

在企业微信中，组织架构特征有：

1、多叉树结构。叶子节点代表成员，非叶子节点代表部门。部门最多只有一个父部门，但成员可属于多个部门。

2、架构隐藏操作。企业管理员可以在管理后台设置白名单和黑名单，白名单可以查看完整的组织架构，其他成员在组织架构里看不到他们。黑名单的成员只能看到自己所在小组和其所有的父部门，其余人可以看到黑名单的成员。

3、组织架构操作。企业管理员可以在 web 端和 app 端添加 / 删除部门，添加 / 删除 / 移动 / 编辑成员等操作，并且操作结果会及时同步给本公司所有成员。

全量同步方案的问题

本节大致讲解下全量同步方案实现以及遇到的问题。

全量同步方案原理

企业微信在 1.0 时代，从稳定性以及快速迭代的角度考虑，延用了企业邮通讯录同步方案，采取了全量架构同步方案。

核心思想为服务端下发全量节点，客户端对比本地数据找出变更节点。此处节点可以是用户，也可以是部门，将组织架构视为二叉树结构体，其下的用户与部门均为节点，若同一个用户存在多个部门下，被视为多个节点。

全量同步方案分为首次同步与非首次同步：

首次同步服务端会下发全量的节点信息的压缩包，客户端解压后得到全量的架构树并展示。

非首次同步分为两步：

服务端下发全量节点的 hash 值。客户端对比本地数据找到删除的节点保存在内存中，对比找到新增的节点待请求具体信息。

客户端请求新增节点的具体信息。请求具体信息成功后，再进行本地数据库的插入 / 更新 / 删除处理，保证同步流程的原子性。

用户反馈

初版上线后，收到了大量的组织架构相关的 bug 投诉，主要集中在：

流量消耗过大。

客户端架构与 web 端架构不一致。

组织架构同步不及时。

这些问题在大企业下更明显。

问题剖析

深究全量同步方案难以支撑大企业同步的背后原因，皆是因为采取了服务端全量下发 hash 值方案的原因，方案存在以下问题：

拉取大量冗余信息。即使只有一个成员信息的变化，服务端也会下发全量的 hash 节点。针对几十万人的大企业，这样的流量消耗是相当大的，因此在大企业要尽可能的减少更新的频率，但是却会导致架构数据更新不及时。

大企业拉取信息容易失败。全量同步方案中首次同步架构会一次性拉取全量架构树的压缩包，而超大企业这个包的数据有几十兆，解压后几百兆，对内存不足的低端设备，首次加载架构可能会出现内存不足而 crash。非首次同步在对比出新增的节点，请求具体信息时，可能遇到数据量过大而请求超时的情况。

(责任编辑：本港台直播)