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

有水友在评论中留言问我：

沈老师，我在一家创业公司，大概有20人左右的研发团队。

团队正在推动先后端分离，我以为架构变得复杂了，项目研发周期变长了，但组长说，互联网公司都在搞先后端分离，因此咱们也要搞。

我仍是不理解，为何要进行先后端分离呀？

今天，简单说说，互联网分层架构里的先后端分离。

画外音：“别人在搞xxoo技术”必定不能成为，一家公司推进“xxoo技术”的理由。

上图，是一个典型的互联网分层架构：

（1）业务站点层：web-server；

（2）业务服务层：biz-service；

（3）基础数据服务层：data-service；

（4）数据存储层：db+cache；

 

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

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

画外音：本文以Java后端举例。

（2）不论是PC，仍是手机H5，仍是APP，应用前端展示的变化频率远远大于后端逻辑的变化频率，改velocity模版并非Java工程师喜欢和擅长的工做；

画外音：感谢那些喜欢作改版的产品经理。

 

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

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

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

画外音：你有没有被折磨过？

 

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

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

 

随着业务的发展，产品须要新增Mobile版本，Mobile版本和PC版本大部分业务逻辑都同样，区别是什么呢？

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

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

（3）展示，交互会有所区别；

 

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

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

（1）service调用的参数有些变化；

（2）大部分service的调用同样，少数service的调用去掉；

（3）修改展示，交互相关的代码；

画外音：你有没有拷贝过代码？

 

业务继续发展，产品又须要新增APP版本，APP版本和Mobile版本业务逻辑彻底相同，区别是什么呢？

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

 

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

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

（1）把拼装html数据的代码，修改成拼装json数据；

这么迭代演化，架构会进化成什么样子？

（1）端：是PC，Mobile，APP；

（2）站点应用层：是PC站，M站，APP站；

（3）服务层：通用的业务服务，以及基础数据服务；

 

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

（1）端到web-server之间链接关系很清晰；

（2）web-server与service之间的链接关系变成了蜘蛛网；

 

上述分层架构，可能存在什么问题呢？

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

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

（2）web-server之间存在大量代码拷贝；

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

 

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

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

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

（1）站点展现层：node.js，负责数据的展示与交互，由FE维护；

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

 

这样作有什么好处呢？

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

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

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

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

 

除此以外，还有其余诸多优势：

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

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

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

 

因而乎，如上图所示，架构进化了，先后端分离了。

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

 

另外要强调的是，是否须要先后端分离，和业务复杂性，业务发展阶段，人员素质模型有关，千万不可一律而论。

要实施先后端分离，如下四点是必需要考虑的。

第一点，SEO的考虑。

若是是 PC 端的站点，须要考虑是否须要强支持 SEO ，先后端分离的架构，极可能对搜索引擎的 spider 不友好，可能影响站点的收录。

固然，若是是原生 APP ，后端 node.js 只返回 json 数据，或者单页应用 SPA （对百度来讲就是一个页面），则不太须要考虑这方面的问题。

 

第二点，产品特性的考虑。

不少产品追求酷炫的前端效果，而且对前端兼容性要求很高，前端产品改版频率很高，那么先后端分离是有必要的。

不然，先后端分离只会带来更多系统架构的复杂性。

 

第三点，公司发展阶段考虑。

公司发展的初级阶段，人比较少，对产品迭代速度的要求较高，此时更多的须要一些全栈的工程师，一我的开发从前到后全搞定。若是此时实施先后端分离，将引入“联调”一说，而且增长了沟通成本比，可能致使产品迭代的速度下降。

 

第四点、人员技能考虑。

传统 FE 与后端 Java/PHP 工程师的合做方式， FE 工程师不须要有很深的后端功底，一旦引入先后端分离， node.js 层的前端同窗须要了解更多的后端知识体系，不排除有 FE 同窗对后端技能的排斥，引起人员的不稳定。

 

总之，先后端分离不仅是一个分层架构的技术决策，和SEO、产品特性、公司发展阶段、人员知识体系相关，千万不可一律而论。

 

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

但愿你们有收获。

若是你喜欢这种讲技术的方式， 扫码 一块儿玩 。

有方法论，能落地，视频讲架构

本文分享自微信公众号 - 架构师之路（road5858）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。