微服务框架为什么首选前后端分离开发模式

        在初学Java Web开发时，通常使用JSP+Servlet完成前端视图和后端业务逻辑的开发，这种开发模式属于Model1模式，虽然实现了逻辑功能和显示功能的分离，但是视图层和控制层都是由JSP或其他后端的模板引擎技术实现的，即视图层和控制层并没有实现分离。
        随着企业应用开发理念演化和技术迭代，开发人员渐渐地摒弃这种技术选型，开始在项目中使用若干开源框架。常用的框架组合有Spring+Struts/Spring MVC+Hibernate/Mybatis等。框架的优越性及良好的封装性使得这些开发框架组合迅速成为各个企业开发中的不二之选，这些框架的出现也减少了开发者的重复编码工作，简化开发，加快开发进度，降低维护难度，随之而火热的是这些技术框架背后的开发模式，即MVC开发模式，它是为了克服Model1的不足而设计的。
        MVC的具体含义是Model+View+Controller，即模型层+视图层+控制层，如下图所示：

        Model（模型层）：常常使用JavaBean编写它，接收视图层请求的数据，之后进行相应的业务处理并返回最终的处理结果。它负担的责任最为核心，利用JavaBean具有的特性实现了代码的重用和扩展，并且维护方便。
        View（视图层）：代表和用户交互的界面，负责数据的采集和展示，通常由JSP实现。
        Controller（控制层）：从用户端接收请求，之后将请求传递给模型层并告诉模型层应该调用什么功能模块来处理该请求，它能够协调视图层和模型层之间的工作，起到中间枢纽的作用，一般交由Servlet实现。

        同时，项目开发在进行模块分层时也会分为三层：控制层、业务层和持久层。控制层负责接收参数、调用相关业务层、封装数据，以及路由并将数据渲染到JSP，并在JSP中将后台的数据展现出来。开发者对这种开发模式十分熟悉，不管是企业开发还是个人项目的搭建，这种开发模式一度成为开发者的首选。

        随着开发团队的扩大和项目架构的不断演进，传统MVC开发模式渐渐有些“力不从心”，出现诸多痛点：

痛点一：效率问题
以Java Web项目开发中的JSP技术为例。JSP必须在Servlet容器（例如Tomcat、Jetty等）中运行。在请求JSP时也需要进行一次编译过程，最后被编译成Java类和Class文件，这些都会占用JVM的内存空间，同时也需要一个新的类加载器进行加载。JSP技术与Java语言和Servlet强关联，在解耦上无法与模板引擎或纯HTML页面相媲美。另外，每次请求JSP后得到的响应都是Servlet通过输出流对象返回HTML页面，效率上没有直接使用HTML高。由于JSP与Servlet容器强关联，在项目优化时无法直接使用Nginx等吞吐量较高的Web服务器作为JSP的Web服务器，因此可供选择的优化方案不多。

痛点二：人员分工不明

MVC开发模式下的工作流程通常是设计人员提供页面原型设计后，前端工程师负责将设计图划分成HTML页面，之后由后端开发工程师将HTML页面转换为JSP页面进行逻辑处理和数据展示。在这种工作模式下，人为的出错率较高，后端开发工程师的任务更重，修改问题时需要前端工程师和后端开发工程师协同工作，效率比较低。一旦出现问题，前端工程师面对的就是充满标签和表达式的JSP，而后端开发工程师在面对样式代码或前端交互问题时，处理起来也有些吃力。在某些紧急情况下，也会出现前端工程师调试后端代码、后端开发工程师调试前端代码的现象。分工不明确且沟通成本大，一旦某些功能需要返工，就需要前后端开发人员同时在场。这种情况对前后端人员的后期技术进步也不利，后端开发工程师追求的是高并发、高可用、高性能、安全、架构优化等，而前端工程师追求的是模块化、组件整合、速度流畅、兼容性、用户体验等。MVC开发模式显然会对这些技术人员产生影响。

痛点三：不利于项目演进

在项目初期，为了快速上线应用，使用MVC开发模式进行Java Web项目开发是非常正确的选择。此时项目的流量不大，用户量也不是很多，并不会有非常苛刻的性能问题出现。但是随着项目的不断完善，用户量和请求压力也会不断增加，对互联网项目的性能要求也会越来越高，此时的前后端模块依旧耦合在一起是非常不利于后续扩展的。例如，为了提高负载能力，通常选择做集群分担单个应用的压力，但是模块的耦合会使得性能的优化空间越来越小，因为单个项目压力会越来越大，不进行合理的拆分就无法做到最好的优化；在发布上线的时候，明明只改了后端的代码，但是前端也需要重新发布，或者明明只改了部分页面或部分样式，后端代码也需要一起发布上线，这些都是耦合较严重时常见的不良现象。因此，原始的前后端耦合在一起的架构模式已经不能满足项目的演进方向，需要寻找一种解耦的方式替代当前的开发模式。

痛点四：无法满足业务发展需求

随着公司业务的不断发展，只有浏览器端的We b应用是不够的。如今，移动互联网用户数量急剧增长，手机端的原生App应用已经非常成熟，随着App软件的大量普及，越来越多的企业加入App软件开发的行列。为了尽可能地抢占商机和提升用户体验，企业不会把所有的开发资源都放在We b应用上，而是多端应用、同时开发，此时公司的业务线可能是如下几种或其中一部分：浏览器端的Web应用、iOS原生App、Android端原生App、微信小程序等丰富的前端承载端。可能只是开发其中的一部分产品，但是除Web应用能够使用传统的MVC模式开发外，其他的都无法使用该模式进行开发，像原生App或微信小程序，前端UI和用户交互部分都有各自的技术实现，再通过调用RESTful API的方式与后端进行数据交互。

        以上四个痛点亟待解决，这也是为什么需要前后端分离的几点原因。由此，演化出了前后端分离模式的相关概念。

一、前后端分离的项目开发模式

        当业务变得越来越复杂或产品线越来越多时，原有的开发模式就无法满足业务需求了。产品越来越多，展现层的变化越来越快、越来越多，此时应该进行前后端分离的分层抽象，简化数据获取过程。比如，目前比较常用的是前端人员自行实现跳转逻辑和页面交互，后端人员只负责提供接口数据，二者之间通过调用RESTful API的方式进行数据交互。如图所示：

 

        此时就不会出现HTML代码需要转换成JSP进行开发的情况，前端人员只负责前端部分，并不会掺杂后端代码，这样代码就不再耦合。同时，前端项目与后端项目也不会再出现耦合严重的现象，只要前后端人员协商和定义好接口规范及数据交互规范，双方就可以并行开发，互不干扰，业务也不会耦合，两端只通过接口进行交互。在使用MVC模式开发项目时，后端任务往往过重，“控制权”也比较大，既要负责处理业务逻辑、权限管理等后端操作，也需要处理页面跳转等逻辑。在前后端分离的模式中，后端由原来的大包大揽似的“独裁者”变成了接口提供者，而前端也不仅仅是原来那样只处理小部分业务，页面跳转也不再由后端处理和决定，整个项目的控制权已经由后端过渡至前端，前端需要处理的工作更多。

        前端项目和后端项目隔离开来、互不干涉，通过接口和数据规范完成项目功能需求，这也是目前比较流行的前后端分离开发方式。

二、前后端分离的项目人员分工模式

        前后端分离的核心就是后端负责数据和逻辑的处理，前端负责页面显示和动效的交互。在这种开发模式下，前端开发人员和后端开发人员分工明确，职责划分十分清晰，双方各司其职，不会存在边界不清晰的情况。前端开发人员通常包括Web开发人员、原生App开发人员。后端开发人员则是指Java开发人员等。
        不同的开发人员只负责自己的项目即可。后端人员专注于控制层(RESTful API)、服务层、数据访问层，前端人员专注于前端控制层、视图层，不会再出现前端人员需要维护部分后端代码，或者后端人员需要调试样式等职责不清和前后端耦合的情况。

         前后端分离后，与原有的开发模式有了较大的不同，此时就可以并行开发多端产品。在设计完成后，Web端开发人员、App端开发人员、后端开发人员都可以快速投入到开发工作中，能够做到并行开发。前端开发人员与后端开发人员职责分离，即使出现问题，也是修复各自的问题而不会互相影响和耦合，开发效率高且满足企业对多产品线的开发需求。

三、前后端分离项目部署模式

        前后端分离后，各端应用可以独立打包部署，并针对性地对部署方式进行优化，不再是将前端代码和后端代码耦合在一起，最终形成一个部署包进行部署。以Web应用为例，部署前端项目后，不再依赖Servlet容器，可以使用吞吐量更大的Nginx服务器，采用动静分离的部署方式，既提升了前端的访问体验，也减轻了后端服务器的压力，再进一步优化，可以使用页面缓存、浏览器缓存，也可以使用CDN等产品提升静态资源的访问效率。对于后端服务而言，可以进行集群部署，提升服务的响应效率，也可以进行服务化的拆分等。前后端分离后的独立部署维护及针对性的优化，可以加快整体响应速度和吞吐量。

四、前后端分离的优点和注意事项

        前后端分离模式的优点：
1）可以真正实现前后端的解耦，不仅是开发方式的改进，前后端开发人员的职责也更加清晰，对于整个技术团队有很大的益处。
2）并行开发可以有效地提升开发效率，因为可以前后端并行开发，而不再是前后端代码强依赖。
3）职责分明意味着出现问题可以快速找到负责人，不会出现互相推诿的现象。
4）前后端开发的解耦也会增加各端代码的维护性和易读性。
5）尽早地使用前后端分离的开发模式，一旦业务扩展需要进行多产品开发，如App、微信小程序等，后端接口只要进行些许的增、改即可，因为有大量的复用接口，大幅度提升效率。
6）在前端项目部署时不需要重启服务器，无缝升级。
7）分开部署会进一步减轻后端服务器的压力。

        前后端分离的开发模式虽然优点众多，但并不是所有项目或所有团队都适合前后端分离的开发模式，需要对当前的开发团队和所开发的项目进行合理的评估；比如：
1）前端开发资源是否充足
如果所在公司以往项目采用传统开发模式，即以后端MVC为主的开发模式，前端开发人员仅提供静态HTML页面，那么采用前后端分离的开发模式会将后端的控制权弱化并增强前端的控制权，也就是后端开发人员的压力会减轻，同时前端开发人员负责的工作更多了，不再是简单的交互效果和静态页面，路由规则、跳转逻辑、数据交互和页面渲染都需要考虑。现在前端技术百花齐放，组件化、模块化等都使得对前端开发人员的要求更高，所以在进行开发模式更改前一定要量力而行，在没有足够知识和人才储备的情况下不要贸然开展重构工作。

2）软件迭代周期需要慎重估算
对于中小型团队来说，一般需要比较快的软件迭代周期，此时不仅是前端开发人员配备不足，后端开发人员也不是十分充足，这种情况下采用前后端分离开发模式，增加了接口制定流程和前后端联调流程，可能会延长迭代周期。如果是项目转型，可能需要多次重构，因此不能盲目进行。

3）并不是所有的项目开发都需要前后端分离的开发模式
如果项目比较简单或一个项目需要快速开发上线，就可以采用普遍使用的MVC开发模式快速迭代。此时需要考虑的是实用性和迭代速度，在不熟悉前后端分离开发模式的情况下不要贸然做出定论。

4）前后端开发人员的沟通成本
前后端分离后，无论是API的对接还是测试工作，都涉及前后端人员的沟通。很多公司采用前后端分离开发模式后，前后端人员协作模式配合力度低、互相等待，开发效率低下，反而不如使用传统的开发模式。在笔者的理解中，“前后端分离”既是一种项目开发模式，也是一种人员分工模式，同时也是一种项目部署模式，能够使得前后端开发工作不再强耦合，提升开发人员的整体效率。

        因为前后端分离开发模式对前后端开发人员有一定的要求，所以一定要结合项目团队实际综合考虑，在有足够把握的情况下再去进行项目的重构和优化。

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

版权声明：本文为【PythonJsGo】博主的文章，同步在【猿小猴子】WeChat平台，转载请附上原文出处链接及本声明。

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