LeanCloud 调研报告

LeanCloud 是一家做后端即服务（BaaS）的厂商，目标是让移动互联网开发者能更加方便的开发应用。

出于工作关系，对 leancloud 进行了一番调研；主要目标是学习其后端即服务的产品化思路等。

整体体会

先说一些整体的感受：

文档质量很高。

关键组件的产品形态清晰，围绕关键组件搭建「业务脚手架」。

典型案例是账号系统（

AV.User

以及一系列基本的业务操作）基于 lean-storage 对象存储来构建。

对客户的数据安全负责。

完善的访问控制策略、跨域安全等；每天备份一次应用数据（用户若误删数据可找 leancloud 恢复）。

数据存储

数据模型

https://leancloud.cn/docs/relation-guide.html

整体：

基于 mongoDB 的数据模型。

RDBMS	MongoDB	LeanCloud
Database	Database	Application
Table	Collection	Class
Row	Document	Object
Index	Index	Index
JOIN	Embedded，Reference	Embedded Object, Pointer/Relation

索引：

复合索引，唯一索引，数组索引，地理空间索引（geospatial 类型的数据），稀疏索引（默认都是创建稀疏索引）。

LeanCloud 后台会根据每天的访问日志，自动归纳和学习频繁使用的访问模式，并自动创建合适的索引。也可以在控制台为每一个 Class 手动创建索引。

建模：

建议根据场景，按照「Pointer/Relation」或者「中间表」的方式来建模。

lean-storage

对象存储：不超过 128KB 的对象存储。

文件存储：集成七牛等第三方文件存储。

对象存储的一些细节：

属性值类型：字符串、数字、布尔值、数组或字典。

内置属性（任何对象都有的属性）：

objectId

，

ACL

（一个包括 ACL 权限配置 JSON 对象），

createdAt

/

updatedAt

（对象创建和修改的时间）。

数据同步的模型：

通过

get()/first()/fetch()/find()

等获取对象数据。之后可在本地做各种操作。本地的各种操作都不会 auto commit 提交给云端。调用

save()

后同步本地和云端的对象数据。

原子操作：

整型属性的

increment

操作；数组属性的

add/addUnique/remove

操作；数据同步

save()

选项

fetchWhenSave

以及

query

带条件的存储。

嵌入/引用数据：

mongoDB embedded（直接内嵌对象，牺牲数据冗余、换取查询性能）；reference（一对多/多对多建模）。

leancloud 将 reference 包装成

AV.Relation

以及 Pointer。

AV.Relation

是在「一对多」的「一」这一方保存一个

AV.Relation

属性，保存的是「多」这一方 Pointer 集合。

Pointer 是一个概念，没有具体化的系统类型，可看做类似 RDBMS 里的外键指针。但是没有直接的 cascade 级联操作，必须在上层来做关联对象的删除。

数据安全

authentication（通过签名做身份认证）和 authorization（通过 ACL 做鉴权）机制都有。

https://leancloud.cn/docs/data_security.html

认证

每个应用都使用唯一的 appId 标识；appKey masterKey 分别对应普通访问、超级权限访问。

签名计算规则，是

md5(appKey+timestamp)

。使用 md5 而非当前更主流/安全/政治正确的 HMAC，让人略惊讶。

尽管如此，由于文档质量非常高，前后文的背景铺垫、场景描述都很足，可能也不会觉得不妥…… 此外实时通信组件 LeanMessage 的签名都是 HMAC-SHA1。

鉴权

粗粒度：Collection/Class 数据集级别的 ACL 鉴权配置。

细粒度：Document/Object 对象级别的 ACL 鉴权配置。

鉴权策略：RBAC（role-based access control），可指定角色/特定用户对资源的访问权限（

-/r/rw

）。

鉴权执行：先查粗粒度，再查细粒度，白名单匹配。

Web 跨域安全

配置安全域，防止跨域的资源盗用（恶意部署造成的服务器资源被盗用）。

其他举措

每天备份一次应用数据。

全站 https。

文档中明确推荐对客户安卓 app 通过爱加密来做混淆。

ACL 权限管理

在上面的《数据安全/鉴权》部分，已经描述了一部分。下面的链接则更详细的阐述了 ACL 的理念和最佳实践。

https://leancloud.cn/docs/acl-guide.html

粗粒度和细粒度的 ACL 鉴权管理相结合。

鉴权策略：RBAC（role-based access control），可指定角色/特定用户对资源的访问权限（

-/r/rw

）。

鉴权执行：先查粗粒度，再查细粒度，白名单匹配。

超级权限：masterKey，越过 ACL 直接操作，适用于在云引擎这种相对安全的运行环境中使用。

Document/Object 级别的权限配置粒度很细，在客户端众多的情况下，细粒度配置 ACL 的代码将散布在各处、不易维护。对此，最佳实践是使用云引擎钩子函数的

beforeSave()

钩子。

云引擎钩子函数

lean-engine hook functions，这个名字取得非常契合 serverless 潮流（手动点赞）。

钩子函数列表见此。

钩子函数主要是围绕对象存储操作（新建、更新、删除）、账号管理（短信邮箱认证、登陆）、实时通信组件（收到消息、消息接收方离线、开启对话组前后钩子、拉人、踢人等）。

应用数据共享

将某个应用下的 Class 分享给另一个应用。典型应用是用户账号（内置的

_User

）在不同应用间共享。

https://leancloud.cn/docs/app_data_share.html

https://docs.mongodb.com/manual/reference/database-references/#DatabaseReferences-DBRef

实时消息系统

leancloud 的实时消息系统主要是面向 IM 场景，如点对点聊天、群组聊天、聊天室、直播弹幕、聊天机器人等。

特点：

独立性强，和其他组件的耦合度低。

不包括用户、好友关系、设备、系统机器人等语义，统统抽象成

clientId

即聊天参与实体的ID。

认证（签名是否合法）/鉴权（是否允许某个操作）也都解耦，在适当的时候（如加入对话、拉人踢人等）调用远程认证鉴权服务器进行检查。

对话类型丰富：

普通对话（专供常见的单聊群聊场景）

暂态对话（专供聊天室场景）

系统对话（专供系统广播消息、聊天机器人等场景）：所有的全用户广播消息都是系统对话类型。

消息业务类型丰富：

在 sdk 层面上，除了普通的文本消息外，还封装了包括文件、图片、音频、视频、地理位置等一系列富文本消息（其消息中的富文本对象则是

AV.File

AV.GeoPoint

等系统对象）。

可以方便的使用 leancloud 文件存储组件，打一套「组合拳」满足客户需求。

QoS 之消息投递优先级：

暂态对话类型中，还存在 QoS 保障，以满足聊天室中丰富的送礼物（消息可靠性要求高）、弹幕（消息可靠性要求低）等丰富场景。其他类型的对话里不存在投递优先级。

QoS 之消息投递可靠性：

消息分为「普通消息」和「暂态消息」。

普通消息会提供接收回执（默认不开启）、云端持久化存储、离线推送等功能。

暂态消息不会在云端持久化，没有离线用户推送；典型使用场景是「对方正在输入中」这样的状态信息。

同 app 推送的结合比较紧密。

支持静态内容推送，和基于云引擎 Hook 的动态内容推送。

丰富的实时通信相关的云引擎 Hook 函数：

可实现许多丰富的业务特性，比如敏感词过滤，消息接收方过滤，推送更个性化的离线消息，实现丰富的对话鉴权操作，批量处理消息发送完毕后的耗时操作等。

另外几个小特点：

扩展对话属性非常简单。同理上文提到的用户系统

_User

表，对话是在

_Conversation

表，也可以在创建对话时，设置各种 attributes，比如是否置顶（

pinned

）等。

默认的一些对话属性（以及对应的操作方法），比如

mute

用户列表，也就是从大量常见的聊天需求中提炼出来的通用属性。

单点登录。内置支持类似微信的单点登录，允许且仅允许一个用户登陆一个客户端。

具体的实现是通过在

createIMClient()

方法中设置 tag，相同 tag 的用户登录将彼此互斥，后续登录的 session 将踢掉之前登录的 session。被踢掉的 session 会在 sdk 层面收到

conflict

事件，方便开发者给出友好的「强制下线/登出」提示。