一篇文章看懂无服务器计算的本质与未来
|
这里比较有意思的一个想法是FaaS功能,由于它们轻量级的应用模式,可以将自己紧紧地绑定一个服务,使得FaaS调用服务功能的生态环境时可以调用其他的FaaS功能,诸如此类等等.这会导致“有趣的”级联错误问题,对于这种错误我们需要更强大的监控工具,会在本文稍后介绍. 站在数据中心后面目前来看,绝大多数的无服务器计算是运行在供应商数据中心平台上的.这就给出了一个替代方案,即如何运行你的代码,而不是在哪里运行代码.Amazon发布了一个有趣的新特性,即是允许它们的客户在不同的地点运行Lambda函数,例如,和Lamdba@Edge一起运行在CDN内,甚至在无服务器地点,和Greengrass一起运行的物联网(IoT)设备.这样做的原因是,Lamdba是一个极端轻量级的编程模型,本质上的事件驱动的,并且非常容易适配相同的知识理念、新地点的代码风格.Lambda@Edge是一个特别有趣的例子,因为它提供了在一个地点进行程序定制的可选项,这在以前是没有出现过的情况. 当然,这种做法的缺点是和供应商深度绑定!对于那些不想使用第三方平台,但是又想利用无服务器计算优势的厂商来说,有一种可以接受的解决方案,类似于Cloud Foundry已经推出的PaaS.来自Kubernetes的Galactic Fog、IronFunctions以及Fission,是这种方案的早期作品. 我们将来需要的工具和技术正如我之前描述的,这里有一个明显的减速,使用无服务器方式时存在条件限制、性价比权衡.天下没有免费的午餐.对于已经过了早期适应阶段的无服务器用户来说,我们需要解决或者缓解这些问题.所幸,这方面目前发展势头良好. 部署工具使用AWS的标准工具向Lambda部署函数挺复杂的,也比较容易出错.向API网关中添加Lambda函数,以响应HTTP请求,你更多要做的工作是安装和配置.无服务器和ClaudiaJS开源项目项目已经推动部署改进措施达一年之久,AWSSAM(AWS无服务器应用模型)也在2016年加入到了这一行动.所有这些项目通过在AWS标准工具的顶层增加大量自动化程序,简单化了无服务器应用程序的创建、配置和部署.但是我们还有很多工作要做.未来将会有两个关键动作实现完全自动化：
第一条很重要,我们也已经开始认识到,以便更广泛地推广“生产提前期概念”.部署一个全新的无服务器应用程序应该是像创建一个新的Github仓库一样容易,填充少量字段,然后按下按钮,通过这种一键部署方式让系统自动创建你所需要的所有东西. 然而,光有简便的初始化部署方式是不够的.我们也需要有比较好的工具,支撑前面提到的混合动力系统的持续交付和持续部署.这意味着我们应该可以部署一系列的计算函数以及CaaS/PaaS组件,连同所有应用程序封装服务的变化(例如,在一个API网关配置http路由,或者一个被单一应用程序使用的Dynamo表),一键生效和回滚能力.此外,这些动作都不应该是很费脑力去理解的,也不会需要几天时间去完成安装和维护任务. 这是一个很艰难的抉择,但是我前面提到的工具(类似于Terraform这样的混合动力工具)正在指引解决这些问题的方式,我完全相信他们在未来的几个月或者几年时间里可以在很大程度上解决问题. 本文不仅仅讨论部署代码和配置服务.其他一些操作上关心的问题也会被讨论.安全问题是一大问题.当前,获取AWS凭证、角色,以及设置和维护都可能是一大麻烦事.AWS拥有一套完善的安全模型,但是我们需要一个工具,这个工具可以让这套安全模型对于开发人员来说更加友好. 总之,我们需要开发人员在开发他们的Webtask产品时,做到UX和Auth0都很好,就像AWS一样的宽广而有价值的生态系统. 监控、日志和调试一旦我们的应用程序被部署完毕,我们就会需要针对监控和日志的良好的解决方案,这类工具目前有几个组织正在尝试积极地发展着.除了评估其中一个组件的功能,我们也需要号的工具追踪请求,这些请求穿越了一个完整的多个无服务器计算功能和配套服务体系的分布式系统.Amazon正在将X-Ray推向该领域,目前说这个还有点为时尚早. 调试也是挺重要的.程序员很少在第一次代码运行通过之前不犯错误,我们也别寄希望于这种情况会有所改变.我们依赖于监控,在FaaS功能的开发阶段评估问题,但是这种调试方式是石器时代的工具. 当我们调试传统的应用程序时,我们从IDE工具那里可以得到很大的支持,通过设置断点、单步调试代码,等等.使用现代化的基于Java的IDE工具,你可以绑定一个正在运行的远程进程,并且远程执行调试工作.因为我们更加倾向于使用云端部署的FaaS功能完成大量的部署工作,希望未来你的IDE工具也可以具有类似的功能,可以连接到一台正在运行的无服务器平台,查询每个功能的执行情况.这需要工具和平台开发商之间的协作,如果想要让无服务器被广泛采用,这些措施都是必要的.这些想法对于云计算来说有一定开发工作量,也有大量的测试工作量. 测试我到目前为止所讨论的所有关于无服务器工具的话题,我认为最落后的是测试工具.值得关注的是,无服务器方案较传统解决方案来说有着相当大的测试优势,主要是两点,(a).无服务器计算的各个功能的单元测试很成熟,(b).无服务器服务写的代码更少,并且至少在单元测试层面,只需要做简单的测试. 但是这并没有解决跨组件功能/集成/验收/业务流程等测试问题.无服务器计算时我们的逻辑是分散在几个函数和服务内的,因此,更高级别的测试甚至比使用接近单一方法的组件更重要.当我们如此依赖于在云端基础设施上运行时,我们应该怎么做呢? 对于我们来说,测试可能是最没有看清楚的.我猜测未来基于云端的测试会变得很普遍.这一部分会变得更加容易部署、监控,以及调试我们的无服务器apps,甚至于比我现在描述的这些原因更加丰富. 换句话说,为了运行更高级别的测试,我们将会部署整个生态系统的一部分到云端,并且对部署在那里的组件执行测试用例,而不是针对部署在我们自己开发机器上的系统运行测试用例.这种做法有一定的优势：
（编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
