一、业务介绍
当管理员在钉钉创建出一个组织后，工作台会发生什么样的变化？工作台又是如何实现千人千面的？工作台如何解决初始化的性能问题？今天这篇文章来分享工作台初始化的一些技术实践。
二、产品流程
三、竞品对标
产品特征/对标 | 企业微信工作台 | 飞书工作台 | 钉钉工作台 |
产品 |
|
|
|
角色工作台 | 不支持 | 不支持 | 支持 |
行业模板 | 不支持 | 不支持 | 支持 |
创建速度 | 快 | 中 | 中 |
管理能力 | 弱 | 弱 | 强 |
动态卡片能力 | 无 | 无 | 有 |
四、时序图
从高度抽象模块来说，主要分成了以下几个步骤：
- 监听通讯录组织创建消息
- 查询命中的模板
- 创建工作台门户对象
- 生成模板对象Schema数据结构
- 异步安装依赖的资源
- 资源回写Schema数据结构
- 发布工作台
具体时序图如下图所示：
五、核心技术难点
如何实现千行千面
理论上来说，对于不同的用户来创建组织，要形成一些的规则来命中指定的模板，就可以实现千行千面。实现的方式有多种，但是一般来说除了算法的叠加外，可以采用一些通用性的规则：
- 基于行业的模板命中规则
即配置行业和模板的对应关系，当组织选择了特定行业，直接加载对应的模板
- 基于人数的模板命中规则
即配置用户创建组织选择的规模人数，来选择对应的模板。一般用于解决特定的大组织架构问题
- 基于组织来源的模板命中规则
即根据组织创建时选择的渠道码，来选择对应的模板，这种一般用于线下部署有指定来源的情况，这种更为精准，用于地推业务场景
- 基于ABTEST的模板中规则
用于对于同一个规则下，配置一个或者多个模板，主要用于控制变量来确认不同模板对于同类对象的效果
- 算法规则
根据用户登录钉钉的已有行为（诸如已创建的组织）来实现算法推荐用户工作台模板，不过经验证，在2B类的场景里，纯算法适用场景相对不多，还是要结合组织和用户特征做较为精准的规则匹配更为合适
如何解决性能瓶颈
许多研究都表明，用户最满意的打开网页时间，是在2秒以下。 用户能够忍受的最长等待时间的中位数，在6～8秒之间。这就是说，8秒是一个临界值。
第一个难点就是性能问题，如何在管理员初始化组织之后，能够较快的初始化出组织工作台是一个极大的挑战。
由于需要初始化一个工作台，一般需要执行几个步骤：
- 初始化布局
- 初始化官方应用开通
- 初始化三方应用营销态
- 初始化应用内实例
- 更新OAURL
- 四端推送
- ...
由于行业化本身比较复杂，需要实现各种资源分发逻辑，因此实际验证下来需要5秒以上才能完成整个工作台的初始化。因此这个时间是个用户极度体验不好的时间。
其中有三个入手优化点，第一是异步化创建工作台，第二个方式是提供足够多产品引导，第三个就是工作台本身资源异步初始化。
- 异步化创建工作台
异步化创建工作台比较好理解，即当用户选择好行业、规模、角色后，就发送出异步消息，服务端线上监听异步组织创建消息开始进行初始化。从同步创建工作台优化成异步创建工作台。这也是最简单最容易想到的一个方案，也是用消息解耦的一个典型用例。
- 优化产品引导
第二个方式是从产品上的引导，由于组织命中的千行千面数据需要同步复制到目标组织，往往由于应用的开通、模板的生成、布局的生成等造成复制耗时极高。在性能问题无法较好解决前，可以通过添加产品引导来优化链路。比如一些存储系统上传或者下载文件就会有明显的loading态来提示用户。
- 异步生产工作台资源
第三个方式是先基于完全复制或者部分复制生成组织的模板，先展现给用户，然后异步线程去开通应用、模板的生成等。
如何解决初始化依赖未完成问题
这是一个理论上不会出现，但是实际上经常会出现的问题。即工作台初始化依赖了大量的外部调用，比如查询组织通讯录管理员、查询通讯录用户数、查询微应用等。往往因为初始化的时候，由于通讯录、微应用本身逻辑复杂而形成大量的模块内异步调用，因此在生成工作台的时候，往往会因为外部依赖查询异常而导致工作台本身异常，比如查不到管理员就无法开通应用。因此解决思路有如下：
- 降低外部依赖
一个很简单的方式，就是降低外部依赖，比如可以将从消息体中取得管理员的信息；
- 消息重试
采用消息队列的自动重试机制，当处理逻辑发生异常时，向外抛异常来解决；这里要尤其注意，大部分消息中间件有重试时延，如果时延过长会导致整体工作台创建链路严重延迟。
- 内存重试
内存模板化代码，在强依赖外部接口的方式使用内存重试，可以设定重试次数、重试间隔等。
思考
工作台作为组织数字化的入口，承载非常重要的入口和协同功能，因此如何快速给结合用户特点初始化一个个性化的组织工作台，是非常重要的。
公众号：ali老蒋。