蘇寧易購：先後端分離架構的落地思考

內容來源：2017 年 12 月 3 日，蘇寧易購技術總監禹立彬在「互聯網架構峯會」進行《先後端分離架構的落地思考》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2851 | 8分鐘閱讀

嘉賓演講視頻及PPT回顧： suo.im/4WlSl9

摘要

本次分享將爲你們介紹先後端分離的存在乎義以及典型業務場景，接下來會細緻的介紹先後端分離的技術利弊，最後根據蘇寧的經驗來談一談漸進式先後端分離。

爲何要先後端分離

先後端分離本質上是工做職責的細化。這兩年先後端分離的呼聲愈加高漲，最重要的緣由在於後端工程師不能簡單的完成前端方面的工做。前端這段時間以來新的技術層出不窮，這種狀況下後端沒法簡單的掌握前端技術，即便對前端來講也有必定的負擔。

前端的門檻愈來愈高，一我的沒法將全部的事情都作完，也是先後端分離的一方面因素。

典型的業務場景

先後端分離其實也並不是萬能良藥，對應不一樣的業務場景狀況會有所不一樣。一樣的應用場景也有所不一樣，前端傳統的應用場景有PC端、移動端，另外還App hybrid、小程序等。針對不一樣的應用場景所使用的技術都會有所不一樣，應用場景衆多讓架構複雜度變的更高。

技術挑戰

咱們在前端方面遇到了不少的技術挑戰，其中最重要的就是在大流量下要求高可用。對於訪問量較小的網站，測試量並非很大，只有在極少數狀況下用戶才能感知到BUG。可是大流量下感知人數會明顯增多，所遇到的各方面問題也會增多，好比網絡、接口緩慢的問題。針對大流量前端能夠採用CDN方式抗住，這時後端的壓力會比較大。當後端扛不住的時候，就須要前端來分擔一部分壓力，不能讓用戶感知到網頁出現的問題，這種狀況下高可用的要求會很是的高。

第二點是全部的前端工程師都很是討厭的問題，瀏覽器的兼容性要求高。相信沒有人會喜歡兼容IE7的需求，可是用戶量多的狀況下總有用會使用IE7的，爲了不用戶投訴這一需求就必須獲得知足。

對於電商來講每一年要應付雙十一、雙十二、418等各類活動，這種狀況下業務的迭代速度是很是快的，架構上處理會很是麻煩。還有一個比較麻煩的技術就是SEO支持，對於SEO不少技術都是不支持的，好比vue、react這樣的MVVM框架是不能使用的。

先後端經常使用技術利弊

技術方案

咱們主要使用的技術方案有四種：前端模板（Ajax + 字符串模板）、MVVM（Vue、React）、Node模板（Express + ejs）、SSR（Node + Vue SSR）。這其中最古老的方案就是Ajax + 字符串模板，它本質上是拼接字符串。

瀏覽器兼容

不管是服務器渲染仍是日常的渲染方式都支持IE6+，使用SSR或Node作渲染在瀏覽器兼容方面則會比較弱。基於現代MVVM框架的技術方案，一樣也處於劣勢，在瀏覽器兼容要求較高的場合中，沒法使用。

SEO支持

對於SEO有要求的網頁來講，使用web模板和Vue方案，不太合適。相對來講web模板要好一點，能夠在頁面未渲染以前添加一些介紹之類。Node和SSR在SEO方面問題不大，它們都是服務端渲染，首屏都包含足夠多的數據。

首屏渲染耗時

如今的各類技術方案中對於首屏渲染耗時，顯然使用Node是最快的。畢竟它是服務端渲染，數據是由Node服務端向服務提供方獲取的。SSR渲染的花費時間相對於Node會多30%-50%。Web模板和Vue都是讀取數據而後加載，其中Vue的渲染耗時會更久一些。整體來看在首屏渲染耗時方面MVVM框架是最慢的。

異步接口速度

在首屏加載完成後，不少頁面都會有懶加載，須要向服務端請求相應的數據接口。這方面MVVM框架和web模板是直連後端的，而Node和SSR的方案都使用Nodejs作中間層轉發一次，消耗掉一部分的網絡鏈接，多出來的是Node服務器到服務提供方的服務。

高可用

Web模板毫無疑問在高可用方面是作的最好的，只要後臺服務提供方沒有掛，通常來講Web模板不會出太多問題。MVVM狀況會複雜一些，在瀏覽器兼容上要求更高，測驗量也會更多，但總歸有些地方會測試不到。

Node做爲中間平臺，不只要關心前端CDN還要注意Node服務器會不會出現問題，這樣每多一個環節在高可用方面的就會差上一些。而SSR不只要在Node上有高可用的要求，若是還引入了先後端代碼同構，同構代碼就有可能會在Node上出現各類問題。基於這種狀況咱們認爲SSR在高可用方面是最差的。

技術門檻

技術的選擇上首先要考慮是否合適當前團隊，不一樣的團隊狀況都會有所不一樣。技術門檻方面就拿校招來講通常在web模板上都不會有太大問題，Vue這樣的MVVM框架可能會了解一種，可是比較熟悉的就相對少一些。Web模板和Vue至少仍是在前端方面，而Node狀況就有些不一樣，它的知識點對前端來講複雜了不少。SSR狀況則更糟糕，不只僅須要知道Node方面的知識，還須要知道一樣一套代碼在Node上如何運行，以及SSR框架的運行狀況，這樣的話門檻就會更高。

先後端分離度

使用web模板或MVVM框架至少還須要和運維等人員配合找臺服務器放置頁面，多少還會和後端方面有些聯繫。而使用Node中間件則能夠獨立解決全部的問題。

三個問題

在談框架落地的時候，我老是有三個問題，第一個問題就是你的項目是否須要SEO。若是須要那麼Node.js就是不二選擇，可是也要面對Node.js的風險，目前Node.js極度缺乏企業級工具，錯誤調試困難，資料也少於主流語言。

第二個問題是項目是否須要兼容IE，目前不少的前端工程師都喜歡使用前端框架。可是若是當前項目須要兼容IE，那麼就能夠和這些框架說再見了。

第三個問題就是是否有足夠多的前端工程師。先後端分離的越完全，前端工做量越多。若是沒有足夠的前端工程師，就會面臨各類各樣的招聘風險，即很難招到有經驗的前端工程師，現階段只能靠加班。

漸進式先後端分離（蘇寧的經驗）

在先後端分離方面總體上都是轉向Node.js中間件，咱們有一我的數很少的架構團隊，主要負責生產各類工具和中間件爲Node.js服務。

對於瀏覽器兼容要求、可用性要求、頁面性能要求都極高的電商類頁面不使用先後端分離配合少許web模板。

對於瀏覽器兼容要求較高的活動展現頁，逐漸從web模板過渡爲Node模板。 核心應用型web頁，可用性要求佔主導的頁面，過渡爲Node + Vue.js方案。某些之前用Vue編寫的頁面如今要想兼容SEO且對性能要求高，能夠漸進過渡到SSR方案。

先後端分離在團隊推動中，根據團隊實際狀況，也應該是漸進的。架構師要嚴格評估風險邊界，保持業務的穩定。業務開發中，多選擇新業務推動高級分離方案。對於老業務改造，應該按部就班，選擇新需求。