一、職責劃分

前端

前端工作專注業務的頁面呈現，非常注重用戶體驗度，也是與各種角色打交道最多的。

比如：

前端開發人員會經常與產品經理或者客戶討論頁面樣式、視覺效果，頁面布局等各種頁面渲染效果

前端開發人員要與UI設計師對接：字體大小、顏色、頁面布局、樣式等

前端開發人員與多個后端開發人員接口對接

前端開發人員與測試人員基于bug修復討論

一般前端工作包括六個部分：

1、UI設計師與產品經理對接需求

2、UI設計：UI設計師設計高保真圖，給前端開發人員設計真實頁面

3、頁面開發：根據UI設計師提供的高保真圖，進行頁面模塊開發

4、前后端接口對接：與后端開發人員對接API接口

5、前后端聯調測試：包括頁面展示以及接口數據

6、bug修復

后端

如果前后端職責劃分很清楚的話，后端更多開發工作在于業務接口設計、業務邏輯處理以及數據的持久化存儲，并提供詳細的接口設計文檔給前端開發人員使用。

一般后端工作包括五個部分：

1、與產品經理對接需求

2、業務API接口開發：根據根據需求文檔進行業務接口開發

4、接口對接：與前端開發人員接口對接

5、前后端聯調測試：包括頁面展示以及接口數據

6、bug修復

二、技術劃分

前端開發技術棧

h5、css、nodejs/vue/angular/react、webpack、hbuilder/vscode等

后端開發技術棧

后端更注重業務邏輯處理，以數據為中心，關注數據存儲及高并發請求等。

SpringCloud/Springboot、SpringMVC、ORM框架、數據庫、緩存框架（Redis，Codis\Memcached等），大數據框架（Hadoop/Spark/hive/Hbase/Storm/ES/Kafka等）等等

三、我們約定

技術選型

最好選擇成熟穩定，易上手、開發效率高的技術，因為實際項目開發時間是有限的，開發人員沒有多少精力放在學習和深度研究技術上。

數據格式

后端開發提供接口設計文檔，詳細寫明每個接口的請求地址、請求參數、響應參數等等；一般采用REST風格以JSON格式提供數據。

接口設計

一個接口設計的好壞，直接影響到前后端一些溝通協調問題。

依筆者經驗來看，如果后端接口不穩定，會導致前端開發人員反復修改頁面數據呈現。常常出現后端開發說這是前端問題，前端開發說是后端問題，來回扯皮，溝通效率低下。

從前端開發的角度來說，他們更關注用戶體驗效果， 因為客戶看到的是最終頁面，頁面效果以及數據呈現效果的好壞最能反映客戶的滿意度的。客戶不關注你用了什么牛逼的技術，有什么牛逼的人。

從后端開發角度來說，他們更關注程序的可靠性、穩定性、安全性以及是數據完整性、一致性等。

所以前后端雙方關注點不同，難免會涉及到一些工作量大小問題。例如接口粒度問題

接口容量問題

一個接口的業務容量大小，往往代表前后端工作量的大小。

如果一個接口的業務容量太小，前端需要分階段處理的事情就多，尤其是對多個接口Ajax異步處理；如果一個接口的業務容量太大，那么業務耦合性高，萬一需求變更，后端程序改動大，不利于程序的擴展。

四、分離帶來的優勢

前后端職責分明，分工明細

局部變化，不會影響所有業務功能；也不會因為某局部功能修改，而導致所有程序重啟服務。

開發效率高，在不涉及接口聯調時，前后端互不干擾

聯調簡單，前后端保證API接口規范穩定就行

問題責任清晰，聯調/測試/預發/上線/bug，都能馬上定位是哪方的問題。

自動化部署：容器化部署：docker+k8s

五、分離帶來的問題

一、前后端分離思想要轉變

不能老是按照傳統WEB（js/h5/css/后端代碼放在一個工程）開發思維去看待前后端分離

二、溝通成本問題

以前傳統WEB開發，開發人員從需求到設計到開發基本上是一個人。而前后端分離后，前端只負責頁面呈現，后端更注重業務邏輯處理以及數據的持久化，雙發都有自己的側重點，工作量上有私心。

三、組織結構問題

康威定律

第一定律：Communication dictates design（組織溝通方式會通過系統設計表達出來）

第二定律：There is never enough time to do something right, but there is always enough time to do it over（時間再多一件事情也不可能做的完美，但總有時間做完一件事情）

第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization（線型系統和線型組織架構間有潛在的異質同態特性）

第四定律：?The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系統組織總是比小系統更傾向于分解）

康威定律說明以下幾點

人與人的溝通是非常復雜的，一個人的溝通精力是有限的，所以當問題太復雜需要很多人解決的時候，我們需要做拆分組織來達成對溝通效率的管理

組織內人與人的溝通方式決定了他們參與的系統設計，管理者可以通過不同的拆分方式帶來不同的團隊間溝通方式，從而影響系統設計

如果子系統是內聚的，和外部的溝通邊界是明確的，能降低溝通成本，對應的設計也會更合理高效

復雜的系統需要通過容錯彈性的方式持續優化，不要指望一個大而全的設計或架構，好的架構和設計都是慢慢迭代出來的

四、部署及監控運維

前后端分離后，拆分的服務會帶來線上部署以及如何監控運維的復雜性。

六、總結

總體來說，前后分離所帶來的好處還是更明顯的。一個成熟的前后端分離的團隊，文檔化約定，前后端職責分離、接口約定都是做的比較好的

總結

以上是生活随笔為你收集整理的前后端分离微服务架构如何设计？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。