1. 首页
  2. >
  3. 架构设计

互联网系统架构为什么要做前后端分离呢?

在现在的互联网架构中,前后端分离已经是一个非常常见的系统架构方式了,但是我们将前后端分离以后,感觉项目的架构比传统的分层架构更复杂了,需要的人力资源也更多了,甚至项目周期也变得更长了,既然看上去好处不大,为什么还要做前后端分离呢?

上面这个疑问可能是很多创业中的互联网企业疑惑的问题,而我们首先要明白,前后端分离并不是一个互联网系统必须的架构模式,任何的架构都是为业务服务的,如果业务不需要前后端分离来解决问题,只是单纯的为了前后端分离而去分离,那么势必就会有以上的疑问。

什么时候需要前后端分离呢?


我们一步一步的来看看架构的一个演进过程:

下图是一个标准的三层架构,Web-Service层通过MVC对系统进行了呈现,Business-Service层对业务进行处理,Data-Service层完成数据的交互。每一层都各司其职,而页面的呈现是交给了后端工程师来完成的(这个时候是可以不要前端工程师的)。

互联网系统架构为什么要做前后端分离呢?

由于页面的呈现交给了后端工程师,所以后端工程师除了需要深入研究业务外,还需要对交互体验、兼容性等等方面的内容进行关注,可能在前期业务并不复杂,交互需求并不是很多的时候,我们都可以轻松应付,但是随着业务的复杂度提高,交互性也越来越强,后端工程师变得苦不堪言,甚至后端的业务没有发生变化,只是页面进行调整,也需要后端工程师来搞定。

我们在人才引进的时候,也就需要越来越全能的程序员,他们既能够搞定前端的交互、兼容性,还需要对后端的各种技术非常精通,于是,人才的瓶颈出现了,我们必须解决这个问题。

于是,我们将前端和后端岗位进行了划分(注意,不是前后端分离,只是前端的岗位独立出来),这样做可以说是缓解了上面出现的问题,交互和兼容性交给了前端工程师,前端工程师将html、css、js搞定后,再拿给后端工程师。前端工程师关注于前端的事务,后端工程师关注于后端的业务,看上去好像挺好,但是慢慢的,新的问题出现了。

由于前端的修改频率远远的大于后端,特别是很多产品经理,对于交互方面有很多的想法,今天调调这里,明天调调那里,于是,就出现了后端工程师一个地方都没有改动,但是也需要合并前端的代码,然后重新编译、打包、发布、重启tomcat。

而且任何的需求,都需要前后端同时完成后才能够进行整体的调试,任何一个部分出现延期都可能导致整个进度的延期。不管是作为后端的研发还是产品经理,都会因为这个问题而被折磨得苦不堪言,于是就开始掉头发。

互联网系统架构为什么要做前后端分离呢?

但是没有关系,我们作为强大的程序员掉一点头发没什么,还能够坚持。而这个时候,业务有了发展,产品经理说,我们的系统需要有手机移动端,用户需要在手机上也能够使用。需求来了自然就需要响应,但是时间紧任务重,想要快速的实现手机端的功能就只有一个方式,那就是Copy。

手机端的业务和PC端大致都是相同的,只是在表现形式上有所不同而已,把PC端的代码Copy过来,修修改改就有一个手机端了。说干就干,于是我们的系统架构就变成了这样。


互联网系统架构为什么要做前后端分离呢?

这样做的话,我们短期的改动最小,能够快速的让项目上线,解决目前的问题,但是也会埋下隐患。

很快,新的业务需求出现,我们除了PC端和手机Web端,还需要APP,而对于手机APP来说,功能和手机web端是一模一样,不同的只是原来Mobile版本返回的html数据需要改变成json数据交给app自己做渲染。

于是,我们又把手机Web端的代码Copy出来一份,然后修修补补,变成了APP的Web Api,把原来html格式的返回变成了Json格式。

互联网系统架构为什么要做前后端分离呢?

经过产品需求的不断演进变化,在传统的三层架构下,我们的系统架构就变成了这样。


互联网系统架构为什么要做前后端分离呢?


在上面的这种架构下,APP端、PC端、Mobile端使用着几乎相同的Web端代码,唯一不同的只是前端的呈现方式。但是,Business-Service发生变化,所有的Web-Service都必须改,几乎就是把相同的代码改三次,由于代码也几乎都是Copy的,一个地方出现Bug就意味着其他地方都可能出现Bug,改完这个Bug,所有的系统都需要重新发布。

这种架构出现了大量重复的劳动,而且让系统维护的复杂度变得非常高,既然系统架构出现了痛点,自然就需要解决,怎么办呢?


互联网系统架构为什么要做前后端分离呢?

于是,前后端分离的架构就出现了,我们让后端程序员只负责提供统一的接口,而如何调用这些接口最终做数据的呈现和交互,完全交给了前端程序员用Node.js来实现,这样,后端的Web-Service避免了大量代码的Copy,只有一份代码需要维护。APP端、PC端、Mobile端需要调整的时候,也只需要管自己,重新发布也只是针对自己这个部分,不需要考虑其他端。

这样前后端就实现了解耦,也就让后端程序员能够更专注于业务和性能,不需要再为前端的事情担忧。

当然,任何的架构都是为业务服务的,我们考虑前后端分离也是一样,如果业务不是非常需要前后端分离,那么做前后端分离就是没有意义的。

例如:

  1. 我公司现在是初创阶段,人少、产品迭代的速度要快,更需要全栈的程序员,一个人能够前后端都搞定,这个时候去做前后端分离就是没有必要的,只会让系统复杂度提高,效率变低。
  2. 我的产品对于前端的要求不高,没有什么酷炫的效果,没有什么兼容性的要求,更重要的是,单纯的前端改版的时候不多,那么就放弃前后端分离吧。
  3. 公司现在的前端是传统的前端,技术体系主要还是在HTML/CSS/JS这个层面,如果去实现前后端分离,就需要前端具备后端的一些知识,学习很多新的技能,这可能很难马上改变。

总而言之,实行前后端分离的架构,和各方面因素都有关系,不能只是因为做而去做。