微服务与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
一次搜索请求的处理流程如下：
- 当请求到达API Gateway时，首先返回代理的前端的静态页面。
- 浏览器根据页面中引用的API，发起新的请求，经由API Gateway触发对应的Lambda函数，比如/search请求对应的是Search Function。
- 函数中的代码访问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大咖说的热心支持！
相关推荐 推荐文章
最近活动