1.1　架构的几个概念

架构的所有概念都是在系统设计过程中不断抽象和衍生出来的，因此，在介绍架构的几个概念之前，需要再花一点儿时间介绍一下架构的产生过程。下面以一个电商购物系统的架构优化为例来进行阐述。

最开始的时候系统还没有构建起来，也基本没有用户，此时系统以提供基本使用功能为主，例如，业务逻辑处理和数据存储都部署在一台服务器上，用户请求的处理和数据存储全部在这台服务器上完成。

随着业务的发展，产品经理规划了更多的功能模块，此时如果依然使用一台服务器来完成业务逻辑处理和数据存储，那么系统的处理能力就会受到限制，需要考虑将业务逻辑处理和数据存储进行分离，即业务逻辑处理单独使用业务逻辑服务器，数据存储单独用另外的服务器。因为业务逻辑处理和数据存储分离了，所以它们之间就多了一些额外的数据传输，而数据传输就是为了连接业务逻辑处理和数据存储这两个模块。

再往下发展，由于产品功能受到特定用户群体的认可，因此用户数量开始增加，这导致单台业务逻辑服务器处理不过来，此时系统就需要再引入反向代理服务器，以使后端的业务逻辑服务器可以更方便地扩展，从而提升后端业务逻辑服务器的处理能力。同时，用户规模的扩大会使数据存储的存取性能受到挑战，此时就需要对数据存储进行读写分离，以独立的读服务器和写服务器来提升系统的数据存储性能。

由于产品受到了特定用户群体的喜爱，因此产品经理就依据用户反馈规划出更多的产品功能，如商品导航、活动、积分等一系列的功能，以提高用户黏性和促进业务增长。此时，为了避免不同模块之间的访问干扰，不同的业务逻辑服务就需要拆分，同时数据也需要基于不同的业务类型进行拆分存储。

随着活动、积分等运营业务的发布，用户产生了裂变，这时用户的并发访问量不断上升，单独的数据存储服务已经无法满足用户体验的要求，就需要考虑引入缓存、流量分发和负载均衡等可以有效提升系统性能的组件。

上述过程大概描述了优化一个系统架构的几个阶段。那么，架构的设计优化需要满足什么条件呢？

（1）业务对于系统有更高的要求。

（2）模块的处理能力有限，需要有效地将系统进行切分。

（3）系统切分后，需要引入协调调度机制，以提升模块的协作性能。

第一点，伴随业务的不断发展、业务功能的多样化、用户规模的不断扩大，业务对系统提出了更高的要求，例如系统的性能、可用性、可扩展性以及可维护性，这是架构产生的一个先决条件。也就是说，产生架构的第一要素是现在或者未来可见的业务对系统有更高的要求，架构不是一种空想的设计。

第二点，模块的处理能力有限，需要有效地对系统进行切分。由于业务对系统的要求提升，而单独一个模块的处理能力又有限，因此就需要对系统进行更多的切分。例如，单台服务器的处理能力有限，就需要将业务逻辑处理和数据存储分离。单台数据存储服务器的处理能力有限，就需要对数据存储进行读写分离。

第三点，系统切分后，需要引入协调调度机制，以提升模块的协作性能。例如，为了提升业务逻辑处理能力，需要引入反向代理服务器。

总结来说，架构是一个系统的优化过程，而分布式系统的架构则是为了实现系统的高性能、高可用、可扩展、可维护等目标所做的一系列优化过程。

1.1.1　系统与子系统

这里仍然以上面的电商购物系统来阐述。

一个完整的电商购物系统包括用户注册/登录系统、用户成长系统、评价系统、购买系统等。因此，可以这样来定义，电商购物系统是一个整体的系统，而用户注册/登录系统等就属于电商购物系统的子系统。从用户视角出发，子系统可以看作独立闭环的一个功能。

1.1.2　模块与组件

模块和组件是进入系统以后区分出来的概念。例如，电商购物系统里的购买功能可以区分出支付、导航、下单等功能，这些功能可以定义为模块，而模块之间需要的数据分发和数据存储服务（如 Kafka、Redis）可以看作不同的组件。因此，概括起来说，模块是进入系统后从业务层面来划分的概念，而组件是从技术层面来划分的概念。

1.1.3　组件与框架

组件在上面已经阐述了，那么框架又是什么呢？框架是对实现某个技术组件服务规范的一种定义。例如，Web系统的MVC规范可以认为是一套框架定义，消息队列的数据传输规范也可以认为是一套框架定义。而组件可以认为是对框架的一种具体实现，例如Kafka是实现消息队列框架的一个组件。