优百信息

一、单體(tǐ)与微服務(wù)

从单體(tǐ)应用(yòng)到微服務(wù)，我们实现了业務(wù)的快速交付。微服務(wù)在帮助我们架构解耦的同时，也带来了很(hěn)多(duō)新(xīn)的挑战，比如运维成本的增加和部署自动化等挑战。即使使用(yòng)云平台动态管理(lǐ)基础设施，我们仍然要面临如下现实问题：

基础设施的创建、配置、维护、安全，比如虚拟机的创建、配置，以及出现安全漏洞后对系统、软件的更新(xīn)等。随着微服務(wù)数量增加，维护的基础设施的规模也对应膨胀，造成创建、配置、维护的困难，并带来安全上的风险。

微服務(wù)的部署。可(kě)能(néng)需要定制专门的部署工具去实现零宕机时间部署，或者使用(yòng)云平台提供的部署服務(wù)，但都需要一定的學(xué)习、开发和维护成本。

服務(wù)的伸缩。云平台虽提供了自动伸缩服務(wù)，但其策略往往比较简单。比如，设定使用(yòng)得最少和最多(duō)的虚拟机根据CPU使用(yòng)率去伸缩，但是总的资源不能(néng)超过策略设定的最多(duō)虚拟机个数。一旦请求超过最大资源能(néng)承载的范围，可(kě)能(néng)会影响用(yòng)户的使用(yòng)體(tǐ)验，甚至服務(wù)中断。

基础设施成本。随着微服務(wù)的增加，需要创建越来越多(duō)的虚拟机/容器来运行这些微服務(wù)，為(wèi)了保证可(kě)用(yòng)性，这些资源会存在一定的冗余，同时利用(yòng)率不一定会很(hěn)高。如果将定时任務(wù)也看成一种微服務(wù)，它也需要一直运行在虚拟机上，而真正有(yǒu)意义的资源消耗只发生在执行阶段，其余时间的资源都白白浪费了。当微服務(wù)数量比较少时，也许看不出明显的成本差异，而当服務(wù)数量增加时，可(kě)能(néng)会导致资源开销的快速增加，造成基础设施的浪费。即便我们将服務(wù)部署在容器上，仍然不能(néng)避免资源浪费的问题。同时，还需要承担容器集群管理(lǐ)工具，如Kubenetes、Mesos等的维护成本。从资源的使用(yòng)率来讲，在单體(tǐ)应用(yòng)下，如果应用(yòng)的某个功能(néng)模块需要水平扩展，那么整个应用(yòng)都得和它一起水平扩展，这是一种资源的浪费。这样的问题在微服務(wù)架构下可(kě)能(néng)同样存在。假设有(yǒu)一个用(yòng)户管理(lǐ)的微服務(wù)，它的相关API endpoint和每分(fēn)钟访问数量如下表所示。

如果/login的请求剧增，需要扩容，而/register搭了顺风車(chē)，但是却没有(yǒu)利用(yòng)到这些资源，则会造成资源浪费。

上線(xiàn)时间（Time to Market）。单體(tǐ)应用(yòng)的上線(xiàn)时间可(kě)能(néng)需要半年，打通持续集成流水線(xiàn)的微服務(wù)可(kě)能(néng)只需要两周，然而对于有(yǒu)些领域，需要更快的上線(xiàn)时间。

将微服務(wù)部署在PaaS上，在一定程度上可(kě)以减轻上面的痛楚，但是有(yǒu)没有(yǒu)更完美的方案呢(ne)？针对上述的问题，业界提出了Serverless的概念，并且很(hěn)多(duō)的云服務(wù)提供商(shāng)已经提供Serverless服務(wù)。

二、  什么是Serverless

Serverless，顾名思义就是无服務(wù)器架构，也就是说从使用(yòng)者的角度，看不到服務(wù)器的存在，只要使用(yòng)或者直接部署代码即可(kě)。它包含两部分(fēn)内容：

BaaS（Backend as a Service后端即服務(wù)）。严重或完全依赖第三方应用(yòng)程序/服務(wù)（比如云平台）管理(lǐ)服務(wù)器端逻辑和状态的应用(yòng)程序。比如对于单页面的应用(yòng)，我们往往会选择将前端的部分(fēn)部署在AWS S3或者华為(wèi)云的OBS这样的服務(wù)中，前端应用(yòng)的部署，只是上传静态文(wén)件。同时S3或OBS的服務(wù)器对我们来说都是不可(kě)见的，不用(yòng)担心任何的维护压力，（大多(duō)数情况下）也不用(yòng)担心如何扩展，由云服務(wù)提供商(shāng)来维护服務(wù)的可(kě)用(yòng)性和数据的完整性。

FaaS（Function as a Service函数即服務(wù)）。开发者实现的服務(wù)器端的应用(yòng)逻辑（微服務(wù)甚至粒度更小(xiǎo)的服務(wù)）以事件驱动的方式运行在无状态的临时的容器中，并且这些容器、计算资源都是由第三方管理(lǐ)。

对于BaaS，可(kě)以视為(wèi)云平台提供的托管服務(wù)，比如NoSQL数据库，可(kě)以用(yòng)它来减轻微服務(wù)关联服務(wù)的基础设施维护成本。

对于FaaS，从架构层面来看可(kě)以视為(wèi)事件驱动架构，粒度上比微服務(wù)更小(xiǎo)，小(xiǎo)到函数级别。同时尽量做到无状态，服務(wù)不再需要复杂的打包等，直接以代码的方式部署，运行时环境由云平台提供。下面我们以AWS Lambda服務(wù)為(wèi)例来解释Serverless的好处以及使用(yòng)的案例/场景。

三、 Serverless的优势

以目前使用(yòng)较多(duō)的AWS的Serverless服務(wù)Lambda為(wèi)例，它提供了如下功能(néng)：

Java/Nodejs/Python的运行时环境。这意味着可(kě)以部署Ruby（JRuby）/Scala/Clojure/Java等运行在JVM上的代码，只是部署时需要编译成class文(wén)件打包上传。Nodejs和Python的代码可(kě)以直接部署，随时上線(xiàn)。

零宕机时间部署。通过Lambda可(kě)以很(hěn)容易地实现函数的蓝绿部署。

限量限时的运行资源。Lambda的运行单位是容器，它能(néng)使用(yòng)的资源比较有(yǒu)限，最大分(fēn)配的内存不超过1.5GB，临时磁盘大小(xiǎo)不超过512MB，进程和線(xiàn)程总数不超过1024个等，代码需要的资源超过限制会出错。每个容器的生命周期只有(yǒu)5分(fēn)钟，超过5分(fēn)钟会自动销毁，所以一定要保证任務(wù)在5分(fēn)钟内完成。

事件驱动。Lambda支持S3、API Gateway、CloudWatch等多(duō)种AWS上的服務(wù)绑定事件句柄，在事件发生时触发对应的Lambda函数。

自动伸缩。每个账户在每个Region上最多(duō)能(néng)同时运行1000个Lambda函数，算上每个容器的生存周期和并发量，几乎可(kě)以认為(wèi)是无限伸缩了。

按请求次数和资源使用(yòng)量收费。在撰写本文(wén)时，Lambda每个月前100万次请求以及400,000 GB秒(miǎo)的运算资源都是免费的。后续的每百万请求约為(wèi)1.5元人民(mín)币，每GB秒(miǎo)的使用(yòng)费用(yòng)约為(wèi)0.00012元人民(mín)币。据估算，使用(yòng)Lambda 部署代码的成本比在EC2上部署服務(wù)的成本低30%。

从Lambda的特性以及相关的数据，我们很(hěn)容易看出，相比部署在虚拟机或者容器的微服務(wù)，Serverless的好处在于：

几乎是“零”维护成本。开发人员可(kě)以专注于实现业務(wù)逻辑，不用(yòng)担心基础设施创建、自动化部署的问题，也不用(yòng)担心服務(wù)器维护、升级等问题。

降低安全风险。不用(yòng)管理(lǐ)基础设施，减少了因為(wèi)维护造成的安全问题，云平台的提供商(shāng)会替我们保障服務(wù)的安全性。

更低的资源开销。Lambda通过请求次数和资源使用(yòng)量收费，而部署在EC2实例上的服務(wù)则是按秒(miǎo)收费。

更灵活的伸缩。相比部署在虚拟机或者容器上的微服務(wù)，需要根据经验或者监控去设置、调整伸缩策略，使用(yòng)Serverless则几乎不需要考虑这点，它会按需自动伸缩。

更快上線(xiàn)。对于开发人员来说，他(tā)们只需要直接部署代码到Serverless的服務(wù)中，而通常这样的部署很(hěn)快，几乎是零宕机时间。

四、Serverless的应用(yòng)场景

根据Lambda以及云平台上托管服務(wù)的特性，我们可(kě)以发现Serverless的应用(yòng)场景大致如下：

事件驱动的业務(wù)。比如传统的ETL流程，往往都是通过运行在虚拟机上的Cron任務(wù)去轮询或者定时运行处理(lǐ)。但是通过在S3上进行事件绑定，在文(wén)件上传时触发处理(lǐ)文(wén)件的Lambda函数，然后顺序将事件和对应的处理(lǐ)传递下去。

实时业務(wù)。比如API，通过API Gateway触发部署在Lambda上的业務(wù)逻辑代码，然后返回处理(lǐ)结果。

定时任務(wù)。不用(yòng)再像以前一样，為(wèi)了节省资源将定时任務(wù)部署在同一台服務(wù)器上。只需将处理(lǐ)的逻辑直接部署在Lambda上，在CloudWatch上设定trigger，定时触发Lambda函数即可(kě)。

我们以一个宠物(wù)商(shāng)店(diàn)网站的单體(tǐ)应用(yòng)為(wèi)例，它提供了用(yòng)户管理(lǐ)、購(gòu)买和搜索的功能(néng)，其基本的架构如图1-19所示。单體(tǐ)应用(yòng)直接部署在虚拟机上，供浏览器访问，相关的数据都保存在数据库中。

图1-19 宠物(wù)商(shāng)店(diàn)的单體(tǐ)应用(yòng)

将宠物(wù)商(shāng)店(diàn)充分(fēn)地拆分(fēn)為(wèi)微服務(wù)后，在AWS上部署的架构如图1-20所示。宠物(wù)商(shāng)店(diàn)的服務(wù)进行前后端分(fēn)离，同时后端的功能(néng)分(fēn)解為(wèi)身份验证、購(gòu)买和搜索的微服務(wù)API，每个API有(yǒu)自己对应的数据库。从图中不难看出，為(wèi)了让服務(wù)上線(xiàn)并保证可(kě)用(yòng)性而需要付出的基础设施和维护的成本。

图1-20 宠物(wù)商(shāng)店(diàn)微服務(wù)化后部署在AWS上的架构

如果使用(yòng)AWS提供的Serverless的服務(wù)，它的架构如图1-21所示。

图1-21 宠物(wù)商(shāng)店(diàn)微服務(wù)化后部署在AWS上的Serverless架构

将宠物(wù)商(shāng)店(diàn)应用(yòng)的前端部署在AWS S3上面，部署可(kě)以表现為(wèi)直接上传前端的静态文(wén)件。

后端的逻辑拆分(fēn)到函数级别，分(fēn)别部署在AWS Lambda上。

状态和数据保存在AWS Dynamodb中（Dynamodb是一个全托管的NoSQL数据库）。

AWS的API Gateway服務(wù)可(kě)以作為(wèi)HTTP代理(lǐ)以及安全入口。

其中所用(yòng)到的服務(wù)都是按照使用(yòng)/请求次数付费，并且可(kě)以自动伸缩。部署在S3上的静态页面可(kě)以通过CDN缓存来进一步提升性能(néng)。

一次搜索请求的处理(lǐ)流程如下：

1、当请求到达API Gateway时，首先返回代理(lǐ)的前端的静态页面。

2、浏览器根据页面中引用(yòng)的API，发起新(xīn)的请求，经由API Gateway触发对应的Lambda函数，比如/search请求对应的是Search Function。

3、函数中的代码访问Dynamodb，获取数据并返回搜索结果。

上面用(yòng)到的所有(yǒu)服務(wù)都是Serverless的，S3、API Gateway、Dynamodb是BaaS的，Lambda是FaaS的，需要创建、配置的东西非常少，开发人员只需要关注各个业務(wù)模块代码的（函数）实现，之后部署代码，就可(kě)以完成服務(wù)的上線(xiàn)。几乎不用(yòng)担心伸缩、维护的问题。

五、 比较微服務(wù)与Serverless

当我们比较微服務(wù)和Serverless时，实际上比较的是微服務(wù)和FaaS。直观上来看，微服務(wù)和FaaS的差别在于粒度，而要实现FaaS，首先必须将单體(tǐ)应用(yòng)演进到微服務(wù)，然后才能(néng)进一步地分(fēn)解到函数级别，实现FaaS。我们可(kě)以进一步从如下几个方面比较微服務(wù)和FaaS。

微服務(wù)和Serverless不完全是同一层面的事物(wù)，但是BaaS可(kě)以帮助解决微服務(wù)带来的基础设施、维护、资源成本等问题，FaaS进一步改造微服務(wù)，降低其实现的粒度，实现更快的上線(xiàn)。Redpoint总结的Serverless LandScape，如图1-22所示。

图1-22 Redpoint总结的Serverless LandScape

虽然现在FaaS距大规模地被应用(yòng)还有(yǒu)一定的距离，并且目前它还存在一定的问题，如管理(lǐ)成本、测试、服務(wù)治理(lǐ)等，但是Serverless，如Lambda，在AWS已经有(yǒu)一些成功的案例，也有(yǒu)实际的应用(yòng)场景，如IoT等。一些本地测试、部署的工具也陆续出现，相信这些问题也会被陆续解决。从图1-22来看，Serverless从平台、框架、类库、工具的层面已经形成了一定的规模。

目前大部分(fēn)的云服務(wù)供应商(shāng)都推出了自己的Serverless架构服務(wù)，比如AWS的Lambda、Google的Cloud Functions、华為(wèi)的FunctionStage等。开源的Serverless框架也层出不穷，比如IBM的openwhisk、Oracle的fn等，Serverless的未来值得期待。