微服务与Serverless

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

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

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

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

1.8.1 什么是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的服务中,而通常这样的部署很快,几乎是零宕机时间。

1.8.2 Serverless的应用场景

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

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

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

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

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

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

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

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

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

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

1

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

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

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

1.8.3 比较微服务与Serverless

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

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

图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的未来值得期待。

来都来了,走啥走,留个言呗~

IT大咖说 | 关于版权

由“IT大咖说(ID:itdakashuo)”原创的文章,转载时请注明作者、出处及微信公众号。投稿、约稿、转载请加微信:ITDKS10(备注:投稿),茉莉小姐姐会及时与您联系!

感谢您对IT大咖说的热心支持!

相关推荐 推荐文章

最近活动

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2019-07-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券