高可用架构为何须要分层后端
高可用架构分层设计原则是什么安全
高可用架构如何分层架构
高可用架构分层最佳实践mvc
all in one 架构运维
-整个架构只有一个模块异步
数据部分，逻辑部分，接入部分，展现部分等性能
-架构存在问题设计
耦合严重接口
职责不分明队列
模块庞大，臃肿
开发成本高，效率低下
运维成本高
组件间相互影响，一旦组件有问题，整个服务都受影响
扩展性差
性能极限差
牵一发而动全身！！
高可用架构分层
all in one架构问题多多（康威定律）
服务高可用需分层设计
模块耦合性低
模块职责分明
数据层，逻辑层，接入层，展现层 等等
模块间再也不相互影响
模块独立扩展
系统总体性能高
-高可用架构分层设计原则
数据，逻辑，接入（数据安全，攻防），展现
-分层间低耦合
接口交互（rpc，http，resfull）
-分层内高内聚
功能聚焦单一
高可用架构分层设计原则
分层适中
层次过多
请求交互路径长
请求响应延迟高
层次多，运维成本高
定位问题设计层次多，定位复杂多增长，定位时间长
层次过少
每一个层次功能不单一，耦合性高
模块内组件相互影响高
高可用性没法保证
高可用架构分层
-前段架构
MVC架构分层
-后端架构
按照功能水平划分
-四层
接入层，逻辑层，数据层，数据存储
接入层，逻辑层，原子服务层，数据存储
-五层
接入层，序列化层（异步消息队列）、逻辑层、数据层、数据存储
按照业务垂直拆分
- 房产、招聘、二手、二手车、行业
-Im、交友等
高可用架构最佳实践
脱离业务场景谈架构分层绝对是耍流氓
架构的分层取决于业务场景
-mvc
创业初期
知足业务快速发展
可用性低
分层少
all in one