可扩展架构与分层架构

可扩展架构

1 概述

软件系统与硬件/建筑系统最大的区别就是可以迭代升级和扩展，一个硬件生产出来后就不会进行改变，除非拿去售后维修，一个建筑完工后也不会改变其整体的结构，除非被破坏后进行修复和重铸

可以发现如果硬件/建筑不进行改变，能说明其质量很不错，稳定，但软件则完全相反，如果一个系统完工后就不做任何更新，反而说明其没有发展，没有生命力

可拓展好吗？好，让系统能根据技术发展和新需求进行升级，但是如何以最小的代价去扩展系统才是难点。一个新的需求可能就会导致全部地方都要改动，但是如果系统的扩展性强，那么扩展时的出错率就会更低，投入可能也就越少

2 可扩展的基本思想

可扩展性架构设计方法很多，但背后基本思想都可以一个字概括拆

拆就是讲原本大一统的系统拆分为多个规模小的部分，修改时只需要改动其中一个部分或者几个部分就可以，降低了改动风险，但是怎么去拆则是有不同的思路

面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。
面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。
面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。

以一个学生信息管理系统为例

面向流程拆分：拆为展示层，业务层，数据层，存储层
- 展示层负责界面设计，不同的业务有不同页面
- 业务层负责业务逻辑处理
- 数据层负责数据的访问，例如增删改查数据库
- 存储层负责存储数据，例如MySQL
面向服务拆分：拆为注册、登录、信息管理、安全设置等服务
面向功能拆分：将每个服务继续拆分，拆为手机号注册、邮箱注册、学号注册、手机号登录、邮箱登录、学号登录、基本信息管理、课程信息管理、成绩信息管理…

可以发现不同的拆分方式，架构图差异很大，但无论使用哪种方式，都可以实现，但是不能随便选择，因为不同的拆分方式，本质上决定了系统的扩展方式

3 可扩展方式

很多时候，即使不拆分系统，只需要在设计和编码时规范编写，也不见得到处修改的问题。但这是大家都遵守这个规则的情况下，团队一般会有各种各样的同事，即使不遵守也只是道德问题，如果合理的拆分了，他能修改的地方就会变小，影响也会降低

不同拆分方式的优势

面向流程：扩展时很多时候只需要修改某一层，少部分情况可能关联两层
面向服务：新增某个服务时，只需要扩展相关服务就可以，如新增一个第三方注册，只需要增加一个第三方注册服务，修改注册服务和登录服务即可，其他服务无须修改
面向功能：扩展和新增功能时，只需要扩展相关功能即可，无须修改所有的服务。如第三方注册，只需要新增一个第三方注册功能，和修改登录功能即可

不同的拆分方式，将得到不同的系统架构，典型如下

面向流程：分层架构
面向服务：SOA，微服务
面向功能：微内核架构

并且不同的拆分方式并不是互斥的，例如微服务架构中一个服务可以拆为分层架构，且某些服务还可以拆为微内核架构

4 总结

软件架构和硬件/建筑系统最大差异在于软件可以扩展和升级
真正有生命力的软件系统都是在不断迭代和发展的
所有可扩展性架构设计，背后基本思想为一个字：拆
拆分软件系统有三种方式：面向流程拆分、面向服务拆分、面向功能拆分
不同的拆分方式将得到不同的系统架构

分层架构

1 分层架构类型

分层架构也被称为N层架构，通常N>=2，例如C/S架构、B/S架构，常见的是3层架构(MVC,MVP)、4层架构、5层架构比较少见，一般像操作系统内核架构才会达到5层。

C/S架构、B/S架构

站在整个业务系统的角度划分，划分维度是用户交互，不管是客户端还是浏览器端都是进行数据呈现的，业务和其他存储的所有能力都在服务端

在这里插入图片描述

MVC架构、MVP架构

站在单个业务子系统的角度划分，划分维度为职责，将不同的职责划分到独立层，但各层的依赖关系比较灵活，两两交互

逻辑分层架构

站在单个业务子系统或者整个业务系统，划分维度为职责，不过和MVC等不同的是，逻辑分层是自顶向下依赖的。

在这里插入图片描述

针对整个业务系统进行逻辑分层的架构图

在这里插入图片描述

2 分层架构详解

无论采取哪种分层维度，最核心的就是要保证各层之间的差异和边界明显，这也是分层不能分太多层的原因。

分层能支撑系统扩展能力的本质在于：隔离关注点(即每层都只处理本层的逻辑)，比如展示层只需处理展示逻辑，业务层只需要处理业务逻辑，这样即使有逻辑变动也不会影响其他层，只需要在业务层做修改即可。
如果要做到扩展稳定，会涉及到抽象概念，比如一个接口下有多个实现，且我们不需要关心不同的实现拿到的结果后需要做什么处理，因为这个在接口中已经抽象了，拿到的结果都是一样的。