企业级IM的联系人组织架构设计

引言

从技术角度去讲企业微信，不是一件容易的事，因为涉及面太广。企业微信是一套包含了IM、办公协作、OA流程、CRM管理、第三方开放 等等多个维度的复杂性的超级SaaS办公系统。底层拥有着数千万行的客户端代码 以及 遍布世界的服务器系统。

组织架构架构设计

企业微信发展至今，其通讯录关系链结构经过了多轮演化，形成了一套非常复杂的结构，并在关系链领域拥有着绝佳的优势。

为了方便理解，我把企业微信的关系链结构定义为四维关系链系统。这里的四维不是空间的维度，而是关系链拓展连接能力抽象的层级。

一维关系链：链式结构

一维关系链的基础结构，是链式结构，由节点与节点的连接组成。
这种结构的典型代表有还手机通讯录、QQ、微信。这个很容易理解。每个人都是一个节点，人与人的单向或双向的关系，则为节点之间的连接。

每个人和自己的通讯录成员的关系链如下：

当进入到云端，因为每一个代表人的原点，都是独立存在而不重复的，每个人的关系链就是可以互相链接起来的，结合更多人的通讯录成员关系，就会形成一张巨大的网状结构。
美国某位心理学家StanleyMilgram 提出的六度人脉就是基于网状的拓扑关系，推算我们每个人和世界上的任何一个陌生人之间间隔的链接个数不会超过6层。
当然，这个推算只是一个理论上的关系抽象，截止目前，世界上还并没有出现真的链接了全世界人口的App系统。目前链接最多活跃人口的whatsapp的记录是20亿的量级。

二维关系链：组织结构

二维关系链，在一维关系链的基础之上，额外增加了组织的关系。

同一个节点可以归属于不同的多个组织。用以形成常规的树状组织架构关系。

企业级IM，就是将全部成员纳入同一个组织，是该结构最基础的抽象。

该结构下：相同组织的成员互相可见，互相可通信。

**其实：**用一维关系链也是可以模仿该结构，就是把全企业的人默认全部互为好友，也会拥有类似效果，但这样做无疑就太复杂了一些，不如用抽象的组织关系来替代者个关联关系。

**实际上：**真实的企业类组织的关系都是多层结构，就像我们电脑上的文件目录结构，层层包含。没有“组织”的抽象，是很难完成企业IM的基础搭建的。

三维关系链：属性抽象

一维和二维都非常简单直白，到了三维，会稍微复杂一点。

三维关系链，在二维的基础之上，我们在关系链系统中引入“属性” 与 “操作权限” 的概念。

我们也可以把二维关系中的“组织”也看做属性的一种，但是“属性”维度明显能涵盖得更多。能够进行按属性为单位的抽象管理，是一个新维度的拔升。

这个维度的提升，让复杂组织的管理变得容易管理与拓展。也是企业微信在大型企业的使用中足够灵活好用的关键之一。

这些灵活的运用：

1）体现在企业组织管理的精细化能力； 
2）实现多个紧密合作企业之间的互联关系； 
3）实现拥有多层上下级结构的集团关系网； 
4）实现联合行业级大批量企业关联互通的上下游架构 … …

参考：参考链接即时通讯网

企业微信针对百万级组织架构的客户端性能优化

相对于传统的消费级IM应用，企业级IM应用的特殊之外在于它的用户关系是按照所属企业的组织架构来关联的起来，而组织架构的大小是无法预设上限的，这也要求企业级IM应用在遇到真正的超大规模组织架构时，如何保证它的应用性能不受限于（或者说是尽可能不受限于）企业架构规模，这是个比较有难度的技术问题。

100万级组织架构时的性能问题

当私有化的组织架构上升到100W的量级时，出现了严重影响组织架构使用的问题：打开二级部门时，加载缓慢。

如图所示，loading可能持续一分钟以上：

100万级组织架构的问题分析

分析一下加载二级部门的流程。

下面是加载二级部门的流程图：

1）如果从来没加载过该部门，需要从服务端拉取部门下的节点详情（这里是因为之前我们已经做了优化，首次登录时只拉取了部门的节点ID，没有拉取详情）；
2）如果加载过该部门，就直接从DB读取该部门的数据，然后返回UI展示。

当只有一条DB线程时，组织架构更新的任务，可能会插入到加载二级部门的任务的前面。而在百万级别的组织架构中，全量更新的DB任务有可能比较久，全量更新的插入或者更新节点可能比较多，导致本来很快可以完成的二级部门加载任务，要排队比较久才能执行完。
下面是组织架构全量更新的流程图：