第1章

架构的基础概念

到底什么是架构？对于这个概念，不同人可能有不同的定义，甚至存在一些争议。我们先来看一下一些标准机构对这个概念的定义。

参考ANSI/IEEE的标准定义，架构是一系列组件之间的组合、交互和继承的关系。

参考维基百科对架构的定义，架构是对建筑物或者其他物理结构规划设计的一个过程。

看了以上对架构的定义之后，读者有什么感觉？是不是感觉过于抽象？那么，如何用一种更直观的方式来阐述架构呢？首先，我们用架构的几个概念来明确一下它的界限和范围。

1.1

架构的几个概念

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

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

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

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

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

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

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

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

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

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

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

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

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

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