小程序上云,有点猛

2019-04-06 21:56 稿源:InfoQ公众号  0条评论

2

小程序Serverless

无服务器托管模式

当开发者想要开发一款小程序的时候,需要考虑的东西有很多:

这个是一个典型的场景,也是开发商的一个标准模式。而对于创业者,或者想快速开发一款小程序的人来说,有没有一种方式将复杂的后端简化?

设想一下,能否将右面所有的东西都简化成一个API,这样用户在开发小程序的时候,只需要考虑业务逻辑,后端直接调用相应的API即可?

如何实现?——>Serverless提供思路:

Serverless是目前最受开发者关注的技术之一。Serverless不代表再也不需要服务器了,而是说:开发者再也不用过多考虑服务器的问题,计算资源作为服务而不是服务器的概念出现。Serverless是一种构建和管理基于微服务架构的完整流程,允许用户在服务部署级别而不是服务器部署级别来管理你的应用部署,用户甚至可以管理某个具体功能或端口的部署,这就能让开发者快速迭代,更快速地开发应用。

Serverless对于小程序后端简化的启示:

传统开发模式可以抽象成三大类内容:

计算资源,就是常说的服务器,包括常见的物理机、虚拟机、容器等;

中间是存储和基础能力,存储包括文件存储、数据库、离线存储等,基础能力是用户在开发过程常用的辅助能力,比如视频压缩、图片水印、消息、定时任务等;

网络和安全,这往往是云端最复杂的部分,这里需要考虑安全、稳定、容灾、风控等问题,也是开发者最容易忽视的问题。

基于这三部分体系,Serverless如何简化?

网络和安全的简化方式:将域名、证书、流量控制、容灾等通过平台内置,由云端接管,形成底层基础设施,对用户直接透明。

计算资源这部分的简化方式:将其所有内容简化为Compute,所有的计算资源在云里对于用户的直观感受就是运行池,运行池如何布置、弹性如何实现等,无需开发者关心。

存储和基础能力的简化方式:BaaS(Backend as a Service)是Serverless的核心。后端除了计算以外的所有能力都可以封装为API,实现开箱即用。简单来说,用户根据需要可以随时调用相应的API,而不需要关心底层的执行和运维。

以上就是Serverless最直观的抽象。基于Serverless的原理,如何构建支付宝小程序Serverless呢?

支付宝小程序Serverless架构如下:

首先来看Compute 部分,从用户的角度,他不需要考虑服务器、Linux、文件存储等,而只需要关心代码,这里涉及App Service的概念,App Service意味着当用户提交一个应用到云上,云端会自动识别应用的构件、部署、弹性,中间的过程用户不需要关心,直接通过API调用即可。

BaaS这部分,就是将所有的能力封装成API,上图中列举了三种解决方案:存储方案、多媒体方案、安全方案。以存储方案为例,存储方案就是将文件、数据库的存储进行API化。举例来说,如果用户有一份数据需要保存,通过调用存储方案API接口就可以实现直接保存。

在Compute和BaaS之上,整套小程序Serverless体系中,用户是不需要关心域名和证书的,因为域名、证书、DDoS防御、流量镜像等已经内置在平台里。需要说明的是,流量镜像是蚂蚁金服特有的能力,可以帮助用户分析流量,寻找流量的风险点,从而对流量进行处理和清洗。

小程序Serverless最上层要解决认证问题。小程序Serverless中已经内置支付宝、高德的体系,默认在使用时已经包含OAuth方案。随着阿里系小程序的全面打通,云端的认证差异问题将通过体系内置方案解决,对用户而言只需要使用统一的API就可以完成认证。

小程序Serverless重点的技术方案如下:

(1)共享资源管理

当用户访问网关时,网关会产生一份摘要数据,数据信息很简单,比如“A小程序访问a数据库 1 次”;数据产生后会进入调度核心,调度核心会根据用户的摘要数据判断用户要访问哪里,并将信息传递给决策,决策再把信息录入到相应数据库中。

由于用户的规模是处在动态变化中,随着用户规模的递增,系统感知到数据的增加,会新初始化一个独立的实例,保证更高的性能和可用性;如果用户数增长特别迅猛,系统感知到后也会将数据进行一定的迁移。这样就实现了根据用户的增长情况,底层资源进行动态调配。

(2)Compute调度

Compute调度依赖于App Service的弹性支撑,是如何实现呢?

App Service有两个概念很重要,一是弹性免运维;二是按量。所谓按量,就是App Service是按照正在执行的业务量来计算。当用户的访问信息进入调度核心,如果机器没开始运行,则将访问信息放到预热池。预热池里会提前初始化Node.js或者Java的执行环境,这样当用户访问信息进入时,可以从预热池中快速调度资源进入Runtime中执行。随着用户访问信息的减少,Runtime会释放一定的资源。这样Compute调度就可以实现根据业务量的情况,在底层资源配置上实现动态化。

(3)数据安全

数据安全问题是Serverless的核心问题。当小程序Serverless把后端服务开放到云端时,后端服务的安全性如何保证?

当用户访问信息通过语义控制后,会进入安全规则进行校验,安全规则的样例如上图。安全规则可以简化为两条:一是用户的数据写入后,所有人都可以读;二是用户写入的数据,只有用户自己可以修改。

不仅如此,小程序Serverless还提供了角色的定义,这就意味着开发者可以指定管理员有哪些权限,游客可以访问哪些内容等。

小程序Serverless的优势:

(1)研发效率大幅提升:在小程序Serverless解决方案下,不需要考虑服务器、资源配置、关联端口等问题,整个开发效率会大幅提升。此外,由于在我国域名申请是需要备案的,备案时间需要30~ 45 天,这就意味着新业务的上线至少要等到 45 天以后。这对于希望小程序快速上线的开发者而言绝对是一个漫长的时间。但是小程序Serverless方案里是不需要用户考虑域名、证书等问题,用户开发完即可上线,这极大地提升了研发效率。

(2)安全可靠的后端服务:网络和安全这部分在小程序Serverless里处于基础设施层,相当于一个平台层,由平台管控,帮助用户实现后端安全服务。整套方案是双机房,数据备份已经帮用户做好,只要用户使用这套方案,就享受安全可靠的后端服务。

(3)更低的成本:以前小程序的后端开发主要考虑两部分成本:一是人力成本,二是资金成本。使用小程序Serverless方案后,整个研发团队不再需要配置运维工程师,后端工程师,安全工程师等,只需要一个会Node.js的前端开发者就可以完成小程序前后端开发。

使用小程序Serverless方案,节省了购买服务器、数据库等的花费,Compute调度是按量付费,也就是只为运行的业务付费,进一步节省了资金成本。

小程序Serverless的未来?

(1)更丰富的BaaS:小程序Serverless会提供更多的基础能力,完善开箱即用的API化。

(2)完善的数据分析:对于商家而言,技术远没有数据更具有价值。数据对小程序的业务发展具有指导意义,小程序想在业务层面取得重大突破,离不开完善的数据分析,为用户提供更多指引。小程序Serverless会不断完善数据分析,帮助商家更好地服务消费者。

(3)前后端一体化:对于商家而言,搭建管理后台非常关键。商家需要录入商品、查看账单等操作,在Serverless方案里提供可视化搭建的集成解决方案,通过拖动相应组件实现管理后台的需求。小程序Serverless后面会不断强化前后台一体化,帮助商家更好地管理后台。

(4)场景化解决方案:在实现通用的能力之外,小程序Serverless会针对一些特殊的业务场景,提供前后端一体化整套方案,满足商家的个性化需求。

支付宝小程序云服务会越来越成为主流的开发模式,“只要有创意、有想法,未来哪怕不具备丰富开发能力的人,也一样可以通过云服务,高效开发出一款不错的小程序”。

未来,阿里系的几大超级App,包括淘宝、钉钉、高德、饿了么等,底层能力都将打通,形成无缝对接。这意味着,阿里系的多元化能力,可以随意组合了。

比如,支付宝小程序不仅可以拥有支付宝的芝麻信用能力,还可以拥有菜鸟的物流能力、饿了么的配送能力、高德的LBS能力等。这些能力都以API接口的形式汇聚到一个API市场里,开发者在开发应用的时候,可以方便地获取,进行按需组装。

想象这样一个场景:你想吃火锅,在高德搜索附近的海底捞,通过高德地图导航过去,同时高德会自动弹出海底捞支付宝小程序,你可以先点餐、领优惠券;吃完饭想去商场逛逛,进入商场的支付宝小程序,小程序里面有停车服务、商家的优惠券等。

阿里真的很懂B端。

虽然阿里系小程序还处于萌芽早期,落地案例并不多,不过随着各大超级App底层能力的互通,势必会实现更多场景的打通和串联。  

商家更关注的流量问题,目前,支付宝、手淘、高德、钉钉、饿了么和微博,这 5 个App的月活总数已经超过 20 亿。各大超级App间的互相导流,将原本各自为战的流量汇聚在一起,形成超级流量红利。这就意味着,通过入驻支付宝小程序,电商、金融、生活服务等各行业开发者和商家将无需反复“造轮子”,即可快速对接整个阿里数字经济体生态,直接复用阿里巴巴二十年积累的运营能力。

换句话说,支付宝小程序云服务已经帮你到这了,剩下的就看谁有本事了。

声明:本文转载自第三方媒体,如需转载,请联系版权方授权转载。协助申请

相关文章

相关热点

查看更多