serverless浅谈介绍

By vadxq

Github

目录


  • 背景现状
  • Serverless(无服务器)架构是什么
  • Serverless的两种形式
  • Serverless与前端
  • Serverless的优缺点
  • Serverless最佳实践(腾讯云的serverless程序流程展示)

背景现状


自6月GMTC以来,国内腾讯和阿里云都铆足了劲在上面发力,提出了各自的解决方案,Serverless 越来越受重视

腾讯推出了 Serverless 2.0

阿里云推出的预留模式

Serverless的两种形式


MBaaS(Mobile Backend as a Service),简称 BaaS

可以理解为 BaaS 就是有第三方提供的包含某一块功能的微服务,使用者以 API 形式接入。

FaaS(Function as a Service)

FaaS 是一种面向函数的构建和部署软件的方式,最先由亚马逊提出,其标志性产品就是 AWS Lambda

Serverless 应用组成

graph TD
    B[Web Client]
    B-->C[API Gateway]
        C-->D(Function);
        C-->D(Function);
        C-->D(Function);
            D-->E(microService/database);
            D-->E(microService/database);
            D-->E(microService/database);

Serverless与前端

前端变革

graph TD
    B[前端0.0 WWW]
    B-->C[前端1.0 AJAX]
        C-->D(前端2.0 Node.js);
            D-->E(前端2.5 React/Vue等MVVM框架);
                E-->F(Serverless-从前端到全栈);
                E-->G(RN和Flutter为突破点的泛前端);

前端研发升级

  • 前端赋能

    打破现有的技术壁垒,朝着更底层,面向数据的地方去深入,探索 全面的视角来理解现有的体系

  • 前端提效

    让 Serverless,用更轻量化的方式进行业务研发,降低整个前端参与业务交付的门槛,同时,在开发期间,也能减少人力总成本,让前端减负,业务小步快跑成为可能

Serverless的优缺点

  • 减少资源开销

    单进程下函数的性能非常不错,但是由于大促要提前预留一些资源,整体机器成本只降低到了平时的 70%,而在非大促期间,不需要预留这些资源,就能更低,降到 40% 以下

  • 降低运维成本

    Serverless 最大的好处是减少运维,减少固定服务器资源,不需要用户关心调度等,同时也简化了开发的代码,专注了逻辑,晚上睡觉会更加的放心,不再担心机器容量不足而报警。

  • 减少治理成本

    对于应用治理来说,之前会考虑各种版本碎片化的问题,node 的多版本,框架的多版本,以及启动脚本、依赖等等问题,而用 Serverless 之后,将这些都固化了,用户也不关心这些,一切都变的简单了,我们也只需要治理运行时一个版本即可。

  • 降低研发成本

    在业务前端方面,带来的是挑战和机遇,一方面,前端的工作量增大了,能干的事情也变多了,成了一职多能的多面手,也更了解业务了,另一方面,传统的后端可以从和前端沟通中解放出来,更专注于提供服务。前端从传统的面向接口编程变成了面向服务编程,大大简化了调用链路

减轻流程负担

在流程方面,原来需要在各个环境准备和调研,从一开始申请应用,申请预算,申请环境开始,需要了解各个方面的知识,和不同部门的人打交道,流程审批也很长,而现在只需要在我们的统一研发平台上直接申请函数组,替代了原本的复杂流程,也提升了整个开发体验。

同时在编码中也不再考虑路由,MVC 的事情,这些在网关层配置就好,编写代码时会更关注逻辑,和之前的构建发布不同的是,现在增加了云端集成测试的步骤,由于函数和前端代码一样,是分版本的,也不担心修改到线上的正常服务,在测试完毕后,只需要将旧函数的 tag 指向新函数即可,这就完成了整个切流的过程,而一旦碰到问题,把 tag 切回去就行。

Serverless 不足之处


老应用的迁移成本巨大

需要k8s和knative等技术改造出serverless平台

目前无论是理论解读还是实践模式都尚未形成绝对统一

老应用的迁移


1、使用 FaaS + Baas 的方式进行重构,代码更精简,就是需要改造成本

2、把整个传统应用作为一个函数,虽然不够优雅,但是能解决迁移的问题

传统代码的结构分解


  • HTTP 服务,原框架(koa/midway/egg…),Node.js 运行时,启动脚本等,将会变为函数运行时,固化下来

  • 原有的 HTTP Router,Web 中间件等,将会由 HTTP 网关承接

  • 原有的 Controller,业务逻辑(调用远程服务),继续保留,变为函数代码

  • 原有的数据库,消息队列,RPC 调用等,都作为 BaaS 服务,用户只关心对应的服务,使用同一的 BaaS Client 进行调用

需要k8s和knative等技术改造出serverless平台?

上云


目前无论是理论解读还是实践模式都尚未形成绝对统一?

这个只能去摸索探讨了,但可以预见前端开发者将成为Serverless的最大受益群体之一

Serverless最佳实践(腾讯云的流程展示)

谢谢!

Thank you !