- 相關推薦
（轉）818前后分離的架構以及Node在其中的作用
818前后分離的架構以及Node在其中的作用
博客分類：前端科普
很久沒寫博客，但是我真是沒閑著，也沒得閑。。。Anyway，一年一篇還是要保證的。
為什么要做前后分離？
可以這樣去理解何謂前后分離，它其實是展現端和數據服務的分離。
這里第一件要做的事情就是服務端純數據接口化改造，為什么要做這件事情呢？因為多端時代已經來臨，一項數據可能需要以不同的樣子展現在PC瀏覽器中、移動瀏覽器中以及移動App中。服務端的純數據接口可以同時為多展現端服務，這顯然可以提高研發(fā)效率。
前后分離的另一個好處就是讓前后端工程師的職責更加明晰，除了單一數據源多展現端支撐之外，好的前后端分離架構還必須具備前后端基于接口定義獨立并行開發(fā)，前后端獨立發(fā)布等能力。
今天討論的內容大綱
在過去的幾年，以Backbone為代表的OPOA（One Page One Application）解決方案盛行。而如今，使用Node在服務端負責展現層的架構亦漸起燎原之勢。那么后者對于前者到底是進化、革新，還是面向不同場景的不同架構？是今天突然想寫篇文章來八一八的內容：
前后分離最徹底的方案是OPOA
OPOA適合什么場景又有什么問題
多端時代OPOA依然需要進化
Node負責展現層的“前后分離”方案又是什么
如何看待Node在其中的位置
前后分離最徹底的方案是OPOA
OPOA的架構示意圖如上，如果我們單看一個邏輯頁面（一個時間點瀏覽器中的全部內容），分析一下有幾個特點：
頁面完全由前端構建拼裝，Backbone等框架的任務是把頁面中的視圖排排好
多數情況由視圖來發(fā)起其所需的數據請求，所以會有多個Ajax請求或并行、或串行的發(fā)生
服務端的數據接口提供獨立的http服務。
為什么說OPOA是最徹底的前后分離方案？首先，這里的分離是瀏覽器端和服務端的真正分離，跟“前”與“后”這個說法更貼近：）；當然更主要是前后端的在物理位置上的鴻溝，客觀要求服務端純數據接口化的改造必須進行的徹徹底底；此外，“徹底”還表現在：OPOA額外的好處是對前端性能有幫助，復雜交互組件所需的JS和模板，無需重復加載、運行，給系統(tǒng)易用性帶來幫助。
在我們團隊負責的阿里媽媽的廣告業(yè)務系統(tǒng)中賣家后臺系統(tǒng)占據了較大的比重，應對這類產品，團隊選擇以單頁應用架構來促成前后分離。歷時三年半，十余個賣家系統(tǒng)已全部OPOA化，可以做到前后端基于接口定義并行開發(fā)、前后端獨立發(fā)布、單一數據源多展現端支撐。
OPOA適合什么場景又有什么問題
OPOA更適合一個頁面不太多，但交互復雜的系統(tǒng)。如果系統(tǒng)中的眾多頁面長的根本不一樣，多頁面間也沒有太多重復的組件，那么OPOA帶來的性能提升就很小了。而且OPOA架構本身也有著難以解決的問題：
OPOA最大的問題是搜索引擎不友好，雖然已有多種為Spider提供內容的方案，但依然對SEO有傷害，這對很多網站而言是致命的。
OPOA中復雜頁面，往往請求數較多，在PC端沒有問題，但對于移動端而言就不那么美觀了。
多端時代OPOA依然需要進化
拋開SEO不談，在多端時代，OPOA依然需要進一步進化，目標是來解決請求數較多的問題。
如上圖所示，我們要做的是“動態(tài)數據的Combo”（這樣說，是方便大家對比常見的靜態(tài)JS、CSS的Combo），即：
前端：我們需要一個動態(tài)請求管理器，將多個請求集中起來，發(fā)送給后臺服務。
后端：我們需要一個請求分解到多個子服務，再將多個子服務返回的數據Combo后返回。
Node負責展現層的“前后分離”方案又是什么
在上上小節(jié)我們分析過，如果一個系統(tǒng)多個頁面之間并沒有太多重合，頁面間沒有太多需共用的復雜的交互組件，那么OPOA就不是必須的。這時候我們還能不能做到前后分離呢？我們回到前后分離的初衷：
單一數據源多展現端支撐
前后端基于接口定義獨立并行開發(fā)
前后端獨立發(fā)布
我們基于上一張圖，而不是OPOA之前的傳統(tǒng)網頁架構去理解所謂“Node負責展現層”相關技術方案，會更容易循序漸進的發(fā)現它的實質。
無論哪種標榜“前后分離”架構服務端純數據接口化的改造都是必須的，我們做到這一點之后，在使用Node負責展現層的架構中，就還有兩個任務需要完成：
Action1：將動態(tài)請求Combo的相關邏輯，用Node實現，包括頁面多數據區(qū)塊對于數據需求的統(tǒng)一管理，以及統(tǒng)一獲取。
Action2：將Backbone等前端OPOA框架中對于路由、視圖的管理移植到Node中。
做完這兩項任務之后，在瀏覽器端的表象上，網頁從單頁應用的Web Application回歸到傳統(tǒng)的多頁Web Page模式。但是通過良好的設計，我們依然可以拿到做“前后分離”最想要的那些好處。
本文總結，以及如何看待Node在其中的位置
在多端時代，服務端純數據接口化改造是大勢所趨，這客觀上給“前后分離”提供了更大的舞臺。一個傳統(tǒng)多頁型網頁系統(tǒng)在完成服務端接口化改造之后，需要做的事情有兩個：統(tǒng)一管理構成一個頁面的所有數據需求，完成頁面拼裝并輸出。
而單就這兩個任務而言，Node應該說不是必須的。Node的異步特性，高并發(fā)能力都不足以成為其在服務端多語言競爭的環(huán)境里獲勝的核心優(yōu)勢。
我認為引入Node的優(yōu)勢有兩個：
促進前后端更好的分離，就像CSS出現之后，我們不再用標簽定義文字樣式一般，引入不同的技術、不同的語言可以讓每（轉）818前后分離的架構以及Node在其中的作用個模塊所承擔的職責更加界線清晰，進而讓服務端純接口化改造更徹底、更堅定�！扒啊迸c“后”在服務端進行分離，OPOA中瀏覽器與服務端在物理位置上的鴻溝不再存在，那么新的語言和技術是劃分邊界這一任務的繼承者。
促成前端工程師和后端工程師在開發(fā)時的解耦，面對明晰的接口定義，前端工程師可以和后端工程師并行無交集的開發(fā)，直到最后階段聯(lián)調。這可以帶來研發(fā)效率上的極大提升。
“天下武功、唯快不破”，無論是做徹徹底底的OPOA，還是用Node做展現層服務，它們所帶來的研發(fā)效率方面的提升才是架構革新的源動力。
對于前端工程師而言，還需戒躁戒躁吧，用了Node不等于“高、大、上”，我們切換至服務端做的事情與一個良好的“Backbone”類框架沒有太多本質的區(qū)別。而在前后分離之后，前端承擔的職責無疑更重了，過往我們開發(fā)完Demo就可以撒手不管的情況不再存在。特別是介入服務端研發(fā)之后，線上故障、穩(wěn)定性、安全性這些過往和前端不太挨邊兒的令人惶恐的東東都會不期而至，我感覺前端們還沒做好準備，常常都是經歷過了才有切身的體會，才會成長吧。
分享到：
來自：http://limu.iteye.com/blog/2042700
【轉818前后分離的架構以及Node在其中的作用】相關文章：
青梅抑菌作用及其抑菌成分的分離鑒定05-03
ERβ相互作用蛋白PSMC5的分離及其在ERβ信號途徑中的作用05-02
微生物谷氨酰胺轉胺酶(MTG)的分離純化05-02
發(fā)財日818發(fā)一發(fā)祝福短信07-08
學在其中樂在其中04-28
考試前后02-07
考試前后05-02
A Fast Global Node Selection Algorithm for Bearings-only Target Localization04-28