BaaS 服务如何用一套代码解决所有需求

2016 年 Google I/O 大会上,Google 彻底改造了 Firebase 这个 realtime database,将文件存储、推送、统计等众多开发者服务打包到一起,使之成为了下一代的云计算平台。在此之前,云计算领域的标杆企业 Amazon,也于去年推出了 MobileHub 产品,将 Amazon AWS 原来的单项服务统合起来,提供应用开发的一站式解决方案,并且在今年年初,又推出了一个名为 Lambda 的新服务。

说起云计算,大家比较熟悉的有 IaaS、PaaS、SaaS,对于上面的新形态,业界给它取了一个新名字:BaaS(Backend as a Service),是说将产品开发中所有后端的需求,通过统一的云平台来解决,这样产品开发团队只需要关注客户端的开发,重点打磨用户体验,快速、高效做出更好的产品。

理想是美好的,但是现实中这都行得通吗?我们知道,业务的需求千变万化,一个统一的云平台,一套代码,真能解决所有问题吗?如果能,又是怎么做到的呢?笔者这里就这些技术细节来跟大家做一个探讨。

后端服务其实也是高度模式化的

提起后端开发,我们最先想到的可能就是 LAMP(Linux+Apache+MySQL+PHP) 技术框架,从系统架构上来看,一个典型的业务系统至少包含如下三部分:

common_arch.png

在业务发展的过程中,我们工程团队花费了大量的精力,解决的都是「扩展」和「容错」这两个问题,对于核心架构却绝少改变。

同时,因为每个产品具体业务不一样,所以客户端和 App Server 的交互内容千差万别,但有两点是基本一致的:

  • 交互协议,基本上都是基于 HTTP(S)。
  • 尽管数据格式千差万别,但是「数据」本身是一样。

不论 App Server 内又细分了多少个模块与子服务,它总是将客户端传来的数据,结合业务规则进行处理,并最终持久化到 Database。所以这就给了我们一个启示:如果我们的云平台能支持任意数据的增删改查,而数据本身由应用自解析,这样就能解决大部分产品的后端问题了。所以我们选择了「JSON Object」这一相当宽松的数据模型,作为客户端和云端交互的唯一格式要求,我们并不关心里面有多少属性、取值如何,而且我们也不理解具体的数据含义。现在我们通过这样的方式来提供通用的后端结构化数据存储服务:

common_arch_object.png

这样,应用开发者可以将任意的数据存储到云端,例如我们要实现一个类似于微博的社交 App,主要有三类数据:账户、帖子、评论,一条微博帖子可能包含下面几个属性:

{
  "content": "每个 Java 程序员必备的 8 个开发工具",
  "pubUser": "LeanCloud官方客服",
  "pubTimestamp": 1435541999
}

无需提前创建表格、指定 schema,这样的数据可以直接存入 BaaS 云端(JavaScript 的示例代码如下)。

var Post = AV.Object.extend('Post');// 声明类型
var post = new Post();// 新建对象
post.set('content','每个 Java 程序员必备的 8 个开发工具');// 设置发布内容
post.set('pubUser','LeanCloud官方客服');// 设置发布者信息
post.set('pubTimestamp',1435541999);// 设置时间戳
post.save().then(function (post) {
    console.log('objectId is ' + post.id);
  }, function (error) {
    console.log(error); 
});// 保存到云端

客户端和云端交互的问题解决了,而要构建一个能支持大量应用的统一平台,在 App Server 端,我们还有大量的开发工作要做。就 LeanCloud 来讲,我们后端系统的核心架构如下:

structure2.png

这里重点要解决如下几个问题:

  • 如何支持任意对象的存储。因为每个应用的 domain class 都各不相同,我们需要能统一存储到一个集群里面去,这就需要后端存储系统支持 schema free 的特性,能够随时应对新结构、属性的追加,而同时我们又要保证现有数据的 schema 不能遭到破坏。我们的存储集群综合使用了关系型数据库(MySQL)、NoSQL 数据库(MongoDB)以及 Hadoop/Hbase 等开源系统来完成这一需求。
  • 如何保证应用之间的数据隔离。在我们的存储系统里,我们为每一个应用建立了单独的「Database」,以保证应用之间数据是物理隔离的,同时我们所有的数据请求都需要带上应用标识,在开发者没有明确设置共享的情况下,跨应用的数据访问是绝对禁止的。
  • 如何保证数据安全。我们做了多方面的努力,来保证各应用的数据安全:
    • SSL 加密传输。我们所有的 API 请求都通过 SSL加密传输,保证传输过程中的数据安全性和可靠性。并且,我们的 iOS/Android SDK 还加入了防范中间人攻击的措施,彻底排除网络抓包和嗅探的威胁。
    • 身份鉴别(Authentication)。我们云端对客户端发过来的每一个请求,都进行了身份鉴别(Authentication)和访问授权(Authorization)的严格检查。BaaS 平台为每一个应用准备了标识信息(应用 id 和应用 key),在每一次网络请求中,我们都要求 SDK 带上 app 标识信息(鉴权签名),以此来对请求发起方进行身份鉴别。
    • 访问授权(Authorization)。Authentication 解决的是冒名访问的问题,Authorization 则对一个合法用户的操作进行权限检查,以保证登录者不能看到或者破坏 ta 本没有权限操作的数据。BaaS 平台对每一条数据都提供「ACL」(Access Control List,访问控制列表),以供开发者进行更细粒度的控制。
    • Web 应用安全域名。在通用的两层鉴权机制之外,我们额外增加了 Web 应用的安全域名设置,以此来对请求来源进行限制,防御住 Web 应用的服务器资源盗取问题。
    • 其它安全措施。我们还有更多的安全选项和数据备份设置,具体可以登录我们的 BaaS 平台了解更多。
  • 如何应对大流量、保证高性能。压力和性能看起来是一对矛盾,但其实它们是一个硬币的两面,我们讨论性能的时候都需要明确是在多大的访问压力下得出的。为了保证在流量增长的情况下,还有出色的性能,我们在架构设计上对 scale up/scale out 做了很多努力,譬如,内部系统都尽量采用微服务的架构,使用 Apache mesos/marathon/Docker 和自动化运维技术来管理资源池并实现自动扩展,等等。

业务逻辑千差万别,通用平台如何解决特定需求

大家可能会觉得,上面的方案只解决了基本的数据增删改查的问题,并不能覆盖复杂的业务逻辑。例如我是一个网商产品,消费者下单购买了某个商品,后台除了需要生成订单、更新库存之外,还需要能通知到物流等其他环节,这时候怎么办?

我们提供了代码扩展的功能——云引擎。这是一个给后端 Web 开发者的零管理计算平台,使用方式上与 AWS 的 Lambda 一样,开发者自己用 Node.js / Python / PHP 等语言实现自己的核心业务逻辑,然后部署到 BaaS 平台的独立容器中,就可以完成一些特定的业务需求了。开发者无需关心具体的代码部署、负载均衡以及平行扩展,都由 BaaS 平台来保证的,所以说这是一个「零管理」的计算平台。

开发者可以使用云引擎来完成如下功能:

  • 定义新的函数,供客户端直接调用,完成特定的业务逻辑,以此来自由扩展数据存储的标准 API 接口;
  • 定义 Hook 函数,响应特定事件(譬如某类数据被修改、被删除等),完成各种关联操作,其作用类似于数据库的存储过程或 trigger。
  • 甚至,还可以用来进行网站托管,这就和大家熟知的 App Engine 差不多了。

为了保障性能,在云引擎中我们也提供云缓存(类似于 memcached、redis)等服务,这样方便开发者轻松实现各种个性化场景功能。

结论

使用第三方云服务已经是大势所趋,在新的产品开发流程里,我们希望让更多的团队忘掉「infrastructure」,能够集中精力在解决用户的问题,而不要浪费时间在打造「又」一个复杂的后端系统。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249

推荐阅读更多精彩内容