全方位认识移动后端即服务 MBaaS-移动后端开发

【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功能的核心方面，因为它直接关系到整个平台的安全性。　

就面向企业的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

布加迪编译