转载

【大咖连载】微服务与Serverless

点击上面“蓝字”关注我们！

从单体应用到微服务，我们实现了业务的快速交付。微服务在帮助我们架构解耦的同时，也带来了很多新的挑战，比如运维成本的增加和部署自动化等挑战。即使使用云平台动态管理基础设施，我们仍然要面临如下现实问题：

基础设施的创建、配置、维护、安全，比如虚拟机的创建、配置，以及出现安全漏洞后对系统、软件的更新等。随着微服务数量增加，维护的基础设施的规模也对应膨胀，造成创建、配置、维护的困难，并带来安全上的风险。
微服务的部署。可能需要定制专门的部署工具去实现零宕机时间部署，或者使用云平台提供的部署服务，但都需要一定的学习、开发和维护成本。
服务的伸缩。云平台虽提供了自动伸缩服务，但其策略往往比较简单。比如，设定使用得最少和最多的虚拟机根据 CPU 使用率去伸缩，但是总的资源不能超过策略设定的最多虚拟机个数。一旦请求超过最大资源能承载的范围，可能会影响用户的使用体验，甚至服务中断。
基础设施成本。随着微服务的增加，需要创建越来越多的虚拟机 / 容器来运行这些微服务，为了保证可用性，这些资源会存在一定的冗余，同时利用率不一定会很高。如果将定时任务也看成一种微服务，它也需要一直运行在虚拟机上，而真正有意义的资源消耗只发生在执行阶段，其余时间的资源都白白浪费了。当微服务数量比较少时，也许看不出明显的成本差异，而当服务数量增加时，可能会导致资源开销的快速增加，造成基础设施的浪费。即便我们将服务部署在容器上，仍然不能避免资源浪费的问题。同时，还需要承担容器集群管理工具，如 Kubenetes 、 Mesos 等的维护成本。从资源的使用率来讲，在单体应用下，如果应用的某个功能模块需要水平扩展，那么整个应用都得和它一起水平扩展，这是一种资源的浪费。这样的问题在微服务架构下可能同样存在。假设有一个用户管理的微服务，它的相关 API endpoint 和每分钟访问数量如下表所示。

Restful API	RPM
/login	1000
/register	100

如果 /login 的请求剧增，需要扩容，而 /register 搭了顺风车，但是却没有利用到这些资源，则会造成资源浪费。

上线时间（ Time to Market ）。单体应用的上线时间可能需要半年，打通持续集成流水线的微服务可能只需要两周，然而对于有些领域，需要更快的上线时间。

将微服务部署在 PaaS 上，在一定程度上可以减轻上面的痛楚，但是有没有更完美的方案呢？针对上述的问题，业界提出了 Serverless 的概念，并且很多的云服务提供商已经提供 Serverless 服务。

【大咖连载】微服务与Serverless

1.8.1 什么是Serverless

【大咖连载】微服务与Serverless

Serverless ，顾名思义就是无服务器架构，也就是说从使用者的角度，看不到服务器的存在，只要使用或者直接部署代码即可。它包含两部分内容：

BaaS （ Backend as a Service 后端即服务）。严重或完全依赖第三方应用程序 / 服务（比如云平台）管理服务器端逻辑和状态的应用程序。比如对于单页面的应用，我们往往会选择将前端的部分部署在 AWS S3 或者华为云的 OBS 这样的服务中，前端应用的部署，只是上传静态文件。同时 S3 或 OBS 的服务器对我们来说都是不可见的，不用担心任何的维护压力，（大多数情况下）也不用担心如何扩展，由云服务提供商来维护服务的可用性和数据的完整性。
FaaS （ Function as a Service 函数即服务）。开发者实现的服务器端的应用逻辑（微服务甚至粒度更小的服务）以事件驱动的方式运行在无状态的临时的容器中，并且这些容器、计算资源都是由第三方管理。

对于 BaaS ，可以视为云平台提供的托管服务，比如 NoSQL 数据库，可以用它来减轻微服务关联服务的基础设施维护成本。

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

Serverless的优势

Serverless 的优势

以目前使用较多的AWS的Serverless服务Lambda为例，它提供了如下功能：

Java/Nodejs/Python 的运行时环境。这意味着可以部署 Ruby （ JRuby ） /Scala/Clojure/Java 等运行在 JVM 上的代码，只是部署时需要编译成 class 文件打包上传。 Nodejs 和 Python 的代码可以直接部署，随时上线。
零宕机时间部署。通过 Lambda 可以很容易地实现函数的蓝绿部署。
限量限时的运行资源。 Lambda 的运行单位是容器，它能使用的资源比较有限，最大分配的内存不超过 1.5GB ，临时磁盘大小不超过 512MB ，进程和线程总数不超过 1024 个等，代码需要的资源超过限制会出错。每个容器的生命周期只有 5 分钟，超过 5 分钟会自动销毁，所以一定要保证任务在 5 分钟内完成。
事件驱动。 Lambda 支持 S3 、 API Gateway 、 CloudWatch 等多种 AWS 上的服务绑定事件句柄，在事件发生时触发对应的 Lambda 函数。
自动伸缩。每个账户在每个 Region 上最多能同时运行 1000 个 Lambda 函数，算上每个容器的生存周期和并发量，几乎可以认为是无限伸缩了。
按请求次数和资源使用量收费。在撰写本文时， Lambda 每个月前 100 万次请求以及 400,000 GB 秒的运算资源都是免费的。后续的每百万请求约为 1.5 元人民币，每 GB 秒的使用费用约为 0.00012 元人民币。据估算，使用 Lambda 部署代码的成本比在 EC2 上部署服务的成本低 30% 。

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

几乎是 “零 ” 维护成本。开发人员可以专注于实现业务逻辑，不用担心基础设施创建、自动化部署的问题，也不用担心服务器维护、升级等问题。
降低安全风险。不用管理基础设施，减少了因为维护造成的安全问题，云平台的提供商会替我们保障服务的安全性。
更低的资源开销。 Lambda 通过请求次数和资源使用量收费，而部署在 EC2 实例上的服务则是按秒收费。
更灵活的伸缩。相比部署在虚拟机或者容器上的微服务，需要根据经验或者监控去设置、调整伸缩策略，使用 Serverless 则几乎不需要考虑这点，它会按需自动伸缩。
更快上线。对于开发人员来说，他们只需要直接部署代码到 Serverless 的服务中，而通常这样的部署很快，几乎是零宕机时间。

【大咖连载】微服务与Serverless

1.8.2 Serverless的应用场景

【大咖连载】微服务与Serverless

根据 Lambda 以及云平台上托管服务的特性，我们可以发现 Serverless 的应用场景大致如下：

事件驱动的业务。比如传统的 ETL 流程，往往都是通过运行在虚拟机上的 Cron 任务去轮询或者定时运行处理。但是通过在 S3 上进行事件绑定，在文件上传时触发处理文件的 Lambda 函数，然后顺序将事件和对应的处理传递下去。
实时业务。比如 API ，通过 API Gateway 触发部署在 Lambda 上的业务逻辑代码，然后返回处理结果。
定时任务。不用再像以前一样，为了节省资源将定时任务部署在同一台服务器上。只需将处理的逻辑直接部署在 Lambda 上，在 CloudWatch 上设定 trigger ，定时触发 Lambda 函数即可。

我们以一个宠物商店网站的单体应用为例，它提供了用户管理、购买和搜索的功能，其基本的架构如图 1-19 所示。单体应用直接部署在虚拟机上，供浏览器访问，相关的数据都保存在数据库中。

【大咖连载】微服务与Serverless

图 1-19 宠物商店的单体应用

将宠物商店充分地拆分为微服务后，在 AWS 上部署的架构如图 1-20 所示。宠物商店的服务进行前后端分离，同时后端的功能分解为身份验证、购买和搜索的微服务 API ，每个 API 有自己对应的数据库。从图中不难看出，为了让服务上线并保证可用性而需要付出的基础设施和维护的成本。

【大咖连载】微服务与Serverless

图 1-20 宠物商店微服务化后部署在 AWS 上的架构

如果使用 AWS 提供的 Serverless 的服务，它的架构如图 1-21 所示。

【大咖连载】微服务与Serverless

图 1-21 宠物商店微服务化后部署在 AWS 上的 Serverless 架构

将宠物商店应用的前端部署在 AWS S3 上面，部署可以表现为直接上传前端的静态文件。
后端的逻辑拆分到函数级别，分别部署在 AWS Lambda 上。
状态和数据保存在 AWS Dynamodb 中（ Dynamodb 是一个全托管的 NoSQL 数据库）。
AWS 的 API Gateway 服务可以作为 HTTP 代理以及安全入口。
其中所用到的服务都是按照使用 / 请求次数付费，并且可以自动伸缩。部署在 S3 上的静态页面可以通过 CDN 缓存来
进一步提升性能。

一次搜索请求的处理流程如下：

当请求到达 API Gateway 时，首先返回代理的前端的静态页面。
浏览器根据页面中引用的 API ，发起新的请求，经由 API Gateway 触发对应的 Lambda 函数，比如 /search 请求对应的是 Search Function 。
函数中的代码访问 Dynamodb ，获取数据并返回搜索结果。

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

【大咖连载】微服务与Serverless

1.8.3 比较微服务与Serverless

【大咖连载】微服务与Serverless

当我们比较微服务和 Serverless 时，实际上比较的是微服务和 FaaS 。直观上来看，微服务和 FaaS 的差别在于粒度，而要实现 FaaS ，首先必须将单体应用演进到微服务，然后才能进一步地分解到函数级别，实现 FaaS 。我们可以进一步从如下几个方面比较微服务和 FaaS 。

【大咖连载】微服务与Serverless

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

【大咖连载】微服务与Serverless

图 1-22 Redpoint 总结的 Serverless LandScape

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

目前大部分的云服务供应商都推出了自己的 Serverless 架构服务，比如 AWS 的 Lambda 、 Google 的 Cloud Functions 、华为的 FunctionStage 等。开源的 Serverless 框架也层出不穷，比如 IBM 的 openwhisk 、 Oracle 的 fn 等， Serverless 的未来值得期待。