前后端分离-分离技术在l-乳酸分离中的应用

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

典型业务场景

事实上，前后端分离并不是万能的，不同的业务场景情况也会有所不同。 同样的应用场景也是不一样的。 传统的前端应用场景包括PC和移动端，以及App混合和小程序。 不同的应用场景所使用的技术会有所不同，应用场景众多，使得架构更加复杂。

前后端分离的优势

可以实现前后端真正的解耦，前端服务器使用nginx。 前端/WEB服务器放css、js、图片等一系列静态资源，服务器负责控制页面引用&跳转&路由。 前端页面异步调用后端接口，后端/应用服务器使用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 + String Templates，它本质上是连接字符串。

浏览器兼容

服务器渲染和普通渲染方式都支持IE6+。 使用 SSR 或 Node 进行渲染在浏览器兼容性方面相对较弱。 基于现代MVVM框架的技术方案也处于劣势，不能用于对浏览器兼容性要求高的场合。

搜索引擎优化支持

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

首屏渲染耗时

目前的技术方案中，首屏渲染比较耗时，显然使用Node是最快的。 毕竟是服务端渲染，数据是从Node服务器获取到服务提供者的。 SSR 渲染比 Node.js 多花费 30%-50% 的时间。 web模板和vue都是读取数据然后加载，vue的渲染时间会更长。 总体来说，MVVM框架在首屏渲染耗时上是最慢的。

异步接口速度

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

高可用性

就高可用性而言，Web 模板无疑是最好的。 只要后台服务提供者没有被挂起，一般来说Web模板是不会有问题的。 MVVM的情况会更复杂，对浏览器兼容性的要求会更高，测试量也会更多，但总有一些地方无法测试。

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

技术门槛

技术的选择首先要考虑是否适合现在的团队，不同团队的情况会有所不同。 在技​​术门槛上，以校招为例。 一般网页模板不会有太大问题。 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，服务层测试用例用junit编写。 ps：前端也能玩单元测试吗？

上面的接口不是java中的接口。 说白了，调用接口就是调用你控制器中的方法。

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

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

如果页面上有一些权限等相关检查，那么这些相关数据也可以通过ajax从接口中获取。

对于前端和后端都可以做的逻辑，我建议放在前端。 为什么？ 因为你的逻辑是需要计算资源来计算的前后端分离，如果放在后端运行逻辑，会消耗带宽、内存、cpu等计算资源，你要记住，服务器端的计算资源是有限的，而如果放在前端，使用客户端的计算资源，这样你的服务端负载就会下降（高并发场景）。 类似于数据校验，前后端都要做！

前端需要有一种机制来处理后端请求超时和后端服务宕机，并以友好的方式展示给用户。

渐进式前后端分离

在前后端分离方面，我们一般会转向Node.js中间件。 我们有一个小型的架构团队，主要负责制作各种工具和中间件来服务于 Node.js。 对于浏览器兼容性要求、易用性要求、页面性能要求极高的电商页面，不要使用前后端分离和少量网页模板。

对于浏览器兼容性要求高的活动展示页面，逐步从Web模板过渡到Node模板。 对于可用性要求占主导地位的核心应用网页，过渡到 Node + Vue.js 解决方案。 一些以前用Vue写的页面，如果要兼容SEO，对性能要求高，可以逐步过渡到SSR方案。

前后端分离应该在团队推进的过程中循序渐进，根据团队的实际情况。 架构师必须严格评估风险边界以保持业务稳定性。 在业务发展上，选择更多新业务推广先进的分离解决方案。 对于老业务的改造前后端分离，要选择新的需求，循序渐进。