BaaS后端即服务 - 概念篇

来源:http://www.chinese-glasses.com 作者:Web前端 人气:147 发布时间:2020-05-06
摘要:时间: 2019-09-07阅读: 602标签: 架构 什么是BaaS?## baas_cloud BaaS(Backend as aService)是一种新型的云服务,旨在为移动和Web应用提供后端云服务,包括云端数据/文件存储、账户管理、消息推

时间: 2019-09-07阅读: 602标签: 架构

什么是BaaS?##

图片 1

baas_cloud

BaaS(Backend as a Service)是一种新型的云服务,旨在为移动和Web应用提供后端云服务,包括云端数据/文件存储、账户管理、消息推送、社交媒体整合等。BaaS是垂直领域的云服务,随着移动互联网的持续火热,BaaS也受到越来越多的开发者的亲睐。它作为应用开发的新模型,可以降低开发者成本,让开发者只需专注于具体的开发工作。

可以说BaaS是诞生于移动互联网,为了加速移动应用开发和降低成本而形成的开发架构。BaaS可以带来后端能力的服务化,服务化也为后端能力优化管理带来了可能,这些能力通过服务开发者而诞生,重复的建设和规划会在初期就得到避免。 开发者通过使用这些服务,实现自己的业务功能的同时,也会对服务的能力进一步提出要求,促进后端服务的发展。

通过将 BFF 构建于 serverless 之上,将人工智能实验室(天猫精灵)数十个中后台应用整合到了一个统一入口。用云函数的方式取代了传统基于 NodeJS 的 BFF 层,提供了在一个站点下不同应用以及不同环境的快速切换能力。从而极大程度的降低了开发成本和运维成本,使机器数量从 200 余台缩减为 10 台,同时有效减少了业务方的学习和理解成本。

BaaS的发展

我们很熟悉IaaS, PaaS和SaaS,这些也是云计算发展的经历阶段,

IaaS, Infrastructure as a Service: 基础设施的服务化,诞生里AWS,阿里云等
PaaS, Platform as a Service: 开发平台的服务化,诞生了Google APP Engine,阿里云,百度开放平台,腾讯开发平台,sina开发平台等。
SaaS,Software as a Service, 软件的服务化,如微软的Office 365.
BaaS, Backend as a Service ,后端的服务化。

BaaS是在PaaS和SaaS之间,为了满足移动互联网快速发展的需要,将后端的能力以服务形式提供,是在PaaS平台开发能力的基础上,用SaaS的思路,将后端能力服务化,让开发者在此基础上开发自己的Software解决方案。

本文主要讲述了 BFF 局限性以及我们对应的 serverless 解决方案,其中平台核心功能包括:

BaaS是PaaS进一步发展

BaaS也是移动中间件的替代品(或者说备选方案),它使用统一的API和SDK来连接移动应用到后端云存储,传统的移动中间件通过本地的物理服务把后端服务集成到应用中。而BaaS通过云来集成后端服务。中间件和BaaS的最大不同是它们是否包含或者提供云的服务,BaaS可以说是PaaS平台在移动垂直领域的延伸,更可以说是移动中间件和云的融合。

BaaS简化了应用开发流程,而PaaS简化了应用部署流程。PaaS是一个执行代码以及管理应用运行环境的开发平台,用户通过SVN或者Git之类的代码版本管理工具与平台交互,对于开发者来说,PaaS就像是一个容器,输入是代码和配置文件,输出是一个可访问应用的URL。而BaaS平台进一步将用户需求进行了抽象,比如用户管理,开发者希望创建用户数据库表(模型)后,客户端就可以通过Restful接口直接操作对应的模型,所有的操作都可以被抽象为CRUD。之前,开发者需要创建表、写接口、写校验,而在BaaS平台中,开发者只需要定义模型,平台就会自动生成对应的接口,这可以让开发者更加专注具体的客户端代码。

云函数:

BaaS是开发架构的升级,从J2EE中间件时代走入云计算服务时代####

图片 2

baas_28

J2EE Stack -> BaaS

从web时代兴起以来(web 1.0, web 2.0),我们就进入J2EE时代一直到现在,我的的开发架构基本在J2EE各种规范的覆盖下, J2EE通过定义一整套服务(Services)、应用程序接口(APIs)和协议,对开发基于Web的多层应用提供了技术栈支持:

  1. JDBC(Java Database Connectivity),JDBC API为访问不同数据库提供了统一的路径
  2. JNDI(Java Name and Directory Interface),远程方法请求,RMI协议调用远程对象上的方法.它使用了序列化的方式在客户端和服务器之间传递数据
  3. Java Servlet, web服务器的功能扩展
  4. JMS, 面向对象消息的中间件相互通信的应用程序接口
  5. ...

我们的服务器端开发由此也进入中间件时代,利用这些中间件提供的功能,规范来满足商业需求。J2EE,中间件的发展也最后形成了云架构时代的PaaS基础,这些中间件,服务器等形成一个开发平台,利用各种规范和协议来提供开发者全面的能力,
这也是我们目前最熟悉和习以为常的开发架构。我们会一度认为,功能太强大丰富了,已经发展到足够好了,剩下的是需要开发者努力去掌握各种技术细节就好。 当我们有这种想法的时候,其实也代表这种架构发展到了瓶颈期。

这种开发架构在我们队开发效率和成本的追求下,更逐渐暴露出教多的缺点,他对开发人员的技术素质要求较高,同时对开发效率的提升设置了一定的壁垒。当我们想进一步追究开发效率和减低开发成本时,我们就需要对这种开发架构做进一步的发展升级,同时随着云计算时代的到来,也为开发技术架构的升级提供了基础。

将 BFF 层的 Node 应用代码拆解成独立云函数,支持动态编写、秒级部署,平台提供隔离的沙箱容器进行执行,并自动接入日志和监控系统,使开发者可实时掌握函数的运行状况;

BaaS如何提高开发效率和降低开发成本####

让我们想想我们开发一个典型web业务系统需要做的事情。

这种开发一般分为后端开发和前端开发, 其中后端需要负责数据存储,检索,集成,业务逻辑,认证授权等一些列功能,想象中可以很简单:

图片 3

baas_3

其实这更接近真相:

图片 4

baas_4

然而这些还不是全部:

图片 5

baas_5

做一个互联网的高可靠高并发高性能的web系统,开发的能力可能需要长时间的积累和付出巨大的资源成本。

当开发了越来越多的类似系统后,我们就会感觉到,除了具体业务逻辑外,我们在做很多重复类似的工作。如果有个界面给我们,让我们选择输入我们想要的功能就能一键输出最后的API,世界将会美好很多。

而云计算的发展也让我们对这种设想变得原来越可能,
我们在阿里云这样的IaaS上,输入我们需要的服务器数目和配置,点击后,我们就把服务器部署解决了。

当我们在阿里云的PaaS上选择RDS,OSS,消息这种中间件服务时,我们需要的存储,消息等能力也可以说一键解决了。

那么更进一步期望, 我们很多的共用服务,比如认证和授权,消息推送,数据建模,地图,语音等是否也能够一键解决就好了,阿里云提供的功能还不能到这一阶段。

而提供这些服务的方式就是BaaS,后端即服务。将后端的能力打包以服务的方式向外提供。

图片 6

baas_8

将后端能力形成平台,构建新的开发架构:

图片 7

baas_6

这就是BaaS架构的公式:

BaaS = IaaS + PaaS + APIs + SDKs

图片 8

baas_9

利用IaaS , PaaS ,API以及SDK基础, 把后端能力以服务的形式提供出来。

对于开发者来说,只需要利用API或者SDK,就可以完成对应的功能,从而可以只专注于本身业务逻辑的开发。 在这种开发架构下, 业务系统的开发将大大提速,没有后端复杂的开发,维护,只需要利用以后的服务完成业务逻辑的开发。 对开发人员的技术要求也极大降低。

图片 9

baas_11

应用:

BaaS业界生态####

BaaS在2012年以来在业界发展迅速,
2013年4月,Facebook收购Parse;2014年6月,苹果在一年一度的WWDC上发布了CloudKit;等到了2014年10月份,Google也出手收购了Firebase。

Parse,Firebase等是BaaS创业公司里的佼佼者,三大互联网公司最近2年在BaaS里的动作也反应了他们对BaaS的重视。

Facebook期望结束应用之间的信息孤岛状态,让不同应用之间的内容能够互通和无缝跳转,于是就发布了一个名为AppLinks“协议”,但这个协议背后则需要Parse这样的后端服务提供数据存储、计算能力、Push通知等一系列技术支撑。

苹果来说,CloudKit可以提供完善且有弹性的后端解决方案,帮助开发者减轻编写服务器代码和维护服务器的需求。很明显,苹果此举也是为了降低开发iOS应用的成本,维护iOS生态圈的繁荣。

Firebase创始人James Tamplin在博客上说的那样,Firebase和Google Cloud Platform可以很好的互补。而且在苹果为iOS开发者提供了CloudKit之后,Google或许也想能有类似服务来为Android生态圈的开发者们提供便利。

在下篇《BaaS后端即服务 - 分析篇》中,我们会对这些主流BaaS平台的功能和架构做详细对比分析,研究其发展趋势。

将各平台的前端代码打包部署,入口路由进行统一注册,我们将这些平台称为应用。

BaaS的价值####

BaaS可以很好的解决技术和业务之间的沟壑,通过BaaS,业务开发团队就像是外界的创业公司,他们的核心竞争力是对业务的理解和实现,让他们以用低成本的方式快速做出能满足自身需求的应用,然后把主要的资源都投入到扩展核心竞争力上面。

BaaS平台本身可以以产品的方式构建,将PaaS的能力升华成对开发者更加简单易用的BaaS服务。 平台独立运维,部署,提供高并发高性能高可靠的服务能力。

BaaS平台可以作为云产品为中小型开发者、创业团队、企业和机构,提供各种BaaS的相关产品和服务。

  1. 个人移动开发者创意实现的门槛问题。对于个人移动开发者而言,要兼具前端和后端的开发能力,才能将好的想法实现,这就需要外包或组建小团队,而对绝大部分人而言并不容易。
  2. 创业团队的成本控制和快速开发需求。对于创业团队,快速敏捷才能抢占市场先机,而移动应用的后端开发和运维工作重复单调繁重,会耗费大量的时间和人力,而创业团队因种种原因,往往一人身兼多职,人力不足,导致产品上线时间不断延期,很多好的创意就这样夭折了。
  3. 企业的数据安全和敏捷开发需求。对于企业而言,自己造后台重复,劳民伤财,与其将人力和时间投入到重复的无意义劳动中,不如购买已有的成熟服务,将企业人力投入到更具创造性价值的岗位上,但各个企业业务逻辑也千差万别,因此,亟需适应自身企业需求的私有云定制服务。

简单地说,Baas 是业务开发的后端业务逻辑解决方案的提供者。为个人开发者和创业团队提供免费的公有云服务,为企业提供私有云定制服务。BaaS的主旨是为开发者免去后端开发和部署的烦恼,让开发者无需购买服务器(IaaS),无需部署后端环境(PaaS),无需编写后端代码(BaaS),轻松修改业务逻辑(SDK和API),快速实现创意(Happy)。

同时,这些无需的背后意味着各种成本的降低,你不用去操心运维了,不用去学习各种中间件了,不用去担心高并发稳定性了,等等.... 所有的这些都变成了简单的服务。

这些应用将直接支持各环境切换及多套预发环境解决方案;

BaaS的想象空间####

  1. 作为移动互联网的基础服务
    Baas面向所有Web和移动应用,移动互联网规模巨大
  2. 与企业市场若即若离,有巨大价值
    BaaS将云服务和开发者服务连接起来,对个人免费,对大中型企业用户收费
  3. 与大数据相联系,只手掌握未来
    BaaS特点是与开发者共享用户,通过API和SDK可以收集用户行为数据。结合大数据的商业智能化,将产生巨大价值和数据壁垒。

SDK:

框架将集团中间件封装为 BaaS SDK 供应用直接调用,提供一套统一的 API 抹平了 Web 和 Node 的差异;

CLI:

提供命令行工具便于开发者可脱离 web 管理平台,而直接快速进行开发、调试和发布。

BFF 的局限

从传统大型机到服务器集群,从虚拟技术到容器化,我们正在走向那些更加轻量、更俱灵活性的解决方案。

阿里各 BU,在“大中台,小前台”的大背景下,也逐渐从巨石应用拆分为了更为灵活的微服务,以便以更小的粒度服务于更多的需求方。

而前端也在以往前后端分离的基础上,更进一步的演变为了 BFF 架构。根据最终端上的需求,通过 BFF 层将各个微服务进行聚合和裁剪后返回。根据”谁享受谁负责“原则,该 BFF 层通常由前端使用 NodeJS 维护。

然而,作为横向支撑的前端团队,我们在实施 BFF 架构1年后,却发现它可能并没有想象的那么美好。为什么会这么说?截止目前,我们大概有40个左右不同的平台服务于我们的各个团队(包括运营、市场、测试、工程、算法、硬件和数据),对于大量的平台的存在,对开发人员的维护和业务方的理解,都成为了一种负担。

首先,每个平台都有一个对应的 Node 层来作为 BFF,我们仍然需要针对每一个平台部署代码、安装依赖的各种软件,关心究竟需要多少台服务器,这极大的增加了我们的运维成本;

其次,由于各个平台十分分散,均由独立域名进行访问,不同团队可能并不清楚已经存在一个类似平台从而导致提出相似需求,并且各个平台对于账户、权限、文件上传等中间件都需进行接入,对开发资源造成严重浪费;

最后,作为业务方,需要记住大量不同平台域名和对应的功能,也成为了一项挑战。

而每个平台还有对应还有多套环境,其也增加了他们的沟通成本和使用成本。

所以,我们核心面临的问题总结起来就是运维成本难降低、重复开发难避免、入口分散难管理。那么有没有一种更轻量的架构,使我们所有人能从上述这些繁琐的工作中解放出来?

我们想到了 serverless,它让 NoOps 成为可能,实现零配置发布业务代码,这能极大降低运维成本。但传统的 serverless 仍然只能解决一个点的问题,如果我们做的更进一步,将 serverless 与已有的 BFF、FE 整合,那是不是有可能同时解决上述问题?基于上述思考,我们提出了自己的 serverless 架构。

在此之前,先介绍一下什么是 serverless。

serverless

serverless 的定义如下

无服务器架构是基于互联网的系统,其中应用开发不使用常规的服务进程。相反,它们仅依赖于第三方服务,客户端逻辑和服务托管远程过程调用的组合。

目前我们说的 serverless,最常是指 Amazon 在 2014 年发布的 AWS Lambda 服务,为在服务端中运行的程序提供了一种全新的架构。我们不需要在服务器上持续运行进程以等待请求,而是可以通过某种事件机制来触发容器从而动态的执行代码。

不需要再关心应该配置多少机器,需要预装哪些依赖,这些统统由平台搞定,而我们只需要维护一个功能的集合,这些功能以“函数”的方式被调用。这种模式我们通常也把它称为 Faas(Function as a Services),一种比微服务粒度更小的代码组织方式。

关于 serverless 的介绍网上已有很多,具体可以从下面这篇文章开始,这里不再进行赘述。

从IaaS到FaaS—— Serverless架构的前世今生

BFF in serverless

然而独立的 FaaS 其实并不具备实用性,因为他是无状态的,无法进行存储意味着无法针对不同用户提供服务。Amazon 的解决方案是让 Lambda 打通 AWS 大量基础服务,通过简单的 API 调用,即可使用 S3、RDS 等存储服务来保存用户数据。即使这样,仍然有很多工作需要开发者完成。

我们结合的实际情况,在平台中统一了 FE、BFF,并封装了大量集团中间件,使其成为一体化解决方案,让开发者仅需在一个平台,即可完成应用的开发、调试、构建和部署。

本文由10bet发布于Web前端,转载请注明出处:BaaS后端即服务 - 概念篇

关键词:

最火资讯