從 CloudKit 看 BaaS 服務(wù)的趨勢

從 6 月份 WWDC 蘋果發(fā)布 CloudKit 開始，BaaS (Backend as a Service，也叫做 mBaaS，最前面的 m 代表 mobile ) 的概念一下子又走入了人們的視野。CloudKit 提供了基本的數(shù)據(jù)存儲和用戶賬號功能，以后要寫一個數(shù)據(jù)交互不是太復(fù)雜的應(yīng)用/游戲，就不再需要自己來開發(fā)后端架構(gòu)，直接連 CloudKit 就搞定了，這就是 BaaS 的價值。這里之所以說「又」，是因?yàn)樵?13 年初 Facebook 收購 Parse 的時候，很多人也都被震驚到了，只是當(dāng)時會有人覺得，真的有很多人會使用這種后端服務(wù)么？現(xiàn)在好了，連號令江湖的水果公司也加入到了服務(wù)商的行列，大家不得不重新審視 BaaS 的價值。

我們還是先來看看 CloudKit 可以為我們做什么吧。從目前公開的資料和 API 來看，CloudKit 有如下幾個基本概念：

• CKContainer —— 每個應(yīng)用有一個 Container，應(yīng)用之間的數(shù)據(jù)是隔離的，如果愿意數(shù)據(jù)可以跨應(yīng)用共

• CKDatabase —— 每一個 Container 都會包含兩個 Database：公開的和私有的。公開的 Database 存放應(yīng)用內(nèi)共享的數(shù)據(jù)，需要開發(fā)者自己的 Apple ID 才能修改；私有的 Database 則存放單個用戶相關(guān)的數(shù)據(jù)，需要終端用戶自己的 Apple ID 才能訪問。
  

• CKRecord —— 代表 Database 里面一條結(jié)構(gòu)化記錄，是鍵值對的封裝，所以可以存儲任何數(shù)據(jù)。與 Parse 等提供的子類化數(shù)據(jù)模型不一樣，CloudKit 中所有存儲的數(shù)據(jù)只能是 CKRecord 類型，開發(fā)者需要使用一個名叫 Record Type 的字符串來區(qū)分不同類型的數(shù)據(jù)。
  

• CKRecordZone —— CloudKit 還引入了 RecordZone 的概念，來給不同的數(shù)據(jù)進(jìn)行分區(qū)，與 Mongodb 中的 collection 比較相似。
  

• CKReference —— 類似于數(shù)據(jù)庫中的「外鍵」概念，主要用來進(jìn)行數(shù)據(jù)關(guān)聯(lián)。CKRecord 中某一個屬性的值，可以是另一個 CKRecord（譬如 Instagram 中的每張圖片，都有一個作者字段），這時候?qū)傩灾稻涂梢允?CKReference 類型。按照 CloudKit API 的說明文檔，這種引用的關(guān)聯(lián)是可以做到反向查詢和級聯(lián)刪除的，不過筆者好奇的是，對于一對多的關(guān)聯(lián)模型，級聯(lián)刪除該怎么才能做到呢？
  

• CKAsset —— 用來處理文件這種非結(jié)構(gòu)化數(shù)據(jù)的存儲，按照 API 的說明文檔，可以高效支持上傳和下載，看來蘋果應(yīng)該也是提供 CDN 支持的，但是國內(nèi)用戶應(yīng)該就享受不到了。
  

• CKQuery —— 主要用來獲取數(shù)據(jù)，通過組合 Record Type、NSPredicate 和 NSSortDescriptor 來查詢數(shù)據(jù)，不過從 API 說明文檔看不出它能否支持 Parse 的級聯(lián)獲取。
  

• CKSubscription —— 與 CKQuery 只是每次去拉 Server 端的數(shù)據(jù)不同，CKSubscription 提供了一種 Server 端主動 Push 的機(jī)制，通過組合 Record Type、NSPredicate 和 APNs Push，可以讓 Client 端主動去監(jiān)聽 Server 端的數(shù)據(jù)變化，從而實(shí)時得到通知。

  
  

其實(shí)，對于蘋果為什么要做 CloudKit，江湖上還流傳著這樣一則軼聞：當(dāng)年蘋果也是 Parse 的竟購方之一，只是 Facebook 為了打造開發(fā)者生態(tài)圈而志在必得，蘋果只能鎩羽而歸，但是數(shù)據(jù)平臺的價值又一直讓蘋果念念不忘，最后蘋果的工程師和 PM 只能心一橫，自己做一個 CloudKit 了。不過與其他 BaaS 平臺相比，筆者認(rèn)為 CloudKit 存在如下不足：

1. 數(shù)據(jù)模型過于簡單。數(shù)據(jù)之間的關(guān)聯(lián)只能通過 CKReference 建立，這樣的話對于多對多的映射模型就比較吃力，不管是讀取還是存儲，都會比 Parse 的方案繁瑣很多。

2. 不能自定義業(yè)務(wù)邏輯，沒有類似于 Parse 的云代碼功能，很多時候需要在客戶端完成全部業(yè)務(wù)邏輯，這都會給開發(fā)帶來一些不便，并且也會影響到移動設(shè)備的耗電和網(wǎng)絡(luò)流量。

3. 訪問速度過慢，從我實(shí)際的測試來看，在 Wifi 下 API 的延遲都已經(jīng)非常明顯，要是再擴(kuò)大到國內(nèi)五花八門的網(wǎng)絡(luò)環(huán)境，特別是弱網(wǎng)環(huán)境，數(shù)據(jù)訪問的延遲會變成一個很大的障礙。而且，對于國內(nèi)用戶來講 Apple ID 的利用率也不高。

4. 不支持跨平臺。所有的數(shù)據(jù)都是存放在 iCloud 里面，需要通過開發(fā)者或者最終用戶的 Apple ID 才能訪問，這樣的服務(wù)方式讓 Android 生態(tài)圈和 Web Application 等完全成為了另外的平行世界，對于第三方應(yīng)用開發(fā)者來說，或許沒有人能把自己的用戶群全部押寶到 iOS 上。

5. 在中國市場面臨政策風(fēng)險。從 WordPress、網(wǎng)盤、AWS 等的前車之鑒來看，所有的數(shù)據(jù)黑洞都會讓監(jiān)管部門感到無能為力，從而心生恐懼，他們只能使用最簡單粗暴的辦法來進(jìn)行處理，那就是讓你變的「不存在」。

   
   

在蘋果的發(fā)布會之后，谷歌在今年的 IO 大會上也發(fā)布了 Google Driver for Work / Google Fit Platform，加上最早的 Facebook，三大巨頭相繼推出類似產(chǎn)品，讓人們對 BaaS 服務(wù)的前景充滿期待。CloudKit 存在的問題，可能就是其他第三方 BaaS 服務(wù)商們的機(jī)遇。在國外 Parse(http://www.parse.com) 和 Kinvey(http://www.kinvey.com) 都做得不錯，StackMob 本來也算是領(lǐng)頭羊之列的 player，但是被 Paypal 收購之后就立刻被關(guān)停，只能讓人唏噓。國內(nèi)的 BaaS 服務(wù)提供商，多只在某一個領(lǐng)域出現(xiàn)，譬如推送領(lǐng)域的個推、統(tǒng)計領(lǐng)域的友盟，能夠像 Parse 一樣提供完整的平臺能力，特別是后臺數(shù)據(jù)存儲能力的，目前來看只有 AVOS Cloud(http://www.avoscloud.com) 一家。并且 AVOS Cloud 的 API 設(shè)計是完全兼容 Parse 的，對于用慣了 Parse 服務(wù)的開發(fā)者來講，可能會像碰到了孿生兄弟一樣熟悉。

在所有人都在強(qiáng)調(diào)「移動！移動！」的今天，BaaS 或許能開創(chuàng)出一個新的云計算方向，讓我們拭目以待吧。