【转】前后端分离介绍

我们为什么要尝试前后端分离

尝试与改变

如果你没有尝试过前后端分离的工作流程，那么可以先试想一下这样的流程改变：

把流程从 
PM：“我要这个功能”
后端：“这个先找前端做个模板”
前端：“模板做完了”
后端：“我来对接一下，这里样式不对”
前端：“我改完了”
后端：“功能交付”
PM：“春节要加这个活动”
后端：“这个先找前端改个模板”
前端：“模板做完了”
后端：“我来对接一下，这里样式不对”
前端：“我改完了”
后端：“功能交付”

变成
PM：“我要这个功能”
前端：“我要接口”
后端：“接口完成了”
前端：“我来对接一下，功能交付”
PM：“春节要加这个活动”
前端：“需要增加接口”
后端：“接口完成了”
前端：“我来对接一下，功能交付”

由此可见，前后端分离的主要概念就是：后台只需提供API接口，前端调用AJAX实现数据呈现。

现状与分歧

作为一名前端开发人员，我们应该尝试一些新颖的技术，完善每一个细节性的问题，不断突破自我。虽然前后端分离已经算不上什么新颖的技术或思路，但是目前很多后台开发人员甚至前端开发人员都没有接触过。

据我个人的了解，如果在一个部门里，部门人员全是后台开发人员，前端的一些页面也是由后台人员完成的，那么前后端分离对于他们而言可能是一片未知的领域，项目大多是前后端强耦合的，甚至不存在前端的概念。

在不重视前端的公司或部门，不了解前后端分离这也无可厚非。在我刚进入一个全是后台开发人员的部门的时候，整个部门就我一个前端，我刚开始的主要职责就是负责项目前端页面的制作和JS功能的实现，虽然部门有前后端分离的意识，但都不知该如何去实践。在那时，部门的后台人员认为前后端分离就是后台不再需要写HTML和JS了，可以交给前端来做了，然而这只能叫做前后端分工。

以上讲述的是一种情况: 不了解前后端分离，也不知如何去实践的。下面还有一种情况：了解前后端分离，但不想去尝试的。

针对第二种情况，很多人也做过相应的解释，其实这就涉及到“前后端分离的利弊”问题。很多后台人员会认为自己所做的那一套没有问题，即便后台套用前端html也是司空见惯，一直是大势所趋，后台MVC框架也是这么推荐使用的，很合理。这时候前端开发人员在部门中的话语权往往是不够的，或者认为后台开发人员的意见永远是对的，没有主观性。

相反，也有可能是后台开发人员非常推荐前后端分离，而前端开发人员不想去实践的。这时候前端会认为后台开发人员在瞎折腾，之前前后端不分离项目做起来都很顺利，分离了反而会给自己带来额外的工作量和学习成本，而这就取决于前端的技术能力和见识了。

当然，这也是我个人认为的前后端分离所存在的一些现状和分歧所在。

场景与要求

对于前后端分离的应用场景，不是所有的场景都适合，但是大多数项目都能够通过前后端分离来实现。

由于我主要从事企业级后台应用的前端开发工作，个人认为对于后台应用的开发来说，前后端分离带来的利是远大于弊的。

大多数后台应用我们都可以做成SPA应用（单页应用），而单页应用最主要的特点就是局部刷新，这通过前端控制路由调用AJAX，后台提供接口便可以实现，而且这样的方式用户体验更加友好，网页加载更加快速，开发和维护成本也降低了不少，效率明显提升。

同样的，在展示类网站和移动APP页面中前后端分离也同样试用。前后端不分离的情况下，服务端要单独针对Web端做处理，返回完整HTML，这样势必增加服务端的复杂度，可维护性差，而web端需要加载完整的HTML，一定程度上影响网页性能，这对于移动端性能为王的地方非常的不友好。

随着前端技术的发展和迭代，前端MVC框架应运而生，利用目前主流的前端框架，如React、Vue、Angular等我们可以轻松的构建起一个无需服务器端渲染就可以展示的网站，同时这类框架都提供了前端路由功能，后台可以不再控制路由的跳转，将原本属于前端的业务逻辑全部丢给前端，这样前后端分离可以说是最为彻底。下面是一段前端控制路由的代码：

'use strict'

export default function (router) {
    router.map({
        '/': {
            component: function (resolve) {
                require(['./PC.vue'], resolve)
            }
        },
        '/m/:params': {
            component: function (resolve) {
                require(['./Mobile.vue'], resolve)
            }
        },
        '/p': {
            component: function (resolve) {
                require(['./PC.vue'], resolve)
            },
            subRoutes: {
                '/process/:username': {
                    component: function (resolve) {
                        require(['./components/Process.vue'], resolve)
                    }
                }
            }
        }
    })
}

前后端分离的实现对技术人员尤其是前端人员的要求会上升一个层次，前端的工作不只是切页面写模板或是处理一些简单的js逻辑，前端需要处理服务器返回的各种数据格式，还需要掌握一系列的数据处理逻辑、MVC思想和各种主流框架。

优势与意义

对于前后端分离的意义我们也可以看做是前端渲染的意义，我主要总结了下面四点：

1.彻底解放前端

前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码，如：

<!--服务器端渲染 -->
<select>
    <option value=''>--请选择所属业务--</option>
    {% for p in p_list %}
    <option value="{{ p }}">{{ p }}</option>
    {% endfor %}
</select>

这是前后端耦合的，可读性差。

<!--前端渲染 -->
<template>
    <select id="rander">
        <option value=''>--请选择所属业务--</option>
        <option v-for="list in lists" :value="list" v-text="list"></option>
    </select>
</template>

<script>
export default {
    data: {
        return {
            lists: ['选项一', '选项二', '选项三', '选项四']
        }
    }，
    ready: function () {
        this.$http({
            url: '/demo/',
            method: 'POST',
        })
        .then(function (response) {
            this.lists = response.data.lists // 获取服务器端数据并渲染
        })
    }
}
</script>

上面是前端渲染的一段代码，前端通过AJAX调用后台接口，数据逻辑放在前端，由前端维护。

2.提高工作效率，分工更加明确

前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。

3.局部性能提升

通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。

4.降低维护成本

通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。

心得与体会

一路走来，项目一个接着一个，从一开始的后台控制路由、后台渲染页面到现在的前端控制路由、前端渲染数据，工作流程和方式都发生了很大的变化。每当遇到下面情形的时候，我都会为前后端分离带来的优势而感慨一番：

• 项目一开始制作前端页面的时候，我不再需要后台给我配置服务器环境了

• 项目的前端文件可以在需要调用后台接口的时候丢进服务器就好了，完全不需要事先放进去

• 增加一个项目页面需要配置路由的时候不再需要让后台同事给我加了，自己前端搞定

• 前端文件里不再掺杂后台的代码逻辑了，看起来舒服多了

• 页面跳转比之前更加流畅了，局部渲染局部加载非常快速

• 页面模板可以重复使用了，前端组件化开发提高了开发效率

等等。面对快速发展的前端，我们应该去适应其带来的工作方式和流程的改变，目前的前后端分离的工作方式必然是今后的趋势所在，作为一个前端开发人员，我们应当承担这个普及前端新知识和改变现状的职责。

只有尝试了才知道适不适合，只有切身体会才能辨别谁是谁非，本文并非推崇一定要前后端分离，而是希望大家在合适的应用场景下去尝试前后端分离，在丰富经验的同时或许也会擦出火花。

以上转自https://www.cnblogs.com/luozhihao/p/5761515.html

---

如果你经历过创业，经历过快速迭代业务，经历过用户量不断上涨，经历过访问并发越来越大，你一定会遇到以下系统问题：

用户访问页面越来越慢

系统性能下降，数据库扛不住，连接数经常打满，最终数据库挂掉，重启后又快速挂掉

改了一个小地方，另外一个看似不相干的地方却挂了，严重耦合

如果你没有经历过，很可能是：

没到这一步项目就死了

身在所谓的大公司，用着所谓先进的架构体系

创业初期遇到上述痛点，很容易想到“三个分离”的架构优化方案：

动静分离：能够100倍以上的提升静态页面/资源的访问速度，详见《必备，动静分离架构实践》

读写分离：能够快速的线性扩充数据库的读性能，详见《必备，读写分离架构实践》

前后分离：前台与后台的数据与访问分离，也就是本文将要重点介绍的内容

一、业务场景介绍

虚拟一个类似于“安居客”租房买房的业务场景，这个业务的数据有两大来源：

用户发布的数据

爬虫从竞对抓取来的数据

这个业务对应的系统有两类使用者：

普通用户，浏览与发布数据，俗称“前台用户”

后台用户，运营与管理数据，俗称“后台用户”

在一个创业公司，为了快速迭代，系统架构如上：

web层：前台web，后台web

任务层：抓取数据

数据层：存储数据

二、数据耦合的问题

系统两类数据源，一类是用户发布的数据，一类是爬虫抓取的数据，两类数据的特点不一样：

自有数据相对结构化，变化少

抓取数据源很多，数据结构变化快

如果将自有数据和抓取数据耦合在一个库里，经常出现的情况是：

-> 抓取数据结构变化

-> 需要修改数据结构

-> 影响前台用户展现

-> 经常被动修改前台用户展现逻辑，配合抓取升级

如果经历过这个过程，其中的痛不欲生，是谁都不愿意再次回忆起的。

优化思路：前台展现数据，后台抓取数据分离，解耦。

如上图所示：

前台展现的稳定数据，库独立

后台抓取的多变数据，库独立

任务层新增一个异步转换的任务

如此这般：

频繁变化的抓取程序，以及抓取的异构数据存储，解耦

前台数据与web都不需要被动配合升级

即使出现问题，前台用户的发布与展现都不影响

三、系统耦合的问题

上面解决了不同数据源写入的耦合问题，再来看看前台与后台用户访问的耦合问题。

用户侧，前台访问的特点是：

访问模式有限

访问量较大，DAU不达到百万都不好意思说是互联网C端产品

对访问时延敏感，用户如果访问慢，立马就流失了

对服务可用性要求高，系统经常用不了，用户还会再来么

对数据一致性的要求高，关乎用户体验的事情就是大事

运营侧，后台访问的特点是：

访问模式多种多样，运营销售各种奇形怪状的，大批量分页的，查询需求

用户量小，访问量小

访问延时不这么敏感，大批量分页，几十秒能出结果，也能接受

对可用性能容忍，系统挂了，10分钟之内重启能回复，也能接受

对一致性的要求始终，晚个30秒的数据，也能接受

前台和后台的模式与访问需求都不一样，但是，如果前台与后台混用同一套服务和结构化数据，会导致：

后台的低性能访问，对前台用户产生巨大的影响，本质还是耦合

随着数据量变大，为了保证前台用户的时延，质量，做一些类似与分库分表的升级，数据库一旦变化，可能很多后台的需求难以满足

优化思路：冗余数据，前台与后台服务与数据分离，解耦。

如上图所示：

前台和后台独立服务与数据，解耦

如果出现问题，相互不影响

通过不同的技术方案，在不同容忍度，业务对系统要求不同的情况下，可以使用不同的技术栈来满足各自的需求，如上图，后台使用ES或者hive在进行数据存储，用以满足“售各种奇形怪状的，大批量分页的，查询需求”

四、总结

创业初期，快速实施架构优化，提升性能的“三大分离”优化利器：

动静分离：能够100倍以上的提升静态页面/资源的访问速度

读写分离：能够快速的线性扩充数据库的读性能

前后分离：前台与后台的数据与访问分离

以上转自：https://baijiahao.baidu.com/s?id=1589584837059740273&wfr=spider&for=pc