Serverless发展早有“端倪”，函数计算源于云用户需求

《Serverless发展早有“端倪”，函数计算源于云用户需求》要点：
本文介绍了Serverless发展早有“端倪”，函数计算源于云用户需求，希望对您有用。如果有疑问，可以联系我们。

Serverless架构用来描述那些显著或完全依赖于第三方应用或服务(“在云端”)的应用程序.这些程序经常是移动端APP或者是最近几年比较火热的单页Web应用.这些应用可以完全基于云的服务进行构建,比如AWS的S3和DynamoDB或者是阿里云的OSS和TableStore.但是总是有一些独立的服务器逻辑代码需要运行,传统的部署方法是使用云服务器来进行进程的托管,但是FaaS (Functions as a Service)的出现改变了这种情况.FaaS能够让用户将自己服务器逻辑代码以Serverless的方式托管到云上,让用户以应用函数为单位对应用进行开发、运行、管理,无需基础设施层面的关心构建和维护工作.

Serverless架构于2014年进入大众视线,AWS、谷歌云、微软Azure和IBM Bluemix等云厂商提供服务.业界认为,Serverless化可大幅降低IT成本,将云的费用减少10%-90%.可口可乐架构师Patrick Brandt曾向外媒披露,向Serverless架构转移是主要出于降低IT运维费用并且提高服务部署效率.

2017年4月云栖大会?南京峰会,阿里云发布了函数计算产品.阿里云函数计算负责人不瞋认为,从云计算整体发展趋势而言,Serverless的出现是意料之中.云计算的第一阶段是基础设施即服务,用户能够使用和调动大规模的计算资源；接下来需要攻关的是如何高效利用资源、更加有效的降低成本,更加弹性的面对业务波动,这就是函数计算的用武之地.InfoQ对不瞋进行了专访,并将内容整理如下.

什么是Serverless?什么是FaaS?

其实,广义的Serverless覆盖范围很大,很多云服务产品可以被视作Serverless化的.以存储服务的发展历程为例：最初常见是云服务器,此种情况对用户熟悉的原有开发方式的模拟,但是需要自行处理云服务器宕机带来的数据不可用问题,云磁盘上的数据也不便于分享；后来,对象存储(OSS),文件存储(NAS),表格存储(TableStore),消息服务(MNS)等都属于Serverless服务.这些服务不再有机器的概念,用户能够享受自动的扩容和负载平衡,性能水平扩展,通过API方便的读写数据,易于共享,并且按实际存储的数据量以及访问次数付费.此外,类似阿里云大数据计算服务(MaxCompute) 也是Serverless的,提供了MapReduce,和Streaming等多种计算框架,用户不需要管理计算资源.

Serverless是一个宽泛的概念,很多存储、计算和中间件服务都是Serverless的.而FaaS是Serverless的子集,也是实现整个应用Serverless化的核心服务.FaaS的关键特征是：事件驱动、细粒度调用、实时弹性伸缩,无需管理服务器等底层资源.在不瞋看来,FaaS兴起是对现有技术很好的补充,配合使用已有的云服务产品,即可以真正构建Serverless的应用.阿里云之所以研发FaaS产品-函数计算,也是观察到在存储和计算业务中,从server-base到Serverless的演变趋势和用户的需求.

Serverless与微服务是一脉相承的

微服务和Serverless是契合的,都强调系统的解耦.

将业务逻辑的实现拆分到Function的粒度再去实现,这种方法其实并不新奇；微服务本身是被越来越广泛使用的模式,并且已经有Netflix、Uber等公司的成功经验.用户完全可以把一个微服务实现为Function.阿里云函数计算设计的一个重要目标也是使之成为以微服务方式构建应用的最好平台.微服务式架构其实是很有挑战的,在拆成成百上千的服务之后,需要高度自动化的发布部署系统,管理各个微服务之间的依赖.从某种角度而言,Serverless和微服务是不同层面、但又互相促进的：微服务式是开发模式,Serverless是计算平台.

不瞋称其个人理解是,让Serverless这种计算平台变成支撑微服务开发模式的最好的平台.当越来越多公司熟悉并实践微服务的开发模式,那么迁移到Serverless就会更顺理成章,因为系统已经被解耦成了众多松耦合的微服务.

所以,Serverless和微服务的未来发展是相互借力的.一个有力的例子就是,大规模使用微服务的方式构建系统的公司,例如Netflix,也在广泛的使用AWS Lambda这类FaaS服务来构建Serverless应用.

但是,微服务化改造并非易事.将一个巨型单体应用以微服务的方式拆分解耦,继而改造为Serverless应用,是采用渐进的方式逐步替换还是完全重写?这是业界非常关心也经常讨论的问题,不瞋认为需要依据情况而定：有时直接重写更快；而在系统错综复杂的情况下,为了保险起见也可平滑过渡,一点点向微服务化演进.拆分微服务有三个考量,组织结构(参考康威定律),运维发布频率(比如将每周发布两次的服务与每两个月发布一次的服务进行拆分)和逻辑调用频度(将高频调用逻辑和低频调用逻辑分开,在Serverless架构下能够进一步降低成本).以上三点需根据业务需求情况进行综合考量,没有普适性的优先级之分.

Serverless适用的两大场景

场景一：应用负载有显著的波峰波谷

Serverless化与否的评判标准并不是公司规模的大小,而是其业务背后的具体技术问题,比如业务波峰波谷明显,如何实现削峰填谷.一个公司的业务负载具有波峰波谷时,机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显下降,因为不能进行资源复用而导致浪费.

业界普遍共识是,当自有机器的利用率小于30%,使用Serverless后会有显著的效率提升.对于云厂商,在具备了足够多的用户之后,各种波峰波谷叠加后平稳化,聚合之后资源复用性更高.比如,外卖企业负载高峰是在用餐时期,安防行业的负载高峰则是夜间,这是受各个企业业务定位所限的；而对于一个云厂商,如果其平台足够大,用户足够多,是不会有明显的波峰波谷的现象的.

场景二：典型用例-基于事件的数据处理

视频处理的后端系统,常见功能需求如下：视频转码、抽取数据、人脸识别等,这些均为通用计算任务,可由函数计算执行.

开发者需要自己写出实现逻辑,再将任务按照控制流连接起来,每个任务的具体执行由云厂商来负责.如此,开发变得更便捷,并且构建的系统天然高可用、实时弹性伸缩,用户不需要关心机器层面问题.

使用小tips：函数的执行本身是无状态的,如果要持久化数据则需使用OSS等存储服务.虽然用户可以使用本地的磁盘,但是需要假定这些数据在函数执行完成后就不再需要了.

Serverless带来哪些冲击?

Serverless不等于没有运维,但是运维内容变了

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!