缘何是Serverless架构？

原创

mob604756fbb3bd 2021-05-20 21:28:52 ©著作权

©著作权归作者所有：来自51CTO博客作者mob604756fbb3bd的原创作品，请联系作者获取转载授权，否则将追究法律责任

李桦译分布式实验室

缘何是Serverless架构？_Jav

几个月前在Tavisca解决方案中，我们开始研发了Beats并且作为产品研发到了一定的阶段，该阶段就是当我们需要一个快速迭代产品时，该产品可以快速发展到我们平时很少需要面对的MVP（最小化可行性产品）阶段。我们每次研发新产品，都有机会选择当时最前沿并且最适合的技术。

本文将讨论我们面对的问题，以及最终我们是怎样为我们的产品选择Serverless架构（耶，这并不是个神秘的博客）。读者阅读本文之前，最好能对微服务有一些了解，如果在该领域不太涉及的话，建议先阅读笔者的另一个文章（https://cloudncode.blog/2016/07/22/msa-getting-started/）。

Serverless到底是什么？

缘何是Serverless架构？_Jav_02

以我的经验，人们第一次听到”serverless”一般都有两个反应：

嗯……代码在哪儿运行呢？
我很想揍捏造serverless概念的人，根本就没有这种东西，它只会让其他人感到困惑；
我喜欢我的服务器，它让我能控制服务；
所以……代码在哪儿运行呢？

请允许用我自己的语言定义serverless，当然是好的声明：

“Serverless架构是完全基于第三方服务设计的，代码运行在临时的容器中，使用FaaS同时调用BaaS达到数据存储的目的。”

一个同事说以上的声明和Martin Fowlers的定义极其类似，但是我向你们保证我同事给我看相关资料之前我从未读过。

函数即服务（FaaS）

FaaS是公有云模型中的创新产品，从经济方面的衡量，使得供应商提供一个简单明了的平台变得可行，用户的代码运行在容器中（例如Docker），这些容器则按照响应的事件构建，例如到API网关的http调用，或者数据流中的一个数据包，诸如此类云供应商可以支持的任何内容。

Azure提供了Azure Function，Google提供了Cloud Functions，而我最青睐的FaaS是AWS Lambda。前面两者都遵循了相同的定律，不创建或者维护服务器。

后端即服务（BaaS）

不像FaaS，BaaS早些时候在app开发者中变得非常流行，他们在因特网上寻找一种后台服务可以提供类似数据存储（duh）、事件驱动通知以及一些随着app增长可以横向扩展的东西，这方面BaaS提供的比FaaS更成熟，并且有越来越多的人认识到了这些。这个环节AWS主要是通过Dynamo DB提供服务，对应Azure的Cosmos DB以及Google的Cloud Datastore。

接下来把我们之前讨论的内容图形化吧：缘何是Serverless架构？_Jav_03

浏览器调用API网关，该网关用容器执行你的代码，然后和DB（BaaS）交互获取到数据，是不是看上去很熟悉？上层的工作流还是一样，在函数方面有着不同的键值，容器的创建和销毁基于FaaS提供商所使用的算法，用户无法控制。笔者写过一篇关于AWS Lambda如何在后台工作以及最佳实践的文章，建议读者阅读。

那么还有服务器吗？

是的，无论何时听到Serverless，就像你的常识告诉你的，实际上还是有服务器存在的。Serverless在我看来，是创造出来实现你不需要创造、维护甚至拥有服务器的存在，在Serverless的世界里，服务器根据你的需求、使用率创建，它可以在后台变化，而用户对此毫无察觉。

以上说明听起来很可怕，我同意，但是如果你以前使用过高质量的第三方服务，特别是像类似Amazon（AWS）、Mircosoft（Azure）或者Google，，你就会知道你可以相信他们至少比使用你自己服务器承诺的运行时间要长得多。

缘何是Serverless架构？_Jav_04

那Serverless是我们遇到所有问题的答案吗？当然不是，为了选择最好的技术，我们首先必须理解我们将要使用该项技术的产品，否则我们将会陷入永远选择下一个酷技术的陷阱，而不管这个技术对实际的生意是否公正，该技术是否适用。

要理解为何采用Serverless，我们就必须在可预见的未来了解产品的需求，还有什么是Serverless以及理解它的本质。

Beats产品的原则是什么？

Beats作为一个SaaS，意味着被DMC（目的地管理公司）代理或者更多简单化的旅行代理使用，这些代理对于旅行行业的术语并是不非常的熟悉。这儿有Beats需要的蓝图：

根据Marty Cagan书里提到的“inspired”产品开发方式开发软件，该方法浅显地谈到了产品研发周期，软件基于产品自身的发展周期高度迭代（包括市场/客户在内的反馈）。
市场调查目前把每个用户license的价格定在999/-INR（~15.6美元），意味着运营每个用户产品的花费会很低。
产品研发周期需要表现出引人注意地、可持续地增长，增长的速度比常规的速度更快，直到最后找到市场立足点。
该软件的本质就是发掘出用户近期的多重经验，例如为代理在网络异常时完成节假日目的地工作的离线app。
我们背后并没有10亿美元的投资人。

产品经理的工作和工程师团队的并不一样？

延缓产品研发进程的因素，主要有以下几点：

人工维护服务器或者编写Chef/Puppet脚本；
编写云自动化脚本或者手工操作（想到就哆嗦）；
可量化目的的重构（处理更多的用户）；
非功能性的bug修复。

SaaS服务中技术分支需要的成本

员工薪水，高级技术职员例如研发、DevOps、QA自动化工程师以及leader；
框架成本 – 该成本用于环境中运行服务器/服务、数据库以及它们所需要的license（Dev-QA-Stage-Prod等等）;
第三方license，举个例子，GitHub私有repo的license，My Get.org（包管理）的license，开发IDE工具例如Visual Studio的license；
研发工作机器；

Serverless架构的性质是什么？

我们不拥有或者控制安全限制之外的成本，例如服务器、虚机或者容器等等；
大部分运行我们代码的FaaS服务都驻留运行在短生命周期的容器中，每个请求对应一个容器，这样可以在服务中规避并发的问题；
基于以上两点，编码需要按照可在大量容器中水平伸缩的原则进行，而不是像运行在大型机器上一样垂直堆砌；
不像在AWS EC2提供的永久或者自动调整虚机中大部分时间可以做的那样，你不能依赖状态保存在内存中的应用；
基于架构分配按照收入需要的原则，FaaS和BaaS一般都按照每个使用的原则付费，如果没有调用，FaaS免费的运行着，BaaS则需要一直付费，因为数据一直都被维护着并且为服务分配着流量；
如果你使用Serverless框架，当然这是笔者强烈推荐的，开发者可以通过在微服务中编码实现对架构的控制；
一般情况下你不需要去选择CPU，在AWS Lambda里是已经分配好的，关于RAM则需要你自己选择。Serverless功能对于繁重的计算需求并不意味着快速，从而关闭一台独立服务器，你可以实现更复杂的设计从而把这类功能伸展成几千个并发运行从而获取更好的结果；
并不是说对于FaaS服务来说分配应答你的请求框架的时间是微不足道的，特别是针对突发流量的场景。以我的经验，AWS Lambda大概需要5~80ms的时间完成动作，时间长短取决于代码量的大小；
你无须考虑并发或者多线程的场景，因为你的框架在任一指定时间点都运行在每请求一容器的模式。