共计 6441 个字符，预计需要花费 17 分钟才能阅读完成。
本文由腾讯 WXG 客户端开发工程师 yecong 分享，本文做了订正和改变。
1、引言
绝对于传统的生产级 IM 利用，企业级 IM 利用的非凡之外在于它的用户关系是依照所属企业的组织架构来关联的起来，而组织架构的大小是无奈预设下限的，这也要求企业级 IM 利用在遇到真正的超大规模组织架构时，如何保障它的利用性能不受限于（或者说是尽可能不受限于）企业架构规模，这是个比拟有难度的技术问题。
本文次要分享的是企业微信在百对百万级大规模组织架构（后文简称大架构）时，是如何对客户端进行性能优化过程的，心愿带给你启发。
内容分成两局部讲述，第一局部是短线迭代的优化，次要是并发性能的优化。第二局部是长线迭代的优化，次要是从业务模式上做了根本性优化。
以下是相干文章，举荐一并浏览：
《企业微信客户端中组织架构数据的同步更新计划优化实战》
《企业微信的 IM 架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等》
《钉钉——基于 IM 技术的新一代企业 OA 平台的技术挑战 (视频 +PPT) [附件下载]》
《阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处》
技术交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）
（本文已同步公布于：http://www.52im.net/thread-4437-1-1.html）
2、100 万级组织架构时的性能问题
当私有化的组织架构回升到 100W 的量级时，呈现了重大影响组织架构应用的问题：关上二级部门时，加载迟缓。如图所示，loading 可能继续一分钟以上：
3、100 万级组织架构的问题剖析
咱们剖析一下加载二级部门的流程。
上面是加载二级部门的流程图：
1）如果素来没加载过该部门，须要从服务端拉取部门下的节点详情（这里是因为之前咱们曾经做了优化，首次登录时只拉取了部门的节点 ID，没有拉取详情）；
2）如果加载过该部门，就间接从 DB 读取该部门的数据，而后返回 UI 展现。
当只有一条 DB 线程时，组织架构更新的工作，可能会插入到加载二级部门的工作的后面。而在百万级别的组织架构中，全量更新的 DB 工作有可能比拟久，全量更新的插入或者更新节点可能比拟多，导致原本很快能够实现的二级部门加载工作，要排队比拟久能力执行完。上面是组织架构全量更新的流程图：
在这里，读写并发上呈现了显著的瓶颈。
起因总结如下：
1）加载二级部门和全量更新共用一条 DB 线程；
2）当全量更新大量节点时，全量更新的低优先级工作卡住加载二级部门的高优先级工作。
4、针对 100 万级组织架构的优化计划
4.1 根本
读写拆散为了进步组织架构在大规模数据下的读写并发性能，咱们开启了 wal 模式，把读写工作别离放在不同的线程中执行。针对加载二级部门的流程，能够在读线程中读取部门的详情节点，而组织架构更新能够在写线程中独自执行。因为加载二级部门的原流程是拉取数据、写入 DB、再从 DB 读取数据，而且 wal 只反对一写多读，因而咱们调整了缓存策略，把保留节点详情的写工作提早到流程最初，优先结构了 cache 返回 UI。这样从 DB 中读出数据的读工作，就不须要期待保留节点详情的写工作。防止了保留节点的写工作再次被其余写工作阻塞，读工作又被保留节点的写工作阻塞，进化成串行操作。
4.2WAL 机制的原理
调用方批改的数据并不间接写入到数据库文件中，而是写入到另外一个称为 WAL 的文件中，而后在随后的某个工夫点被写回到数据库文件中。在这个工夫点的回写操作，会升高数据库过后的读写性能。然而通过设置对 WAL 文件大小的限度，这种性能影响是可控的。实际上线后也没有遇到因为 checkpoint 同步导致数据库慢的反馈。
4.3 缓存策略
写策略的步骤：先更新缓存中的数据，再更新数据库中的数据。
读策略的步骤：
1）如果读取的数据命中了缓存，则间接返回数据；
2）如果读取的数据没有命中缓存，则从数据库中读取数据，而后将数据写入到缓存，并且返回给 UI。
4.4 计划总结
5、100 万级优化后的成果
在优化前，只有 52% 的用户能在 1s 内加载完二级部门。上线之后，93% 的用户都能在 1s 内关上二级部门。耗时小于 1s 的用户占比晋升 40%！
6、当对面 300 万组织架构时的问题
6.1 概述
当业务进一步倒退时，咱们预估将来将要达到 300W 量级的组织架构。于是咱们就开始提前布局如何能在组织架构数量始终增长的状况下，还能让组织架构晦涩好用。
6.2 问题
次要是：
1）选人控件闪退和 ANR；
2）组织架构全量更新闪退。在 300w 的组织架构环境中，旧的组织架构加载计划，在全量更新、选人控件中均呈现了占用内存过大甚至闪退的问题。而且旧计划的加载工夫会随着节点数量的减少，不可避免地成正比增长。
6.3 剖析
以后计划的耗时、内存占用与用户组织架构的大小成正比，单点优化无奈满足组织架构持续增长的需要。
具体来说，会造成上面的一些问题：
1）选人控件会加载全量的组织架构 ID 树，数量过多时容易产生闪退和 ANR；
2）组织架构全量更新占用内存过大，造成闪退。
因而，咱们须要一个新的业务模式，即使总的组织架构规模始终上涨的状况下，也能维持较好的性能。
7、针对 300 万组织架构的优化计划
比拟容易想到的一个计划是 web 加载的模式，不保留本地数据，然而体验比拟差，每层都会出 loading。分割到咱们的具体业务，因为私有化对不同的部门，划分出了具备意义的独立组织机构——单位。单位是具备治理意义的部门，不同单位能够独立加载。而每个人，也领有主单位和兼岗单位。所以能够依照单位加载的形式，从根本上解决目前组织架构面临的瓶颈。按单位加载，能够简略了解为按部门加载：
概念定义：
1）单位：政府行政组织构造中的职能部门，组建架构并承当对应责任；
2）主单位：“我”所在的单位；
3）其余单位：除了“我”所在的其余单位；
4）骨架：通讯录骨架蕴含了所有的单位节点；
5）一般部门：不属于任何单位的部门节点。下图是组织架构树的示意图：
如上图所示：蓝色节点是优先加载的本单位，灰色节点是其余单位，红色节点是骨架。不同的单位独立加载。
8、300 万优化计划中的“按单位加载”技术思路
8.1 加载策略
接下来咱们看看加载策略。
第一：是对本人所在的主单位（蓝色节点），每次唤醒时就会更新，跟旧组织架构的逻辑相似，然而会限度拉取节点的数量。
第二：对于其余单位（灰色节点），点击到该单位时才会拉取，2 个小时后会淘汰删除，防止数据表过大。
第三：对于骨架（红色节点），会全量加载节点 ID，再拉取节点详情。拉取策略限度了可能拉取的节点详情数量，如果单位节点数量超过了限度，首先拉取全量 ID，再依照优先规定，拉取配置的节点详请数量。
8.2 加载流程
加载的流程是先拉取本人的单位列表，而后拉取每个单位的全量通讯录 ID，再依照后盾策略，拉取所需的具体节点，最初拉取骨架。
如果点击到主单位：
1）如果只有 ID 没有节点，会立即拉取节点详情返回界面；
2）如果 ID 和节点详情都有，能够间接返回 UI 展现，而后提早刷新节点。
如果是点击到其余单位：可能呈现 ID 和详情都没有的状况，须要拉取其余单位的节点，界面 loading 期待。如果是骨架：就肯定有节点和详情，只须要提早刷新。
9、300 万优化计划的分层设计思路
接下来咱们看看如何分层。
在 300 万量级的大规模组织架构下，挪动端和 pc 端都呈现了组织架构卡顿、闪退的问题，所以咱们心愿可能开发一套各端共用的逻辑，对立保护。
第一：是要抽取公共的根底库，包含 boost 库、工作框架、线程治理框架等。
第二：是设计公共的数据结构。
第三：因为不同端的网络库差别比拟大，这里不好齐全共用，所以须要抽取网络工作接口，由各端独立实现。
具体到框架图，咱们从下往上看：
1）底层是根底库；
2）接着是 C ++ 实现的跨平台业务层；
3）Service 层是挪动端和 pc 端离开实现，次要是做接口调用和回调的简略封装；
4）下层则各端界面实现。
下层界面为了兼容新旧两套组织架构，也做了接口形象，能够通过开关自在切换。这样长处就是有对立的业务逻辑代码、DB 设计和线程治理。
关键点：
1）抽取公共根底库；
2）形象公共的数据结构；
3）形象网络层和数据库层接口。
长处：对立的业务逻辑代码、DB 设计、线程治理。
10、300 万优化计划的整体架构设计思路
在具体实现之前，咱们来看看架构设计的一些概念。
10.1 架构整洁之道
1）业务实体和用例：
要害业务逻辑和要害业务数据是严密相干的，所以它们很适宜被放在同一个对象中解决。咱们将这种对象称为“业务实体”。业务实体这个概念中应该只有业务逻辑，没有别的，与数据库、用户界面、第三方框架等内容无关。用例所形容的是某种特定利用情景下的业务逻辑，能够了解为：输出 + 业务实体 + 输入 = 用例。
2）软件架构：
软件的零碎架构应该为该零碎的用例提供反对。一个良好的架构设计应该围绕着用例来开展，这样的架构设计能够在脱离框架、工具以及应用环境的状况下残缺地形容用例。
3）整洁架构：
下图的同心圆别离代表了软件系统中的不同档次，越凑近核心，其所在的软件档次就越高。基本上，外层圆代表的是机制，内层圆代表的是策略。这其中有一条贯通整个架构设计的规定，即依赖关系规定：
10.2 咱们的架构
咱们的类图与架构设计概念的对应关系如下：
1）业务实体：ArchTask；
2）用例：ArchProto；
3）模型层：即最外层，各种第三方框架，如 DbInterface（数据库模块）、ArchLogicHandler（网络模块）等。
咱们从一次具体的业务调用流程来看看这样设计的意义。上面是从 UI 发动的一次架构更新流程，大家能够次要关注控制流是怎么穿梭各层的边界：控制流从最外层的用户界面开始，穿过用例（Arch），最初调用最外层的组件：网络模块和数据库模块。然而咱们源码中的依赖方向却都是向内指向用例的。这里，咱们采纳的是依赖反转准则（DIP）来解决这种相同性。咱们能够通过调整代码中的接口和继承关系，利用源码中的依赖关系，限度控制流只能在正确的中央跨域架构边界。
在下面的流程图中，次要有两个利用依赖反转准则的中央：
1）CalcPreLoadArchIDs 是从 SyncUnitArchTask（业务实体）调用调用到 ArchProto（用例）。业务实体这样的高层概念，是毋庸理解像用例这样的底层概念的。反之，底层业务用例却须要理解高层的业务实体。所以在 SyncUnitArchTask 中，其实是通过调用 ArchProto 的接口来调用 CalcPreLoadArchIDs。
SyncUnitArchTask 中的调用代码如下：
arch_service_context_->CalcPreLoadArchIDs(unit_id_, arch_service_context_->GetCurrentVid(), other_unit_click_partyid_, vecHashNode, all_tmp_ids, arch_ids, ptr_map_);
ArchProto 会在 Task 初始化时，把本人设置进 Task 中，给各类型的 Task 反向调用。classArchProto : publicArchServiceContext{…};
2）最外层的模型层个别是由工具、数据库、网络框架等组成的。
框架与驱动程序层中蕴含了所有的实现细节。从零碎架构的角度看，工具通常是无关紧要的，因为这只是一个底层的实现细节，一种达成指标的伎俩。当 Task 须要调用网络模块收发申请或者调用数据库模块获取数据时，为了防止内层策略依赖外层机制，Task 只会调用外层工具的接口层，而不会依赖实现细节。这样的架构设计给咱们带来的益处是，咱们能够轻松替换框架，而不影响内层策略。比方在桌面端，咱们会有另外一套齐全不同的网络模块实现，只须要挂接不同的网络实现子类，咱们就能够在桌面端复用新的大架构模块。良好的架构设计应该尽可能地容许用户推延和延后决定采纳什么框架、数据库、网络框架以及其余与环境相干的工具。总之，良好的架构设计应该只关注用例，并能将它们与其余的周边因素隔离。
10.3 新旧组织架构模块的交互
大架构跨平台层，跟原来的组织架构模块是怎么交互的呢？
原来的组织架构的数据表次要分成三局部：
1）部门表；
2）人员信息表；
3）部门人员关系表。
而呈现性能问题的次要在于关系表上。所以数据设计上，人员信息保留在原组织架构底层，部门人员关系表、部门表在大架构底层。
表结构设计：
1）次要组成：人员信息表、部门表、部门人员关系表；
2）大架构底层保留部门和部门人员关系表，人员信息保留在原组织架构底层。
大架构底层与原组织架构底层的业务关联：
1）人员展现的部门链路如何获取？从大架构底层获取，因为关系表寄存在大架构底层；
2）搜寻如何做？部门名字保留到原组织架构底层，复用原组织架构底层的索引建设逻辑。
11、300 万优化计划的双 DB 切换模式
11.1 旧的读写表切换形式
旧计划里组织架构的全量更新流程：
当后盾通知客户端须要全量更新时，客户端会将所有节点标为待删除，而后同步后盾的节点，革除待删除标记。同步实现后，将写表的数据同步到读表，更新版本号。最初 UI 就能够从读表中读取到最新的数据。而之前通过用户日志案例剖析，最长的耗时次要是在将写表的数据拷贝到读表下面。在这个过程中，大架构下局部用户的日志里有更新 57w 节点的数据用了 2 个半小时的状况，而且这个步骤是原子操作，如果不可能一次实现，下次还得从新执行。原有流程里，读表和写表是固定的，导致全量更新须要等读表同步完数据，界面能力读到新数据。
剖析：写表同步数据到读表耗时很久，当全量更新时，如果有大量节点须要更新，会耗时很长。
毛病：写表和读表固定，全量更新须要等数据同步实现，界面能力读取到新数据。
11.2 新的双 DB 切换形式
针对旧计划中读写表同步过久的问题，大架构计划里咱们换成了双 DB 切换的模式。上面是咱们的状态机设计和业务代码获取表名的逻辑。这样批改之后，不须要等读写表同步完，UI 就能够读取到最新数据。而同步的过程能够在后盾缓缓实现，并且不会受原子性操作的限度。业务代码获取读表的逻辑，也收拢到了一个函数。
因为单位模式下，每个单位的节点数量都不会很多，而且大多数用户只会加载日常有交换的几个单位，所以读写表同步这里，咱们采纳了把原表删掉，全量拷贝的形式。
12、200 万级优化后的成果
对于耗时，优化前应用全量加载的形式使得耗时很长，而优化后采纳的“本单位 + 骨架”的预加载逻辑使得加载耗时大幅度减小。优化后的内存占用大小在各场景下均有减小，通讯录页面的晦涩度也失去了肯定的晋升。
耗时：
CPU 占用率：
内存占用大小：
卡顿：
13、相干材料
[1] 企业微信客户端中组织架构数据的同步更新计划优化实战
[2] 企业微信的 IM 架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等
[3] 钉钉——基于 IM 技术的新一代企业 OA 平台的技术挑战 (视频 +PPT) [附件下载]》
[4] 阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处》
[5] 深度解密钉钉即时消息服务 DTIM 的技术设计
[6] 深度揭密 RocketMQ 在钉钉 IM 零碎中的利用实际
[7] IM 开发干货分享：万字长文，详解 IM“音讯“列表卡顿优化实际
[8] 手 Q 客户端针对 2020 年春节红包的技术实际
[9] 挪动端 IM 实际：Android 版微信如何大幅晋升交互性能（一）
[10] 挪动端 IM 实际：Android 版微信如何大幅晋升交互性能（二）
[11] 挪动端 IM 实际：iOS 版微信的多设施字体适配计划探讨
[12] 爱奇艺技术分享：爱奇艺 Android 客户端启动速度优化实际总结
[13] 微信团队分享：微信领取代码重构带来的挪动端软件架构上的思考
（本文已同步公布于：http://www.52im.net/thread-4437-1-1.html）