最近研究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號就要過小年，呵呵，年味濃了，所以今天在這裡祝關注部落格園的童鞋們：新春快樂，新年大發哦！