【51CTO譯文】假使你還沒有開始構建移動體驗，就能為自己的移動應用程序構建一個完整的后端――該后端在數據同步、推送通知支持、用戶管理和文件處理等方面功能齊全，那會怎么樣？假使該后端采用的架構讓你可以在這個后端上輕松構建新的跨平臺的原生應用程序和Web應用程序，那又會怎么樣？

雖然這聽起來可能如同天方夜譚，但這正是移動后端即服務（MBaaS）提供商旨在為廣大應用程序開發人員所提供的。至于這對你構建的移動體驗而言是不是屬實，就由你來斷定。

我希望通過本文，你能夠獲得四個部分的重要信息：MBaaS提供商多適合現代的移動應用程序開發、評估MBaaS提供商的方法，MBaaS提供商提供的核心功能，以及使用這種解決方案面臨的不足。掌握了這些信息，你就可以很方便地確定MBaaS提供商是不是適合你的數字化戰略。

為討論設定基調

使MBaaS方面的討論規范化極具挑戰性。雖然MBaaS是一個已得到接受的術語，但每個人對它的定義各不一樣。Kinvey公司最近以圖形的方式盤點了諸多后端即服務企業解決方案提供商（http://www.kinvey.com/enterprise-mobility-ecosystem-map）。這張圖闡明了一個全面而廣泛的生態系統，界定不同的解決方案群組可能極具挑戰性。

企業移動生態系統圖

由于市場格局在時時刻刻發生變化，想在某一個時刻弄清楚所有的玩家并非易事。不過，幾家重要提供商已在這個市場證明了自己的地位。Parse、Kinvey和Salesforce.com等提供商都構建了成熟的平臺，人們每天使用的許多應用程序目前就依賴這些平臺。其他比較新興的解決方案仍需要時間來加以評估，比如亞馬遜網絡服務（AWS）的Cognito、微軟Azure的Mobile Services、蘋果的CloudKit、Kony MobileFabric和Pivotal CF。橫向比較MBaaS提供商面臨的另一個重大挑戰就是，并非所有的提供商都有同樣的功能特性。

請注意：就這篇文章而言，我將側重介紹Parse和Kinvey，一則是由于它們很成熟，二則是由于它們功能廣泛。這兩款解決方案都適用于大多數使用場合，從獨立開發人員的應用程序，到跨多個數字化項目的企業解決方案，都適合。

實際環境中的MBaaS

為了幫助解釋MBaaS的用途，我將舉一個例子，我們最近從Universal Mind的研究開發小組獲得了這個例子。我們在Universal Mind的所有辦公室都有靈活的辦公區。我們想要看一下如何使用iBeacon來跟蹤可用的辦公區。

iBeacon是一類傳感器，遵守蘋果公司的iBeacon規范。它們使用藍牙4低能耗協議來進行通訊，這讓應用程序可以在不消耗用戶電池電量的情況下不斷搜尋iBeacon。說到確定用戶的鄰近性（用戶離某物體有多近），它們是再理想不過的傳感器；在某些環境下（比如室內），它們比使用GPS更合適。

作為概念證明，我們想建立一個快速的跨平臺應用程序原型，闡明可以如何大規模地運用這個概念。應用程序本身相當基本。下面簡單概述了描述應用程序將如何正常運行的數據關系：

•用戶擁有帳戶。

•如果用戶離位于某個站點的iBeacon的位置足夠近，用戶可以被分配給工作區。

•工作區可能被占用，也可能空著。

•工作區位于在特定位置的辦公室。

•用戶可以列出那個點附近的所有空著的工作區。

在這個應用程序例子中，我將介紹兩種不同的場景。首先，我們會看一下如何不用MBaaS解決方案來構建該應用程序。然后，我會介紹如何使用MBaaS解決方案來實際構建應用程序，以此作為比較。這樣一來，你就會清楚地看到需要的工作量大不一樣。

[[126985]]

這是Universal Mind的研究開發小組開發的移動應用程序原型的視圖。

不用MBaaS

為了構建這個跨平臺應用程序，我們需要落實一些核心的組件：

•服務器

我可以啟動一個AWS彈性計算云（EC2）實例，并運行Node.js服務器。我甚至可以使用Elastic Beanstalk或OpsWorks，處理一些常見的部署過程。

•數據庫

由于我著眼于AWS，可以使用關系數據庫服務（RBS）或DynamoDB作為數據存儲區。還有一個選擇就是在AWS上部署另一個解決方案，比如MongoLab。

•服務

我可以構建與數據庫之間的全面整合，然后暴露基于REST的服務，那樣就便于對數據執行創建讀取更新刪除（CRUD）操作。

•用戶管理和安全

我需要加入作為數據一部分的用戶實體，然后將服務里面的許可權限與某個用戶及/或某個用戶組擁有的數據聯系起來。此外，我需要為用戶賦予進行注冊、重置密碼、刪除帳戶等操作的功能。

•推送通知

在部署到EC2服務器上的這個Node.js應用程序里面，我需要整合允許面向iOS和安卓，實現跨平臺通知的幾個模塊中的一個。雖然大多數繁重任務將在這些開源模塊里面進行處理，但我仍需要將應用程序邏輯與通知整合起來。

•iOS服務整合

由于iOS是一個目標操作系統，我需要用Swift或 Objective-C，與iOS上的這個服務器整合起來。此外，我還需要確定如何處理服務緩存、數據存儲、離線處理、推送通知處理等操作。

•安卓服務整合

由于安卓是一個全然不同的平臺，我同樣需要在該平臺上建立同樣的服務器整合。我還需要處理在iOS上處理的所有同樣問題。

這些部分落實到位后，我可以開始實際構建應用程序的視圖，并將它們與數據聯系起來。我還可以開始處理iBeacon整合，根據用戶的鄰近性，將工作區設為“已占用”。不過，要做到這一點，并將基礎架構落實到位，需要我花大量的時間、做大量的配置。這時候，MBaaS的優點充分體現出來。

使用MBaaS

MBaaS在這方面的優點在于，它為我處理了最主要的部分：我根本沒必要處理這些事務：配置服務器、安裝和配置數據庫、安裝服務、管理用戶、確保數據安全、設置推送通知或整合原生服務。所有這一切都作為MBaaS的一部分來加以提供。我的步驟現在看起來有點不一樣：

1. 借助MBaaS提供商構建應用程序。

2. 把原生軟件開發工具包（SDK）加入到每個應用程序中。

這些部分落實到位后，我就可以處理兩個主要的服務整合，只需要極少的代碼：獲取附近的工作區，以及將工作區的狀態從空著改為已占用（反之亦然）。下面，我使用這些示例，詳細給出了一些示例的iOS Objective-C代碼，使用Parse作為MBaaS提供商：

// 在頭文件或類擴展中 
 
@property (nonatomic,strong) NSArray *workstations; 
 
// 在實現里面 
 
/* 

視圖裝入后，我們可以異步獲取用戶的位置，

然后使用該位置，查詢附近工作區列表。

*/ 
 
- (void)viewDidLoad 
 
{ 
 
  [super viewDidLoad]; 
 
  // 獲得用戶的位置，作為Parse PFGeoPoint 
 
  [PFGeoPoint geoPointForCurrentLocationInBackground:^(PFGeoPoint *geoPoint, NSError *error) { 
 
    if (!error) { 
 
      [self fetchWorkstationsNearPoint:geoPoint]; 
 
    } 
 
  }]; 
 
} 
 
/* 
 
  該方法異步獲取離用戶的當前位置在兩英里之內的所有工作區。 
 
*/ 
 
- (void)fetchWorkstationsNearPoint:(PFGeoPoint *)geoPoint 
 
{ 
 
  PFQuery *query = [PFQuery queryWithClassName:@"Workstations"]; 
 
  [query whereKey:@"location" nearGeoPoint:userLocation withinMiles:2]; 
 
  [query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
 
    if (!error) 
 
    { 
 
      self.workstations = objects; 
 
    } 
 
  }]; 
 
} 

在上述代碼中，我解決了第一個難題：獲取離該用戶的當前位置兩英里之內的工作區的數據。這首先是在應用程序完成裝入后，調用以獲取用戶的當前位置。Parse提供了獲得該數據的一個helper類，那樣我們就沒必要直接依賴CLLocationManager。下一步，調用fetchWorkstationsNearPoint方法，該方法異步查詢Parse的數據存儲區。SDK在幕后進行了REST調用，以便從Parse的數據存儲區獲取數據。

/* 
 
  該方法獲取被賦予iBeacon標識符的工作區數據對象。 
 
然后，它設置已占用屬性，并異步保存對象。 
 
*/ 
 
- (void)setWorkstationState:(BOOL)isOccupied 
 
withBeaconIdentifier:(NSString *)beacon 
 
completionHandler:^(NSError *error)completion 
 
{ 
 
  PFQuery *query = [PFQuery queryWithClassName:@"Workstations"]; 
 
  [query whereKey:@"beaconIdentifier" equalTo:beaconIdentifier]; 
 
    [query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
 
    if (!error) 
 
    { 
 
      POWorkstation *workstation = [objects firstObject]; 
 
      workstation[@"occupied"] = [NSNumber numberWithBool:isOccupied]; 
 
      [workstation saveInBackgroundWithBlock:^(BOOL succeeded, NSError *error) { 
 
        completion(error); 
 
      }]; 
 
    } 
 
  }]; 
 
} 

在上述代碼中，我克服了第二個難題：為某個特定的工作區設置已占用狀態。該代碼就與第一個代碼片段一樣簡潔。雖然你看不到觸發這個整合的iBeacon代碼，但我想捕獲與Parse之間的所有交互。首先，根據信標標識符，獲取特定的工作區。該字符串值是數據存儲區中工作區的一個屬性。下一步，我設置對象的已占用屬性，然后將該值保存回到后臺的數據存儲區。

只需要極少的代碼就可以完成這些任務，因為大多數邏輯都是在Parse的iOS SDK里面進行的。這可以處理諸多任務，比如服務委托、數據轉換及緩存數據存儲，因而大大減少了開發人員在一段時間后需要編寫和維護的代碼。雖然這不是什么萬靈藥，但它為最常見的移動使用場合提供了一種可靠的解決方案。

核心前提

通過上面這個例子，你就能明白MBaaS的核心前提是，它一次性克服了支持移動后端這個艱巨挑戰，那樣可以跨多個項目，始終始一地使用它。你不需要啟用基于云的數據庫、推送通知服務器和用戶管理系統――你需要管理這些系統，而是可以借助MBaaS提供商，它將直接提供所有這一切功能。此外，你再也沒必要為后端的正常運行時間和可擴展性負責，而是這方面完全可以依賴提供商。

雖然MBaaS肯定也遭到懷疑，但毫無疑問，過去一年MBaaS備受關注。早期的MBaaS提供商Parse已被Facebook收購；此后，蘋果、微軟、亞馬遜和谷歌都各自收購了云平臺。此外，現有的提供商已發展壯大；由于平臺日趨成熟，它們的采用率已有了明顯上升。

區別選擇方案

沒有兩種MBaaS解決方案是一樣的，所以知道如何進行比較很關鍵。提供商之間的主要區別在于三大方面：平臺支持、部署方法和功能重心。

跨平臺支持

MBaaS的一個主要優點是，能夠跨多個平臺支持某個應用程序。說到在單一平臺上提供深入整合的數據存儲區（MBaaS的一個組件），iCloud和CloudKit等一些解決方案做得很到位。雖然這很適合單一平臺，但它也大大限制了應用程序在將來成為跨平臺應用程序的功能。不然而，如果某應用程序將來只在單一平臺上運行，這可能是一種很好的解決方案。

有些提供商致力于原生移動平臺，而另一些提供商支持移動Web體驗、甚至桌面應用程序。從本質上來說，大多數MBaaS體驗提供了REST服務，這樣允許在幾乎任何平臺上使用，但針對特定技術的SDK對開發人員來說是一大優點。如果挑選的一家MBaaS提供商提供的SDK可支持你想要支持的所有平臺，那就再理想不過了。

•Parse目前提供的SDK支持iOS、安卓、Windows Phone 8、Windows 8、PHP、JavaScript、Mac OS X和Unity。

•Kinvey目前提供的SDK支持iOS、安卓、JavaScript、AngularJS、Backbone.js、Ember.js、Node.js、PhoneGap和Titanium。

部署方法

除了跨平臺支持外，MBaaS解決方案在如何部署方面也有所差異。想確定哪些選擇方案適合企業，這取決于幾個因素，包括現有的基礎架構、數據存儲方面的監管（針對敏感數據）以及成本門檻。

下面是MBaaS解決方案最流行的幾種部署方法：

•托管型多租戶

如果使用托管型多租戶MBaaS解決方案，你沒必要為在你的基礎架構上部署環境而操心。在大多數情況下，提供商會使用現有的云服務提供商（比如AWS），將你的應用程序部署到一種可擴展的環境上。在這種環境中，你的后端將在服務器上與面向該平臺其他用戶的其他應用程序一塊運行。

•托管型專用

如果使用托管型專用解決方案，提供商仍使用公有云（比如AWS），但你將確保MBaaS環境部署到專門供你使用的服務器上。

•托管型內部

如果使用內部解決方案，提供商將把MBaaS環境部署到你擁有的服務器上。在大多數情況下，這需要你使用一種特定的虛擬化平臺，比如VMware vCloud Air。對一些處理敏感的管制數據的企業來說，可能要求這么做。在大多數情況下，提供商將與企業的內部IT團隊一起共同管理平臺。

•開源

如果使用開源MBaaS解決方案（比如OpenKit和Helios），你將把解決方案自行部署到所選擇的任何基礎架構上，并自行管理。這可能是一種內部的解決方案或基于云的解決方案。不過，你仍得自行維護和更新系統。雖然這種解決方案讓你擁有全面的控制權，但它們也抵消了MBaaS解決方案具有的諸多優點。

對大多數小企業來說，托管型多租戶方案最適合不過了。大企業可能面臨隱私問題、州和聯邦監管以及企業要求，這些因素決定了它只能使用某一種解決方案。比如說，金融機構通常在帳戶數據存儲在哪里方面有嚴格的限制。在這種情況下，托管型內部解決方案可能是唯一的選擇。

Parse目前提供托管型多租戶方案。Kinvey目前提供托管型多租戶方案、托管型專用方案和托管型內部方案。

功能重心

幾乎每一款MBaaS解決方案都有其側重的方面。有些主要針對獨立的應用程序開發人員，而另一些提供商專注于企業。明白自己的精力主要花在何處，也將幫助你確定哪種MBaaS解決方案值得為之投入時間和資金。

這方面的一個典例就是，Kinvey格外注重企業。Kinvey提供了數據連接件規范，讓企業可以將外部數據源連接到現有的MBaaS數據存儲區，另外提供了AuthLink，以便與企業驗證和授權整合起來。這些功能對大多數獨立的應用程序開發人員來說不太重要，但是它們對期望把MBaaS解決方案整合到現有系統中的企業來說卻絕對必不可少。

Parse的重心則不一樣。自從被Facebook收購以來，它并不像過去那么關注企業，但由于被Facebook整合，現在它大大加強了與這個社交巨頭的整合。Parse的SDK現在提供了專門用來簡化訪問某些部分的Facebook數據的七個實用工具。

MBaaS的核心功能

通過MBaaS解決方案提供的大多數核心服務可滿足移動應用程序的基本要求。主要的MBaaS提供商都提供了四大功能：用戶管理、安全的同步數據、推送通知和文件處理。明白這些主要的功能方面，將幫助你了解MBaaS提供商如何能成為你數字化戰略的一部分。

用戶管理

大多數提供商提供了用戶管理這一核心功能。有了這項功能，你就能為每個用戶分配以便與帳戶關聯起來的帳戶。一些服務在此基礎上更進一步：讓你可以輕松整合電子郵件驗證、密碼重置、社交網站登錄和支持匿名用戶。這是MBaaS功能的核心方面，因為它直接關系到整個平臺的安全性?！?/p>

就面向企業的MBaaS而言，這類解決方案更進一步。Kinvey等提供商提供了與現有的LDAP提供商整合的功能，甚至讓用戶能夠使用Salesforce.com登錄信息來驗證身份。這里的關鍵在于，很少有企業客戶想重新處理用戶管理工作，而是就想與現有的解決方案整合起來。一些企業級MBaaS提供商正好滿足這個要求。

安全的同步數據

在如今的數字化領域，用戶很少只與一種設備或者甚至只與一種平臺交互。雖然iCloud等解決方案讓開發人員能夠為同一平臺上使用多種設備的用戶確保數據持久性，但根本無力應對這種情形：用戶需要從網站訪問與從移動應用程序訪問的同樣的數據。同步的跨平臺數據對任何旨在方方面面將自己暴露在用戶面前的應用程序而言必不可少。正由于如此，同步數據是幾乎每款MBaaS解決方案的核心。

推送通知

實時推送通知是許多移動應用程序的一個必要部分。然而，與蘋果推送通知服務（APN）或谷歌Cloud Messaging整合常常需要一種專用的服務器應用程序。許多企業搭建了自己的跨平臺通知服務器來管理這　　種交互。

Parse和Kinvey都為安卓和iOS提供了基本的推送通知整合。

文件存儲和分發

從用戶生成的內容上傳到遠程應用程序內容的全球分發，應用程序需要與文件進行交互。許多應用程序用到現有的服務（比如亞馬遜CloudFront），以便充分利用全球內容分發網絡（CDN），從而分發遠程內容。大多數MBaaS提供商提供CDN解決方案的抽象機制，好讓應用程序開發人員能夠使用邊緣服務器網絡，以便確保其內容以一種始終如一、高性能的方式在全球分發。

額外功能

除了這一批核心功能外，MBaaS提供商在許多不同的功能特性方面開始有所差異。比如說，Kinvey具有iBeacon整合功能，而Parse擁有針對發送短信等功能的第三方整合。如果你期望利用特定的功能，找到一種適合你應用程序路線圖的平臺很重要。這方面橫向評估解決方案變得很困難，因為可用的方案并不完全做到功能對等。

缺點和懷疑

雖然這種功能對期望縮短應用程序的總體上市時間，并跨數字化項目確保后端一致性的企業來說似乎很理想，但也要考慮幾個方面：

•在大多數情況下，MBaaS解決方案旨在在成本方面提供一個非常低的準入門檻。然而，隨著應用程序的使用越來越廣泛，成本曲線通常也會出現相當陡峭的斜坡。

•由于MBaaS解決方案并不完全對應于標準規范，又由于大批數據遷移并不總是很簡單，應用程序被最初選擇的那種MBaaS解決方案牢牢束縛。這倒不是說它沒法更換，而是說在許多情況上更換起來成本很高、很費勁。

•MBaaS提供商眼下是搶手貨。你只要看一下Facebook收購Parse的案例，就明白MBaaS提供商肯定會被收購。全面審查一下你所考慮的每家MBaaS提供商的條款，弄清楚這對你的應用程序會有何影響。

不過，在許多情況下，優點壓倒缺點。正是由于MBaaS存在缺點，要全面地調查可能適合的MBaaS解決方案，之后將某一款解決方案納入到你的應用程序開發計劃中。

MBaaS無疑同樣遭到懷疑。我在MBaaS的早期階段經常遇到這類懷疑人士。他們擔心的主要問題是，單單一款解決方案如何才能提供每個應用程序所需的那種靈活性？事實上，沒有哪種解決方案具有滿足各種要求的靈活性。體驗的所有者需要選擇最適合所需功能以及將用來提供這種體驗的平臺的解決方案。在一些情況下，會發現找不到合適的，這時候自定義后端將是最佳辦法。

在我前面提到的那個使用場合下，這種辦法恐怕為了我減少了幾周的開發工作。此外，它還讓我沒必要監控和管理作為整個解決方案一部分的服務器實例。對我來說，好處就是為這個原型縮短了上市時間。然而，正如我們會在下一個章節中討論的那樣，這并非唯一的好處。

MBaaS和數字化標準

我竭力推崇在企業內部確立數字化標準（不管企業規模大小如何）。數字化標準確實需要深謀遠慮，但是如果實施得當，它們會為整個企業的數字化項目確保很高的效率和一致性。然而，大多數企業只致力于用戶界面標準。在許多情況下，跨多個數字化項目使用MBaaS的企業還有望帶來后端交互方面實現類似的標準化。

跨單一項目采用MBaaS顯然對企業來說有一定的好處，但是最主要的價值還是體現在跨多個項目使用MBaaS所獲得的共享經驗和一致性。

誰應該考慮這種方案？

MBaaS對幾乎任何規模的企業來說都有價值，但是優點不一樣：

•大企業

對大企業而言，企業級解決方案（比如Kinvey）將為企業的移動應用程序如何執行常見任務方面設定后端標準。此外，它統一規范了移動應用程序如何訪問MBaaS云外面的數據（借助Kinvey的數據連接件等解決方案）。

•中小企業

對許多小企業來說，MBaaS提供了一套完全無人管理的可擴展基礎架構。企業可以部署體驗，不需要專門的團隊全天候不間斷地監控基礎架構。此外，它能大大縮短上市時間，并大大減少將來需要維護的代碼數量。

如今許多公司在充分利用這種方法。不少公司在充分利用MBaaS，凱迪拉克、Travel Channel和The Food Network就是其中幾個例子。GovTribe、Hipmunk和Timbre等體驗的背后都有MBaaS提供商的身影。

Parse和Kinvey都提供了幾個客戶案例，可幫助你評估成功的體驗。

結束語和下幾步

我在下一篇文章中將逐步介紹如何構建跨平臺的MBaaS應用程序。那篇文章會重點突出利用MBaaS提供商而不是開發自定義解決方案，從而提高效率的幾個主要方面。

如果你準備現在就投身于MBaaS，那么下一步就是打量提供商提供的實例，分析每種平臺的功能和價格。下列資源會幫助你確定哪種解決方案最適合你的體驗。

Kinvey資源

•開發中心：http://devcenter.kinvey.com

•Kinvey的應用程序成本評估工具：http://www.kinvey.com/app-cost-estimator

•平臺（概況）：http://www.kinvey.com/platform

Parse資源

•說明文檔：https://parse.com/docs

•價格：https://parse.com/plans

•Parse Core：https://parse.com/products/core

英文原文： Understanding Mobile Back End As A Service

布加迪編譯