从 CloudKit 看 BaaS 服务的趋势

从 CloudKit 看 BaaS 服务的趋势_第1张图片

从 6 月份 WWDC 苹果发布 CloudKit 开始,BaaS (Backend as a Service,也叫做 mBaaS,m 代表 mobile ) 的概念一下子又走入了人们的视野。CloudKit 提供了基本的数据存储和用户账号管理功能,以后要写一个数据交互不是太复杂的应用/游戏,就不再需要自己来开发后端架构,直接连 CloudKit 就搞定了,这就是 BaaS 的价值。这里之所以说「又」,是因为在 13 年初 Facebook 收购 Parse 的时候,很多人也都被震惊到了,只是当时会有人觉得,真的有很多人会使用这种后端服务么?现在好了,连号令江湖的水果公司也加入到了服务商的行列,大家不得不重新审视 BaaS 的价值。

我们还是先来看看 CloudKit 可以为我们做什么吧。从目前公开的资料和 API 来看,CloudKit 有如下几个基本概念:

  • CKContainer —— 每个应用有一个 Container,应用之间的数据是隔离的,如果愿意数据可以跨应用共享。
  • CKDatabase —— 每一个 Container 都会包含两个 Database:公开的和私有的。公开的 Database 存放应用内共享的数据,需要开发者自己的 Apple ID 才能修改;私有的 Database 则存放单个用户相关的数据,需要终端用户自己的 Apple ID 才能访问。
  • CKRecord —— 代表 Database 里面一条结构化记录,是键值对的封装,所以可以存储任何数据。与 Parse 等提供的子类化数据模型不一样,CloudKit 中所有存储的数据只能是 CKRecord 类型,开发者需要使用一个名叫 Record Type 的字符串来区分不同类型的数据。
  • CKRecordZone —— CloudKit 还引入了 RecordZone 的概念,来给不同的数据进行分区,与 Mongodb 中的 collection 比较相似。
  • CKReference —— 类似于数据库中的「外键」概念,主要用来进行数据关联。CKRecord 中某一个属性的值,可以是另一个 CKRecord(譬如 Instagram 中的每张图片,都有一个作者字段),这时候属性值就可以是 CKReference 类型。按照 CloudKit API 的说明文档,这种引用的关联是可以做到反向查询和级联删除的,不过笔者好奇的是,对于一对多的关联模型,级联删除该怎么才能做到呢?
  • CKAsset —— 用来处理文件这种非结构化数据的存储,按照 API 的说明文档,可以高效支持上传和下载,看来苹果应该也是提供 CDN 支持的,但是国内用户应该就享受不到了。
  • CKQuery —— 主要用来获取数据,通过组合 Record Type、NSPredicate 和 NSSortDescriptor 来查询数据,不过从 API 说明文档看不出它能否支持 Parse 的级联获取。
  • CKSubscription —— 与 CKQuery 只是每次去拉 Server 端的数据不同,CKSubscription 提供了一种 Server 端主动 Push 的机制,通过组合 Record Type、NSPredicate 和 APNs Push,可以让 Client 端主动去监听 Server 端的数据变化,从而实时得到通知。

其实,对于苹果为什么要做 CloudKit,江湖上还流传着这样一则轶闻:当年苹果也是 Parse 的竟购方之一,只是 Facebook 为了打造开发者生态圈而志在必得,苹果只能铩羽而归,但是数据平台的价值又一直让苹果念念不忘,最后苹果的工程师和 PM 只能心一横,自己做一个 CloudKit 了。不过与其他 BaaS 平台相比,笔者认为 CloudKit 存在如下不足:

  1. 数据模型过于简单。数据之间的关联只能通过 CKReference 建立,这样的话对于多对多的映射模型就比较吃力,不管是读取还是存储,都会比 Parse 的方案繁琐很多。
  2. 不能自定义业务逻辑,没有类似于 Parse 的云代码功能,很多时候需要在客户端完成全部业务逻辑,这都会给开发带来一些不便,并且也会影响到移动设备的耗电和网络流量。
  3. 访问速度过慢,从我实际的测试来看,在 Wifi 下 API 的延迟都已经非常明显,要是再扩大到国内五花八门的网络环境,特别是弱网环境,数据访问的延迟会变成一个很大的障碍。而且,对于国内用户来讲 Apple ID 的利用率也不高。
  4. 不支持跨平台。所有的数据都是存放在 iCloud 里面,需要通过开发者或者最终用户的 Apple ID 才能访问,这样的服务方式让 Android 生态圈和 Web Application 等完全成为了另外的平行世界,对于第三方应用开发者来说,或许没有人能把自己的用户群全部押宝到 iOS 上。
  5. 在中国市场面临政策风险。从 WordPress、网盘、AWS 等的前车之鉴来看,所有的数据黑洞都会让监管部门感到无能为力,从而心生恐惧,他们只能使用最简单粗暴的办法来进行处理,那就是让你变的「不存在」。

在苹果的发布会之后,谷歌在今年的 IO 大会上也发布了 Google Driver for Work / Google Fit Platform,加上最早的 Facebook,三大巨头相继推出类似产品,让人们对 BaaS 服务的前景充满期待。CloudKit 存在的问题,可能就是其他第三方 BaaS 服务商们的机遇。在国外 Parse 和 Kinvey 都做得不错,StackMob 本来也算是领头羊之列的 player,但是被 Paypal 收购之后就立刻被关停,只能让人唏嘘。国内的 BaaS 服务提供商,多只在某一个领域出现,譬如推送领域的个推、统计领域的友盟,能够像 Parse 一样提供完整的平台能力,特别是后台数据存储能力的,目前来看只有 AVOS Cloud 一家。并且 AVOS Cloud 的 API 设计是完全兼容 Parse 的,对于用惯了 Parse 服务的开发者来讲,可能会像碰到了孪生兄弟一样熟悉。

在所有人都在强调「移动!移动!」的今天,BaaS 或许能开创出一个新的云计算方向,让我们拭目以待吧。

你可能感兴趣的:(parse,leancloud,移动应用开发,baas,cloudkit)