一篇文章看懂无服务器计算的本质与未来

• 无服务器计算,或者功能即服务(Functions-as-a-Service,以下简称FaaS),未来将会改变我们的产业链,凡是基于它的企业或者组织,最终会受益于它在价格、人力,以及上市时间等方面带来的竞争优势.
• 许多无服务器应用程序,未来将会对FaaS和其他第三方提供的服务进行组合,以便提供功能预管理和状态管理.
• 工具会有极大地提升,特别是在部署和配置方面.
• 较好的无服务器架构模式稍后就会出现,现在了解细节为时过早.
• 未来需要基于真正的DevOps概念,无服务器可以提供的所有市场效益,最终将会被拥有自己管理能力、自给自足的产品团队所收获.

现在是2017年,距离两年前无服务器计算革新只取得了少许进展(你听见人们在唱歌吗?).这次变革并不是像Docker那样突飞猛进地前进,而是采用了相对平稳的发展节奏.Amazon新发布了Web Services的Lambda特性,产品保持了一个有规律的发布节奏,另一个重要的第三方(微软)正在一个接一个地发布生产环境版本,也有一些新的开源项目频繁地加入这场盛宴.

当我们接近早期阶段的末尾时,来做一个有趣的游戏,让我们戴上预测护目镜(开个玩笑),深入思考下一步会走向哪里,如何走到那一步,以及我们的组织需要去做什么来支持这一步的到来.所以,加入我们,让我们看看无服务器计算未来可能发生什么.

让读者了解真实的未来!你可以通过阅读这篇文章开始了解细节.我们离无服务器还有多远?2020年怎么样?请寄一张明信片给我!

无服务器能力展望

计算

过去十年我们目睹了云计算的出现,然后它迅速地异军突起.9年以前,虚拟公有云服务器还只是手上的玩具而已,但是在相当短的时间里,当我们考虑任何新的部署架构方案时,它变成了大多数行业的首选平台.

无服务器计算,或者Functions-as-a-Service(Faas),当我们考虑“IT”如何变化时,它会是这次重大变化的最新出现部分.这次变革是一次我们一直以来所期待的自然过程,从我们如何交付应用程序给客户开始,到希望能够删除所有的部件和基础设施.

我们开发的相当一部分应用程序,是由许多小的组件所组成的.每个这样的组件包含了一个小的输入集和上下文信息,需要消耗10毫秒或100毫秒完成组件的一些内部工作,最终可能反馈一个结果,也可能更新相关内容.这类场景最适合无服务器计算.

我们预测未来由于FaaS在部署上的方便、快速、廉价,会有越来越多的团队基于FaaS开发,这样便于管理和扩展基础设施.我们对FaaS可以有很多种使用方式,包括：

• 由大量的顺序消息处理器所组成的完整的后端数据管道
• 通过HTTP API调用的同步服务
• 通过独立的胶水代码提供针对部署、监控的自定义操作逻辑
• 对于计算密集任务,由实体服务器直接调用平台缩放功能组成的混合动力系统

使用FaaS的企业相较没有使用的企业具有竞争优势,包括价格、投向市场时间等.

管理应用程序状态

广泛采用FaaS的一个先决条件是针对快速而简单的状态管理方法的解决方案,或者一系列解决方案.无服务器计算是一种无状态模式.我们不能假定任何有用的状态存在,即不存在即时执行环境内不同的运行时调用之间的有用状态.一些应用程序在这种限制下依然适用.例如,单纯进行数据转换的消息驱动组件不需要访问外部状态,拥有无限制响应时间需求的Web Service组件,其每一次调用时需要连接到一台远程数据库,这种做法也是可以接受的.但是对于其他应用程序来说,这种限制就显得有些不足了.

解决这类不足的一种方案是混合动力系统,即在不同类型的组件里管理状态,而不是执行我们的FaaS代码.比较流行的混合动力方案是通过云端基础设施提供其他服务的前端FaaS功能.我们已经见到了这种类似于API网管的特定上下文逻辑的组件,它们提供了HTTP路由、授权,以及我们经常在典型的Web Service里看到的节流逻辑,采用定义替换配置方式实现.Amazon最近也在管理状态的通用方式上露了一手,使用他们的Step Functions服务,允许团队基于可配置的状态机器定义应用程序.Step Funcations服务本身可能没什么过人之处,但是通常情况下这种无码解决方案是很受欢迎的.

当供应商服务不充足时,对于混合动力系统来说,一种改变方式是团队坚持开发追踪状态的长生命周期组件.这些组件可能被部署在CaaS(容器即组件,Containers-as-a-Service)或者PaaS(平台即组件,Platform-as-a-Service)环境,和FaaS功能协同工作.

这种混合动力系统组合了长期运行的组件逻辑和每一次FaaS功能请求逻辑.另一类做法是完全地聚焦于FaaS功能,让这些FaaS功能超越它们当前执行的环境,极其快速地获取和持久化状态.一种可能的实施方式是确保一个特定的FaaS功能,或者一系列FaaS功能,确保它们拥有类似于Redis这样的外部缓存机制,起到低延时访问作用.通过启动类似于Amazon的same-zone plancement groups(置放组群)这样的特性可以做到这一点.虽然这种解决方案较内存/本地磁盘状态方案来说有些延迟,但是很多应用程序会认同这种解决方案.

混合方法的好处是经常被访问的状态可以和逻辑一起保存在环境当中,那样并不复杂,但是可能有点贵,必须要有逻辑网络选址和外部状态.另一方面,一个单纯的FaaS方式的有点是更加一致性的编程模型,外加无服务器带来的更为宽广的伸缩使用和可操作性优势.当前的发展势头显示最终混合方式会胜出,但是我们也应该对其他方式开放,比如类似于启用置放群组Lambdas.

无服务器协作服务

超越业务管理和状态管理,我们可以预见到其他组件的服务化和商业化,即使在云端环境,传统意义上我们希望开发,或者至少自己管理这些服务.例如我们可以停止运行在EC2机器上面的Mysql数据库服务器,转而使用Amazon的RDS服务器,我们可以使用Kinesis替换我们自管理的Kafka消息总线安装程序.其他的基础设施服务包括文件系统和数据仓库,而更多的面向应用示例包括认证和语音分析.

（编辑：应用网_丽江站长网）

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