转角遇到你-Serverless

Serverless 最近几年可谓是一个很是火热的话题，尤为在今年（2019），几乎人人都听过 Serverless。

全部人都在说 Serverless，几乎没人知道怎么落地 Serverless，可是你们都以为其余人都在作 Serverless，因而你们都在声称本身在作 Serverless。

这句话仍是我当时在蚂蚁的时候听到的，已经忘了是谁说的了，抱歉不能引用做者。

既然这么火，那么什么是 Serverless 呢？为何要使用 Serverless？咱们该如何开始学习它？它是否是下一个技术的风口？这一系列的问题一直在困扰着我，想必你们也曾经想过。因而本身尝试着去研究它，也尝试着去帮助你们解惑。

什么是 Serverless

在 web 应用开发早期时代，想要构建 web 应用程序就须要有人去购买服务器硬件，而后在服务器上处理运维部署的事宜，这是一项很是繁琐而昂贵的事情。再后来，云出现了在咱们的视野中。能够经过云厂商购买固定的服务器资源，而后利用这些资源完成运维部署工做。可是通常状况下，客户们会为了处理流程或业务高峰问题而超额购买一些服务器资源，虽然如今的云产商提供了自动伸缩能力，可是这些服务器资源的利用率并不高，客户依然在为未使用的资源付费。

无服务器计算（Serverless ）是一种新型的软件架构。它的命名很奇怪，容易让人产生误解。Serverless 并非没有服务器，只是服务器通常由云服务器提供商来管理，开发人员无需关心。Serverless 可以提供用户编写和部署代码，提供监控、定时、弹性伸缩等服务。Serverless 让开发人员无需关心软件的部署、运维细节以及底层基础架构。开发人员只需专一于业务自己，将精力集中在为用户带来价值的事情上。Serverless 客户真正的按需付费，对于未使用的资源客户不须要付一分钱还能保证服务正常运行。

在提到 Serverless 时，有几点须要咱们去了解：

微服务（Microservices）

上面也说起到在过去咱们的研发模式比较单一，软件架构也比较传统简单。通常一个项目的软件架构由前端、服务端和数据库组成。而随着应用的复杂度上升，过去的应用架构已经开始制约着应用的发展，下图简单的描述了应用架构的演进。

微服务是一种软件设计架构，微服务从设计上来说倾向于单一职责，每每将一个大型应用按照业务领域、职责划分等拆分红多个子服务。就像积木同样，为了搭建成一个完整的建筑，须要众多的积木来组合成复杂而庞大的建筑。

微服务的优点：

• **弹性：**因为应用程序已分割，所以应用程序的一部分损坏或崩溃并不必定会影响其他的应用程序
• **选择性可伸缩性：**无需扩展整个应用程序，只能扩展得到大量使用的微服务
• **易于添加或更新功能：**能够一次推出或更新一个功能，而没必要更新整个应用程序堆栈
• **开发人员的灵活性：**微服务能够用不一样的语言编写，而且每种都有本身的库

为何须要在 Serverless 中说起微服务。虽然微服务有多种部署方式，可是将微服务部署在 Serverless 中才能将优点体现的很明显，微服务仅在应用程序须要它们时才运行，而且自然支持弹性伸缩。咱们还能够根据微服务的大小，分解成为更小的函数（FaaS）。

函数即服务（FaaS）

在 Serverless 架构里，FaaS 是一项很重要的技术。它改变了传统架构的服务模式，Faas 的粒度变为了函数级别，一个函数即一个服务。可是函数一般是运行在无状态容器中，这意味着没法保持状态，没法在函数中使用以前的执行上下文，并且函数的执行时间是有限制的，像 AWS Lambda 函数能够配置为每次执行最长运行 15 分钟，因此这也是 FaaS 的限制所在，也就意味着不能执行耗时的任务。 Faas 的执行时机是基于事件触发的，至于事件的种类依赖于云厂商，HTTP 触发器是最多见也是使用最多的一种。FaaS 的运行时如今各大云厂商提供的也挺多，例如 Node.js、Python、Go、Java 等等。

例如咱们实现一个 helloworld 函数，你只须要在 Serverless 平台中上传这份代码片断，就能够经过触发器来完成执行。执行完毕后直接输出 hello world!，真的是太方便了。

module.exports = {
  foo: function (event, context) {
    return 'hello world!';
  }
}

复制代码

上述代码可经过该连接访问。

后端即服务（BaaS）

BaaS 做为在 Serverless 架构里另一项重要的技术，旨在提供业务依赖的服务，例如数据库、消息通知等服务。这些 BaaS 服务通常由云厂商提供，像被谷歌收购的的数据库服务 FireBase 以及身份验证 Auth0。配合 FaaS，能够轻松完成业务开发。BaaS 提供基础服务，FaaS 负责业务逻辑组合，组织 BaaS 基础服务，相互协做，相互配合，真正的让开发人员只关心本身的业务。

例如咱们想要实现个文件上传服务，在过去，咱们须要创建数据库、配置存储空间、编写服务端代码等等，复杂状况还须要考虑分布式存储、并发等等状况。在 Serverless 中，咱们只须要写一个 FaaS 来完成文件上传这个事件，而后文件存储调用 BaaS 对象云存储服务 SDK ，再配合数据库存储 BaaS 服务 SDK，完成这样常见的文件上传服务。结合这个流程来看其实真正咱们作的工做就是编写 FaaS，大大减轻了开发的负担，缩短了研发周期。并且还不用考虑存储并发等等问题，由于 Serverless 帮助咱们作了这些。

正常状况下 BaaS 提供商可以提供如下功能，例如：

• 数据库管理
• 云存储
• 用户认证
• 推送通知
• 远程更新

冷启动（Cold Start）

因为函数是运行在容器中的，所以启动容器须要必定的时间，这也被称为冷启动。通常当你的函数执行完毕，容器通常会保留一段时间（AWS Lambda 为 5 分钟），若是在这段时间内没有新的事件请求过来，这个容器将被销毁掉。

冷启动的持续时间取决于特定云服务商的实现。在 AWS Lambda 上，它的范围从几百毫秒到几秒不等。它可能取决于使用的运行时（或编程语言）、函数（以包的形式）的大小，固然，还取决于所讨论的云服务商。多年以来，随着云服务商在优化时延方面变得愈来愈出色，冷启动已经大为改善。

热启动（Warm Start）

上面提到了冷启动，那么就有对应的热启动，热启动在 Serverless 中指的是函数容器冷启动后在限制的时间内

依然保持启动状态不被销毁，来了新的事件请求后可以立马提供服务。一般咱们能够利用一些小技巧，例如经过定时器每隔几分钟来触发一个事件，使得咱们对应的函数可以继续被执行，可以保持运行状态。

API 网关（API Gateway）

API Gateway 在微服务领域是个必备的技术。它可以处理全部来自客户端的请求，而后根据网关配置，转换和转发请求到合适的微服务。在 Serverless 架构里面，因为都是 FaaS，不能直接对外服务。前面说到 FaaS 是基于事件机制，事件有不少触发器，最多见的就是 HTTP 触发器。那么这么多的 FaaS 服务若是想要以 HTTP 对外服务，那么就须要网关的配合了。就像在微服务领域同样，网关负责将各种 FaaS 服务的触发器捆绑，继而向外暴露安全服务。

为何要用 Serverless

到目前为止，我尝试着解释了下 Serverless 架构的一些知识点。如今，咱们未来从 Serverless 的优缺点来一块儿探讨下咱们为何要用 Serverless。

与传统的基于云或以服务器为中心的基础架构相比，Serverless 具备不少优点。对于开发人员而言，Serverless 提供了更大的灵活性以及更快的发布时间。借助 Serverless，开发人员无需担忧购买，供应和管理后端服务器。可是，无服务器计算并非全部 Web 应用程序开发人员的灵丹妙药。对于企业而言，Serverless 这种按需收费模式将为企业节省很大一笔的资金，尤为对于创业型企业来说，能够将资金放到最关键的创造用户价值的事情上去。

优势

下降运维成本

在当前的开发模式下，运维人员须要处理各类繁琐的事情，例如数据库维护、服务器管理等等。在 Serverless 架构下，虽然程序仍是跑在服务器上，但运维人员是无需去管理这些服务的，这些事情将交给云产商管理。这能够减小在运维中的资金投入，从而下降支出，还可使开发人员腾出时间来建立和扩展其应用程序而不受服务器容量的限制。

使用 Serverless 架构，减少了部署发布的难度、缩短了部署的时间。 运维人员无需发布代码到服务器进行配置便可发布新版本，转而向云产商上传代码片断，这是一种思惟上的转变。

下降开发成本

开发系统一般最麻烦的事情是配置开发环境，而在 Serverless 架构中，你只须要一个能够文本编辑器或者只须要一个浏览器。最方便快捷的是使用云厂商提供的云端编辑器，你只须要在编辑器中编写函数便可。编辑完成后通常 Serverless 云厂商提供了部署相关的按钮，点击它便可完成函数的部署。在将来的云端 IDE 编程时代，这也将是一个极大的吸引点。

由于是 FaaS，运行时和开发语言也没什么限制，团队在招人技术栈方面也不须要花费更多的精力，能够直接面向业务，也无需关心复杂的系统架构，这样给与了前端开发人员更多的领域涉及的可能。

在系统的更新迭代上，开发人员能够根据更新的内容选择更新部分函数，更新完成后只须要部署这个更新的函数而不须要从新部署整个系统，没必要对整个系统进行更改。

结合 BaaS 服务后，开发一个应用程序将会变得更为简单高效，那些通用的能力交给第三方去管理，缩短的开发时间周期放到更为紧要的事情上去，尤为在创业型互联网企业中来说，时间就是金钱，更快的上线对他们来说是相当重要的。

下降拓展成本

Serverless 架构的另外一优势就是水平拓展是彻底自动的、弹性的而且这种行为是由云厂商提供的。这个特性很直接的好处是咱们真的是按需付费。

举个例子，假设咱们有一个应用程序每分钟有 1 个请求，若是咱们有 10 台机器作为集群，每台机器处理每一个请求的平均 CPU 利用率为 1%。那么站在机器利用率的角度来说，一万个相似的应用程序能够跑在这 10 台机器中，可是如今很明显的是利用率极低。这是一种假想的情形，实际上你可能考虑会下架掉其余机器，以保证经济成本。

可是咱们来换一种场景，咱们的运营们上线了一个营销活动，这个活动持续的时间是 1 天，带来的结果是如今每分钟有 100 请求，如今的压力是之前的 100 倍。在传统情形中，处于提早应对峰值的考虑，咱们须要提早将硬件总数提高到当前的 100 倍，假设为 1000 台，而后就是须要部署下这 1000 台机器作为集群。这其中的工做量以及成本都是很是之大。当活动结束后，这些剩余的计算能力将是一笔巨大的浪费，还须要处理下架的机器。

固然如今的云厂商也提供了自动缩放的能力，可是也有着它的缺陷，就是这些自动缩放的机器可能须要很长的时间来启动和注册，可能会错太高峰时间。

可是在 Serverless 架构中，因为 Serverless 具备天生的水平拓展能力，这将再也不是一个问题。从上面的示例来看，很明显有一个特色，就是流量的不稳定，存在流量的波峰和波谷。在波峰时，Serverless FaaS 会自动拓展，帮助应用度太高峰期流量。波谷时，在 FaaS 中咱们提到，FaaS 容器会必定时间内若是没有请求过来，将会释放掉该容器，以保证资源不被浪费。基于此，Serverless 能够帮助咱们节省一笔资金，还能平稳度过流量高峰。

若是你的应用流量一直很平稳，可以充分利用硬件资源，那可能 Serverless 不是你很好的选择，因此须要你很好的进行评判与计算，选择最适合本身业务的解决方案。

缺点

云厂商锁定

在应用初期，你极可能是选择一个特定的云厂商来做为 Serverless 提供商。初期的架构设计都依赖于特定的云厂商，因为各大云厂商的设计方案不一致，若是要更换云厂商，也就意味着须要修改代码以适应云厂商之间的差别。这将又会是一个成本的问题。

即便在软件设计前期考虑了多个云厂商，可是一旦受到某个厂商的变动的影响，仍是会存在迁移的成本，如此一来，很大可能就会被云厂商锁死。

在将来，随着 Serverless 的发展，各大云厂商一定会根据规范来让客户能够平滑迁移，达成一致的使用体验。

安全性

在使用 Serverless 也会带来一些安全问题，知道这些潜在的安全问题也会让咱们更好的去使用 Serverless 从而能够避开一些风险。

将源码部署到云厂商服务器而不是公司的私有服务器这自己就会有安全隐患，固然这不是 Serverless 独有的问题。因此在云厂商选型时，咱们应当选择可靠的云厂商，例如阿里云、亚马逊等等。另一个问题是云厂商并不会给客户单独分配机器，而是以多租户的模式来运行。多租户模式可能会影响应用的性能，若是云厂商的多租户配置不合理可能会致使客户的数据泄露。

使用 Serverless 将会和传统的应用架构的安全性有所区别，一些安全的访问将直接迁移到云厂商提供的安全平台上，这可能也会形成一些潜在的风险，须要特别注意下。

Serverless 的适用场景

在谈论 Serverless 的适用场景以前，咱们仍是要回顾下 Serverless 的特性。在文章前面部分咱们有向你们介绍过 FaaS。前面有介绍到 FaaS 的执行时机是基于事件触发的而且函数的执行时间是有限制的，那么综合考虑这两点，咱们能够想象下当今哪些业务场景是此中类型的。

咱们很容易就想到 IoT、消息通知、定时任务、图像处理等等。很明显针对须要长时间通讯的场景 Serverless 并不适用。

前面咱们有讲到 HTTP 触发器是 FaaS 事件触发最多见的一种，那么和 HTTP 相关的又符合上面两点的业务那是最合适不过了，例如 RESTful API、SSR 服务和 BFF。

另外最值得一提的一种业务场景就是小程序。虽然叫小程序，可是一个稳定的小程序对于后端的整个架构而言几乎是五脏俱全。本身去搭建这样一套架构不是一件轻松的事情，而 Serverless 就能够帮助咱们解决这些棘手的问题，提供 FaaS、云存储等等服务，可以快速帮助小程序上线。并且不担忧前期服务器费用，按量付费模式，减轻开发门槛，下降开发成本，就能够更专一于产品打造。我相信有了 Serverless 的辅助，将来会有更多更好用的小程序会上架。其实相似小程序场景均可以借助于 Serverless 快速上线产品、快速变现。在今年，阿里云和腾讯云都相继推出了小程序 Serverless，这也能够看出各厂商对于 Serverless 的重视，其中腾讯云今年还与 serverless.com 达成战略合做成为大中华区独家合做伙伴。

开源 Serverless 产品

kubeless

kubeless 是基于 k8s 原生的无服务器框架，可以让您部署少许代码而没必要担忧基础架构的问题。

fission

fission 是基于 k8s 的快速无服务器框架，专一于开发人员的生产力和高性能。

OpenWhisk

OpenWhisk 是一种云优先的基于事件的分布式编程服务。它提供了一种编程模型，可将事件处理程序上传到云服务，并注册处理程序以响应各类事件。

案例

notes.devops.godotdotdot.com