【轉】先後端分離介紹

咱們爲何要嘗試先後端分離

嘗試與改變

若是你沒有嘗試過先後端分離的工做流程，那麼能夠先試想一下這樣的流程改變：

把流程從 
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倍以上的提高靜態頁面/資源的訪問速度，詳見《必備，動靜分離架構實踐》

讀寫分離：可以快速的線性擴充數據庫的讀性能，詳見《必備，讀寫分離架構實踐》

先後分離：前臺與後臺的數據與訪問分離，也就是本文將要重點介紹的內容

1、業務場景介紹

虛擬一個相似於「安居客」租房買房的業務場景，這個業務的數據有兩大來源：

用戶發佈的數據

爬蟲從競對抓取來的數據

這個業務對應的系統有兩類使用者：

普通用戶，瀏覽與發佈數據，俗稱「前臺用戶」

後臺用戶，運營與管理數據，俗稱「後臺用戶」

在一個創業公司，爲了快速迭代，系統架構如上：

web層：前臺web，後臺web

任務層：抓取數據

數據層：存儲數據

2、數據耦合的問題

系統兩類數據源，一類是用戶發佈的數據，一類是爬蟲抓取的數據，兩類數據的特色不同：

自有數據相對結構化，變化少

抓取數據源不少，數據結構變化快

若是將自有數據和抓取數據耦合在一個庫裏，常常出現的狀況是：

-> 抓取數據結構變化

-> 須要修改數據結構

-> 影響前臺用戶展示

-> 常常被動修改前臺用戶展示邏輯，配合抓取升級

若是經歷過這個過程，其中的痛不欲生，是誰都不肯意再次回憶起的。

優化思路：前臺展示數據，後臺抓取數據分離，解耦。

如上圖所示：

前臺展示的穩定數據，庫獨立

後臺抓取的多變數據，庫獨立

任務層新增一個異步轉換的任務

如此這般：

頻繁變化的抓取程序，以及抓取的異構數據存儲，解耦

前臺數據與web都不須要被動配合升級

即便出現問題，前臺用戶的發佈與展示都不影響

3、系統耦合的問題

上面解決了不一樣數據源寫入的耦合問題，再來看看前臺與後臺用戶訪問的耦合問題。

用戶側，前臺訪問的特色是：

訪問模式有限

訪問量較大，DAU不達到百萬都很差意思說是互聯網C端產品

對訪問時延敏感，用戶若是訪問慢，立馬就流失了

對服務可用性要求高，系統常常用不了，用戶還會再來麼

對數據一致性的要求高，關乎用戶體驗的事情就是大事

運營側，後臺訪問的特色是：

訪問模式多種多樣，運營銷售各類奇形怪狀的，大批量分頁的，查詢需求

用戶量小，訪問量小

訪問延時不這麼敏感，大批量分頁，幾十秒能出結果，也能接受

對可用性能容忍，系統掛了，10分鐘以內重啓能回覆，也能接受

對一致性的要求始終，晚個30秒的數據，也能接受

前臺和後臺的模式與訪問需求都不同，可是，若是前臺與後臺混用同一套服務和結構化數據，會致使：

後臺的低性能訪問，對前臺用戶產生巨大的影響，本質仍是耦合

隨着數據量變大，爲了保證前臺用戶的時延，質量，作一些相似與分庫分表的升級，數據庫一旦變化，可能不少後臺的需求難以知足

優化思路：冗餘數據，前臺與後臺服務與數據分離，解耦。

如上圖所示：

前臺和後臺獨立服務與數據，解耦

若是出現問題，相互不影響

經過不一樣的技術方案，在不一樣容忍度，業務對系統要求不一樣的狀況下，可使用不一樣的技術棧來知足各自的需求，如上圖，後臺使用ES或者hive在進行數據存儲，用以知足「售各類奇形怪狀的，大批量分頁的，查詢需求」

4、總結

創業初期，快速實施架構優化，提高性能的「三大分離」優化利器：

動靜分離：可以100倍以上的提高靜態頁面/資源的訪問速度

讀寫分離：可以快速的線性擴充數據庫的讀性能

先後分離：前臺與後臺的數據與訪問分離

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