你好，欢迎进入模块二的系统架构设计。

前面 3 讲我们介绍了如何分析功能需求和非功能需求，按照一个软件项目开发流程，接下来我们要做什么呢？

设计软件的系统架构。

为什么要重视架构设计呢？

软件的系统架构和我们盖房子有许多相似的地方。你可以想下，一栋大楼是怎么盖起来的？

它先是通过建筑设计院，在图纸上把大楼外观、主体结构、材料工艺、施工流程等设计好后，交给施工队来施工。施工队根据图纸，打好地基，并开始建设能满足抗震、抗风、抗酸碱、抗沉降等必备条件的大楼主体框架，然后再浇筑墙体和封顶、做外墙施工，以及最后的室内装饰。

建筑设计院对主体结构的设计，在软件工程中便是架构设计；大楼的主体结构在软件工程中就是架构，它主要处理软件的子系统和组件的开发和部署方式、技术指标和规范，以及它们之间的相互关系。

想象一下，一栋 100 层的大楼，如果没有设计院提供的图纸，施工队要怎么施工？即使施工队造出来了，谁能保障大楼可以扛住狂风暴雨呢？系统架构之于软件，就像设计图纸之于楼房，架构设计对它非常重要。

架构设计方法

架构设计都有哪些方法呢？架构设计遵循特定的方法，比如 TOGAF（The Open Group Architecture Framework，开放组体系结构框架）、五视图方法等。其中 TOGAF 主要针对复杂的企业系统架构，比较重，不大适合迭代速度非常快的互联网产品，所以互联网公司常用的主要是五视图方法。

什么叫五视图方法？它是指从业务逻辑、开发环境、运行状态、物理部署、数据关系等方面绘制出相应的逻辑视图、开发视图、运行视图、物理视图、数据视图来设计架构。 其中，逻辑视图、开发视图、运行视图属于软件架构的内容，物理视图、数据视图属于系统架构的内容。

接下来我就一一展开介绍下。

逻辑视图：对应逻辑架构，主要关注功能需求，以及系统职责和行为的划分。逻辑视图不仅包括用户可见的功能，还包括相应的辅助功能。比如秒杀系统中的活动场次切换、商品列表、用户登录、活动管理、后台权限等功能，其中后台权限属于辅助功能。

开发视图：对应开发架构，主要关注系统开发过程中的质量属性。它包括软件源码的组织方式、配置方式、编译打包方式以及与第三方包的依赖关系等。

比如，我们这里介绍的秒杀系统，采用的是 Go 语言开发代码，使用的是 TOML 格式存放配置，还有 Gitlab 执行编译打包等。

运行视图：对应运行架构，主要关注软件运行过程中的质量属性，它包括进程、线程、协程、对象之间的并发、同步、通信的问题等。

比如，秒杀系统在运行时有用于从队列消费数据的协程，有用于过滤请求并将有效请求写入队列的协程，这就需要好的设计来解决它们之间并发、同步、通信的问题。

以上是五视图法中软件架构方面的内容，接下来咱们看另外的两个，属于系统架构方面的内容。

物理视图：对应物理架构，主要关注安装和部署需求。它包括软件运行时的系统、网络、服务器等基础设施和相关配置，以及如何利用基础设施来实现应用程序的高可用、可伸缩等。

比如秒杀系统使用云厂商的 SLB（Server Load Balancer，负载均衡器）来提供负载均衡能力，使用云厂商的多可用区来实现高可用。

数据视图：对应数据架构，主要关注数据需求，它包括数据的格式、属性、关系等。

比如，秒杀系统中活动场次与活动主题、活动商品的关系和属性，管理员可以通过管理后台创建、修改和删除活动主题、场次、商品等。

为什么软件架构设计需要这些视图呢？它们是为了解决什么问题呢？

俗话说“一图抵千字”，架构设计中的五视图就好比建筑工程中大楼的各部分施工图，可以让我们更容易理解各自需要完成的工作。

比如，研发人员一看逻辑视图、开发视图、运行视图、数据视图，就知道要开发哪些功能、如何实现、如何部署；运维人员一看物理视图，就知道基础设施需要怎么部署；测试人员一看数据视图，就明白如何通过一系列的操作来验证数据的准确性。

秒杀系统架构设计

前面我们介绍了架构设计的方法，以及为何要做架构设计。那么秒杀的系统架构该如何设计呢？

接下来我就用刚才提到的五视图方法来介绍下。

逻辑架构

从前面的定义我们了解到，逻辑架构关注的是功能需求。还记得我在模块一里面提到的小米网秒杀系统的那些功能需求吗？当时介绍了秒杀系统的前端、后端及管理后台的需求分析，比如活动信息管理、活动详情、商品详情等，这些需求分析结果就是为了设计逻辑架构。

系统前端、后端和管理后台的需求有那么多，我们该怎样组织那些需求信息呢？在逻辑架构中有一个“三层架构”法可以帮我们解决这个问题。哪三层呢？它们是表现层、业务逻辑层、数据层。

表现层

所谓表现层，简单来说是指用户可以通过哪些方式使用系统功能。通过需求分析我们了解到小米网秒杀系统的主要使用者有：消费者、管理员。其中消费者可以通过电脑 Web 端、手机 Web 端、手机 App 端获取秒杀的活动信息、商品信息；管理员可以从电脑 Web 端访问管理后台管理秒杀活动。

这里的电脑 Web 端、手机 Web 端、手机 App 端主要用来向用户呈现秒杀的活动信息、商品信息，并提供相关操作的入口，比如购买和后台维护，它们属于表现层。

逻辑层

逻辑层主要是和业务逻辑相关，比如秒杀系统的前端功能主要包括有用户登录、查看活动、订阅通知、查看商品、抢购、下单等；管理后台的功能主要包括有专题管理、场次管理、商品管理、库存管理、价格管理、限购管理等。这些都跟秒杀业务逻辑相关，所以我们可以把相关需求归于逻辑层。

数据层

数据层是指系统的业务逻辑需要处理哪些数据。比如，秒杀系统的数据包括配置数据和用户数据，其中配置数据主要是活动信息和商品信息，用户数据主要是用户订单和用户信息，他们就可以归于数据层。

最终，我们得到逻辑视图如下图所示：

物理架构

秒杀的物理架构都有哪些内容呢？

首先，为了实现动静分离，我们需要部署 CDN 节点，将秒杀系统静态页面和静态数据利用 CDN 缓存起来，以便利用 CDN 的就近访问能力提供更高的性能。比如我们可以在中国和新加坡都部署 CDN 节点，以便为中国用户和海外用户提供更好的访问速度。

第二，动静分离意味着除了 CDN 外，我们还需要部署秒杀后端节点。

更多课程访问：https://shop.exp-9.com

为了实现秒杀后端节点的高可用，我们需要使用云架构保障其基础设施层的高可用。而且需要部署到云的多个可用区，防止单一可用区发生故障影响服务。

比如，使用两个可用区，每个可用区使用两台机器。每台机器访问存储的时候，采用主备方式，优先访问当前可用区内的存储，如果当前可用区内存储有故障，自动切到其他可用区的备用存储。不同可用区之间的存储，采用高速专线同步。

第三，为了将不同可用区作为一个整体对外提供服务，我们需要部署路由器、防火墙、交换机、SLB（Server Load Balancer，负载均衡器）。

其中，路由器是负责接收外网请求并转发到内网；防火墙负责过滤掉有风险的数据，比如过滤掉黑客发起的网络攻击；交换机负责将请求转发到具体的可用区内；SLB 是负载均衡器，它可以将可用区内多个节点作为一个整体对外提供访问，并将请求均衡地转发到后端各节点。

SLB 之间采用主备的方式部署，如果可用区 1 的 SLB 挂了，可用区 2 的 SLB 会自动接管属于可用区1 的流量，并将流量转发给可用区 1 内的云主机。

第四，部署完各节点后，还需要设置域名解析，将域名解析到我们部署的 SLB 外网 IP 上。通常，对于流量大的系统，会采用多个负载均衡器，然后使用动态 DNS 解析的方案做多个 SLB 的 DNS 负载均衡，以防单个 SLB 无法扛住大流量。

最终我们得到的物理视图，如下图所示：

数据架构

数据架构通常用 E-R 图（Entity Relationship Diagram，实体-联系图）表示，我们通常用它来表示数据对象与属性、用户之间的关系。

在需求分析过程中，我们了解到秒杀系统主要有两大主要数据：活动信息和商品信息。除了这两大主要数据外，还有两大次要数据：订单和黑名单。其中订单是用户抢购商品并下单生成的，而黑名单是为了反黄牛而设计的，通常通过大数据分析统计生成，如果用户 ID 在黑名单中，则不允许抢购商品。

那这几大数据都包含哪些属性呢？

结合需求分析过程，我们得知：

• 活动信息，包括专题、场次、描述、时间、限购策略、商品列表、状态等信息；

• 商品信息，包括商品 ID、名称、描述、规格、原价、活动价、活动库存等信息；

• 订单信息，包括订单 ID、用户 ID、商品 ID、商品价格、商品数量、总价、收货地址、创建时间等信息；

• 黑名单，包括用户 ID 列表。

这些数据中，活动信息、商品信息、黑名单都是由管理员在管理后台管理的，只有订单信息是由用户在商城下单创建的，管理员可以通过管理后台查看订单信息。

我们将这些数据绘制成 E-R 图，如下图所示：

以上是五视图法里对应的逻辑架构、物理架构、数据架构。

其中物理架构用于指导运维工程师部署软件，以便实现基础设施的“三高”；数据架构用于指导开发人员做数据库表设计，以及指导测试人员进行软件功能测试时检查数据准确性。

严格来讲，逻辑架构属于软件架构而不是系统架构。那为什么我要给你介绍逻辑架构呢？主要是因为它能帮助我们从顶层了解系统的功能划分，从而更方便进行系统架构设计。

另外的开发架构、运行架构关注的是软件的开发和运行阶段，主要用于指导研发人员开发代码和运行程序，因为涉及实战，我会在后面的模块六~模块十详细介绍， 到时可以留意一下哦。

小结

好了，到这里咱们这一讲就介绍完了，我主要介绍了架构设计当中最常用的五视图法，以及如何用它来设计秒杀的系统架构。

有了系统架构设计图，我们对整个秒杀系统的功能逻辑有了进一步认识：有哪些人用它，它要处理哪些数据，它是如何部署的。这对后续研发人员开发和发布软件、测试人员进行功能测试、运维人员部署基础设施都非常重要。因为它可以有效减少沟通成本，提高工作效率。

试想一下，如果拿着需求文档直接去找测试、运维去沟通，他们能清晰得理解你的意图吗？

思考题：在数据视图中，我们提到了订单数据，那么你能想到订单中心的系统架构该如何设计吗？

下一讲我将为你介绍如何使用领域驱动设计（DDD）为秒杀系统划分业务边界，到时见。