架构设计 9-可扩展架构之分层架构

导读：《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第九部分。首先整体介绍可扩展架构的基本思想——“拆”，以及如何拆；随后介绍了面向流程的拆分，即分层架构。

扫描文末二维码 关注公众号 回复 “架构设计” 获取架构设计笔记完整思维导图

基本思想

所有的可扩展性架构设计，背后的基本思想都可以总结为一个字：拆！

拆，就是将原本大一统的系统拆分成多个规模小的部分，扩展时只修改其中一部分即可，无须整个系统到处都改，通过这种方式来减少改动范围，降低改动风险。

不同的拆分方式，本质上决定了系统的扩展方式。

拆分思路

面向流程拆分

• 方案：将整个业务流程拆分为几个阶段，每个阶段作为一部分
• 优势：扩展时大部分情况只需要修改某一层，少部分情况可能修改关联的两层，不会出现所有层都同时要修改
• 典型架构：分层架构

面向服务拆分

• 方案：将系统提供的服务拆分，每个服务作为一部分
• 优势：对某个服务扩展，或者要增加新的服务时，只需要扩展相关服务即可，无须修改所有的服务。
• 典型架构：SOA & 微服务

面向功能拆分

• 方案：将系统提供的功能拆分，每个功能作为一部分
• 优势：对某个功能扩展，或者要增加新的功能时，只需要扩展相关功能即可，无须修改所有的服务
• 典型架构：微内核架构

分层架构

概念：分层架构是很常见的架构模式，它也叫 N 层架构，通常情况下，N 至少是 2 层。

根据不同的划分维度和对象可分为：C/S 架构&B/S 架构、MVC 架构&MVP 架构、逻辑分层架构。

C/S 架构、B/S 架构

• 划分的对象是整个业务系统
• 划分的维度是用户交互，即将和用户交互的部分独立为一层，支撑用户交互的后台作为另外一层

MVC 架构、MVP 架构

• 划分的对象是单个业务子系统
• 划分的维度是职责，将不同的职责划分到独立层，但各层的依赖关系比较灵活

逻辑分层架构

• 划分的对象可以是单个业务子系统，也可以是整个业务系统
• 划分的维度也是职责，逻辑分层架构中的层是自顶向下依赖的

核心要点

• 需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构
• 分层架构之所以能够较好地支撑系统扩展，本质在于隔离关注点（separation of concerns），即每个层中的组件只会处理本层的逻辑
• 并不是简单地分层就一定能够实现隔离关注点从而支撑快速扩展，分层时要保证层与层之间的依赖是稳定的，才能真正支撑快速扩展。
• 分层结构的另外一个特点就是层层传递，也就是说一旦分层确定，整个业务流程是按照层进行依次传递的，不能在层之间进行跳跃。

优缺点

优点

强制将分层依赖限定为两两依赖，降低了整体系统复杂度。

缺点

• 分层架构另外一个典型的缺点就是性能，因为每一次业务请求都需要穿越所有的架构分层，有一些事情是多余的，多少都会有一些性能的浪费
• 分层结构的代价就是冗余，也就是说，不管这个业务有多么简单，每层都必须要参与处理，甚至可能每层都写了一个简单的包装函数。