serverless浅谈介绍

By vadxq

Github

目录

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

背景现状

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

腾讯推出了 Serverless 2.0

阿里云推出的预留模式

Serverless(无服务器)是什么

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 !