Life Will Change Lyn
  1. 1 Life Will Change Lyn
  2. 2 Flower Of Life 发热巫女
  3. 3 Time Bomb Veela
  4. 4 かかってこいよ NakamuraEmi
  5. 5 Last Surprise Lyn
  6. 6 Libertus Chen-U
  7. 7 Hypocrite Nush
  8. 8 Warcry mpi
  9. 9 One Last You Jen Bird
  10. 10 BREAK IN TO BREAK OUT Lyn
2019-08-10 17:47:35

从BFF到SFF

最近Serverless这个概念异常火热,感觉是哪家公司都在搞,但具体怎么搞怎么落地的,大多也属于探索阶段。概念很美好,但其中可见的坑也不少。跟风不可取,场景合适的才是最好的,所以要想用好Serverless,必须先了解下相关生态和现状,这篇文章就记录下我粗浅的理解。

架构的演进

新技术的出现从来都不是无中生有的,必然是在基础技术的发展下,自然产生的一种高效解决某个问题的方案。在具体谈到Serverless的使用之前,有必要先了解,是如何走到这一步的。

前后端分离

前端这个职业真正的兴起应该从这个时间节点开始谈——Web2.0。伴随着Ajax技术的出现,以jQuery为起点,到三大框架的稳定期,业务开发的模式由原来的前后端耦合的后端模板渲染转化为后端仅提供接口,前端通过接口获取数据并在前端接管模板渲染。与此同时,伴随着Node的出现,基于Node的命令行工具,构建工具,包管理机制等等相继出现,代表着前端工程化的发展。

BFF

与此同时,后端也在发展,架构由巨石模式转化为微服务。此时就有了新的问题,微服务带来的后端接口原子性,导致接口不再适配于UI,同时不同设备对接口也有不同的需求,需要对接口进行进一步的聚合和裁剪。这一层谁来做?要知道的是Node的出现不仅带来了前端工程化,同时也给予了前端写服务端代码的能力。于是BFF(Backend For FrontEnd)的架构自然就产生了。在后端和前端间,由前端加一层BFF对接口进一步处理再输出到前端,同时带来的能力还有在BFF同构直出的服务端渲染。

Serverless

BFF看起来很美好,但问题依然是有的,最主要的问题就是成本问题。

  • 人才成本:前端不再是单纯的前端,不仅要掌握常规的前端技术,还要进一步学习后端和DevOps才能适应BFF架构,这样的人现在不仅难招也不便宜。
  • 服务器成本:BFF架构下计算压力被分摊到了更多的服务器上,由此带来的服务器利用率不足造成服务器资源浪费。

随着云计算的发展,这些问题有了可以期待的解决方案,就是Serverless了。一句话概括核心思想的话,就是让业务开发只需要专注于业务本身,将服务器,运维,后端服务等都托管给云平台,声明好业务相关的函数就可以完成应用的接入。

定义与使用

先看AWS的定义。

通过 AWS Lambda,无需预置或管理服务器即可运行代码。您只需按使用的计算时间付费 – 代码未运行时不产生费用。 借助 Lambda,您几乎可以为任何类型的应用程序或后端服务运行代码,而且完全无需管理。只需上传您的代码,Lambda 会处理运行和扩展高可用性代码所需的一切工作。您可以将您的代码设置为自动从其他 AWS 产品触发,或者直接从任何 Web 或移动应用程序调用。

从中可以提取出一些核心特性:

  • 开发者只需要专注于业务本身,不需要关心运维与其他服务
  • 按需调用,只需要为函数运行付费,节省服务器资源
  • 依赖于云平台

再精简一些的话就是FaaS和BaaS的结合。通过FaaS将我们的业务函数注册到云平台,云平台再为FaaS使用BaaS(对象存储,云数据库,网关等),和业务无关的通用技术细节都由云平台为我们隔离开。我认为这就是Serverless的核心思想了——隔离。从虚拟机,到Docker,再到Serverless,解决的问题虽然不同,但思想可以类比理解。

以一个博客系统的的文章发表为例子,POST请求先来到网关,这里会处理授权和监控等服务,付费计数加1,再到函数计算服务,这里由我们注册进业务相关函数生成文章相关数据,付费计数加1,文章数据需要被存储,那么可以继续使用云数据库服务,付费计数加1。当然,如果这个博客需要静态部署的话,也可以使用云存储服务。这样这个博客的文章发表功能就完成了,整个流程实际上需要我们编写代码的地方只有函数计算中使用到的我们的业务相关函数,其他的全由云平台托管。

SFF

之前谈到的BFF相关缺点,实际上在整合了Serverless后就能得到很好的解决,基于Serverless的BFF就可以称为SFF(Serverless For FrontEnd)。具体做法为,将原先实现在BFF层的接口处理逻辑转移到FaaS中,将前端向BFF发起的请求设置为云平台FaaS服务的触发器即可。

缺陷

当然Serverless并不是没有缺点,目前最大的一个问题就是,相比于常规服务启动后就常驻内存,Serverless是事件驱动的。当事件触发时,云平台需要启动一个容器并在容器中启动执行环境,再运行代码。这些过程称为冷启动。很明显冷启动耗时带来的性能问题是一个不能忽视的问题,目前也并没有一个特别好的解决方案,比较靠谱的有冷启动之后复用之前的运行环境,本地缓存镜像等手段,以及给函数预热,但都没有从根本上解决问题,还是比正常微服务会慢上一些。

另外一个问题就是本地调试相对困难,毕竟与函数相关的服务都在云端,虽然目前有一些cli处理这个问题,但也都不能算完美。

总之如果考虑上SFF的话,以上两个问题是必须要先思考并调研的。

小结

目前对于Serverless还处于探索阶段,但在可预见的未来还是有落地的机会的并且也是大趋势。现在能做的除了紧跟风向之外,还是要抓紧把Node熟练起来,毕竟市面上可见的 Serverless服务Node是绝对的烫手山芋,完美避免了Node作为后端语言的缺陷,总之我接下来一年的计划就是专攻Node了。。

-- EOF --

添加在分类「 前端开发 」下,并被添加 「Node.js」「工程化」 标签。