前后端分离架构的一些思考

这里说的前后端分离指的是，终端（前端）和后端系统彻底分离，团队各司其职，各自迭代。现如今，随着前后端分离架构的流程，Vue、React等前端框架飞入寻常百姓家，彻底的前端开发方式已逐步成熟。本文欲简单分析前后端分离架构适用场景，不足之处欢迎交流讨论。

软件最开始，重后端，轻前端。系统的早期由一个单体系统组成，以javaee为例，后台使用springMvc，前台使用jsp或者Thymeleaf。这样研发人员基于mvc组装相关model，所有的值由controller传递给前端，从而完成相关业务。此时如果需要业务调整，需要开发人员从前端到后端统一调整，乍一看起来，开发速度也还够快。可是加上美工的介入和时间线，项目时间或许就会有相应延迟。

当系统演化到彻底前后端分离，前端团队和后端团队通过接口进行通信，需求明确后，共同讨论出接口标准和数据格式后即可按照自己的节奏安排研发工作。前端不依赖后端，所需要的数据可以使用mock模拟，后端研发完成后，只需要进行单元测试即可完成接口验证。最后系统集成时将mock入口切换至真实后台服务即可。这样的好处是，提升了各自的效率，也提升了客户和领导的满意度。

以上两种开发方式各有好处，使用的场景也有所区别。我们按照用户量和可靠性和软件预期3个方面来对比。

1、用户量。通常用户量基数大意味着并发量大，对系统要求较高，一般2C的系统或者互联网应用，用户多，对系统要求更高。而未前后端分离的系统就会面临系统性能瓶颈，扩展较差，系统性能优化技术有限的问题。而彻底的前后端分离，后端可以服务化，使用不同的语言和架构，采用高性能部署机制来保证系统的高可用。

2、可靠性。可靠性是相对的一个概念，比如一般的企业内部应用，不需要那么高的可靠性。采用非前后端分离架构更适合系统升级部署，如果为了系统性能，只需要简单部署几个节点负载均衡即可满足要求。一般企业容忍内部系统的短暂停机，而互联网应用或者2C应用，有可能24小时有用户使用，不能容忍系统停机（当然有些重要的企业或者应急救护部门也不可以停机运维）。前后端分离系统可以通过流量控制来进行分离升级，保证系统能平稳升级且不停机。

3、软件预期。一般软件项目都有明确的目标。在项目的角度，只需要完成一定的预期即完成，而产品则不然。一般企业内部生产ERP或者财务软件等大型应用，由于其自身业务的复杂和繁琐工作流，使用前后端分离的架构有可能还会增加系统设计的复杂性，而采用单体化对于屏蔽系统的复杂性说不定还有一定的优势。市面上，很少看到大型的ERP软件采用前后端分离的架构，反而基本采用单机架构，有可能未来会走上分离的道路。

综上所述，在什么情况下采用前后端分离架构？以什么样的姿势使用前后端架构？这是各位技术人员需要考虑的，什么样的场景适合什么样的架构？不是为了分离而分离，因地制宜一定是最好的。万一应用遇到了瓶颈，也可以通过演化来改造系统。

以上思考来自于本文作者，如有雷同，不甚荣幸，如有不苟，欢迎交流。