系統架構：Web應用架構的新趨勢---前端和後端分離的一點想法（轉）

      原文地址：http://www.cnblogs.com/sharpxiajun/p/3531665.html ，感謝博主

      最近研究servlet，看書時候書裏講到了c/s架構到b/s架構的演變，講servlet的書都很老了，如今的b/s架構已經不是幾年前的b/s架構，其實b/s架構就是web應用開發，對於這樣的架構咱們如今應該考慮的是前端和後端的分離（注意：這裏的後端是指服務端）。

　　Web前端如今是一個獨立的技術工種，這個工種的產生主要是針對互聯網行業的需求，我在之前的文章裏曾經講到過，一個大型互聯網網站，例如想淘寶網，它絕對不是一個Web項目，而是一羣web項目的集合，那麼若是不在前端進行整合，這麼多web項目前端開發必定存在大量重複勞動，而且運維時候也存在難以統一管理的問題。本文假想一個面對須要前端資源整合的組織，如何作到先後端分離的解決思路。本文詳情以下：

 

(一) 先後端分離的目的和做用

 

　　作Web開發也能夠說是B/S架構開發，B端和S端從技術體系角度而言異構性很大，換而言之就是B端使用的技術和S端使用的技術不適於同一個體系，這樣的結果致使實際開發中，很難作到專業分工，若是項目開發過程當中管控不到位，這樣的問題可能會影響到整個項目的開發質量，所以先後端分離的目的之一就是要作到專業化分工，提升項目的質量和開發效率。

 

　　隨着技術的發展，當下的Web開發形勢已經和之前有了很大的不一樣，早期的Web項目是一個封閉的項目，用戶從瀏覽器裏看到的頁面直到後臺數據庫都是在一個項目裏集成的，而如今Web系統的規模愈來愈大，中大型的Web系統是一個開放式的系統，開放型的系統用戶在瀏覽器發起的請求可能會轉發到外部的系統裏進行處理，或者是本地的系統和外部系統一塊兒完成請求的處理，此外有的請求可能不會直接請求數據庫，而是請求緩存服務器，這些變化幾乎都是發生在Web系統的服務端，先後端耦合度很高的Web系統服務端的複雜度提高必然帶來了Web前端的複雜度的提高。所以Web前端從系統架構的角度也須要更加專業的管控，管控的做用之一就是先後端進行分離，下降前端對服務端的依耐性。

 

　　富客戶端應用的普及致使Web前端技術開發更加專業化，Web前端工程師成爲一個獨立的技術崗位，Web前端開發技術的難度也愈來愈高，先後端的分離就是爲Web前端開發營造一個良好的開發環境，不要讓前端工程師被一些不可控的外在因素所影響（例如：先後端的耦合性），最後致使前端不能專心致志作出更加好的做品。因此，先後端分離是讓先後端更加專業化，在技術和管理上將前端角色更加明確，更深刻的挖掘前端開發的價值。

(二) 現有系統架構給先後端帶來的問題以及解決方法

 

　　上圖是目前大部分系統的架構圖，雖然有些系統採用分佈式架構，層與層之間使用了遠程調用框架，可是本質上都逃不開上面這個架構設計。這張圖是一張比較合理的圖，在實際開發裏最常發生的事情就是控制層（Control）越過服務層（Service）直接處理下面的資源。

　　先後端耦合的問題主要發生在控制層（Control），控制層是前端和服務端交互的邊界，可是在開發過程當中控制層（Control）和服務層（Service）經常混淆不清，這就是先後端耦合度高的重要緣由。

　　所以要先後端解耦，就是要劃清控制層的邊界，控制層到底該屬於前端仍是服務端，在MVC模式裏控制層做用是調度，控制層不是寫業務邏輯的地方，所以將大量業務邏輯寫到控制層實際上是違背了MVC模式的思想，同時控制層是前端和服務端通信的橋樑，其實控制層是參入了前端的工做任務，既然控制層要剝離業務操做同時控制層也要參入前端應用的開發，那麼將控制層歸爲前端的一部分是徹底合情合理合規的。

　　把控制層剝離了業務邏輯處理可能會讓人不知道如何開發了，我以爲有這種想法的人是開發時候沒有理解透MVC模式思想，編程隨意性大養成了壞習慣，這個就須要這些人一點點去適應技術新趨勢的發展。

　　先後端分離的終極目標應該是前端和服務端是徹底獨立的項目，前端項目包含上圖裏的瀏覽器和控制層，服務端項目包括服務層、DAO層等等，前端項目和服務端項目以高效的遠程調用框架作通信介質，項目開發時候前端項目作前端的事情，服務項目作服務端的事情，這樣就讓服務端開發的人員沒有機會在控制層亂寫代碼了，保證了Web前端環境的純粹性，最後生產發佈也要獨立部署，這樣就達到了先後端真正解耦，可是先後端的溝通機制也是不可或缺的，我以爲它們之間的溝通使用高性能的遠程調用框架，先後端相互約定通信報文格式。.

　　其實無論服務端仍是前端宏觀流程無非是輸入數據à數據處理à輸出數據，可是服務端要把心思花在數據處理上，前端要更多關心的是輸入輸出數據時候的用戶體驗操做，服務端開發最大的問題就是違背MVC原則，代碼編寫的隨意性，而前端無論出於安全仍是性能考慮，最好是儘可能少牽涉業務。前端和後端通信層的獨立，會將先後端進行真正的解耦，前面我講到先後真正問題就是前端和後端技術路線不一致，可是傳統Web開發裏先後端又要融爲一體，這就致使先後端很難作到專業化分工，對於前端應該儘可能弱化通信級別的開發工做，前端通信編程只要知道調用哪一個接口，傳什麼參數，怎麼處理響應信息就好了。這樣就能讓前端和後端實現真正的專業化。

　　作到了這些，就不會發生開發時候先後端邊界不清的問題了。

(三) 先後端分離的一些想法

　　本文主題應該是先後端分離，我上面的建議是個完全方案，要革之前系統的命，對存量系統那該如何處理，答案仍是重構代碼，千方百計逐步減小已經發現的先後端耦合度高的問題，這個跟我以前的建議就是小重構和大重構的區別，若是有人以爲我上面建議合適，前端組應該立刻提供一套這樣的框架出來，這樣後面的新系統就不會在循環前面的錯誤了。我以爲搭建這樣的框架不會太複雜的。

　　我上面的先後端分離的目的就是將前端資源整合爲一個總體，理清先後端的邊界，這些作完後，前端組裏該如何提高本身的能力了？

　　這時候要讓前端的東西項目化，工程化，前端技術不能再當作開發者的玩具，它也是須要大量的系統架構，開發規範，自動化壓縮混淆，自動化發佈，前端監控和分析，前端優化等等。

　　上面這些問題都很重要，也很專業，若是我有機會能參入這樣的事情，我還有個特別的建議，具體以下：

　　在一個企業內部，Web前端的組件，無論這個組件是UI層級，仍是javascript開發層級，都脫離不了該企業業務產品的模式，其實看看像網易，新浪這樣的門戶網站的前端應用組件，它們用於作門戶很合適，可是用它來作企業應用軟件可能就不是太好使用，所以對於組件要有一個清晰的認識，我以爲能夠把組件按業務場景分類，這裏我能夠舉個例子，若是這個企業有給門戶使用的組件，而這個組件很適合門戶，應該把它歸爲門戶組件，若是某些組件適合作網站後臺管理的，那麼就列爲後臺管理組件，若是某些組件能跨多了業務場景則標記爲通用組件。

　　作分類的緣由是爲了理清組件的應用邊界，這樣咱們能夠有針對性的積累和完善這些組件，有意識的開發相關的組件，最終造成一個針對某個業務組件的組件倉庫，這樣等新需求過來，Web前端的項目經理或Web前端的技術經理能夠經過場景分析該需求須要使用那些現有的技術，需求裏的那些場景是要進行開發，新場景裏有沒有新開發的代碼能生成新的組件，這就能夠作到有計劃有次序的積累。

　　Web前端的核心人員應該花更多精力去設計、積累、整理各類組件，經過實際業務需求去完善和豐富這些組件，最終達到組件能夠覆蓋到全公司絕大多數場景，最終經過組件積累造成完善的Web前端開發規範，這樣的規範覆蓋面廣更加易於操做，對於企業而言Web前端開發流程就能夠作到標準化，從而達到簡單培訓一些技術能力不高的開發人員就能完成相關的開發任務，同時也讓Web前端核心人員也能很好的把控項目的質量和進度。

　　以上就是個人一些先後端分離的想法，它是一個很宏觀的想法，沒有太多技術實現細節，若是這個想法若是針對存量系統，的確是一個顛覆性的方案，若是Web前端容許一切重頭來作，我我的以爲這仍是很好的一個思路。先後端分離是Web前端專業化的萬里長征第一步，若是這一步作好，前端就有一套專屬本身的優質環境，那時候Web前端就會有更大的餘力作更優秀的工做，這就是個人願景。

　　固然個人構想也許並不太正確，若是有大牛看了本人文章還請多多指教。

　　今天是臘月23號，據說在北方23號就要太小年，呵呵，年味濃了，因此今天在這裏祝關注博客園的童鞋們：新春快樂，新年大發哦！