高可用架構爲何須要分層後端
高可用架構分層設計原則是什麼安全
高可用架構如何分層架構
高可用架構分層最佳實踐mvc
all in one 架構運維
-整個架構只有一個模塊異步
數據部分，邏輯部分，接入部分，展現部分等性能
-架構存在問題設計
耦合嚴重接口
職責不分明隊列
模塊龐大，臃腫
開發成本高，效率低下
運維成本高
組件間相互影響，一旦組件有問題，整個服務都受影響
擴展性差
性能極限差
牽一髮而動全身！！
高可用架構分層
all in one架構問題多多（康威定律）
服務高可用需分層設計
模塊耦合性低
模塊職責分明
數據層，邏輯層，接入層，展現層 等等
模塊間再也不相互影響
模塊獨立擴展
系統總體性能高
-高可用架構分層設計原則
數據，邏輯，接入（數據安全，攻防），展現
-分層間低耦合
接口交互（rpc，http，resfull）
-分層內高內聚
功能聚焦單一
高可用架構分層設計原則
分層適中
層次過多
請求交互路徑長
請求響應延遲高
層次多，運維成本高
定位問題設計層次多，定位複雜多增長，定位時間長
層次過少
每一個層次功能不單一，耦合性高
模塊內組件相互影響高
高可用性沒法保證
高可用架構分層
-前段架構
MVC架構分層
-後端架構
按照功能水平劃分
-四層
接入層，邏輯層，數據層，數據存儲
接入層，邏輯層，原子服務層，數據存儲
-五層
接入層，序列化層（異步消息隊列）、邏輯層、數據層、數據存儲
按照業務垂直拆分
- 房產、招聘、二手、二手車、行業
-Im、交友等
高可用架構最佳實踐
脫離業務場景談架構分層絕對是耍流氓
架構的分層取決於業務場景
-mvc
創業初期
知足業務快速發展
可用性低
分層少
all in one