`
lizaochengwen
  • 浏览: 643869 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

从 CloudKit 看 BaaS 服务的趋势

阅读更多
从 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 存在如下不足:

数据模型过于简单。数据之间的关联只能通过 CKReference 建立,这样的话对于多对多的映射模型就比较吃力,不管是读取还是存储,都会比 Parse 的方案繁琐很多。
不能自定义业务逻辑,没有类似于 Parse 的云代码功能,很多时候需要在客户端完成全部业务逻辑,这都会给开发带来一些不便,并且也会影响到移动设备的耗电和网络流量。
访问速度过慢,从我实际的测试来看,在 Wifi 下 API 的延迟都已经非常明显,要是再扩大到国内五花八门的网络环境,特别是弱网环境,数据访问的延迟会变成一个很大的障碍。而且,对于国内用户来讲 Apple ID 的利用率也不高。
不支持跨平台。所有的数据都是存放在 iCloud 里面,需要通过开发者或者最终用户的 Apple ID 才能访问,这样的服务方式让 Android 生态圈和 Web Application 等完全成为了另外的平行世界,对于第三方应用开发者来说,或许没有人能把自己的用户群全部押宝到 iOS 上。
在中国市场面临政策风险。从 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 或许能开创出一个新的云计算方向,让我们拭目以待吧。

http://segmentfault.com/blog/jwfing/1190000000623718
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics