一、V2單體架構局限性

1. JSP開發模式，必須是全棧開發工程師才能勝任。對于人員要求較高，成本太高了；
2. 開發無法專注業務，需要解決前端樣式又要做后端業務控制，會對后期的維護造成很大風險；
3. 表單模塊是沒有辦法模塊化的，擴展性太差，無法多人并行擴展表單控件；
4. 集群、負載方案支持相對比較困難；
5. 模塊耦合性較高，無法對單獨的業務擴容增加負載能力，比如流程用得較多，需要整個應用擴容；
6. 對外發布接口時還必須重新寫一套接口，增大開發/維護工作量；

二、V3分布式架構優勢

1)前后端分離模式

1. 為優質產品打造精益團隊
   術業有專攻，通過前后端分離，讓前后端工程師只需要專注于前端或者后端的開發工作，有利于編寫出高質量的代碼，培養開發工程師獨特的技術特性，然后構建出一個全棧式的精益開發團隊。

2. 提高工作效率，分工更加明確
   前后端分離的工作流程可以使得前端專心前端，后端關心后端，兩者開發同時進行，提高開發效率，頁面的增加和路由的修改也不必再去麻煩后端，開發更加靈活。
   前端可以借助mock系統模擬接口完成前端開發。

3. 降低服務器負載，系統性能提升
   通過前端路由的配置，我們可以實現頁面的按需加載，無需一開始加載首頁便加載網站的所有資源，服務器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。

4. 增強代碼的可維護性
   前后端分離后，應用的代碼不再是前后端混合，只有在運行期才會調用依賴關系，并且分層明確，應用代碼變得整潔清晰。
   前端代碼全面模塊化，所有功能代碼都是獨立的，且抽離很多公用組件，可快速實現特定功能。
   后端接口只需維護一套，即可適應各端的調用要求，無需重復維護接口。

5. 增強應用的吞吐能力
   前端使用nginx靜態容器，后端每個微服務都是原生支持集群，可動態擴容，大大增強了應用的負載/吞吐能力。

2)后端分布式架構

1. 后端業務獨立
   后端按業務模塊劃分應用（代碼、數據庫），每個應用獨立維護（更專注），集群原生支持，擴容特別方便（同機擴容只需改端口即可、不同機擴容直接復制部署文件即可啟動），大大提升吞吐能力，更好的保證系統的穩定性；

2. 增強運維可行性
   配置中心組件的出現，可支持在線動態修改應用配置并及時生效，還支持環境、版本等高級功能，再也不需要忍受修改一個配置項就得重啟應用的痛苦。
   日志監控組件，可以讓查日志、定位問題更便捷，不需要到服務器拷貝日志再查閱。
   鏈路監控組件，可以讓我們更了解我的應用健康狀況，為我們提升性能提供非常必要的數據支持。
   灰度發布（金絲雀），可以實現接口逐步上線，大大降低了風險。

3. 增強數據安全性
   引入了網關這個組件，非內部后端應用都需要從網關去訪問數據，未授權的調用都是不允許對數據進行訪問/操作。
   數據控制粒度到接口級別。