高可用架构总体架构篇

高可用架构为什么需要分层

高可用架构分层设计原则是什么

高可用架构如何分层

高可用架构分层最佳实践

 

all in one 架构

-整个架构只有一个模块

 数据部分，逻辑部分，接入部分，展示部分等

-架构存在问题

耦合严重

职责不分明

模块庞大，臃肿

开发成本高，效率低下

运维成本高

组件间相互影响，一旦组件有问题，整个服务都受影响

扩展性差

性能极限差

牵一发而动全身！！

 

高可用架构分层

all in one架构问题多多（康威定律）

服务高可用需分层设计

模块耦合性低

模块职责分明

         数据层，逻辑层，接入层，展示层 等等

模块间不再相互影响

模块独立扩展

系统整体性能高

 

-高可用架构分层设计原则

数据，逻辑，接入（数据安全，攻防），展示

-分层间低耦合

   接口交互（rpc，http，resfull）

-分层内高内聚

    功能聚焦单一

 

高可用架构分层设计原则

分层适中

     层次过多

      请求交互路径长

      请求响应延迟高

    层次多，运维成本高

定位问题设计层次多，定位复杂多增加，定位时间长

层次过少

 每个层次功能不单一，耦合性高

模块内组件相互影响高

高可用性无法保证

 

高可用架构分层

-前段架构

    MVC架构分层

-后端架构

     按照功能水平划分

          -四层 

                接入层，逻辑层，数据层，数据存储

                接入层，逻辑层，原子服务层，数据存储

          -五层

              接入层，序列化层（异步消息队列）、逻辑层、数据层、数据存储

            按照业务垂直拆分

               -  房产、招聘、二手、二手车、行业

              -Im、交友等

高可用架构最佳实践

脱离业务场景谈架构分层绝对是耍流氓

     架构的分层取决于业务场景

       -mvc

 

创业初期

 满足业务快速发展

可用性低

分层少

all in one

 

 

 

 

转载于:https://my.oschina.net/u/3103846/blog/1421768