打造千万级流量秒杀系统第四课 系统架构：如何设计秒杀的系统架构？

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

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

设计软件的系统架构。

为什么要重视架构设计呢/p>

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

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

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

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

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

秒杀系统架构设计

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

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

逻辑架构

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

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

表现层

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

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

逻辑层

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

数据层

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

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

秒杀物理视图

数据架构

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

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

那这几大数据都包含哪些属性呢/p>

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

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

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

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

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

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

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

数据视图

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

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

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

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

小结

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

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

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

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

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

精选评论

**翔：

很有帮助，以前每次写文档都没有系统性思维，从别人手里交接的没文档的项目也不知道如何入手，现在清晰很多，例如开发视图和项目结构类似，运行视图应该就是关键业务逻辑的流程图和时序图吧

    讲师回复：

    运行视图是指系统内部的运行时状态，比如每个进程、线程、协程负责做什么事情，程序内部状态流转等。

**哈：

不错，受益匪浅。

**1279：

写得很好，老师能不能给个样例文档让我参考谢

    讲师回复：

    可以参考 http://www.360doc.com/content/20/0903/16/36739237_933797007.shtml

**强：

没有涉及库存扣减相关的 aba问题 分布式事务怎么处理多服务项目间的调用 这个做秒杀很重要的么

    讲师回复：

    库存数据只需要达到最终一致，使用 MQ 做事件驱动加上 Redis 事务即可。增加/扣减库存时用 Redis 事务做原子操作，每次扣减库存时生成一个唯一 ID，归还时带上该唯一 ID 用于做幂等操作。下单出错或者关单归还库存时可以通过 MQ 异步做最终的事务补偿。