前后端分离架构怎么落地

￡神魔★判官ぃ 2021-09-19 15:38 427阅读 0赞

转发的一篇前后端分离框架的文章，值得一看

前后端分离本质上是工作职责的细化。这两年前后端分离的呼声越发高涨，最重要的原因在于后端工程师不能简单的完成前端方面的工作。前端这段时间以来新的技术层出不穷，这种情况下后端无法简单的掌握前端技术，即使对前端来说也有一定的负担。前端的门槛越来越高，一个人无法将所有的事情都做完，也是前后端分离的一方面因素。

典型的业务场景

前后端分离其实也并非万能良药，对应不同的业务场景情况会有所不同。同样的应用场景也有所不同，前端传统的应用场景有PC端、移动端，另外还App hybrid、小程序等。针对不同的应用场景所使用的技术都会有所不同，应用场景众多让架构复杂度变的更高。

前后端分离的优势

可以实现真正的前后端解耦，前端服务器使用nginx。前端/WEB服务器放的是css，js，图片等等一系列静态资源（甚至你还可以css，js，图片等资源放到特定的文件服务器，例如阿里云的oss，并使用cdn加速），前端服务器负责控制页面引用&跳转&路由，前端页面异步调用后端的接口，后端/应用服务器使用tomcat（把tomcat想象成一个数据提供者），加快整体响应速度。（这里需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack）

发现bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象。页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。双方互不干扰，前端与后端是相亲相爱的一家人。

在大并发情况下，我可以同时水平扩展前后端服务器，比如淘宝的一个首页就需要2000+台前端服务器做集群来抗住日均多少亿+的日均pv。

减少后端服务器的并发/负载压力。除了接口以外的其他所有http请求全部转移到前端nginx上，接口的请求调用tomcat，参考nginx反向代理tomcat。且除了第一次页面请求外，浏览器会大量调用本地缓存。

即使后端服务暂时超时或者宕机了，前端页面也会正常访问，只不过数据刷不出来而已。

也许你也需要有微信相关的轻应用，那样你的接口完全可以共用，如果也有app相关的服务，那么只要通过一些代码重构，也可以大量复用接口，提升效率。（多端应用）

页面显示的东西再多也不怕，因为是异步加载。

nginx支持页面热部署，不用重启服务器，前端升级更无缝。

增加代码的维护性&易读性（前后端耦在一起的代码读起来相当费劲）。

提升开发效率，因为可以前后端并行开发，而不是像以前的强依赖。

在nginx中部署证书，外网使用https访问，并且只开放443和80端口，其他端口一律关闭（防止黑客端口扫描），内网使用http，性能和安全都有保障。

前端大量的组件代码得以复用，组件化，提升开发效率，抽出来！

技术挑战

我们在前端方面遇到了很多的技术挑战，其中最重要的就是在大流量下要求高可用。大流量下感知人数会明显增多，所遇到的各方面问题也会增多，比如网络、接口缓慢的问题。针对大流量前端可以采用CDN方式抗住，这时后端的压力会比较大。当后端扛不住的时候，就需要前端来分担一部分压力，不能让用户感知到网页出现的问题，这种情况下高可用的要求会非常的高。第二点是所有的前端工程师都非常讨厌的问题，浏览器的兼容性要求高。还有一个比较麻烦的技术就是SEO支持，对于SEO很多技术都是不支持的，比如vue、react这样的MVVM框架是不能使用的。

前后端常用技术利弊

技术方案

我们主要使用的技术方案有四种：前端模板（Ajax + 字符串模板）、MVVM（Vue、React）、Node模板（Express + ejs）、SSR（Node + Vue SSR）。这其中最古老的方案就是Ajax + 字符串模板，它本质上是拼接字符串。

浏览器兼容

无论是服务器渲染还是平常的渲染方式都支持IE6+，使用SSR或Node做渲染在浏览器兼容方面则会比较弱。基于现代MVVM框架的技术方案，同样也处于劣势，在浏览器兼容要求较高的场合中，无法使用。

SEO支持

对于SEO有要求的网页来说，使用web模板和Vue方案，不太合适。相对来说web模板要好一点，可以在页面未渲染之前添加一些介绍之类。Node和SSR在SEO方面问题不大，它们都是服务端渲染，首屏都包含足够多的数据。

首屏渲染耗时

现在的各种技术方案中对于首屏渲染耗时，显然使用Node是最快的。毕竟它是服务端渲染，数据是由Node服务端向服务提供方获取的。SSR渲染的花费时间相对于Node会多30%-50%。Web模板和Vue都是读取数据然后加载，其中Vue的渲染耗时会更久一些。总体来看在首屏渲染耗时方面MVVM框架是最慢的。

异步接口速度

在首屏加载完成后，很多页面都会有懒加载，需要向服务端请求相应的数据接口。这方面MVVM框架和web模板是直连后端的，而Node和SSR的方案都使用Nodejs做中间层转发一次，消耗掉一部分的网络连接，多出来的是Node服务器到服务提供方的服务。

高可用

Web模板毫无疑问在高可用方面是做的最好的，只要后台服务提供方没有挂，一般来说Web模板不会出太多问题。MVVM情况会复杂一些，在浏览器兼容上要求更高，测验量也会更多，但总归有些地方会测试不到。

Node作为中间平台，不仅要关心前端CDN还要注意Node服务器会不会出现问题，这样每多一个环节在高可用方面的就会差上一些。而SSR不仅要在Node上有高可用的要求，如果还引入了前后端代码同构，同构代码就有可能会在Node上出现各种问题。基于这种情况我们认为SSR在高可用方面是最差的。

技术门槛

技术的选择上首先要考虑是否合适当前团队，不同的团队情况都会有所不同。技术门槛方面就拿校招来说一般在web模板上都不会有太大问题，Vue这样的MVVM框架可能会了解一种，但是比较熟悉的就相对少一些。Web模板和Vue至少还是在前端方面，而Node情况就有些不同，它的知识点对前端来说复杂了很多。SSR情况则更糟糕，不仅仅需要知道Node方面的知识，还需要知道同样一套代码在Node上如何运行，以及SSR框架的运行情况，这样的话门槛就会更高。

前后端分离度

使用web模板或MVVM框架至少还需要和运维等人员配合找台服务器放置页面，多少还会和后端方面有些联系。而使用Node中间件则可以独立解决所有的问题。

三个问题

在谈框架落地的时候，我总是有三个问题，第一个问题就是你的项目是否需要SEO。如果需要那么Node.js就是不二选择，但是也要面对Node.js的风险，目前Node.js极度缺少企业级工具，错误调试困难，资料也少于主流语言。

第二个问题是项目是否需要兼容IE，目前很多的前端工程师都喜欢使用前端框架。但是如果当前项目需要兼容IE，那么就可以和这些框架说再见了。

第三个问题就是是否有足够多的前端工程师。前后端分离的越彻底，前端工作量越多。如果没有足够的前端工程师，就会面临各种各样的招聘风险，即很难招到有经验的前端工程师，现阶段只能靠加班。

注意事项

相关会议前后端工程师必须全部参加，并且需要制定好接口文档，后端工程师要写好测试用例，不要让前端工程师充当你的专职测试，推荐使用chrome的插件postman或soapui或jmeter，service层的测试用例拿junit写。ps：前端也可以玩单元测试吗？

上述的接口并不是java里的interface，说白了调用接口就是调用你controler里的方法。

加重了前端团队的工作量，减轻了后端团队的工作量，提高了性能和可扩展性。

我们需要一些前端的框架来解决类似于页面嵌套，分页，页面跳转控制等功能。

如果页面上有一些权限等等相关的校验，那么这些相关的数据也可以通过ajax从接口里拿。

对于既可以前端做也可以后端做的逻辑，我建议是放到前端，为什么？因为你的逻辑需要计算资源进行计算，如果放到后端去run逻辑，则会消耗带宽&内存&cpu等等计算资源，你要记住一点就是服务端的计算资源是有限的，而如果放到前端，使用的是客户端的计算资源，这样你的服务端负载就会下降（高并发场景）。类似于数据校验这种，前后端都需要做！

前端需要有机制应对后端请求超时以及后端服务宕机的情况，友好的展示给用户。

渐进式前后端分离

在前后端分离方面整体上都是转向Node.js中间件，我们有一个人数不多的架构团队，主要负责生产各种工具和中间件为Node.js服务。对于浏览器兼容要求、可用性要求、页面性能要求都极高的电商类页面不使用前后端分离配合少量web模板。

对于浏览器兼容要求较高的活动展示页，逐渐从web模板过渡为Node模板。 核心应用型web页，可用性要求占主导的页面，过渡为Node + Vue.js方案。某些以前用Vue编写的页面现在要想兼容SEO且对性能要求高，可以渐进过渡到SSR方案。

前后端分离在团队推进中，根据团队实际情况，也应该是渐进的。架构师要严格评估风险边界，保持业务的稳定。业务开发中，多选择新业务推进高级分离方案。对于老业务改造，应该循序渐进，选择新需求。

--------------------

来源：CSDN  
转自 作者：360linker ：[https://blog.csdn.net/belalds/article/details/81571830][https_blog.csdn.net_belalds_article_details_81571830]

[https_blog.csdn.net_belalds_article_details_81571830]: https://blog.csdn.net/belalds/article/details/81571830