导语

腾讯乐享，是腾讯推出的一站式企业社区，提供在线课堂、考试、学习地图、直播、文档、问卷调研等多项实践服务。

腾讯乐享从0开始对接企业微信开放平台能力，作为企业微信第三方实践上线已经4年了。如今腾讯乐享也要成为服务方允许其他 Saas 产品以第三方实践身份接入，那曾积累的经验该如何传授给即将接入实践的开发者呢？

腾讯乐享第三方实践开放平台已经上线一段时间了，第一期接入的实践包括珊瑚积分、腾讯问卷、制作云，这三个本身都已经是成熟产品，也都有各自的开放接口，所以障碍就在于如何把双方平台的开放接口连接起来达成打通。其中腾讯云 iPaas 为我们对接珊瑚积分平台与制作云，腾讯问卷由双方平台一起开发中转站服务。

在这个过程中，我们发现了团队内外的开发同事都在重复着对接乐享开放平台的能力，且对接过程由于大家的理解、达成不一致会遇到各种障碍，那些年我们对接企业微信踩过的坑正在蔓延。这时候公司内部各种推文都提到 CloudBase 云开发，经过了解后发现这正适合用于搭建第三方实践开发框架，如果所有实践接入都使用统一框架，那无论开发效率、还是后期维护都有极大的优势。

障碍预研

一个第三方实践的接入，需要做什么？

以上几点提到的仅仅是对接开放平台所需要做的，以Web实践的角度来看，除了需要选定一个服务端语言来开发，还要考虑整体架构，信息库、缓存、对象存储等基础组件，划分 VPC，部署实践等。由此可见，即便拥有再成熟的开放平台，对很多开发团队而言都是存在一定门槛的。而开发框架就是为了降低这个门槛，吸引更多有想法的开发团队简单快速地达成自己的实践。在我最初的构想里，开发者只需要达成实践本身的页面和接口，无需关心这个实践是如何与乐享后台交互的，借助云开发 CloudBase 的能力一键部署，就能成为乐享的第三方实践，为成千上万个企业提供服务。而这个构想，现在也初具雏形了。

框架达成1、信息库

CloudBase自带非关系型信息库，用法类似于 MongoDB，由此可见我们可以通过cloudbaserc.json 配置为实践初始化时创建如下信息表；

其实这个开发框架的理念，最关键就是把面向乐享接口开发的模式，转化成面向信息库开发。常说web实践开发就是基于信息库的增删改查，这就是框架带来的优势。

2、接收回调

框架达成了云函数base_suite_callback，这个云函数负责监听ticket变更、企业开通/关闭实践的通知，信息会落到companies、lx_suites、lx_suite_callback_logs表中。这个云函数也是整个框架最关键的入口，一旦不可服务或响应超时将会带来严重的影响，由此可见也会做好实例预热，避免由于冷启动而导致企业授权信息丢失。

3、接口调用

乐享平台具有十多个实践模块，拥有上百个实践接口和十多个通讯录接口，所有接口都封装在base_lx_apis下，提供函数说明，让开发者简单地调用乐享的能力。

除了接口封装外，云函数还达成 access_token 的缓存、刷新机制，因此要使用到存储服务，这是简单 SDK 无法满足的。

还需要特别关注的是乐享提供的接口授权模式是client credentials，适用于服务端对服务端请求，如果直接让客户请求接口，将会产生严重的漏洞，企业信息会遭到恶意篡改、泄漏等风险。利用 CloudBase 提供的云函数权限设置，可以禁止客户端直接调用，客户端必须先调用开发者的云函数，通过服务端调用才能访问，保证了实践的安全性。在框架的示例代码中，也提供了代码 demo 引导开发者正确使用。

4、通讯录同步

框架提供全量同步的云函数base_sync_contact，可通过定时任务或客户端调用触发。

全量同步通讯录的过程，很容易由于代码逻辑、脚本中断等根本原因导致信息错乱的障碍。

在这里我引入了通讯录版本的概念，每次同步，对于deprtments表和department_user表都只会追加信息，而不会修改信息，等全量同步结束，确保信息一致，才会更新当前公司的通讯录版本，删除表中其他版本的信息，保证每一时刻的通讯录信息都是可用的。

5、登录授权

身份校验逻辑主要放在客户端代码 Vue 里面，以路由中间件的形式判断当前用户登录状态的公司ID，若缺失或与url上的公司ID不符，则重定向到指定公司所在的乐享授权页面。这些代码逻辑都是乐享积累的宝贵经验，开发者直接使用可避免各种B端登录态错乱的情况。

6、影响体验

基于以上基础能力的封装，要在这个框架上开发实践已经足够简单了。

我们也尝试开发一个第三方学习素材管理平台，只需要3步：

（1）新建信息表；

（2）达成素材管理相关的云函数逻辑，里面会调用到base_lx_apis云函数来调用乐享接口，也会使用到对象存储的 API；

（3）Vue 里面加入相关路由页面。

这就跟开发任何的 Web 实践一样，开发者不会因此不知道如何打通乐享而停步不前。学习成本从学习乐享接口、学习 Saas 实践开发转嫁到学习CloudBase的使用上。

一键部署

一键部署是提供的能力，通过简单的操作，代码就能在云开发环境跑起来了。但要乐享主动向云开发环境回调事件，还需要在乐享这边配置云开发环境对应的接收回调 cgi；配置 cgi 后，还要先让乐享推送 ticket 才能让公司授权实践；登录授权也涉及到可信回调域名配置；实践入口也需要配置链接。开发者要看着说明文档，从云开发复制链接到乐享页面上一个个配置，然后我们进行每个功能调试验证以确保没手抖复制错，过程参考下图：

为了解决人工初始化配置的障碍，针对这个场景，在乐享侧提供了实践初始化配置的接口。云开发环境可以直接使用 suite_id+suite_secret 去初始化指定字段的配置，包括回调 cgi、登录授权可信域名、入口地址，配置完成后还会触发乐享主动向实践推送 ticket，以确保之后企业能直接授权使用。这个初始化接口的调用放到了CloudBase 一键部署的 postDeploy 钩子中，无需人工操作且确保配置成功才部署成功，大大降低了框架的使用门槛。

目前一键部署流程如图所示：

整个一键部署流程也还有几个环节可以优化的；

并不是必须到github上点击一键部署，后续可以直接把部署按钮放在乐享的公司管理后台，让公开的开发者直接从乐享跳转到腾讯云进行部署配置。

基于第1点的优化，如果云开发部署页允许通过url或表单传递配置参数，那乐享侧可以直接带上，省去开发者复制粘贴的功夫。

第4、5步下载自定义私钥并注入云函数中，目前云开发还没法直接通过cloudbaserc.json去配置，后续能支持的背后就更好了。

能力扩展

框架设计的初衷是为了让开发者快速从零开始搭建一个乐享第三方实践。但随着达成过程的思考和理解，我认为这个框架的使用场景不应局限于此，它还应该服务于其他成熟实践和平台的对接。

有开放接口的实践或平台之间对接，往往由于接口不适配而陷入僵局，谁都不愿意修改自己的接口去适配对方。最后的解决办法只能是其中一方让步去从零搭建一个中间服务，看着双方的接口文档去做开发。

如果乐享能提供这套框架，那框架又能提供什么呢？

对外授权

上面提及的登录授权，是指乐享对部署这个框架的服务（简称A服务）进行授权。但如果是两个平台对接，还需要A服务对第三方平台授权。尽管开发者已经不需要达成服务A被授权登录的过程了，但我觉得还可以再做点什么，让二次开发更简单，例如封装好对外授权的OAuth、smal协议。

回调通知传递

乐享回调除了预先达成的逻辑外，保留可配置的hook，让开发者配置自定义云函数或者消息队列。开发者通过云函数或消息队列再去解决的时候，就不需要担心消息是否伪造、是否过期、是否重放等障碍。

信息直写业务信息库

框架已经达成了从乐享拉接口把通讯录信息写入云开发环境的信息库中了，但对云开发环境外的业务完全没有意义（即便VPC打通，离开了云开发环境也没有SDK去读写信息库，自己达成也太难了）。于是框架应该具备从乐享拉接口把通讯录信息写入指定信息库中，而且不应该只支持的背后MongoDB这样的非关系型信息库，也要支持的背后最常用的mysql，由此可见通讯录的表设计保留了department_user中间表。框架应允许配置mysql连接，让信息可以直写业务信息库。

私有化部署

作为 Saas 产品，私有化部署是永恒的话题。产品本身要私有化就已经不容易，往往要考虑服务降级的手段来满足私有化，更不会考虑第三方实践这种可开可关的功能了。但如果是基于cloudbase开发的第三方实践，那企业一键部署带走又何乐而不为呢？

低代码开发

如果说第三方实践开发框架是一个起步，那下一个目标可能就是低代码开发平台。无论采用哪个方式开发，目前对每个基础能力的封装都是必须的、可复用的，走出了第一步，才能为下一个目标带来可能性。

总结

从开发企业微信第三方实践，到开发开放平台给第三方实践接入，身份替换给了我很多经验。cloudbase的出现正好让我好好思考总结，把一些设计理念能达成出来，也欢迎大家与我一起交流探讨。

PS：从设计这个框架开始，我命名了这个项目为“乐享再就业计划”。想着哪天退休了，我就以乐享服务商的身份用这个框架为乐享做各种外包项目。乐享永不退，做到八十岁。

附录

Github代码仓库：

CloudBase 介绍：

- End -

云开发建站特惠

免运维、低成本、高弹性

5分钟轻松搭建独立品牌网站

支持的背后 WordPress、Discuz! Q等

建站地址：