在现在的互联网架构中，前后端分离已经是一种很常见的系统架构方式，但是我们前后端分离之后，感觉项目架构比传统的分层架构要复杂，需要的人力资源也多了，甚至项目周期也变长了。既然看起来好处不大，为什么还要前后端分离呢？上面的问题可能是很多创业头脑中的互联网公司都疑惑的问题，首先我们要明白，前后端分离并不是一个互联网系统必须的架构模式。任何架构都为业务服务。会有以上问题。什么时候需要前后端分离？下面一步步看一下架构的演进过程：下图是一个标准的三层架构，Web-Service层通过MVC呈现系统，Business-Service层进行业务处理，Data-服务层完成数据交互。每一层各司其职，页面的呈现交给后端工程师完成（此时可能不需要前端工程师）。由于页面的呈现交给了后端工程师，后端工程师除了要对业务进行深入研究外，还需要关注交互体验、兼容性等方面。可能前期业务不复杂，交互需求也不大。很多时候，我们可以轻松搞定，但是随着业务复杂度的增加，交互性越来越强，后端工程师就苦不堪言了。连后台业务都没变，只是页面调整了，就需要后台工程师来处理了。我们在引进人才的时候，需要越来越多的多才多艺的程序员。他们不仅可以处理前端的交互和兼容性，还需要非常精通各种后端技术。因此，人才的瓶颈就出现了。我们必须解决这个问题。因此，我们划分了前端和后端岗位（注意前后端岗位不是分开的，而是前端岗位是独立的）。这可以说是缓解了上面的问题。交互和兼容性交给前端工程师。工程师把html、css、js做好后，交给后端工程师。前端工程师专注于前端事务，后端工程师专注于后端业务。好像还好，但是慢慢的，新的问题又出现了。因为前端的修改频率远大于后端，尤其是很多产品经理对交互有很多想法，今天这里调整，明天那里调整。需要合并前端代码，然后重新编译，打包，发布，重启tomcat。而且，任何一个需求，都需要前后端同时完成后才能进行整体调试，任何一个环节的延误都可能导致整个进度的延误。不管是后端研发，还是产品经理，都会因为这个问题折磨得焦头烂额，开始掉头发。不过没关系，作为一个强悍的程序员，我们掉一点头发也没关系，还能坚持下去。这个时候业务有了发展，产品经理说我们的系统需要有移动端，用户需要能够在手机上使用。需求来了自然要响应，只是时间紧，任务重。快速实现移动端功能的方法只有一种，那就是Copy。移动端的业务与PC端的业务大致相同，只是表现形式不同。把PC端的代码复制过来，修改成有移动端的。照做就行了，所以我们的系统架构就变成了这个样子。这样做的话，我们短期内的变化是最小的，能够快速的让项目上线，解决当前的问题，但是也会埋下隐患。很快，新的业务需求出现了。除了PC端和移动web端，我们还需要一个APP。对于手机APP，功能与手机网页端完全一样。不同的是，需要将原来移动版返回的html数据改为json数据，交给app渲染。因此，我们从手机的Web端复制代码，然后修复成为APP的WebApi，并将原来html格式的返回改成Json格式。经过产品需求的不断演进和变化，在传统的三层架构下，我们的系统架构变成了这样。在上述架构下，APP、PC、Mobile使用几乎相同的web端代码，唯一不同的是前端的呈现方式。但是，当Business-Service发生变化时，必须更改所有Web-Services，这意味着将相同的代码更改3次。由于代码几乎都是复制过来的，一个地方出bug就意味着其他地方也可能出现bug。出现此错误后，所有系统都需要重新发布。这种架构涉及大量的重复劳动，使得系统维护非常复杂。既然系统架构上有痛点，自然要解决。我们应该做什么？因此，前后端分离的架构应运而生。我们让后端程序员只负责提供统一的接口，如何调用这些接口最终展示和交互数据，完全交给前端程序员用Node.js去实现。这样后端的Web-Service就避免了很多代码的Copy，只需要维护一段代码。当APP、PC、Mobile端需要调整时，您只需要自己处理，重新发布只是针对您自己的部分，不需要考虑其他终端。这样前后端解耦，让后端程序员更专注于业务和性能，而不用操心前端。当然，任何架构都是为业务服务的，在考虑前后端分离的时候也是如此。如果业务真的不需要前后端分离，那么前后端分离就没有意义了。例如：我的公司现在处于创业阶段。人少，产品迭代速度更快。我们需要全栈程序员。一个人可以同时处理前端和后端。系统的复杂性增加，效率降低。我的产品对前端要求不高，没有炫酷的效果，没有兼容性要求，更重要的是前端简单改版不多，所以还是放弃前后端分离吧——结尾。公司目前前端为传统前端，技术体系主要在HTML/CSS/JS层面。如果要前后端分离，前端需要对后端有一定的了解，学习很多新的技能，可能很难马上改过来。.总而言之，前后端分离架构的实现与多方面的因素有关，不能仅仅因为做了就做不到。
