您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

大前端架构思考与选择

时间:2020-08-11 09:50:07  来源:  作者:

问题

  • “一云多端”成为趋势,终端类型越来越多。比如,现在PC Web网站的产品已经有了,现在想扩展App小程序... ...怎么办?一个直接能想到的方法就是在原来的基础上,为APP等增加API接口,如下图所示:
大前端架构思考与选择

 


大前端架构思考与选择

 

这样做是可以的,然而一旦遇到修改,那么要同时修改几个端的代码,很麻烦,不是很完美。

  • “前后端分离”成为趋势。一开始的PC Web网站,大多是采用服务端渲染的前后端一体化的模式。随着技术的发展,前后端分离,前端渲染逐渐成为趋势。相应地,前端开发人员也从后端团队中独立出来。

现在兴起的APP,小程序等,天生就是前后端分离的。前端,APP,小程序等各自独立成专门的团队,当然可以满足这种趋势。相应地服务端需要为每一个前端部门提供服务,在实践中常常发现,重复的内容很多,有没有办法增加复用?或者说后端能否只对接一个“大前端”部门,剩下的“大前端”部门内部自己解决?

大前端架构思考与选择

 

  • 服务端设计的API接口,面向通用服务,还是面向UI?各个端对数据的显示要求不同,给一个公共的API还是分别给不同的API?

比如,时间显示,PC端可能要求“2020-8-9”的格式,而APP端可能要求“2020/8/9”的格式,接口怎么给?

再比如,相同功能的一个接口,PC Web端需要20个字段,已经做好了。现在APP端因为屏幕小,只要10个字段就够了,是复用老的API,让APP忍受垃圾信息,还是为APP额外新增一个接口?

前端和服务端人员可能会有不同意见,这就带来了冲突。大家都有一定的道理,怎么协调?

  • 产品经理提出PRD-》UED设计交互稿-》UI设计界面-》后台设计API接口-》后台实现服务-》前后端联调... ..

架构

从现状来看,前后端分离之后,服务端直接给各种端提供服务是很自然能够想到的一种方式。这种方式的优点是简单直接,缺点是不够灵活。因此,考虑在前端和后端之间插入一个中间层,作为前后端之间的桥梁,增加灵活性。

对于这个中间层的称呼,一种是“网关层或者接入层”,这个可能会和后台现有的网关和接入层造成混淆。另一种叫法叫做BFF(Backend for Frontends,为前端而存在的后端),这种称呼相对比较准确,不会带来混淆。

  • 网关层或者接入层
大前端架构思考与选择

 

  • BFF(Backend for Frontends,为前端而存在的后端)
大前端架构思考与选择

 

解决方法

  • 针对“一云多端”,可以在BFF层做适配。可以考虑MVVM的模式,从服务器来的数据当做Model,在BFF中针对各种端,提供不同的ViewModel。如果数据变了,只要修改Model就可以了。如果要增加一种端,只要增加一个ViewModel就可以了。在这里集中修改,就可以解放各个终端的格式转化工作。
  • “前后端分离”之后,各种端可以融合为一个“大前端”,跟后端对话的窗口就是BFF。对于后端来说,只要满足BFF的数据需求就可以了,剩下的事情,就让“大前端”内部自己解决。
大前端架构思考与选择

 

  • 服务端设计的API接口,面向通用服务,不需要面向UI。各种端的UI差异,由BFF层负责适配。这样的话,可以让后端更加专注于业务逻辑和数据服务,不需要操心各种端的差异。
  • 整个开发流程太长,导致相互等待,造成浪费。针对这个问题,可以考虑在BFF层将开发流程分为两部分。“大前端”作为一个独立开发部门,领先后端一个版本发布周期。

具体做法是,对于新业务,将Mock数据生成在BFF层,对于各种端来说,相当于后端服务已经好了,可以直接进行联调,不需要等待。这样就把前端对后端的数据依赖去除了,更加灵活。

组织结构

针对上面提到的“大前端”技术架构,需要相应的“大前端”组织结构相对应。

分类思路

  • “大前端”是针对整个后端来说的,所以这一层是按照职能来分的
  • 在“大前端”下面,是否仍然按照职能来分呢?比如IOS开发,Android开发,H5开发等等。这种分法是可行的,然而收益不是很大。这只是将一个个小部门“组合成”一个相对大的部门,融合度不是很高。另外一种融合度更高的划分方法是在“大前端”下划分为“基础服务”,“业务开发”两个子部门。
大前端架构思考与选择

 

  • “基础服务”的主要职责是为整个“大前端”部门提供公共服务,公共组件,周边设施等等。根据需要和实际情况可以分为“架构”、“工具”、“组件”等小组
  • “业务开发”的主要职责完成业务部门的需求。根据业务发展情况,按照具体业务划分小组

管理

管理方式跟组织结构相适应,采用职能管理和敏捷管理相结合的方式。

职能管理

“大前端”是按照职能分的,跟后端相对应,是技术部下面的一个子部门,按照职能管理方式进行统一管理。

敏捷管理:

  • “大前端”内部,主要还是按照业务分组的,并且由于BFF的引入,“大前端”内部可以形成开发的闭环,可以考虑引入敏捷管理。
  • 要实行敏捷管理,需要产品和测试的支持。根据业务,将相关的产品、设计、测试、开发(“大前端”)组成虚拟团队。

流程

和管理模式相对应,采用瀑布模型和敏捷模型相结合的方式。

瀑布模型

职能型组织,采用瀑布模型的开发流程是合适的。产品部,技术部,测试部一般跟产品开发相关度比较大,按照瀑布模型联系起来。这里考虑前后端分离的开发模式,“大前端”可以独立完成开发闭环,虽然BFF层的数据是Mock的。
另外,大前端版本的开发要求领先后端一个版本以上,这样也方便对于后端服务的测试。简单讲,就是将通常的“后端功能推动型”改为“大前端产品拉动型”

  • 产品PRD -》交互/UI设计 -》大前端开发 -》大前端测试 -》大前端内部发布
  • 后端服务开发 -》后端测试 -》对接大前端合适版本(主要是BFF的工作,Mock数据改为从后端服务取数据) -》预发环境验证 -》产品上线

敏捷模型

产品,测试,大前端可以考虑合作,按照敏捷模型进行开发。目的是打破部门墙,加强沟通;以业务开发为共同目标,形成合力。

  • 开发周期为4周,按照1周预研、2周开发测试、1周重构的比例进行分配。
  • 1周预研:这周的主要任务是产品、测试、开发进行充分沟通,对这一期的业务目标达成共识。
    产品的主要工作是讲解需求、原型、设计,进行场景化的描述,定出优先级,确保团队成员对本期业务有正确的理解。
    测试的主要工作是进行测试用例编写,用例评审,最终通过相应工具,将测试用例数据在BFF层形成可执行的Mock数据。
    开发的主要工作是根据业务需求进行技术预研,技术选型,技术设计,任务划分,工作评估等等。完成“计划会议”所要求的内容,将开发任务分配到人。
  • 2周开发:按照敏捷的模式进行开发,将业务落地。“每日站会”要坚持开,及时沟通。开发每完成一项,测试就可以直接验证,注重效率。Mock数据由测试统一负责,开发测试用同一套数据,减少误会。这期的结束标志是2周之后的“评审会议”,开发测试向产品演示完成的业务场景。
  • 1周重构:这周对应的是敏捷开发里面的“回顾会议”,也是产品、测试、开发进行充分沟通的一周。产品在公司内部试运行一周,进行验收,收集反馈,为下一期的产品设计提供数据支持。开发一方面可以修改bug,更重要的是根据“回顾会议”的内容,进行流程改进,对“技术债”及时进行重构。也可以进行组件开发,提高今后代码的复用度。

特殊之处

Mock数据

  • 以前的Mock数据由开发自己负责,要么直接代码写死,要么借助Charles等工具。现在,将Mock数据由测试统一负责,直接生成在BFF层。
  • 以前开发要写自测代码,单元测试代码;测试设计出用例数据之后,一般通过流程工具,比如JIRA,要求开发自测。现在的模式是测试专职维护BFF上的Mock数据,将设计的用例转化为实际可用的Mock数据,开发测试用同一套标准,减少流程和沟通上的损耗。

内部版本

  • “大前端”开发测试完成的内部版本是半成品,是缺乏后台实际支撑的。内部发版之后,在内部的测试服务器上试运行。(开发版本运行在开发服务器上)。运行需要的数据由测试负责Mock。
  • 这个内部版本不能交给实际的用户使用,但是内部的产品,开发,测试可以使用,用来体验,查找bug等等。
  • 对于后端开发来说,也很便利,服务开发好之后,有现成的产品用来测试,能省很多事。
  • 向老板汇报,或者向客户展示,也很方便,有实际可用的产品可以体验,虽然数据是Mock的。这个跟看word文档,ppt,原型设计,或者UI图,感觉是完全两样的。
  • 修改成本小,一般来说,70%的工作在后台开发,30%的工作在“大前端”页面。在内部试用的那一周中,发现的问题,或者需求变更,可以非常容易的在下一个版本迭代完成。这个时候,后台服务的开发还没开始,或者刚刚开始,变更成本很小。

需求拉动

  • 以前,想开发一个功能,首先考虑的是后端逻辑是怎么样的。很多时候,要根据后端现有的逻辑,修改页面的展示,交互的顺序等等。是一种“后端功能推动的模式”
  • 现在,产品和“大前端”一起,领先后端至少一个迭代以上。遇到需求变更强烈的点,或者争论较大的点,可以考虑让内部版本运行时间长一点,比如领先两三个版本。等产品想清楚了,基本稳定了,后端再上。这样,产品思考问题的重点,就从后端现有的功能转移到客户现实需求上来。“需求拉动型开发模式”,解放了产品的思维,更容易设计出符合客户期望的产品。
  • 原来的模式是由后端推着前端走,现在的模式是产品和前端拉着后端走,思维模式是完全不一样的。
  • “大前端需求拉动型开发模式”:先有个可用的产品,搞清楚用户喜欢什么,再接上后端实现。
  • “后端功能推动型开发模式”:先做需求分析,评估现有后端功能,然后想办法满足客户需求。
  • 问题是:“客户或者用户知道自己想要什么吗?需求分析能有效吗?”。相对来讲,如果有个可用的东西,真正用起来了,用户更加容易知道自己想要什么。比如“这个颜色最好改一下”,“这里的按钮碍眼,最好去掉”,“这里我想看更多的信息,最好能加上”。诸如此类

平稳的节奏

  • 职能型组织,瀑布式开发模型,有利于控制风险,缺点是时间过长,一般项目至少1个月以上,面对需求变更能力较弱。是一种偏重计划的模式。
  • 敏捷开发模式,有利于团队沟通,时间一般较短,一般是2~4周。至于风险,考虑较少,一般是先用了再说,发现问题,下个周期再改。是一种偏重经验的模式。
  • 将这两者结合,是希望达到风险和速度的平衡,形成平稳的节奏。将敏捷模型中原本只有4小时的计划会议和回顾会议扩展为一周,是为了让跨部门沟通更充分,让产品验收更全面,降低风险。
  • 集中资源做“重要而不紧急的事情”。客户需求很重要,但从想法到落地,并没有那么快。所以发挥“大前端”灵活的优势,让客户早一点看到想法落地,可以超越客户期望。
  • “需求变更”本身,也是一种潜在的客户需求。在用上实际可用的产品前,很多时候,客户也不知道自己想要什么。所以,采用两阶段交付的方式,用总开发成本30%左右的“大前端”半成品,挖掘客户的潜在需求,可以提高客户的满意度。
  • “可用的产品胜过完备的文档”,虽然是个半成品,站在客户的角度,比word文档,原型设计等更实在,更靠谱。

重视重构

  • 技术债怎么办?是立即处理还是等累积到一定程度,再集中处理?
  • 让业务停下,专门做重构,这种机会只能说可遇而不可求。
  • 将原来敏捷中不超过4小时的回顾会议,扩展为1个星期的重构阶段,正是为了解决技术债不断累积的问题。达到“一边飞行,一边换引擎”的效果。
  • 这个阶段,产品和业务也没有停,在试用,在体验,在验证一开始的设计理念是否符合实际。这样就促成了产品和技术的双赢局面。

重视预研

  • 这里将敏捷开发中原本4小时的“计划会议”扩展为1周。
  • 敏捷模型在介绍时有个假设,那就是需求确定,原型设计,UI资源,前后端接口设计等各种资源都准备好了,相关的可行性,也就是预研都完成了,再开“计划会议”
  • 实际情况是,上面提的那些条件往往都没准备好,或者有缺失。开发在进行到一半的时候,经常发现交互逻辑不落地,要改原型。或者发现UI资源缺少,接口定义不合理等等。
  • 特别是职能型组织,跨部门沟通,这种信息缺失的事情更容易发生。
  • 在正式开发之前,花1周时间,集中进行沟通,进行技术预研,做好充分准备,将问题发现在工程开始之前,对减少不必要的返工是很有意义的。

面向BFF编程

  • BFF成了“大前端”和后端之间的抽象接口
  • BFF需要做好两边的适配
  • 可以考虑将一些公共业务也接过来,实现“轻客户端”的目标
  • 自然而然的“热更新”,BFF采用了后端的技术,做的是“大前端”的工作。有修改,更新服务,就生效了,天然的热更新。
  • 天生的“跨平台”,BFF这一个地方修改,各种端都能起作用。
  • 增加掌控力。BFF由企业维护,而各种端掌握在用户手里。将业务由各种端移到BFF,可以显著提供企业的掌控力。
    这里的边界是:“能服务端(BFF)实现的,就不要放到客户端去,除非遇到严重的性能问题”。
  • 注意性能瓶颈,这是关键节点,是前后端的对接点。并且还要注意,对接之后,Mock数据要清除干净,保证生产版本的数据是来自真正的后端。

效率和安全并重

  • “大前端”注重效率,快速响应用户的需求变更。
  • 后端注重安全,按照瀑布模型或者迭代模型,注重风险管控。
  • 通过BFF解耦,让前后端各自独立运行。

思考

  • “大前端”是最近起来的概念。和传统的前端相比,“大前端”有两个方面的扩展。一个是端的多样性,比如新增了iOS,Android,小程序,公众号等等。另外一个是往后端扩展,比如Node.js的兴起,或许写后端服务没有JAVA成熟,写BFF还是可以胜任的。
  • “大前端”是相对于传统的前端,iOS,Android,H5等独立小团队而言的。从基础服务+业务支持两个方面,促进团队的融合。在架构,工具链,组件化等几个方面提高复用,提升效率。
  • “大前端”是随着前后端分离的趋势逐步提出来的,是相对于后端来讲的,因此,要达到和后端既相互独立、减少依赖,又相互合作、沟通清晰的目标。
  • “大前端”概念最初是从阿里传出来的,后来饿了么发展最出名,现在很多公司在用,和微服务一起,接受度也在增加,成为一种趋势... ...
  • “大前端”在具体落地的时候,还没有固定的模式,各家的方案也不尽相同。有可供参考的成功案例,没有可供复制的成熟模式。需要根据自身的具体情况,摸索前进。


Tags:前端架构   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
领域驱动,各自只管各自的模块,顶层再来进行组装和分配...【详细内容】
2021-06-25  Tags: 前端架构  点击:(92)  评论:(0)  加入收藏
问题 “一云多端”成为趋势,终端类型越来越多。比如,现在PC Web网站的产品已经有了,现在想扩展APP,小程序... ...怎么办?一个直接能想到的方法就是在原来的基础上,为APP等增加API...【详细内容】
2020-08-11  Tags: 前端架构  点击:(58)  评论:(0)  加入收藏
这篇文章将简略地介绍我们当前的无线前端架构设计及其演进之路。主要内容包含以下几个部分,希望我们的经验能带给大家一些启发。1)当前的前端方案及其解决的问题2)现在面对的新...【详细内容】
2020-07-24  Tags: 前端架构  点击:(59)  评论:(0)  加入收藏
前言近来,微前端的概念非常火爆,那么什么是微前端架构?微前端架构是一种架构风格类似于微服务的架构,它将微服务的理念应用于浏览器端,即将 Web 应用由单一的单体应用转变为多个...【详细内容】
2020-02-18  Tags: 前端架构  点击:(51)  评论:(0)  加入收藏
这是帮助开发人员构建Web应用程序的三种最流行的工具。 请继续阅读,了解哪一个最适合您的需求。 在当今的发展世界中,技术正在快速增长并且变化迅速,许多开发工具似乎可以...【详细内容】
2019-09-23  Tags: 前端架构  点击:(196)  评论:(0)  加入收藏
稿件来源:https://juejin.im/post/5cea1f705188250640005472目录: 1、综合 1.1、使用场景 1.2、核心思想 1.3、切入角度 1.4、其他 2、基础层设计 2.1、自建Gitlab 2.2、版本...【详细内容】
2019-08-20  Tags: 前端架构  点击:(193)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(3)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(8)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(20)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(16)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(16)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条