Serverless 笔记
Serverless 笔记
什么是Serverless
Serverless 能解决什么问题？
理清 Serverless 要解决的问题其实很简单，我们可以从字面上把它拆开来看。Server 这里指服务端，它是 Serverless 解决问题的边界；而 less 我们可以理解为较少关心，它是 Serverless 解决问题的目的。组合在一起就是“较少关心服务端”。怎么理解这句话呢？我们依然是拆开来分析。
我们可以先看 Serverfull 的概念，对比 Serverfull 和 Serverless 之间的差别，相信这样可以加深你的理解。Serverfull 就是服务端运维全由我们自己负责，Serverless 则是服务端运维较少由我们自己负责，大多数的运维工作交给自动化工具负责。
时代划分：
史前时代，Serverfull：
这个时代研发和运维隔离，服务端运维都交给小服一个人，纯人力处理，也就是 Serverfull。
农耕时代，DevOps:
这个时代就是研发兼运维 DevOps，小程兼任了小服的部分工作，小服将部分服务端运维的工作工具化了，自己可以去做更加专业的事情。
工业时代
这时，小服发现资源优化和扩缩容方案也可以利用性能监控 + 流量估算解决。小服又基于小程的开发流程，OpsConsole 系统再进一步，帮小程做了一套代码自动化发布的流水线：代码扫描 - 测试 - 灰度验证 - 上线。现在的小程连 OpsConsole 都不用登陆操作，只要将最新的代码合并到 Git 仓库指定的 develop 分支，剩下的就都由流水线自动化处理发布上线了。这个时代研发不需要运维了，免运维 NoOps。
未来：
实现了免运维 NoOps，免运维 NoOps 并不是说服务端运维就不存在了，而是通过全知全能的服务，覆盖研发部署需要的所有需求，让研发同学小程对它的感知越来越少。另外，NoOps 是理想状态，因为我们只能无限逼近 NoOps，所以这个单词是 less，不可能是 ServerLeast 或者 ServerZero。
Server 限定了 Serverless 解决问题的边界，即服务端运维；less 说明了 Serverless 解决问题的目的，即免运维 NoOps。所以我们重新组合一下这个词的话，Serverless 就应该叫做服务端免运维。这也就是 Serverless 要解决的问题。
到底什么是 Serverless?
第一种：狭义 Serverless（最常见）= Serverless computing 架构 = FaaS 架构 = Trigger（事件驱动）+ FaaS（函数即服务）+ BaaS（后端即服务，持久化或第三方服务）= FaaS + BaaS
第二种：广义 Serverless = 服务端免运维 = 具备 Serverless 特性的云服务
FaaS
先说 FaaS，函数即服务，它还有个名字叫作 Serverless Computing，它可以让我们随时随地创建、使用、销毁一个函数。
FaaS 的 Runtime 是预先设置好的，Runtime 里面加载的函数和资源都是云服务商提供的，我们可以使用却无法控制。你可以理解为 FaaS 的 Runtime 是临时的，函数调用完后，这个临时 Runtime 和函数一起销毁。
FaaS 的函数调用完后，云服务商会销毁实例，回收资源，所以 FaaS 推荐无状态的函数。如果你是一位前端工程师的话，可能很好理解，就是函数不可改变 Immutable。简单解释一下，就是说一个函数只要参数固定，返回的结果也必须是固定的。
用我们上面的 MVC 架构的 Web 应用举例，View 层是客户端展现的内容，通常并不需要函数算力；Control 层，就是函数的典型使用场景。MVC 架构里面，一个 HTTP 的数据请求，就会对应一个 Control 函数，我们完全可以用 FaaS 函数来代替 Control 函数。在 HTTP 的数据请求量大的时候，FaaS 函数会自动扩容多实例同时运行；在 HTTP 的数据请求量小时，又会自动缩容；当没有 HTTP 数据请求时，还会缩容到 0 实例，节省开支。
此刻或许你会有点疑惑，Runtime 不可控，FaaS 函数无状态，函数的实例又不停地扩容缩容，那我需要持久化存储一些数据怎么办，MVC 里面的 Model 层怎么解决？
BaaS
BaaS 其实是一个集合，是指具备高可用性和弹性，而且免运维的后端服务。说简单点，就是专门支撑 FaaS 的服务。FaaS 就像高铁的车头，如果我们的后端服务还是老旧的绿皮火车车厢，那肯定是要散架的，而 BaaS 就是专门为 FaaS 准备的高铁车厢。
MVC 架构中的 Model 层，就需要我们用 BaaS 来解决。Model 层我们以 MySQL 为例，后端服务最好是将 FaaS 操作的数据库的命令，封装成 HTTP 的 OpenAPI，提供给 FaaS 调用，自己控制这个 API 的请求频率以及限流降级。这个后端服务本身则可以通过连接池、MySQL 集群等方式去优化。各大云服务商自身也在改造自己的后端服务，BaaS 这个集合也在日渐壮大。
基于 Serverless 架构，我们完全可以把传统的 MVC 架构转换为 BaaS+View+FaaS 的组合，重构或实现。
第一种：狭义 Serverless（最常见）= Serverless computing 架构 = FaaS 架构 = Trigger（事件驱动）+ FaaS（函数即服务）+ BaaS（后端即服务，持久化或第三方服务）= FaaS + BaaS
而广义 Serverless，其实就是指服务端免运维，也是未来的主要趋势。总结来说的话就是，我们日常谈 Serverless 的时候，基本都是指狭义的 Serverless，但当我们提到某个服务 Serverless 化的时候，往往都是指广义的 Serverless。我们后面的课程中也是如此。
为什么阿里要举集团之力趟坑Serverless？
而 Serverless 既可以满足资源最大化利用的需求，也能够调优行业内的开发岗位分层结构，让每个开发岗位都能够在最适合自己的地方发挥最大的价值。杜欢表示，阿里正是因为看到了经济体内存在的上述问题，在尝试寻找相应解决方案的过程中发现 Serverless 可能是一个好的解决方案，才开始研究 Serverless，研究后认为确实可行，才启动了“阿里巴巴经济体前端 Serverless 研发升级项目”这样一个项目，拉上大家一起来共建。
Serverless，Serverless 应该被广泛地运用在不同的场景和实际开发需求中。从云厂商的角度来看，云计算未来一定会成为整个社会和商业的基础设施，届时使用云计算就应该像现在我们使用水电煤一样简单，不需要了解水从哪里来、怎么过滤、怎么铺设管道等一系列问题，只需要打开水龙头接一杯水而已。
而 Serverless 的概念正好可以帮助云计算朝这个方向往前走一步，**它提倡的是人们不需要关心应用逻辑以外的服务相关的事情，包括管理、配置、运维等，用多少就付多少。**从这个角度来看，Serverless 是真正让云计算变成社会商业基础设施的一个实现路径，也更接近现在业内提倡的云原生的方式，因此人们在使用云计算的过程中自然就应该按照 Serverless 的方式来使用。
前端开发者看好、后端开发者观望，Serverless 为何如此？
前端工程师除了要保持在 UI、交互逻辑方面的优势，还要理解整个业务和业务背后的意图，这意味着未来前端行业的思考模式会变成面向业务的思考模式。与此同时，前端的协同和开发模式、上下游流程也会发生变化，原来前端可能很少跟产品经理、设计打交道，未来前端要对整个应用负责，就需要天天跟产品经理、设计打交道。后端则要在最底层提供更深的能力付出，比如如何按照一亿流量的支出支撑十亿流量，这是更大的挑战。
目前 Serverless 最佳实践模式尚未出现
“2020 年 Serverless 会进入初步实践阶段，还不能称之为大规模实践，可能到 2021 年才会进入大规模实践阶段。在这个过程当中，云厂商会进一步补充更多的 Serverless 服务，包括一些后端的 BaaS 服务，把基础打得更牢一点。”