包括分层架构、SOA 架构、微服务和微内核等
优点：部署成本低、改动成本、低成本扩容，弹性伸缩，适应云环境
二、可扩展的基本思想
大到小依次为：拆流程 > 拆服务 > 拆功能
流程
TCP/IP 网络通信流程：应用层 → 传输层 → 网络层 → 物理 + 数据链路层
服务
应用层的 HTTP、FTP、SMTP 等服务，HTTP 提供 Web 服务，FTP 提供文件服务，SMTP 提供邮件服务
功能
HTTP 服务提供 GET、POST 功能，FTP 提供上传下载功能，SMTP 提供邮件发送和收取功能。
学生信息管理系统
1. 面向流程拆分
展示层：负责用户页面设计，不同业务有不同的页面。例如，登录页面、注册页面、信息管理页面、安全设置页面等。
业务层：负责具体业务逻辑的处理。例如，登录、注册、信息管理、修改密码等业务。
数据层：负责完成数据访问。例如，增删改查数据库中的数据、记录事件到日志文件等。
存储层：负责数据的存储。例如，关系型数据库 MySQL、缓存系统 Memcache 等。
2. 面向服务拆分
3. 面向功能拆分
注册服务：提供多种方式进行注册，包括手机号注册、身份证注册、学生邮箱注册三个功能。
登录服务：包括手机号登录、身份证登录、邮箱登录三个功能。
信息管理服务：包括基本信息管理、课程信息管理、成绩信息管理等功能。
安全设置服务：包括修改密码、安全手机、找回密码等功能。
不同拆分方式，决定扩展方式。
三、可扩展方式
当我们谈可扩展性时，很多同学都会有一个疑惑：就算是不拆分系统，只要在设计和写代码时做好了，同样不会出现到处改的问题啊？例如，在面向服务拆分的案例中，增加“学号注册”，就算是不拆分为服务，也可以控制修改的范围，那为何我们要大费周章地去拆分系统呢？
在一个理想的环境，你的团队都是高手，每个程序员都很厉害，对业务都很熟悉，新来的同事很快就知晓所有的细节……那确实不拆分也没有问题。但现实却是：团队有菜鸟程序员，到底是改 A 处实现功能还是改 B 处实现功能，完全取决于他觉得哪里容易改；有的程序员比较粗心；有的程序员某天精神状态不太好；新来的同事不知道历史上某行代码为何那么“恶心”，而轻易地将其改漂亮了一些……所有的这些问题都可能出现，这时候你就会发现，合理的拆分，能够强制保证即使程序员出错，出错的范围也不会太广，影响也不会太大。
下面是不同拆分方式应对扩展时的优势。
1. 面向流程拆分
扩展时大部分情况只需要修改某一层，少部分情况可能修改关联的两层，不会出现所有层都同时要修改。例如学生信息管理系统，如果我们将存储层从 MySQL 扩展为同时支持 MySQL 和 Oracle，那么只需要扩展存储层和数据层即可，展示层和业务层无须变动。
2. 面向服务拆分
对某个服务扩展，或者要增加新的服务时，只需要扩展相关服务即可，无须修改所有的服务。同样以学生管理系统为例，如果我们需要在注册服务中增加一种“学号注册”功能，则只需要修改“注册服务”和“登录服务”即可，“信息管理服务”和“安全设置”服务无须修改。
3. 面向功能拆分
对某个功能扩展，或者要增加新的功能时，只需要扩展相关功能即可，无须修改所有的服务。同样以学生管理系统为例，如果我们增加“学号注册”功能，则只需要在系统中增加一个新的功能模块，同时修改“登录功能”模块即可，其他功能都不受影响。
不同的拆分方式，将得到不同的系统架构，典型的可扩展系统架构有：
面向流程拆分：分层架构。
面向服务拆分：SOA、微服务。
面向功能拆分：微内核架构。
当然，这几个系统架构并不是非此即彼的，而是可以在系统架构设计中进行组合使用的。以学生管理系统为例，我们最终可以这样设计架构：
整体系统采用面向服务拆分中的“微服务”架构，拆分为“注册服务”“登录服务”“信息管理服务”“安全服务”，每个服务是一个独立运行的子系统。
其中的“注册服务”子系统本身又是采用面向流程拆分的分层架构。
“登录服务”子系统采用的是面向功能拆分的“微内核”架构。
专栏后面的内容我将详细阐述每种可扩展架构。
小结
规则引擎是常用的一种支持可扩展的方式，按照今天的分析，它属于哪一类？
评论：
面向流程、面向服务、面向功能，这三个的命名，面向服务和面向功能还可以，面向流程这个容易让人误解。
面向流程，大概指的是数据移动的流程，而不是业务流程。分层架构的本质，就是固定的内核，移动的数据。
规则引擎的扩展方式，可以用下排除法。
首先，肯定不是分层架构，即不是面向流程的，因为规则引擎主要作用在业务层。
其次，也不应该是面向服务的，因为规则引擎都是跨越多个服务的。
规则引擎和插件式架构，解决的都是功能扩展的问题。微内核架构就是一种插件式架构。
所以，规则引擎应该是面向功能的扩展方式。
