Serverless架构：用服务代替服务器

还记得在十多年前，SaaS鼻祖SalesForce喊出的口号『No Software』吗？SalesForce在这个口号声中开创了SaaS行业，并成为当今市值520亿美元的SaaS之王。今天谈谈『No Server』有关的事， 继OpenStack、Docker 、MiscroService、Unikernel、Kubernetes和Mesos之后，ServerLess正成为Google、AWS乃至创业公司暗战的新战场，它能否成为云计算领域的颠覆性趋势？

我相信大家也会存在一些疑问： Serverless到底是什么鬼？Serverless架构有啥优点，竟然让IT界巨头纷纷布局？业界有哪些已经成功的产品使用了Serverless架构？我们的项目是否适合使用Serverless架构？Martin Fowler在2016.6.17号发表了一篇博客： 《Serverless Architectures》，引起业界的关注，同时Serverless与我们目前研发的产品相关，也进行一些研究与实践。下面我将会从以下几点进行分享：

• Serverless的背景以及概念
• Serverless与传统架构比较
• Serverless架构适合那些业务场景以及竞品分析
• Serverless理解容易存在误区

一．Serverless的背景以及概念

1.1  Serverless的背景

当我们还在容器的浪潮中前行时，已经有一些革命先驱悄然布局另外一个云计算战场：Serverless。

2014年11月14日，亚马逊AWS发布了新产品Lambda。当时Lambda被描述为：一种计算服务，根据时间运行用户的代码，无需关心底层的计算资源。从某种意义上来说，Lambda姗姗来迟，它更像S3，更像云计算的PaaS理念：客户只管业务，无需担心存储和计算资源。而在此之前不久，2014年10月22日，谷歌今天收购了实时后端数据库创业公司Firebase。Firebase声称开发者只需引用一个API库文件就可以使用标准REST API的各种接口对数据进行读写操作，只需编写 HTML＋CSS＋JavaScrip前端代码，不需要服务器端代码（如需整合，也极其简单）。

相对于上两者，Facebook 在2014年二月收购的 Parse，则侧重于提供一个通用的后台服务。不过这些服务被称为Serverless或no sever。想到PaaS了是吗？很像，用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者们习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代里去了。

1.2  Serverless的概念

提到Serverless，大家都想到一张经典图描述传统的互联应用架构图与Serverless architactures的不同点，Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA，按照调用次数进行计费，有效的节省应用成本，如下所示

Serverless是最新兴起的架构模式，中文意思是“无服务器”架构。目前，业界并没有给出明确的定义，把其分成两种类型，分别为“Backend as a Service” 和 “Functions as a Service”。

“Backend as a Service”即BaaS，是一种新型的云服务，旨在为移动和Web应用提供后端云服务，实现对逻辑和状态进行管理，包括云端数据/文件存储（例如Parse、Firebase）、消息推送（例如极光推送、个推）、应用数据分析等等。可以说BaaS是诞生于移动互联网，为了加速移动应用开发和降低成本而形成的开发架构。BaaS可以带来后端能力的服务化，服务化也为后端能力优化管理带来了可能，这些能力通过服务开发者而诞生，重复的建设和规划会在初期就得到避免。

开发者通过使用这些服务，实现自己的业务功能的同时，也会对服务的能力进一步提出要求，促进后端服务的发展。BaaS是在PaaS和SaaS之间，为了满足移动互联网快速发展的需要，将后端的能力以服务形式提供，是在PaaS平台开发能力的基础上，用SaaS的思路，将后端能力服务化，让开发者在此基础上开发自己的Software解决方案。

“Functions as a Service”即FaaS，指这样的应用，一部分服务逻辑由应用实现，但是跟传统架构不同在于，他们运行于无状态的容器中，可以由事件触发，短暂的，完全被第三方管理，功能上FaaS就是不需要关心后台服务器或者应用服务，只需关心自己的代码即可。其中AWS Lambda是目前最佳的FaaS实现之一。

二．Serverless与传统架构比较

传统的互联网APP主要采用C/S架构，服务器端需长期维持业务进程来处理客户端请求，并调用代码逻辑完成请求响应流程。而在Serverless架构中，应用业务逻辑将基于FAAS架构形成独立为多个相互独立功能组件，并以API服务的形式向外提供服务；同时，不同功能组件间的逻辑组织代码将存储在Amazon Lambda，Azure Function，Google Cloud Functions等产品上，业务代码仅在调用时才激活运行，当响应结束占用资源便会释放。

2.1  Serverless架构的优势

• 低运营成本

  在业务突发性极高的场景下，系统为了应对业务高峰，必须构建能够应对峰值需求的系统，这个系统在大部分时间是空闲的，这就导致了严重的资源浪费和成本上升。在微服务架构中，服务需要一直运行，实际上在高负载情况下每个服务都不止一个实例，这样才能完成高可用性；在Serverless架构下，服务将根据用户的调用次数进行计费，按照云计算pay-as-you-go原则，如果没有东西运行，你就不必付款，节省了使用成本。同时，用户能够通过共享网络、硬盘、CPU等计算资源，在业务高峰期通过弹性扩容方式有效的应对业务峰值，在业务波谷期将资源分享给其他用户，有效的节约了成本。

• 简化设备运维

  在原有的IT体系中，开发团队即需要维护应用程序，同时还要维护硬件基础设施；Serverless架构中，开发人员面对的将是第三方开发或自定义的API 和URL，底层硬件对于开发人员透明化了，技术团队无需再关注运维工作，能够更加专注于应用系统开发。

• 提升可维护性

  Serverless架构中，应用程序将调用多种第三方功能服务，组成最终的应用逻辑。目前，例如登陆鉴权服务，云数据库服务等第三方服务在安全性、可用性、性能方面都进行了大量优化，开发团队直接集成第三方的服务，能够有效的降低开发成本，同时使得应用的运维过程变得更加清晰，有效的提升了应用的可维护性。

• 更快的开发速度

  这一点在现在互联网创业公司得到很好的体现，创业公司往往开始由于人员与资金等问题，不可能每个产品线都同时进行，这时候就可以考虑第三方的Baas平台，比如使用阿里云提供的RDS，极光推送的消息推送，Bmob支付以及地理位置等等，能够很快进行产品开发的速度，把工作重点放在业务实现上，把产品更快的推向市场。

2.2  Serverless架构的缺点

• 厂商平台绑定

  平台会提供Serverless架构给大玩家，比如AWS Lambda，运行它需要使用AWS指定的服务，比如API网关，DynamoDB，S3等等，一旦你在这些服务上开发一个复杂系统，你会粘牢AWS，以后只好任由他们涨价定价或者下架等操作，个性化需求很难满足，不能进行随意的迁移或者迁移的成本比较大，同时不可避免带来一些损失。Baas行业内一个比较典型的事件，2016年1月19日Facebook关闭曾经花巨额资金收购的Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。

• 成功案例比较少，没有行业标准

  目前的情况也只适合简单的应用开发，缺乏大型成功案例的推动。对于Serverless缺乏统一的认知以及相应的标准，无法适应所有的云平台。

三．Serverless架构适合

哪些业务场景以及竞品分析

3.1  Serverless架构适合哪些业务场景

• 低频请求场景

  物联网行业中，由于物联网设备传输数据量小，且往往是固定时间间隔进行数据传输，因此经常涉及低频请求场景。例如：物联网应用程序每分钟仅运行一次，每次运行50ms，这意味着CPU的使用率为0.1%/小时，这也意味着其实有1000个相同的应用可以共享计算资源。而Serverless架构下，用户可以购买每分钟100ms的资源来满足计算需求，通过这种方式就能够有效解决效率问题，降低使用成本。

• 流量突发场景

  移动互联网应用经常会面对突发流量场景，例如：移动应用的通常流量情况是QPS 20，但每隔五分钟会有一个持续10s的QPS 200流量（10倍于通常流量），传统架构下企业必须扩展QPS 200的硬件能力来应对业务高峰，即使高峰时间仅占整个运行时间的4%；而在Serverless架构下，用户可以利用弹性扩展特性，快速构建新的计算能力来满足当前需求，当业务高峰后，资源能够自动释放，有效节省成本。

3.2  Serverless架构业界竞品分析

• AWS Lamdba

  提到Serverless的业界竞品，我们第一个会想到AWS Lamdba，通过 AWS Lambda，无需配置或管理服务器即可运行代码。您只需按消耗的计算时间付费 – 代码未运行时不产生费用。借助 Lambda，您几乎可以为任何类型的应用程序或后端服务运行代码，而且全部无需管理。只需上传您的代码，Lambda 会处理运行和扩展高可用性代码所需的一切工作。您可以将您的代码设置为自动从其他 AWS 服务触发，或者直接从任何 Web 或移动应用程序调用，关于Lambda的优势如下图所示：

• FaceBook Parse

  Parse是一个完整的 iOS,android 后端支持平台，它可以让开发者完成忘掉服务器端的事情，包含了 schema free 的数据存储和云代码（CloudCode）。其数据存储服务涵盖了结构化的对象存储和非结构化的文件存储（也包括 CDN），并且，Parse 提供了完善的账户系统和数据访问控制，而且提供了强大的数据关联（一对一、一对多、多对多等）和查询能力。除此之外，由于定位于通用的后台服务，所以在标准化 API 之外，Parse 也提供了方法让开发者可以定制自己的商业逻辑。他们的做法是建立一个 node.js 容器，让开发者使用 javascript 这种广为人知的前端语言来完成数据整合、计算，再将结果返回给客户端。具体如下图所示：

• Bmob

  国内最近几年BaaS的发展也很迅速，可以说目前国内的创业环境和这些BaaS服务的发展相辅相成。目前国内在BaaS中除了互联网巨头外，领头的公司有Leancloud，Bmob等。Bmob是我曾经在一家创业公司使用过的产品，当时使用了它的移动支付和推送服务的功能，做的类似最近比较火的“在行”和“分答”（知识经济共享），对于初期想把产品推向市场检验自己的Idea来说是不错的，既节约人力与维护成本，也加快了开发速度。该平台为移动应用提供了一个完整的后端解决方案，让开发者以最小的配置和最简单的方式使用Bmob平台提供的服务，进而完全消除开发者编写服务器代码以及维护服务器的操作。主要功能有：

• （1）数据服务：可视化的云端NoSQL数据库设计，支持丰富的数据类型，灵活方便的增删改查，可视化的数据操作，安全的角色和ACL管理，数据的批量处理，本地数据缓存，让开发者们可以不需要关注服务器后端的事情。
• （2）移动支付：无需第三方申请审核，不论个人开发者还是企业都可快速接入移动支付功能，接入渠道现支持支付宝支付和微信支付。
• （3）推送服务：提供了Android和iOS两个版本的推送服务，采用Websocket保持长连接，稳定性更好，目前，64GB的单机能够支撑600万的用户长连接;
• （4）扩展服务：容器服务、定时任务、地理位置、云端逻辑等扩展服务，确保您的个性化业务逻辑能够在云端更好的运转。

四．Serverless理解容易存在误区

4.1  不能简单理解为PaaS

对于Serverless的理解，Adrian Cockcroft曾经这样说过“如果你的PaaS可以将以前半秒启动的应用在20ms内启动，就叫它Serverless”，换句话说，许多PaaS应用不会每次请求来了启动，请求结束则关闭，可以认为FaaS是一种特殊化的PaaS。但是又存在一些不同点，FaaS让用户更加注重自己的业务，不需要关注代码部署以及部署到那个服务器，甚至不需要考虑可扩展性（scaling），而PaaS平台会考虑这些因素。

4.2  NoOps并不意味着“免运维”  

Serverless并不意味着“免维护”，应该意味着“不需定时维护“。Serverless不代表完全去除服务器，而是代表去除有关对服务器运行状态的关心和担心，以及透明化基础设施。首先“Ops”意味着比服务器维护更多的内容，Serverless不要关注基础设施以及服务器，但是针对应用还是存在监控、网络、安全，以及产品排错等问题，这些问题对于Serverless应用来说仍然还在，需要一种策略来处理。

总结

本文从业内发展趋势引出Serverless架构，然后分成几大模块进行讲解：

第一部分，Serverless背景来源以及其概念定义，Serverless代表无服务器计算技术崛起， 是新一代云服务和开发架构的实践，主要分为BaaS和FaaS两部分；

第二部分，Serverless架构与传统架构比较的优缺点，Serverless架构低运营成本、简单化运维与高效开发速度等优点，同时也带来平台商的绑架以及目前技术不够成熟等问题存在；

第三部分，Serverless架构适合那些业务场景以及竞品分析；

第四部分，主要讲解对于Serverless架构，一些大家容易出现偏差的概念。

Serverless代表无服务器计算技术崛起， 是微服务的一种表现形式，是新一代云服务和开发架构的实践，是云计算发展重点方向之一。Serverless架构是BaaS实现的精髓，是BaaS进一步的解读，FaaS（Function as a service)是BaaS中云代码的实现方式。作为使用方我们不仅熟悉业内Serverless架构的经典产品，而且需要进行学习进而开发属于自己Serverless产品，或者能够很好的进行选型为自己产品快速的开发与运营提供基础条件。

关于作者：

王召

现任普元信息资深开发工程师，为普元新一代数字化企业云平台开发团队一员，负责新一代SPM（软件产品管理）与MKT（软件市场）领域系统的开发。曾在百度西北营销自主研发中心、格林谈谈科技等互联网公司从事开发经理工作，曾主导开发过多款电商和社交项目，并获得风险基金的投资。平时喜欢旅游，骑行，爬山等活动。

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。

查看原文