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 级联操作，必须在上层来做关联对象的删除。

leancloud 文档非常清晰，也挺人性化。在 LeanStorage 的开发指导页面上，提供了影响查询性能的一些因素。并指出如有问题，可以联系他们进行指导。此外，提供了付费咨询的服务「LeanCloud 咨询师」，方便开发者更高阶的深度咨询业务。

不等于和不包含查询（无法使用索引）

通配符在前面的字符串查询（无法使用索引）

有条件的 count（需要扫描所有数据）

skip 跳过较多的行数（相当于需要先查出被跳过的那些行）

无索引的排序（另外除非复合索引同时覆盖了查询和排序，否则只有其中一个能使用索引）

无索引的查询（另外除非复合索引同时覆盖了所有条件，否则未覆盖到的条件无法使用索引，如果未覆盖的条件区分度较低将会扫描较多的数据）

数据安全

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 事件，方便开发者给出友好的「强制下线/登出」提示。