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

最新推荐文章于 2024-09-16 16:38:03 发布

转载最新推荐文章于 2024-09-16 16:38:03 发布 · 620 阅读

文章标签：

13 篇文章

订阅专栏

随着业务复杂性和产品形态的增加，前后端分离成为一种有效解决数据获取复杂性和提高效率的方法。通过对站点展示层和数据层进行分层抽象，可以显著减少重复工作并加快开发流程。

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

随着时间的推移，系统架构并不会一成不变，业务越来越复杂，改版越来越多，此时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版本大部分业务逻辑都一样，唯一的区别是屏幕比较小：

由于工期较紧，Mobile版本的web-server一般怎么来呢？

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

业务继续发展，产品又需要新增APP版本，APP版本和Mobile版本业务逻辑完全相同，唯一的区别是：

由于工期较紧，APP版本的web-server一般怎么来呢？

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

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

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

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

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

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

通过前后端分离分层抽象：

这样的好处是：

除此之外：

结论：

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

最后再强调两点：

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

思路比细节重要。

阅读前序文章，“分层架构设计”的背景与来龙去脉更加清晰：

若有收获，随手帮转哟。