從 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 存在以下不足：

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 或許能開創出一個新的雲計算方向，讓咱們拭目以待吧。