其實對於很多團隊和公司來說，前後端分離的出發點是有些問題的。如果業務沒有梳理清楚，就要大一統的方案，顯然這個方案是需要反覆迭代，這個迭代的代價尚可忽略，但是對於流程的改動影響範圍是很大的。所以解決問題也需要聚焦，優先解決見效快，對當前工作有顯著改善的部分。
一個系統如果從零到一，基本會是一個如下的大體架構方式：
所以在這裡我們的目標很簡單，系統像個車輪能夠運轉起來，至於系統的高可用和性能，這個在目前來看不是緊急優先的，而前後端分離的事情現在是無法支持的。
第二階段是一個基礎的重構，看起來是一種割肉的感覺。 因為我們要對重邏輯做裁剪，否則前後端分離無從談起。所以在此我提出一個基本的概念，那就是本地前端。這個本地前端是一種面向功能的實現，沒有考慮更多的體驗和互動性，後端邏輯和前端邏輯要華清界限，最直接的界限就是全部API化，後端邏輯全部提供為API的服務形式，和本地前端的交互還是通過類似MTV的方式來實現，但是view層裡面不存在核心的邏輯了，只負責跳轉和數據轉發。
到了這個階段，其實系統已經有了一些良好的基礎，那麼我們就可以考慮接入一個大而全的平臺了，這裡的前端就是平臺前端，這個平臺前端可以是統一規劃的技術棧或者是全新的系統，這裡對接的代價很低，一來已經存在一個基本原型，只能比它更好，二來之前的對接都是API,我們可以在完全不改動已有邏輯的情況下做平臺前端的對接。
這個階段，你可以理解為混合跑的階段，絕對不會因為某個技術而隔掉其他技術的命。
接下來才開始有意思，那就是後端邏輯的垂直拆分。我們可以根據通用和業務邏輯來拆分為多個邏輯層。比如權限是通用的邏輯，日誌是通用的邏輯，安裝部署和特有的邏輯。
其實到了這裡，我們的目標還不夠明顯，顯然很多工作還是需要明確，首先這麼做的意義是什麼，我們可以在代碼層等來隔離，但是邏輯間的調用和關聯還是沒有完全降低，怎麼改進，一個思路就是模塊化，比如我要建設自己的業務系統，權限管理每次都得重新建設，實在是麻煩，如果能夠類似docker的模板容器化這個工作，我們的業務邏輯就是一種類似插件的方式，那麼服務的可配置和管理型會大大增強。
所以到了這個階段之後，邏輯的部分還是API來交互，在高可用方面我們就可以考慮一些接口服務，比如RESTful API來完善了。
至於後續的接口服務的高可用等等，這個就是一套完整的框架和系統來支撐了。前端也可以把平臺前端統一化了。
閱讀更多 楊建榮的學習筆記 的文章
