可扩展的基本思想

可扩展性架构的设计方法众多，但无论如何变化，所有的可扩展性架构设计背后的基本思想都可以用一个字来概括：拆！拆，即将原本庞大的系统拆分成多个规模较小的部分。在扩展时，只需修改其中的一部分，无需对整个系统进行大规模修改，通过这种方式来限制变动范围，减小变动风险。虽然这一理念听起来简单，但在软件系统中的实际拆分远非如拆卸物品一般粗暴。软件系统的"拆"是一种建设性的过程，旨在通过拆分使得软件系统更加精致，具备更好的可扩展性

按照不同的思路来拆分软件系统，就会得到不同的架构。常见的拆分思路有如下三种。

面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。

面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。

面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。

流程

对应 TCP/IP 四层模型，因为 TCP/IP 网络通信流程是：应用层 → 传输层 → 网络层 → 物理 + 数据链路层，不管最上层的应用层是什么，这个流程都不会变。

服务

对应应用层的 HTTP、FTP、SMTP 等服务，HTTP 提供 Web 服务，FTP 提供文件服务，SMTP 提供邮件服务，以此类推。

功能

每个服务都会提供相应的功能。例如，HTTP 服务提供 GET、POST 功能，FTP 提供上传下载功能，SMTP 提供邮件发送和收取功能。虽然具体应用层的协议和服务可能不同，但整体通信流程和服务功能在 TCP/IP 模型中的位置和关系保持一致。

以一个简单的学生信息管理系统为例，拆分方式为：

1. 面向流程拆分展示层 → 业务层 → 数据层 → 存储层，各层含义是：

展示层：负责用户页面设计，不同业务有不同的页面。例如，登录页面、注册页面、信息管理页面、安全设置页面等。

业务层：负责具体业务逻辑的处理。例如，登录、注册、信息管理、修改密码等业务。数据层：负责完成数据访问。例如，增删改查数据库中的数据、记录事件到日志文件等。

存储层：负责数据的存储。例如，关系型数据库 MySQL、缓存系统 Memcache 等。这种拆分方式有助于按照不同层次划分职责，使系统更易于维护和扩展，同时使得各个层次的功能更为清晰

2. 面向服务拆分

将系统拆分为注册、登录、信息管理、安全设置等服务，最终架构示意图如下

面向功能拆分:

每个服务都可以拆分为更多细粒度的功能，例如：注册服务：提供多种方式进行注册，包括手机号注册、身份证注册、学生邮箱注册三个功能。登录服务：包括手机号登录、身份证登录、邮箱登录三个功能。信息管理服务：包括基本信息管理、课程信息管理、成绩信息管理等功能。安全设置服务：包括修改密码、安全手机、找回密码等功能。这种拆分方式有助于将整体服务划分为更小、更专注的功能单元，提高系统的可维护性和可扩展性。每个功能服务都可独立开发、测试、部署，降低了服务之间的耦合性，使得系统更加灵活

可扩展方式:

1. 面向流程拆分：扩展时大部分情况只需要修改某一层，少部分情况可能修改关联的两层，不会出现所有层都同时要修改。例如学生信息管理系统，如果我们将存储层从 MySQL 扩展为同时支持 MySQL 和 Oracle，那么只需要扩展存储层和数据层即可，展示层和业务层无须变动。

   
   

2. 面向服务拆分：对某个服务扩展，或者要增加新的服务时，只需要扩展相关服务即可，无须修改所有的服务。同样以学生管理系统为例，如果我们需要在注册服务中增加一种“学号注册”功能，则只需要修改“注册服务”和“登录服务”即可，“信息管理服务”和“安全设置”服务无须修改。

   
   

3. 面向功能拆分：对某个功能扩展，或者要增加新的功能时，只需要扩展相关功能即可，无须修改所有的服务。同样以学生管理系统为例，如果我们增加“学号注册”功能，则只需要在系统中增加一个新的功能模块，同时修改“登录功能”模块即可，其他功能都不受影响。

不同的拆分方式，将得到不同的系统架构，典型的可扩展系统架构有：

面向流程拆分：分层架构。

面向服务拆分：SOA、微服务。

面向功能拆分：微内核架构。

思考：

规则引擎的扩展方式是什么？

面向流程、面向服务、面向功能，这三个的命名，面向服务和面向功能还可以，面向流程这个容易让人误解。     

面向流程，大概指的是数据移动的流程，而不是业务流程。

分层架构的本质，就是固定的内核，移动的数据。     

规则引擎的扩展方式，可以用下排除法。     

首先，肯定不是分层架构，即不是面向流程的，因为规则引擎主要作用在业务层。     

其次，也不应该是面向服务的，因为规则引擎都是跨越多个服务的。     

规则引擎和插件式架构，解决的都是功能扩展的问题。

微内核架构就是一种插件式架构。     

所以，规则引擎应该是面向功能的扩展方式。