软件系统与硬件或建筑系统的主要区别在于其可扩展性。例如，一旦生产的CPU安装在电脑上，它就无法返回工厂增加新功能；同样，一座建成的金字塔，无论历经多少年，其结构与最初相同。而软件系统则不同，如果一个软件在发布后不再更新，就意味着它缺乏活力。一个有活力的软件系统会随着技术的进步而不断发展和迭代，如Windows操作系统，从Windows 3.0发展到现在的Windows 10。

接下来，我们将学习关于架构可扩展模式的知识，包括分层架构、SOA架构、微服务和微内核等方面。

软件的可扩展性是其吸引力所在，也是设计上的挑战。这种特性允许我们通过不断的修改和扩展来丰富软件系统的功能和特性，以满足新的需求或技术发展的趋势。然而，扩展的难点在于如何最小化改动范围和成本，因为扩展过程中小的改动可能需要大范围的调整，这不仅风险大，成本也高。因此，在设计软件架构时，如何有效控制扩展带来的改动是一个关键的考虑因素。

可扩展的基本思想

幸运的是，有许多方法可以设计出可扩展的架构，而所有这些方法的核心理念都可以归结为一个简单的原则：分解。

分解的意思是把一个庞大的统一系统拆分成多个小的模块。这样，在需要扩展功能时，只需修改特定的模块而不必对整个系统进行全面的修改，从而减少了改动的范围和风险。

虽然这听起来很直接，毕竟我们经常看到各种拆解的场景。在日常生活中，无论是用推土机拆除建筑，还是用剪刀打开快递，或是用手撕开包装袋，这些拆解通常都是直接且粗暴的，一旦拆解就废弃不用。但在软件系统中，拆解的过程远不如物理拆解那么简单。这是因为我们拆解软件时不是为了销毁它，而是为了通过重组使其更加高效且具有更好的可扩展性。因此，软件中的拆解更像是一种建设性的活动，其复杂度和精细度远高于物理拆解。

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

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

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

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

  
  

我以 TCP/IP 协议栈为例，来说明“流程”“服务”“功能”的区别和联系。TCP/IP 协议栈和模型图如下图所示。

流程 在 TCP/IP 四层模型中，通信过程始终遵循以下层级顺序：从应用层开始，然后是传输层，接着是网络层，最后达到物理层和数据链路层。无论应用层的功能如何变化，这一基本流程保持不变。

服务 在应用层，存在多种服务，如 HTTP、FTP、SMTP 等。HTTP 负责提供网页浏览服务，FTP 负责文件传输服务，SMTP 则是邮件交换服务。

功能 每种服务都具备其特定的功能集。例如，HTTP 支持 GET 和 POST 请求；FTP 允许用户上传和下载文件；SMTP 使用户能够发送和接收电子邮件。

以一个典型的学生信息管理系统为例，系统的拆分可以根据不同的层次结构来进行，具体如下：

分层架构拆分

• 展示层：这一层主要负责界面的呈现，根据不同的业务需求展示不同的用户界面。例如，包括了登录界面、注册界面、学生信息管理界面和安全设置界面等。

• 业务层：这层处理系统的核心业务逻辑，包括登录、注册、学生信息的处理、密码修改等操作。

• 数据层：这一层负责数据的处理操作，包括对数据库的增加、删除、修改和查询操作，以及日志记录的功能。

• 存储层：主要负责数据的持久存储，使用的存储技术包括关系型数据库如MySQL和缓存技术如Memcache等。

  
  

2. 面向服务拆分

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

3. 面向功能拆分

各个服务可以进一步细化为具体的功能单元，如下所示：

• 注册服务：提供多样化的注册选项，包含通过手机号、身份证或学生邮箱进行注册的功能。

• 登录服务：提供多种登录途径，可以通过手机号、身份证或邮箱进行登录。

• 信息管理服务：涵盖不同类型的信息处理，如基础个人信息、课程详情以及成绩数据的管理。

• 安全设置服务：包括更改密码、设置安全手机和密码找回等安全相关的功能。

  
  

最终架构图如下：

当然不能随便挑，否则架构设计就没有意义了，架构师也就要丢掉饭碗了。原因在于：不同的拆分方式，本质上决定了系统的扩展方式。

可扩展方式

许多人在讨论系统的可扩展性时，常常会提出这样的疑问：如果在设计和编码阶段就已经做得很好，即使不进行系统拆分，也能避免在修改时引发广泛的变更，那么为什么还需要花费大量精力去拆分系统呢？

确实，在一个理想的情况下，如果你的团队成员都非常熟练和了解业务，甚至新成员也能迅速掌握所有细节，那么系统不拆分似乎并无大碍。然而，现实情况往往并非如此理想：团队中可能包括初级开发者，他们可能会根据自己的理解随意修改代码；有些开发者可能偶尔疏忽大意；有些人可能某天工作状态不佳；新加入的成员可能对代码的历史背景一无所知，轻易地修改了看似“糟糕”的代码段……这些情况都可能发生。在这种背景下，一个合理的系统拆分就显得尤为重要，它可以确保即使开发者犯错，错误的影响也能被限制在较小的范围内，从而减少整体的影响。

下面是不同拆分方式应对扩展时的优势。

面向流程的拆分

在大多数情况下，扩展系统仅需修改特定的层级，很少需要同时修改多层。以学生信息管理系统为例，假设需要将存储层从仅使用 MySQL 扩展至同时支持 MySQL 和 Oracle，这种情况下，只需对存储层及数据层进行调整，而展示层和业务层则无需改动。

面向服务的拆分

扩展特定服务或增加新服务时，只需对相关服务进行修改，无需涉及到其他服务。例如，在学生管理系统中增加“学号注册”功能，只需要在“注册服务”和“登录服务”中进行修改，而“信息管理服务”和“安全设置服务”则保持不变。

面向功能的拆分

当需要扩展或添加新功能时，只需针对该功能进行操作，无需调整整体服务。例如，若在学生管理系统中添加“学号注册”功能，只需要增加一个新的功能模块并对“登录功能”进行适当修改，其他功能则不受影响。

不同的拆分策略会导致不同的系统架构。典型的可扩展系统架构包括：

• 面向流程拆分的分层架构。

  
  

• 面向服务拆分的SOA和微服务架构。

  
  

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

这些架构并非相互独立，而是可以在设计中互相结合使用。以学生管理系统为例，最终的系统架构可以如下设计：

系统整体采用“微服务”架构进行面向服务的拆分，分为“注册服务”、“登录服务”、“信息管理服务”和“安全服务”，每个服务作为一个独立的子系统运行。

“注册服务”子系统内部则使用面向流程的分层架构。

而“登录服务”子系统则采用面向功能的微内核架构。