重庆市住房和城乡建设厅官方网站查询,江苏省建设职业中心网站,做公司网站需要准备什么资料,快手小程序入口云 端模式成为当前前端开发的新风向#xff0c;由此而来的 Serverless 正帮助前端工程师提升开发能力和效率。InfoQ 记者在近日有幸在 2019ArchSummit 全球架构师峰会北京站采访到了阿里高级前端技术专家杜欢#xff08;风驰#xff09;#xff0c;他为我们详细梳理了阿里… 云 端模式成为当前前端开发的新风向由此而来的 Serverless 正帮助前端工程师提升开发能力和效率。InfoQ 记者在近日有幸在 2019ArchSummit 全球架构师峰会北京站采访到了阿里高级前端技术专家杜欢风驰他为我们详细梳理了阿里这两年在前端工程化的过程中使用云 端的 Serverless 来探索前端演进过程的经验和体会。 InfoQ杜老师您好请您介绍一下您的从业经历以及目前在阿里云战略 合作部负责的工作。
杜欢风驰目前我在阿里云战略合作部负责阿里云的开发者业务更多的是在考虑怎么在云的时代帮助整个广大的开发者社区和生态能够在成为云时代原住民开发者的状态下有个更好的开发环境。
InfoQ您从事前端工作多久了对这个行业有过哪些困惑与思考
杜欢风驰我其实进入到前端行业还是很有趣的一个过程我最早是在 2001 年左右开始接触到 Web 开发。那个时候就是做网站做网站前端、后端、数据库然后发布运维都要做。那个时候其实也没有现在这么多岗位基本上就一个岗位——开发所有的事情都做。
后来随着公司业务的拓展开始去接一些 Browser 端的工作当时有一个词叫做 BS它和 CS 是对应的CS 叫 Client Side就是客户端。Client 和 Server就是客户端和 Server。BS 是 Browser 和 Server。从那个时候开始这种 BS 结构的应用出现这种结构的出现其实当时是为了解决开发成本和部署成本的问题。就是有些企业想做一个系统这个系统可以很容易地让整个企业内部不同的团队、不同的角色很好地利用部署的成本不要那么高开发成本也不要那么高。
所以那个时候开始有这种业务类型出现这种业务类型操作的主要界面就在 Browser 端那 Browser 端就会遇到一个很大的挑战也就是说你的操作行为、表现、习惯跟原来传统的客户端软件开发的那种操作体验是不太一样的。因为 Browser 是浏览器。浏览器里边就是很有限的几个元素 API。然后主要客户就会提一些要求说你需要帮我把传统的那种体验交互保留下来。因为对我而言我只是换了一个软件提供商但是我和我的同事在使用的时候不能有什么感知对他们来讲应该是一样的。
那个时候遇到的挑战是在浏览器里如何实现和传统的开发软件里的 UI、组件一样的行为。举个例子比如说你在搜索框里输入任何一个字符它会有下拉提示这是非常常见的一个 UI但在那个时候是没有的。这个 UI 至今也是没有原生提供的都是前端去模拟出来的。
所以那个时候我做的就是这些事情。做着做着我发现挑战非常大相当于你要完全模拟出一套传统的开发体系里的整个 UI 体系。那个时候就想我能不能把这个做得更好一点。所以慢慢地开始加入到前端的一些社区。认识了当时的一些朋友。就这样进入到前端行业一直做到今天。
InfoQ前端的发展很快在研发体系的升级上阿里云是如何部署的
杜欢风驰 前端升级确实是让人又爱又恨的。而且这种升级在我看来比如说框架层它可能要解决的是一些新的研发形态但是对业务而言它其实并没有很大规模地解决上一个阶段遇到的问题。
举个研发效率的例子比如我们现在做工程化、框架的演进和最早用 jquery 的时候相对业务而言有什么变化吗没有什么变化。而且有时候反而使你的整个协同成本、交付成本、人力成本在一定程度上变高了。因为你引入了工程的概念你就要去做工程化工程化不是所有人都能做得很深入。因为工程化本身就是一个领域所以你又得为了把工程化做好去准备一些特定的侯选人组建一个团队。相对来讲你又多了一批做业务的人业务流程又要变慢。原来可能你在 UI 上做完JS、HTML、CSS你怎么做马上就可以看到。现在你是看不到的你写完之后要编译工程化和编译完之后你可能才能看到。
我想表达的是前端不断地在演进它其实是更精细化了质量更有保障在一定程度上效率可能也有提升。但是从更宏观的角度从业务的角度来看它可能不一定真正解决了业务痛点。就比如说今天我们提到有的业务期望是人一进来马上就能干活干完活马上就能上线。从业务的视角来看前端这几年的演进可能还不是一个终态它处在一个摸索的阶段。
InfoQ所以就像您说的工程化现在还没有达到它的预期效果
杜欢风驰我们认为工程化的出现和持续演进未来一定是能帮到业务的但是它还在摸索的阶段。本身做工程化需要消耗人力、资源包括流程的新增这些其实在这个阶段是会降低业务交付效率的。所以我们也不能说它不对因为它毕竟有一个发展的过程。只是在它还没有到达终态之前不管是框架还是这种工程化的这种演进相对来讲都是比较痛苦的。
但是未来如果终态来临随着未来结合云原生 Serverless从写代码到最终发布一体化的时代来临可能所有的问题就迎刃而解了。
InfoQ我之前采访过一个专家他说前端工程化就是在做“消灭”自己的工作您怎么看
杜欢风驰我是这么理解如果是消灭自己那意味着前端这个岗位目前做的事情未来会有一个东西替代它。
那今天前端的岗位在做什么事情呢核心是在做用户交互行为的开发在普遍的基础上如果加上业务的特性用户交互行为就会有很多定制化的东西。再加上因为每一个业务都要差异化才能生存尤其是 to C 的产品类型它一定会在用户侧寻找和竞品的差异化用户侧更多的表现就是怎么让用户看起来更舒服操作起来更舒服整个体验更好。这些往往会表现在真正的用户交互行为上的差异。
这里有一个矛盾的点抽象出来的那些东西通过工程化确实能以一定的手段来替代但是差异化的东西怎么来做是不是能够完全替代这个还很难说至少今天还没有一个大家都觉得可信的方案说能够替代掉。就像今天的企业级定制开发也是类似之所以叫定制开发就是它至少在提定制的这个时间点没有一个可抽象、可覆盖它的一个通用的东西要不然它就不需要定制了就用通用的就好了。
所以我觉得工程化能够消灭那种通用抽象的东西但是定制的东西至少目前来看还不能除非未来机器学习演进到能够理解真正不同的需求并且能够把这种需求跟现有的技术体系、科学体系完整地链接起来的时候那我觉得是有机会的。
InfoQ阿里经济体的前端技术架构是什么样的它经历了哪些发展阶段可否提取几个重要的时间节点谈谈
杜欢风驰阿里经济体的前端在一定程度上至少能代表国内的前端行业发展的阶段。首先据我所知在国内前端这个岗位最早就是在阿里出现的。那个时候为什么会出现前端已经从原来的所有的应用由一个人开发变成一种用户需求导向用户觉得你这个应用虽然好但是操作起来很差或者整个体验不好所以能不能有人把这块做得更好所以在业务的需求下产生了职业精细化的要求。这个精细化的需求在前端岗位诞生的时候它的核心是把结构、表现、行为这三者做精细化的处理或演进。这是这个岗位诞生之初阿里前端在做的事情。
后来随着业务体量逐渐增大开始覆盖到的人群以及人群所在的地理位置都不太一样的时候越来越多的来自网络比较差的环境的用户会说打开特别慢体验不好那个时候又经历了做性能优化的时代。性能优化主要的目的是让不同的地理位置的用户都能够以最好的速度访问到我们的业务让大家的体验尽量是最好的。
第三个阶段Node.js 的出现为我们前面谈到的工程化提供了基础。因为做工程化意味着你要去做编译、文件处理操作一些事情这些东西需要有一种能力让它能够跑在本地跑在系统里面不只是在 Web 页面上。Node.js 当时帮助前端有能力做这件事情然后开始演进出前端如何进一步地把行为、样式、结构分离如何做模块化的设计、模块化的开发。拆开之后这个页面你就看不到了你想看到怎么把拆开的东西重新聚合起来那个时候就是通过 Node.js 做这种整体的工程化。
第一更精细化第二更精细化之后能够把它编译在一起能够看到同时去解决或优化和原来后端的协同方式。其实在这个阶段之前前端和后端的协同方式是比较粗暴的是那种交接式的。就是前端做完页面然后把产物交接给后端后端拿着前端做的页面在那些特定的区域操作比如说一个表格表格里面应该有数据前端会填一些假的数据在里面占位后端再把真实的数据塞在里面那是最早的阶段。有了工程化体系之后前端和后端的衔接就可以通过 API 的方式来做。在有 API 之前前端可以去模拟这个假数据通过约定的 API 规范之类。这是第三个阶段就是工程化带来的这种更精细化的设计、模块化的设计以及这种前后端协同的演进。
再往后的演进就是无线时代前端开始向混合开发模式演进比如几个框架的诞生。阿里内部也诞生了一些框架比如大家知道的 Weex最近的 Rax 等等。这是在 all in 无线业务背景下前端的演进。阿里内部有很多中后台的业务它有很多相对固定的结构形态其实我们在工程化上又进一步演进了就是诞生了这种中后台的研发模式。这种低代码的研发模式更多地体现在页面的搭建当我们有足够多的设计资源已经抽象好的、比较通用的、设计好的模块那么就可以简单地通过一些框架把这些模块组装在一起而不用写代码或者写很少的代码。这是中后台的演进。
现在结合云的到来企业希望通过云去提高效率。这只是一个愿望一定要经过一个技术的演进才能落地。相应地从今年年初到“双 11”我们整个阿里再一次演进了自己的技术体系升级到了 Serverless 的研发体系。它不仅可以帮助前端完成面向用户交互的开发还能够完成整个应用的开发整个应用的开发基于云计算的实时弹性的能力能够快速做好并且能够真实地在线上服务好“双 11”这么大的流量真正帮助企业实现用云来快速商业化、节约成本的初衷。
InfoQ阿里是什么时候开始采用 Serverless 的
杜欢风驰2017 年阿里就开始讨论这个事情正式启动是在 2018 年。阿里内部由于开发环境、网络的客观原因暂时不能直接使用阿里云的公共资源所以我们要内部实现一套公共云上有的 Serverless 的能力所以我们在 2018 年自己建设了这么一套能力。2019 年我们开始做上层研发的架构和模型到今年“双十一”我们正式投入使用。
InfoQ云 端是一个老生常谈的话题阿里云的云 端和其他企业的云 端有哪些不同之处
杜欢风驰为什么今天云出现了这么久大家提云 端也提了这么久提 Serverless 也提了有一段时间但是真正的实践那么少呢因为在研发实践当中还是需要很挑战的一些东西去帮助它推动。
第一个是顶层的设计因为你是研发生态而不是简单地利用云的能力去做一个任务这是不一样的两件事情。如果是利用云的能力去完成一个任务这个很简单很多人都在用。但是现在真正利用云 端利用 Serverless 的能力去帮助自己提升研发能力是没有的。问题就在于大家都缺乏对整个研发架构的改变。因为你要真正利用它研发模型要发生改变研发的流程链路也要发生改变这个大家没有参考。
今天阿里作为前期的实践者愿意分享自己的设计为大家提供参考未来真正要在自己的研发体系里实践大概要怎么设计有哪些环节哪些关键节点哪些特征等等。第二个是真正的实践如果阿里巴巴也只是停留在设计上没有拿自己的业务去实践我相信大家也缺乏信心也可能会认为这只是我们的想象但是今天我们真正地通过“双十一”这个很大的场景来考验。
其实我相信这能够给到整个行业一些信息我们不仅在思考和设计整个 Serverless整个云 端落到真正的研发模式上同时我们也通过自己的业务去验证了我们的设计是可行的。最后我们也希望不仅是分享我们的架构设计未来我们自己内部的整个研发平台能有机会通过阿里云开放给整个行业让外面整个开放的生态也能够使用。大家都使用一样的方式、一样的平台、一样的架构。
InfoQ正如您所说今年“双 11”是 Serverless 在阿里的第一次大检验取得了振奋人心的效果但是这个过程当中肯定会有一些坎坷您能分享一下这方面的经验吗
杜欢风驰最痛苦的还是 Serverless 底座的建设。我花了比较多的时间和大家讲为什么不要去自建这一层的原因是因为落地和实践 Serverless不是一个技术诉求而是一个业务诉求。为什么因为云本身是帮助企业用低成本高效快速地实现商业化技术只是为了让这个业务诉求落地是这样的一个关系所以说如果没有 Serverless 底座是很痛苦的一件事。并且如果它的能力不行基本上也是不可用的因为落地 Serverless 意味着你的所有服务都是跑在上面的。如果它挂了你的业务也挂了没有人愿意这样。
InfoQ所以说小企业可能不太适合做 Serverless
杜欢风驰小企业最好不要自己去建设 Serverless 底座资源能力。第一存在技术上的挑战第二存在资源规模化的挑战。因为 Serverless 的核心要素是它是按量使用的按量使用意味着如果今天的量很小你就用很少的资源如果今天的量很大就会给你调很多资源。“双十一”的时候流量都是亿级的流量如果你的企业内部没有按亿级做单位的这种流量的机器资源你怎么去调度这些资源给他人使用呢你没办法实现按量调度。所以小企业或者不具备这种资源规模化的企业不需要去自建 Serverless 能力不是说不能去实践 Serverless可以用公共云比如说用阿里云或其他的云。
我们遇到的最困难的也是这个事情就是内部研发网络环境和生产运行网络的问题。我们也是不互通的我们内部也很难直接在公共云环境去使用阿里云这些已有的能力。我们其实花了一年的时间在阿里内部推动不同的团队去建设 Serverless 底座。这是第一个我认为比较挑战的点。
第二整个研发模型对研发体系带来了挑战。其实很多时候这种东西一出来看起来是帮助前端拓展了边界拓展了价值能力但是相应来讲后端同学可能第一反应就是那这是不是把我革命了我就不需要干活了其实不是这样的。比如阿里的导购业务就是取数据展示的场景。这种事情让一个后端来做没有任何技术价值、技术沉淀、技术成长但是现有的研发模式就是需要有后端同学进来开发。所以其实对他们来讲Serverless 研发模式的演进有助于帮助他们往更底层演进让他们聚焦于真正需要做技术研究的部分。比如这些数据的能力、服务的能力怎么做得更好、更扎实这是我们期望看到的。但是这个研发模式乍一看如果大家没有深入了解的话就会认为对整个研发模式、研发流程挑战很大那么就需要去和大家沟通、布道讲它对每个岗位会带来的价值。
第三回到前端来讲这个东西虽然看起来很美好但如果你真正下决心要进去对每一个前端来讲是撕裂的成长。因为我们要开始知道这个业务是什么为什么要做这个业务这个业务到底服务谁关键的指标是什么怎么做。这个时候他已经从前端变成一个业务的功能整个业务都是他去开发、交付。
这是从技术准备、研发体系的协同到前端岗位的挑战三个层面的难点是我觉得印象比较深刻的可能是未来大家在实践当中都会遇到的。
InfoQ我在网上了解到有人说 Serverless 存在不适合长时间的运行应用完全依赖第三方服务缺乏调试还有构建复杂等缺点。您认同这些观点吗对于那些还没有涉足 Serverless 的人您可以帮助他们辨清这些概念吗
杜欢风驰我觉得没有什么对错。它只是提到了一些特征但是我也想从特征的角度给大家鼓鼓劲。比如说今天 CNCF就是云原生在推的事情核心就是 Serverless。Serverless 的核心特征是什么呢第一按量。也就是说先不要站在技术的角度去看站在业务角度它是按量的按量就意味着对于业务而言它是最好的资源使用方式既不会带来浪费也不会不足。第二计费方式。现在很多的方式是你买的多浪费买的少就不够而且需要再补买很难把它和你的应用扩容上去。Serverless 的计费方式是按量走的用多少付多少。另外它是平台承载的因为平台的实时弹性帮助了用户实现按量诉求。
第二关于技术实践上的复杂我觉得也只是一个阶段性的现状而已。今天整个行业还没有一个开箱即用或者说比较成熟的研发框架或研发体系、研发平台出来大家都在一个摸索的阶段就包括我们自己也是刚刚摸索实践出来并且也还不算是成熟我们也还遇到很多要去继续推动解决的问题。所以我是这么看先从业务的角度去看它一定是一个最佳的路径。阶段性的痛苦肯定是有的所以没有什么对错。
InfoQ目前国内外 Serverless 实践存在怎样的差距
杜欢风驰相对来讲国外的整个开发生态就时间上要比国内领先一点原因在于国外的主流云厂商对整个 IT 行业对整个开发生态的布道做了很多工作。国外的开发生态对云原生对 Serverless 的接受度和实践比我们要好很多并且也早很多。对他们而言这是一个先发优势。提供的早就意味着实践的多然后大家对整个 Serverless 的通用性的东西比如通用的研发环节能够去做一些沉淀和抽象所以诞生了一些像 Serverless.com 这些 Serverless 的开发框架。他们更多地是站在一个第三方的公共框架的角度来看你可能既可以用这个云厂商也可以用那个云厂商基于我的框架可以快速地去做基于我的框架框架自然会有些约束你跟着这个框架的要求去做一些动作然后你可以去实践真正实践这个 Serverless 在业务里面落地这是一些现状。
那我们今天在做的也有点类似这个事情但是我们可能不仅仅是一个开发框架而是希望把整个开发平台都开放出来。所以大家不仅仅是说云层面函数层面可以按照我们提的建议去做你甚至可以直接在我们上面去做我们希望是这样。
InfoQ明年 Serverless 有哪些更细粒度的技术值得关注
杜欢风驰当 Serverless 整个研发模式大概成形之后接下来就是实践。在实践的过程当中对渲染层、服务层、函数运行时、框架这几层可能会有一个更深入的实践产生更细节的一些需求。我理解从明年开始可能就是非常 detail 的垂直分层演进了可能会有更多的这类内容产生比如服务编排是如何演进的函数运行时是如何演进的性能是怎样提升的稳定性是怎样进一步保障好的就是又会回到一个大的运维架构演进的阶段。
InfoQ最后一个问题您预测未来 5 年前端行业会有什么变化您所在团队目前有没有针对这些技术判断做出一些布局
杜欢风驰今年阿里经济体的其他几个大的方向比如前端智能、搭建等这些都有可能串联起来成为影响整个前端行业发展趋势的一些因素。但我今天讲的更多的可能是整个研发生态的变化未来的研发模式使前端可以供整个业务具体到每一个环节比如前端可能通过 UI 的智能化让自己释放出来通过一些成熟的视觉物料、前端物料以及服务的物料通过 AI 的辅助快速地把一些原本需要前端去开发的一些模式化页面模块通过 AI 的方式自主生成。
运维这块可能随着云原生能力的不断增强工程化能力的补充未来有可能进入到 NoOps 就是不需要运维只需要关注好一些数据。因为整个弹性会跟这些数据运行的实时数据关联起来去做不同的变化。
所以整体而言未来五年对前端而言是能力价值进一步放大的五年云上 Serverless 开发能力将成为前端的“金手指”企业愿意去组建一个由云端的应用用开发工程师构成的研发团队通过研发团队结合整个云的研发体系快速地交付它的业务。同时在这个过程当中结合智能化进一步提高生产效率可能是这样一个趋势。
原文链接 本文为阿里云原创内容未经允许不得转载。
