互联网架构，为啥要先后端分离？

通用业务服务化以后，系统的典型后端结构如上：

• web-server经过RPC接口，从通用业务服务获取数据

• biz-service经过RPC接口，从多个基础数据service获取数据

• 基础数据service经过DAO，从独立db/cache获取数据

• db/cache存储数据

随着时间的推移，系统架构并不会一成不变，业务愈来愈复杂，改版愈来愈多，此时web-server层虽然使用了MVC架构，但如下诸多痛点是否似曾相识？

• 产品追求绚丽的效果，并对设备兼容性要求高，这些需求不断折磨着使用MVC的Java工程师们（本文以Java举例）

• 不论是PC，仍是手机H5，仍是APP，应用前端展示的变化频率远远大于后端逻辑的变化频率（感谢那些喜欢作改版的产品经理），改velocity模版并非Java工程师喜欢和擅长的工做

此时，为了缓解这些问题，通常会成立单独的前端FE部门，来负责交互与展示的研发，其职责与后端Java工程师分离开，但痛点依然没有彻底解决：

• 一点点展示的改动，须要Java工程师们从新编译，打包，上线，重启tomcat，效率极低

• 原先Java工程师负责全部MVC的研发工做，如今分为Java和FE两块，须要等前端和后端都完成研发，才能一块儿调试总体效果，不只增长了沟通成本，任何一块出问题，均可能致使项目延期

更具体的，看一个这样的例子，最开始产品只有PC版本，此时其系统分层架构以下：

客户端，web-server，service，很是清晰。

随着业务的发展，产品须要新增Mobile版本，Mobile版本和PC版本大部分业务逻辑都同样，惟一的区别是屏幕比较小：

• 信息展示的条数会比较少，即调用service服务时，传入的参数会不同

• 产品功能会比较少，大部分service的调用同样，少数service不须要调用

• 展示，交互会有所区别

因为工期较紧，Mobile版本的web-server通常怎么来呢？

没错，把PC版本的工程拷贝一份，而后再作小量的修改：

• service调用的参数有些变化

• 大部分service的调用同样，少数service的调用去掉

• 修改展示，交互相关的代码

业务继续发展，产品又须要新增APP版本，APP版本和Mobile版本业务逻辑彻底相同，惟一的区别是：

• Mobile版本返回html格式的数据，APP版本返回json格式的数据，而后进行本地渲染

因为工期较紧，APP版本的web-server通常怎么来呢？

没错，把Mobile版本的工程拷贝一份，而后再作小量的修改：

• 把拼装html数据的代码，修改成拼装json数据

这么迭代，演化，发展，架构会变成这个样子：

• 端，是PC，Mobile，APP

• web-server接入，是PC站，M站，APP站

• 服务层，通用的业务服务，以及基础数据服务

这个架构图中的依赖关系是否是看上去很别扭？

• 端到web-server之间链接关系很清晰

• web-server与service之间的链接关系变成了蜘蛛网

PC/H5/APP的web-server层大部分业务是相同的，只有少数的逻辑/展示/交互不同：

• 一旦一个服务RPC接口有稍许变化，全部web-server系统都须要升级修改

• web-server之间存在大量代码拷贝

• 一旦拷贝代码，出现一个bug，多个子系统都须要升级修改

如何让数据的获取更加高效快捷，如何让数据生产与数据展示解耦分离呢？

先后端分离的分层抽象势在必行。

经过先后端分离分层抽象：

• 站点展现层，node.js，负责数据的展示与交互，由FE维护

• 站点数据层，web-server，负责业务逻辑与json数据接口的提供，由Java工程师维护

这样的好处是：

• 复杂的业务逻辑与数据生成，只有在站点数据层处写了一次，没有代码拷贝

• 底层service接口发生变化，只有站点数据层一处须要升级修改

• 底层service若是有bug，只有站点数据层一处须要升级修改

• 站点展示层能够根据产品的不一样形态，传入不一样的参数，调用不一样的站点数据层接口

除此以外：

• 产品追求绚丽的效果，并对设备兼容性要求高，再也不困扰Java工程师，由更专业的FE对接

• 一点点展示的改动，再也不须要Java工程师们从新编译，打包，上线，重启tomcat

• 约定好json接口后，Java和FE分开开发，FE能够用mock的接口自测，再也不等待一块儿联调

结论：

当业务愈来愈复杂，端上的产品愈来愈多，展示层的变化愈来愈快愈来愈多，站点层存在大量代码拷贝，数据获取复杂性成为通用痛点的时候，就应该进行先后端分离分层抽象，简化数据获取过程，提升数据获取效率，向上游屏蔽底层的复杂性。

最后再强调两点：

• 是否须要先后端分离，和业务复杂性，以及业务发展阶段有关，不可一律而论

• 本文强调的先后端分离的思路，实际状况下有多种实现方式，文章并无透彻展开实现细节

任何脱离业务的架构设计，都是耍流氓。

思路比细节重要。