Serverless(无服务器架构)是指服务端逻辑由开发者实现,应用运行在无状态的计算容器中,由事件触发,完全被第三方管理,其业务层面的状态则存储在数据库或其他介质中。
Serverless可以使开发者更聚焦在业务逻辑,而减少对基础设施的关注。
Serverless通常包含了两个领域 BaaS(Backend as a Service)和 FaaS(Function as a Service)
BaaS是一种广泛依赖于第三方应用和服务的无服务器计算方法。BaaS供应商可以提供加密、用户认证、云数据库的使用。这些服务可以通过调用云供应商提供的API进行访问;相比自己重新开发,这些功能可以更方便地整合到各个类型的系统中。
FaaS 是一种事件驱动的由消息触发的服务,FaaS 供应商一般会集成各种同步和异步的事件(如AWS的SNS),通过订阅这些事件,可以触发指定的函数运行,例如当前使用很广泛的 AWS 的 Lambda函数。
Serverless架构的优点
降低运营成本:
Serverless是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑。由于这个服务使用者的数量会非常庞大,于是就会产生规模经济效应。在降低成本上包含了两个方面,即基础设施的成本和人员(运营/开发/维护)的成本。
降低开发成本:
Serverless作为一种云服务,使得整个应用程序组件被商品化。
扩展能力:
横向扩展是完全自动的、有d性的、且由服务提供者所管理。从基本的基础设施方面受益最大的好处是,您只需支付您所需要的计算能力。
更简单的管理:
Serverless架构明显比其他架构更简单。更少的组件,就意味着您的管理开销会更少。
有效利用计算资源:
据《福布斯》的统计,在商业和企业数据中心的典型服务器仅提供5%~15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。Serverless让服务提供商提供我们的计算能力最大限度满足实时需求,更有效地利用计算资源。
Serverless架构的缺点
状态管理:
要想实现自由的缩放,无状态是必须的,而对于有状态的服务,使用serverless这就丧失了灵活性。
延迟:
Serverless应用程序是高度分布式、低耦合的,这就意味着延迟将始终是一个问题,单纯使用serverless的应用程序是不太现实的。
本地测试:
Serverless应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境,但是对于无服务应用的集成或者端到端测试很困难。
前端的发展太快了,前端框架和技术的发展也层出不穷,还包括不同智能设备的出现,对前端开发同学来说是个很大的跳转,简单列举下:
这样就滋生了一些问题,比如我要开发一个通用的页面,兼容不同的端侧和 小程序 ,显然目前是做不到的,我们只能开发多套页面去适配不同的场景,这样的话成本就太高了。
很多同学都在尝试解决这个问题,也催生了类似taro这样的多端统一开发框架,这是一个好的解决方案,但是比较被动,缺乏一定的扩展性。
这篇文章我们要探讨的是,看能不能换个角度去解决这个问题,提升开发效率。
ViewModel
当我们在开发一个页面的时候,不管用的是哪一种框架,通常都会抽象出一层viewmodel层,它主要有2个作用
从上图中我们可以看出,viewmodel是一段独立的通用代码逻辑,起到了承前启后的作用。它和view层关系更加紧密,因此通常会放在前端测。
既然viewmodel是独立的,那我们能不能把它放在后端呢?这样一个最大的好处就是viewmodel可以进行复用,不需要在重复编写,而且只需要改动一个viewmodel,就可以全量生效。
似乎是一个很美好的想法,但是这部分代码由谁去开发呢,总不可能寄希望于后端同学吧,当然只能是我们自己,也感谢于serverless架构的出现,让这件事情变成了可能。
有些同学可能会问,既然viewmodel后移了,那view呢?后续会考虑结合我们的ui2code技术,那真的就比较完美了。
什么是serverless
架构上,我们可以把serverless分为FaaS和BaaS。
FaaS是用于创建、运行、管理函数服务的计算平台,它支持多种开发语言,比如java、nodejs、dart等,这有利于不同端侧的开发同学介入开发。FaaS是基于事件驱动的思想,只有当一个函数被事件触发时才会占用服务器资源执行,不然都是无需占用服务器资源的。
BaaS提供了用于函数调用的第三方基础服务,比如身份校验、日志、数据库等,它是由服务商直接提供,开发者无需关系实现,直接调用即可。
业务落地
我们是通过gaia平台开发后端接口,gaia可以理解为上文提到的FaaS平台。
日常开发中有这样一个需求,下面是这个需求的一个页面。
因为这个页面上的数据比较多,先把它切分成一个个小的模块,后台返回数据的时候也根据模块来返回数据。
我们是根据viewmodel来设计接口,首先肯定有一个首屏数据接口;然后是页面上的交互,比如切换卡片、切换芝麻信用按钮,切换会引起页面数据变化,我们可以统一封装一个页面更新的接口;最后是一个开通的接口。
后端接口
前后端交互最重要的数据结构的设计,我们省略了中间的业务逻辑处理,看下接口的数据结构。
首屏接口返回的数据主要有几个特征:
更新接口的返回数据结构和首屏接口类似,但是入参有所不同,主要包括2个字段:
前端处理
从后端返回的数据可以看到,数据是及其详细的,无需我们做任何的业务逻辑处理,直接映射到页面即可。这样,前端已经变成了很薄的一层数据,没有任务的业务逻辑处理,变的很简单,当需要迁移到其他端时,只需要迁移视图层即可。当有任何的业务变动时,只需要修改后端的接口,就能生效。
收益与总结
通过具体的实践,我们发现,对于前端开发同学来说,变的简单了,开发效率有很大的提升,前端同学甚至都不需要去理解具体的业务逻辑,就能完成页面的开发。而且,提取的viewmodel可以复用到不同的端侧,设置还包括native端。我们还可以将viewmodel拆分成更小粒度的viewmodel,方便在不同的页面接口中进行复用。我们有同学还在FaaS侧基于redux的思想封装了一个通用的状态管理框架,规范了前后端的交互。
后面, 还有一些问题待我们去解决,比如开发成本、viewmodel的逻辑拆分、具体接口问题定位等。
闲鱼团队是Flutter+Dart FaaS前后端一体化新技术的行业领军者,就是现在! 客户端/服务端java/架构/前端/质量工程师 面向 社会 招聘,base杭州阿里巴巴西溪园区,一起做有创想空间的社区产品、做深度顶级的开源项目,一起拓展技术边界成就极致!
*投喂简历给小闲鱼→ guicai.gxy@alibaba-inc .com
开源项目、峰会直击、关键洞察、深度解读
请认准 闲鱼技术
For serverless applications的中文翻译是适用于无服务器应用程序
重点词汇:for
词语分析:
音标:英 [fə(r)] 美 [fərfɔːr]
prep. (表示对象、用途等)给,对;为了;关于;代表;受雇于;意思是;支持;因为;为得到;换取;就……而言;……后(更好、更快乐等);(表示去向)往;(安排或预定)在……时;对(某人)来说(困难、必需、愉快等);以……为价格;(表示一段时间)计;表示一系列事件之一
conj. 因为,由于
abbr. 外国(foreign);林业(forestry)
短语:
abandon for 为...而放弃
vouch for 担保;保证
例句:
They are neighbours, for better or for worse.
好歹他们是邻居。
I have a reservation for a table for three.
我订三个人的桌位。
We left a tip for the waiter.
我们留给服务生小费。
近义词:
conj. 因为 because,since,seeing,that
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)