阅读 5299

我在阿里云做前端

前言

今年是我毕业的第10个年头,半路出家做了前端,title一直是前端,你可以说我很专注,有时候也有些遗憾。一直以来,当别人问起你是做什么的,我说前端或者全栈,别人说:哦,做页面的啊!心里难免有些失落。前端是个资源型角色,在认知里对业务的理解深度不够,加上通常负责业务领域很广,比较难有积累和沉淀。如果你问一个毕业10年的JAVA老司机,他跟你谈的一定是大流量下的分布式架构,而前端可能还是昨天茶余饭后讨论vue和react,或者是angular谁更强。如何突破,如何提供业务更多价值,前端们一直在苦苦探寻。网上很多文章,给人启发,但每个人面对的环境,负责的业务不同,不一定都适用。结合自己过去几年在阿里云的前端经验,也做个总结。

1.0版本-工具&团队

今年是我来阿里云的第五个年头了,从没有想过会在一个公司呆的如此之久,更没想过我能在一个岗位上沉淀4、5年。刚入职在阿里云控制台团队,主要负责云盾控制台、drds控制台等,开发过程中发现大部分场景是「表格」、「表单」,为了避免自己不断重复开发,封装了simpleForm以及控制台cli脚手架,可以做到新开发控制台一键敲定(这个脚手架直到去年还有人问我如何用……也是经久不衰)。这个时候也萌生了做个ide,可视化搭建UI视图,不过限于精力和当时团队的方向,且当时vscode还没今天这么流行,没有尝试,比较遗憾。不过做WebIDE这个点,算是在心里种下了。

后由于组织结构调整,我从控制台团队独立出来,负责当时的网站运营方向,开始比较艰难的从0-1组件团队过程。当时业务相对比较简单,主要是:阿里云官网以及官网的Nodejs、云市场业务。由于在控制台团队主要用的angularjs,感觉上手成本比较大,在建立新团队,以及我自己可以选择的时候,React成了我的首选。当时vue还没成熟,其实能选的也只有react。新的技术体系,需要有配套的工程化体系,当时Def还处在1.0时期,为了稳定以及减少开发成本,很自然我们在xef上做了插件式开发,结合自己业务特性,分装了响应的模板,以及定制了开发周期。后由于xef1.0升级2.0,导致我们工具的不稳定,且改动非常大,逐步将我们的工程化体系独立,这就有了后续的DBL(当时叫屌爆了)。

我跟老板做汇报时,老板觉得这名字上不了大雅之堂,还硬是憋了个比较有内涵的名字——实在不好记,我现在都记不起来了。这个阶段,我们做了很多技术上的尝试,团队成员都非常苦逼,也非常有激情。团队基础设施建设,我们一直在优化,随着Dawn的基于中间件式的pipeline方式设计,可以说是将工程化做到一个比较高的高度,未来不管是webpack升级到多少,或者新的打包工具出现,对我们来说影响都比较小。面向未来的模式,让我们只需要修改内核,使用者无感知。新的工程化方案也积极跟阿里云其他团队沟通和交流,之前跟风驰和释然也达成一致意见作为阿里云统一构建工具推进,不过落地的不是很好。同时,新的方案也完全遵循集团的标准,跟淘宝阿大团队无缝对接。另外还有一个好处是:dawn不局限在react,你可以使用任何框架;dawn不局限在redux,你可以使用任何你喜欢的数据管理,实际上我们自己有用mota,mobx,graphql-apollo等等。Dawn连接:github.com/alibaba/daw…

讲完工程化,其实应该讲讲组件化,这是个无法回避的问题,但这对我们来说也是个艰难的过程。15年的时候,我们用过antd(已开源),但是在上层做了一层业务封装;后来fusion开始盛行,在跟ued沟通后,考虑到集团统一,用了一段时间的fusion(已开源);最后我们还是选择了自建组件库,这是一个很无奈的举动。具体细节不表,其中一个重要原因是我们的前台业务需要「阿里云自己的设计元素」,在经过团队很长时间的建设,APS组件库已经作为团队组建库的基础,在其之上构建了业务组件,并在之上构建了业务解决方案。

除了折腾传统前端领域,也尝试做了很多跨栈的事情。在我所负责的业务中,由于「端」业务的确实,我们更多的是偏「全栈」。前端同学做全栈,讲实话是不行的——绝大部分前端同学在架构、运维部署方面还是经验偏少,考虑更多的是跟展现层相关。在全栈路径上,由于我们负责的是核心交易链路,我们没有用大家熟悉的nodejs,而选择跟后端一样的语言——Java。做这个决策,其实是挺困难的,也是有故事的。原先有个系统,前端同学用Nodejs写的,但由于业务非常复杂,加上前端一直是个资源瓶颈的角色,一个人干三个人的活,所以这个同学最后搞不定,离职了。这么个系统就变成了后端想接无法接,前端「没人力」接的状况,非常尴尬。从那以后,业务系统中就决定了直接使用Java。

在全栈路上,我们主要有两个策略:

  • 大前端下自己写部分业务的Java
  • 利用serverless通过代理统一配置化转

大前端写 Java,阿里云其实非常多的前端都已经具备了这个能力,我自己也有独立开发几个系统从0-1上线,分布式部署且支持国际化的经历。做了一段时间后发现,其实效率上还好,并没有传说中nodejs比Java要高效很多的体感.

利用serverless通过代理统一配置化转,有段时间看社区有部分人提到Graphql,对此产生了兴趣,就顺便了解了下,通过代理的方式可以将后端数据转换成前端需要的格式,非常吸引人,也就一下子扎进去。我自己也同时做了Nodejs的版本给团队同学普及,同时做了Java版本的demo给后端普及。同时了解到b2b的Mbox平台跟我们想要的能力比较像,找过他们给我们分享,但由于业务系统整个搭建在他们平台有一定得风险,于是决定了自建代理平台,这也是「云查询」平台的背景。云查询主要是战锋主导并推进落地的,在集团内取得了不错的影响力,很多BU很多部门去做过分享。在业务上,通过云查询,我们实现了不用管应用的运维和部署,实现业务逻辑和接口的转换,并自动扩容。尤其是营销体系,在元策&隐天和战锋得协同下,取得了比较大的效率提升,并支持了阿里云去年的双十一。具体「云查询」文章介绍可以看我另外一篇文章。

云查询经过一段比较长时间的发展,我们已经逐步将它作为基础能力下沉,在云查询的serverless之上长出了不同的「轻应用」,以支持不同的垂直业务场景。比如:可视化搭建领域「页橱」、基于权限&角色的中后台解决方案「Flex」等;

还记得我之前说过5年前我想做WebIde,没有开始;2年前,看到其他云厂商有WebIDE,我们由于业务压力,业务压力没有搞成;今年我们总算是有一点启动,已经和appStudio的同学在共建,基于appStudio基础之上把我们的dawn、云查询做打通,做云端集成化、一站式的研发体验。

通过以上的技术基础建设,已经为我们构建了很好的基础基础。业务布局对应着团队、组织的建设。过去几年,团队从0-1建设,到目前xx个在岗同学,形成了4个梯队,三个3业务方向&一个技术架构方向,一路走来,感觉带团管理水很深,很多时候不是说你带的人越多越好,最近看到一本书提到一个词「情感成熟」,这个非常重要。一个技术好,做业务的好手未必能管理好团队,在不同阶段需要适应不同角色的要求,最重要的是时刻保持忧患意识、保持持续学习。在团队建设时,需要重点区分manager和leader,尤其是业务团队我们更希望成为leader,去带着做业务,而不仅仅是做绩效管理。

2.0,也就是过去一年,我们在业务思维指导下,owner了部分业务,并利用横向的技术打通、横向的业务思维,取到了一些成果,接下来进入2.0

2.0业务思维-以横向视角推进业务赋能

我们通常把组织中的人分为:一字型、|字型、T字型、+字型。前端正好是—字型团队,负责的业务非常广,而前端又是个非常稀缺的岗位,招聘很困难,所以盘子越大资源瓶颈越明显。「一字型」角色团队,典型的问题就是对业务的深度理解不够,单纯从技术层面去做营销的搭建、中后台的可视化,结果都不尽如人意。这么说起来,可能你觉得没法往下看了,天花板在那里,如何突破其实并没有太多可参考的例子。我写这篇总结,正是有些这样的感悟,希望给大家做一些输入,帮助大家去思考。

「一字型」虽然从业务上看我们的深度不够,但从专业技能看我们是标准的「|字型」。前端经过这10来年的发展,语言、框架、工具已经逐步趋于稳定,各种端的性能也越来越流畅,生态非常活跃,任何你碰到的困难相信社区都已经有比较成熟的方案。前端生态快速发展的10年,也验证了我们这些人有着非常强大的学习能力,7天一个框架、3天一个数据库估计都不是太大难事(略夸张,但表达的是这么个意思)。前端直接对接客户,对客户体验的敏感、对流程数据化的敏感、对业务逻辑流程的感知,都是我们生存的根,也是我们独一无二的能力,这个根我们不能丢。

有句话叫:饱暖思淫欲,不太恰当,姑且一比。在前端纵深领域的深耕,让我们成为了「紧缺资源」,随着工具的完善,前端们也更希望利用技术为业务赋能。如何赋能?挡在我们面前的是「意识」。在营销中,认知、需求、品牌、品类、价格五个要素中,「认知」最为重要。比如阿里是做电商的、腾讯是做社交的、百度是做搜索的,bat在自己主营业务范畴不断布局,构建了庞大的生态,做过很多尝试,但看起来最终还是围绕本身的基因做生态投资成功率要高一些。那我们想要业务赋能,瓶颈就在于「你个切页面」也要赋能吗?好好做好体验、提效不好吗?我认为「体验、提效」这是前端最核心的能力,也是毕生都努力要实现的目标,坦白讲我们没法马上解决资源瓶颈问题,毕竟现在毕业生都在应聘算法、ai、人工智能;我们也没办法搞一轮体验提升计划;这是个很漫长的过程。但如果我们能以业务的角度出发,去发现问题进而辅助以技术手段解决,并沉淀平台,应对未来千变万化的需求,可能更为实际一些。做为团队的TL,除了在专业上给与同学「|」型的能力纵深,也更希望带着团队同学获得更多业务体感。离开业务谈技术、谈中台都是空中楼阁;离开业务谈前端,注定只能是重复造轮子,而这种低水平的重复正在发生,且可能会持续很久。

在很长一段时间里,我都试图把我们「一字型」业务广度做个抽象和融合,希望把「点状」形成「线」,进而形成整体「面」解决方案。我所负责的业务中,主要有4个大方向:

  • 官网&营销—for长尾
  • 商业化流程后台-for 小二
  • 核心售卖流程—核心能力层
  • 销售、合作伙伴

官网&营销:主要包含获客、激活、转换、留存几个节点,构建高效的「人」、「货」、「场」。很长一段时间里,阿里云的内容维护、营销大促都是基于集团CMS来的。传统大促会场、卡片的方式,前端挖坑后运营编辑内容,而阿里云的「商品」跟淘系有着比较大的差别,另外我们也没有招商、选品的体系,导致这种简单人肉运行的大促方式存在很多弊端,比如不高效、不复用、不能做个性化、数据流程监控力度不够精细等。此外「投放」能力的建设还不够,没有办法做到精细化的人群做精准的营销内容投放。为了解决这些问题,去年开始,由前端团队和pd一起推进完善的营销体系建设:

  • 在原有商品的基础上,构建了「营销商品」的概念。更抽象的「货」,且可视化在线配置直接拉取了实时价格和库存。通过我们1.0工具建设的dawn,打通开发流程,使得整个开发链路一致,成本更低。可抽象的货匹配上专门为货打造的UI视图,形成场景能力沉淀。
  • 构建ACE(Alibaba Cloud Experience)架构体系,打通搭建体系,通过技术降级打通各类「场」,更好的承载好营销商品的投放。
  • 通过全链路场景的曝光,点击,转化,以及最终成交的商品信息等数据的积累,生成用户画像,提供内容场景化方案(在不同场景中精确得向用户展示商品或信息)完善「人」的定位。

商业化商品配置:上面提到「营销商品」时提到「基础商品」。目前阿里云基础商品主要分为:「公有云商品」和「技术输出型」。过去很长一段时间我们偏公有云的能力建设,今年年初才开始逐步融入专有云体系。在商业化系统中,我们的小二需要配置售卖规则、价格,需要定义商品模型;同时复杂的规格之间的约束,异常复杂。如何提高商业化的输入和输出的强体验,我们还有很长的路要走。结合今年的专有云项目,从模板的方式出发,将一类产品做个聚合,简化商品模型配置的步骤,大大提高了配置效率,提高体验。

销售&合作伙伴:15年刚开始组建团队(这里指的都是前端团队,不是业务团队),15年-18.3月大部门的核心kpi是营收、是首购用户数,主打的是中长尾客户,获得了非常高速的市场增长。后来团队cover范围不断扩大,也负责销售&合作伙伴体系,围绕着「市场营销」、「商机培育」、「商机转化」、「合同履约」构建了我们自己的销售crm系统。toC的业务通常比较好理解,毕竟我们也是c的一员。这段toB的经历,结合业务一号位的培训班,让了解到销售系统的核心,除了工具,最想要的是解决方案,是产品能力的丰富。

大概介绍了各个方向的业务,回到我们讨论的主题来——借助横向优势,整合资源&架构提供业务赋能。为了分析他们之间的共性,我们经过很多次的讨论,终于汇聚得到我们的业务流程大图(对外脱敏后的示意图):

f5c68805ec51c616fb9eda48eb994722.png

从这个流程大图中,各个分支最后都需要依赖「售卖能力」,这个售卖能力

  • 表现在营销中是「弹窗buy(减少跳出,直接购买)」、购物车(多产品交叉购买、数据算法推荐)、套餐(多产品打包优惠售卖)、提货券(下单和生产分离的售卖能力);
  • 表现在销售链路中是「产品配置清单」、「采购单」、「CBM提供给大客户的CTO价格计算器」
  • 表现在商品商业化链路中是「模板化」配置清单能力

在一大团子中找到业务的共性「售卖能力」,在经历一段时间比较耗资源、耗时的烟囱式开发方式后,抽象出了售卖的核心支持层——紫金阙。这一层,我们定位为业务中台,偏前端层面,也是大前端的领域范畴。唯一需要指出的是,我们用的是Java,没有用nodejs,无其他差别。最后架构如下(脱敏,细节忽略):

bfa37aa756650b02aaa7f9cda99ee7bd.png

新的架构模式下,我们减少了大量的前后端沟通,比如「分销采购市场」以传统开发方式需要1-2个月,我们2周就搞定了。新的架构模式,在可预见的未来,可以很好的支持各种营销新玩法,也可以支持销售和合作伙伴的『解决方案』。

我想说的是,如果没有我们全量业务的横向视角,我们的抽象方案不会这么通用,这是前端团队的优势。如果没有大前端稳定的技术生态,我们也没机会去做业务赋能。这才是前端的未来,利用横向优势整合,结合某个领域做深做透,形成垂直深度,为业务提供价值,也让我们的技术方案「有的放矢」。前端经常是围绕一个点做需求,得到工具,但无法提供解决方案,因为没有业务属性;唯有结合业务特性,做好沉淀,工具变成平台才能释放更大价值。

3.0探索以技术能力为业务提供增值

707077a00c9d4ed707e05bae815fbedb.png

「云计算」核心是解决企业成本的问题,用低成本获得超强的计算、存储能力,获得高并发下弹性扩容的能力。云计算提出了很多概念:IAAS、PAAS、SAAS。。。相对前端角色来讲,体感并不是很强。但是BAAS的出现,让前端眼前一亮。试下想,原先我们需要大量后台开发的应用,逐步都沉淀成领域能力,提供baas服务给前端调用,前端再也不用考虑部署、运维,只关心业务代码,想想也是心动。目前市面上提供类似服务的公司很多,有专门做后台数据存储的如Leancloud、有做数据分析的、有做消息推送的等。所以,Baas会是前端的春天吗?这个拭目以待。

扯了理想,我们也说说现状。目前阿里云大概是Buy In Aliyun,我们售卖的是IAAS层的资源,用户核心的业务流程还是基于自己的研发体系。在前端这个纵深领域内,基于云打造「云端一站式研发流程」,将企业前端变成:Work In Aliyun or Dev In Aliyun。通过对企业前端生命周期的分解,通过WebIDE来承载整个流程:

1. 将创建关联阿里云的code

395cfd74792f9f8dbf2b594fd508d215.png

2.阿里云前端构建工具dawn作为基础构建能力,可定制化团队构建的中间件(webpack、lint、server、mock等)、构建stage(init、dev、test、publish);基于工程化化能力提供统一的规范,提供各种不同应用框架的初始化模板。

3.代码点击发布后,自动编译,并发布到cdn。

在此基础流程之上,我们提供serverless相关能力,通过调用BaaS领域服务能力,以及FaaS网关触发能力,实际上我们可以完全一站式,且是前端主导的应用开发。

还记得我前面提到我们的serverless应用「云查询」,这一层我们逐步进行能力下沉,变成serverless基础能力。各公司几乎都有营销搭建体系,过去搭建的玩法不够多样,主要依托cms能力自行开发,随着现在各种「端」能力的延伸、多样性化,营销搭建也变得越来越复杂。而我们基于「云查询」之上沉淀出的「页橱」搭建体系,完全可以借助「云端一站式研发流程」提供很好的SAAS化服务。这是我们的优势,「云端前端解决方案」也只有我们适合做这个,这里只列举了其中一个场景,类似的机会还有很多。

总体感觉,一云多端借助serverless前端的春天已然来临。抓住我们核心的竞争力,并同时发现业务中的问题,跨端推进解决,这是最好的出路。你问我做什么的,我…… 我就是阿里云CPO(首席页面仔啊)

ps:阿里云智能业务中台&阿里通信招P6-P8前端,欢迎来撩。base可北京可杭州,杭州工位在美丽的西溪园区哦。旁边挨着的都是UED妹子&测试妹子。xiaoming.dxm@alibaba-inc.com

本文作者:阿里云高级前端技术专家 城池

原文链接:https://yq.aliyun.com/articles/695361?utm_content=g_1000049154 


关注下面的标签,发现更多相似文章
评论