艺术~对走向前后端分离的理解

前言

截止目前，所有的新项目都优先推荐使用前后端分离的架构，在前端使用MVVM模式，后端使用分布式部署或者使用简单的MVC单体架构。

所以前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。

核心思想是前端html页面通过axios或者ajax调用后端的restuful api接口并使用json数据进行交互。

前端MVVM架构

MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。
当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。（vue的专注就是在ViewModel 的设计上）

一句话总结：vm层（视图模型层）通过接口从后台m层（model层）请求数据，vm层继而和v（view层）实现数据的双向绑定。

ViewModel 是由前端开发人员组织生成和维护的视图数据层。在这一层，**前端开发者对从后端获取的 Model 数据进行转换处理，做二次封装，以生成符合 View 层使用预期的视图数据模型。**需要注意的是 ViewModel 所封装出来的数据模型包括视图的状态和行为两部分，而 Model 层的数据模型是只包含状态的，比如页面的这一块展示什么，那一块展示什么这些都属于视图状态（展示），而页面加载进来时发生什么，点击这一块发生什么，这一块滚动时发生什么这些都属于视图行为（交互），视图状态和行为都封装在了 ViewModel 里。这样的封装使得 ViewModel 可以完整地去描述 View 层。由于实现了双向绑定，ViewModel 的内容会实时展现在 View 层，这是激动人心的，因为前端开发者再也不必低效又麻烦地通过操纵 DOM 去更新视图，MVVM 框架已经把最脏最累的一块做好了，我们开发者只需要处理和维护 ViewModel，更新数据视图就会自动得到相应更新，真正实现数据驱动开发。看到了吧，View 层展现的不是 Model 层的数据，而是 ViewModel 的数据，由 ViewModel 负责与 Model 层交互，这就完全解耦了 View 层和 Model 层，这个解耦是至关重要的，它是前后端分离方案实施的重要一环。

对开发人员而言

对于后端工程师

以前的JavaWeb项目大多数都是java程序员，使用JSP技术是又当爹又当妈，又搞前端，又搞后端。

随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人的时间毕竟是有限的，如果什么都会，那么他毕竟什么都不精。

大中型公司需要的是专业人才，小公司需要全才，但是对于个人职业发展来说，我建议是分开，开始阶段专功某一个方向，后期再去往全面发展。

把精力放在编程基础，设计模式，原理，源码，linux，mysql事务隔离与锁机制，mongodb，http/tcp，多线程，分布式架构，弹性计算架构，微服务架构，性能优化，以及相关的项目管理等等。

目前后端追求的是：三高（高并发，高可用，高性能），安全，存储，业务等等。

所以分离对后端程序员来说绝对是好事！！！

对于前端工程师

把精力放在html5，css3，jquery，angularjs，bootstrap，reactjs，vuejs，webpack，less/sass，gulp，nodejs，Google V8引擎，javascript多线程，模块化，面向切面编程，设计模式，浏览器兼容性，性能优化等等。

前端追求的是：页面表现，速度流畅，兼容性，用户体验等等。

术业有专攻，这样你的核心竞争力才会越来越高，正所谓你往生活中投入什么，生活就会反馈给你什么。并且两端的发展都越来越高深，你想什么都会，那你毕竟什么都不精。

通过将team分成前后端team，让两边的工程师更加专注各自的领域，独立治理，然后构建出一个全栈式的精益求精的team。

不分离时耦合的痛点

1. 几曾何时，我们的JavaWeb项目都是使用tomcat作为容器，前后端代码全都在那个war包里，包括你的js，css，图片，各种第三方的库，如果现在输入URL访问你的网站，浏览器在通过域名通过dns服务器找到你的服务器外网ip,将http请求发送到你的服务器，在tcp3次握手之后（http下面是tcp/ip），通过tcp协议开始传输数据，你的服务器得到请求后，开始提供服务，接收参数，之后返回你的应答给浏览器，浏览器再通过content-type来解析你返回的内容，呈现给用户。假设你的首页中有100张图片，此时，用户的看似一次http请求，其实并不是一次，用户在第一次访问的时候，浏览器中不会有缓存，你的100张图片，浏览器要连着请求100次http请求（有人会跟我说http长连短连的问题，不在这里讨论），你的服务器接收这些请求，都需要耗费内存去创建socket来玩tcp传输，所以动态资源和静态资源全部耦合在一起，服务器压力大，服务器会收到各种http请求，例如css的http请求，js的，图片的等等。一旦服务器出现状况，前后台一起玩完，用户体验极差。
2. UI出好设计图后，不仅前端工程师只负责将设计图切成html，还需要由java工程师来将html套成jsp页面，出错率较高（因为页面中经常会出现大量的js代码），修改问题时需要双方协同开发，效率低下。
3. jsp必须要在支持java的web服务器里运行（例如tomcat，jetty，resin等），无法使用nginx等（nginx据说单实例http并发高达5w，这个优势要用上），性能提不上来。
4. 第一次请求jsp，必须要在web服务器中编译成servlet，第一次运行会较慢。
5. 每次请求jsp都是访问servlet再用输出流输出的html页面，效率没有直接使用html高。
6. 如果jsp中的内容很多，页面响应会很慢，因为是同步加载。

开发模式的转变

以前老的方式是：

1、产品经历/领导/客户提出需求

2、UI做出设计图

3、前端工程师做html页面

4、后端工程师将html页面套成jsp页面（前后端强依赖，后端必须要等前端的html做好才能套jsp。如果html发生变更，就更痛了，开发效率低）

5、集成出现问题

6、前端返工

7、后端返工

8、二次集成

9、集成成功

10、交付

新的方式是：

1、产品经历/领导/客户提出需求

2、UI做出设计图

3、前后端约定接口&数据&参数

4、前后端并行开发（无强依赖，可前后端并行开发，如果需求变求变更，只要接口&参数不变，就不用两边都修改代码，开发效率高）

5、前后端集成

6、前端页面调整

7、集成成功

8、交付

请求方式的转变

以前老的方式是：

1、客户端请求

2、服务端的servlet或controller接收请求（后端控制路由与渲染页面，整个项目开发的权重大部分在后端）

3、调用service,dao代码完成业务逻辑

4、返回jsp

5、jsp展现一些动态的代码

新的方式是：

1、浏览器发送请求

2、直接到达html页面（前端控制路由与渲染页面，整个项目开发的权重前移）

3、html页面负责调用服务端接口产生数据（通过ajax等等，后台返回json格式数据，json数据格式因为简洁高效而取代xml）

4、填充html，展现动态效果，在页面上进行解析并操作DOM。

大量并发浏览器请求—>web服务器集群(nginx)—>应用服务器集群(tomcat)—>文件/数据库/缓存/消息队列服务器集群

同时又可以玩分模块，还可以按业务拆成一个个的小集群，为后面的架构升级做准备。

前后端分离的优势

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

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

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

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

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

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

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

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

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

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

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

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

做进步一优化

1. 对于js，css，图片这类的静态资源可以考虑放到类似于阿里云的oss这类文件服务器上（如果是普通的服务器&操作系统，存储在到达pb级的文件后，或者单个文件夹内的文件数量达到3-5万，io会有很严重的性能问题），再在oss上配cdn（全国子节点加速），这样你页面打开的速度像飞一样， 无论你在全国的哪个地方，并且你的nginx的负载会进一步降低。
2. 如果你要玩轻量级微服务架构，要使用nodejs做网关，用nodejs的好处还有利于seo优化，因为nginx只是向浏览器返回页面静态资源，而国内的搜索引擎爬虫只会抓取静态数据，不会解析页面中的js，这使得应用得不到良好的搜索引擎支持。同时因为nginx不会进行页面的组装渲染，需要把静态页面返回到浏览器，然后完成渲染工作，这加重了浏览器的渲染负担。浏览器发起的请求经过nginx进行分发，URL请求统一分发到nodejs，在nodejs中进行页面组装渲染；API请求则直接发送到后端服务器，完成响应。
3. 如果想玩多端应用，注意要去掉tomcat原生的session机制，要使用token机制，使用缓存（因为是分布式系统），做单点，对于token机制的安全性问题，可以搜一下jwt。
4. 前端项目中可以加入mock测试（构造虚拟测试对象来模拟后端，可以独立开发和测试），后端需要有详细的测试用例，保证服务的可用性与稳定性。