04课 - 系统架构:如何设计秒杀的系统架构?(秒杀系统)

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

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

设计软件的系统架构。

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

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

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

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

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

架构设计方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

秒杀系统架构设计

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

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

逻辑架构

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

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

表现层

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

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

逻辑层

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

数据层

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

最终,我们得到逻辑视图如下图所示:

image.png

image.png

物理架构

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

首先,为了实现动静分离,我们需要部署 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 无法扛住大流量。

最终我们得到的物理视图,如下图所示:

image.png

数据架构

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

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

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

结合需求分析过程,我们得知:

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

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

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

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

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

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

image.png

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

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

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

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

小结

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

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

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

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

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


相关文章

02课 - 功能需求:秒杀活动信息是如何管理的?(秒杀系统)

02课 - 功能需求:秒杀活动信息是如何管理的?(秒杀系统)

上一讲我们介绍了秒杀业务背景和前端需求是怎么产生的。回想一下,你在秒杀活动的前端页面能看到什么?有活动场次信息,比如第一场、第二场,以及对应每个活动场次的详情及规则,有商品的名称、价格等基本信息,还有...

课程表:打造千万级流量秒杀系统(秒杀系统)

收集不容易,访问 https://shop.exp-9.com/#/goods?goods_id=2  获取所有课程内容课程列表:00 开篇词秒杀系统的“三高”架构是怎么炼成的?....

01课 - 功能需求:秒杀业务背景及前端需求是怎么产生的?(秒杀系统)

01课 - 功能需求:秒杀业务背景及前端需求是怎么产生的?(秒杀系统)

先问你一个问题:为何我们要在项目开始前要先了解业务背景和需求?拿到一个项目,你也许能从技术层面上做出来,但你真的知道为何要做这个项目吗?如果没有充分了解业务背景和需求,你能确保自己理解项目的业务价值吗...

03课 - 非功能需求:高可用、高性能、高并发的指标如何计算?(秒杀系统)

03课 - 非功能需求:高可用、高性能、高并发的指标如何计算?(秒杀系统)

你好,欢迎来到第 03 讲,这一讲主要介绍秒杀系统的非功能需求分析,特别是涉及高可用、高性能、高并发方面的内容。前两讲,我们介绍了秒杀系统的前、后端功能需求,许多人在做业务系统时会发现,虽然功能自测、...

开篇词  秒杀系统的“三高”架构是怎么炼成的?

开篇词 秒杀系统的“三高”架构是怎么炼成的?

记得那是 2016 年初,我做 IM 云核心服务开发。当时我们的核心服务是个大的单体应用,每到客户做活动的时候,系统的 CPU 负载都会超过 90%,请求错误率超 10%。更可怕的是,高负载导致已建立...

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。