秒杀系统总体方案目标与架构设计
在前面的文章中，梳理了秒杀系统的需求和业务流程，并对秒杀系统的技术流程进行了总体梳理，不管是从业务角度出发，还是从技术角度出发，都大致了解了秒杀系统的执行流程。从业务和技术角度了解秒杀系统的执行流程后，接下来，就要制定方案目标和总体架构设计了。
一、前言
相信很多小伙伴都有多这样的体会，接到需求后，如果不做全面的需求分析、系统分析和架构设计，一上来就干代码，往往在开发中途就会发现代码不太符合需求，或者突然发现有更好的实现方式，大部分时候，已经来不及将代码推倒重来，只能在原有代码的基础上苦苦支撑。最终，原本设想的高并发、高性能、高可用和高可扩展的代码，却变成了一坨 “屎山”。
二、本章诉求
作为系统架构师和研发人员，在充分了解了系统需求、业务流程和技术流程后，就需要为系统设定方案目标，制定技术方案选型，对系统进行总体架构设计和分层架构设计。从全局视角充分理解秒杀系统的方案目 标、技术选型、总体架构和分层架构，以指导后续秒杀系统的具体实现。
三、方案目标
在进行技术选型和总体架构设计之前，需要明确一个事项，就是系统无论采用何种方案，采用何种架构设计都需要明确这种方案的业务目标、技术目标和架构目标，并在研发过程中不断评估系统的总体性能表现，发现系统瓶颈并不断进行优化。
总体上，无论采用何种方案实现秒杀系统，都要实现如下方案目标。
- 业务目标：满足用户故事中的各类场景。
- 技术目标：秒杀商品详情页接口：10W+QPS，秒杀接口：1W+TPS。
- 架构目标：高并发、高性能、高可用、可监控、可预警、可伸缩。
四、技术选型
在技术选型上，除了采用 SpringBoot 等基础框架外，也会采用容器化方案。为了尽量降低技术门槛，在整个秒杀系统的技术选型中，主要采用市面上比较主流的技术框架和方案，具体技术选型如下所示。
- 开发框架：SpringBoot。
- 缓存：Redis + 本地缓存。
- 数据库：MySQL。
- 业务网关：SpringCloud Gateway。
- 持久层框架：MyBatis。
- 服务配置与注册发现：Nacos。
- 容器：Docker。
- 容器化管理：Swarm、Portainer。
- 监控：Prometheus、Grafana。
- 系统限流：Nginx+Lua、Sentinel。
- 消息中间件：RocketMQ。
- 单元测试：Junit。
- 压测工具：JMeter。
五、一般系统架构设计
如果是按照一般系统的架构设计方案来设计秒杀系统的话，相信大部分小伙伴会将秒杀系统的架构设计成如图 6-1 所示。
这种架构设计也是比较常见的，在这种架构设计中，Nginx 只做负载均衡和反向代理，研发人员更多的是关注 Web 服务层和基础服务层的开发。虽然这种架构设计在一般的系统中没什么问题，但是放到秒杀系统中，会存在很多问题。
（1）Web 服务性能问题
Nginx 只提供负载均衡与反向代理的功能，大部分流量会直接进入 Web 服务层，Web 服务层一般会采用 Tomcat 作为服务器。了解 Tomcat 的小伙伴都知道，Tomcat 是通过线程池来处理请求。如果大部分流量都直接涌入 Tomcat 的话，Tomcat 就会瞬间接收大量的请求，如果 Tomcat 线程池中的线程设置的比较小，很容易导致 Tomcat 线程池中的线程不够用，继而 Tomcat 中线程池的等待队列会被占满，后续的请求会被拒绝，并且 Tomcat 会持续高负载运行，最终导致系统卡顿。如果 Tomcat 线程池中的线程数设置的过大，很容易将 CPU 打满，到时机器卡死，即使没有卡死，当 Tomcat 中线程池的等待队列被占满后，后面的请求也会被拒绝掉，总体上的表现就是性能很差，并且会有很多请求被拒绝掉。
（2）拉取资源填充数据性能问题
这种架构设计无论是将静态资源放在 Nginx 中，还是放到 Web 服务层，对会表现的比较卡顿。因为大量请求涌入 Web 服务层，会大量的调用相关的接口，导致 Web 服务层变得卡顿，后续请求进入系统后，加载静态资源，例如静态页面后，静态页面会调用接口获取数据，由于接口此时变得非常卡顿，就会导致静态资源上的数据加载缓慢，直接表现就是页面无法正常加载，拉取资源填充数据性能很差。
六、秒杀系统总体架构设计
可以在一般系统架构设计的基础上，进行优化设计，来满足秒杀业务场景的需求，优化后的秒杀系统屏蔽掉技术细节的架构设计如图 6-2 所示。
对比图 6-1 和 6-2 可以看出，在屏蔽掉技术实现细节的前提下，在秒杀系统的架构设计中，会将静态资源放到 CDN。并且对业务校验和流量管控进行前置化，放大 Nginx 的职责。使得 Nginx 不仅具备反向代理和负载均衡的功能，还能实现限流、黑白名单、流量管控、业务校验等，并且在 Nginx 层面也能实现直接查询商品数据返回给客户端。
也就是说，在这种架构模式下，充分利用 Nginx 的高并发、高吞吐的能力，尽量将大部分刷单流量和无效请求拦截在 Nginx 层，使得进入系统的流量是真正的有效流量，这样会大大减轻业务系统的压力。
除了在 Nginx 中实现限流、黑白名单、流量控制、业务校验等功能外，为了进一步保证下游系统的安全，在 Web 服务层也可以实现限流、降级、流控、业务校验、服务降级等流量管控措施。
经过一系列的流量处理措施，进入基础服务层面的流量已经相对比较小和可控了。那么问题来了：这种架构设计还有进一步优化的空间吗？
七、秒杀系统容器化架构设计
为了进一步增强秒杀系统的性能、可用性和弹性伸缩性，可以对秒杀系统的架构设计进行进一步优化，采用容器化架构设计，如图 6-3 所示。
由图 6-3 可以看出，对秒杀系统进行容器化架构设计优化之后，总体上会分成客户端、流量入口、系统网关、应用服务、容器化和基础支撑服务等。
（1）客户端
客户端主要包括 PC、H5、APP 和小程序，可以将 PC 和 H5 等静态资源发布到 CDN 服务器，来加速静态资源的加载速度。
（2）流量入口
主要由 Nginx 负责流量的入口，此处同样会放大 Nginx 的职责，除了常规的反向代理和负载均衡外，Nginx 还会提供限流、黑白名单、流量控制、业务校验和商品数据查询等功能。也就是说，在 Nginx 层会做一些业务逻辑处理。
（3）系统网关
系统网关层除了做路由功能外，还提供限流、熔断、鉴权与安全的功能，可以使用 SpringCloud Gateway 结合 Sentinal 实现。
（4）应用服务
在应用服务层，除了做业务开发外，需要考虑本地缓存、分布式 缓存、缓存数据一致性，这里缓存数据一致性包括本地缓存与分布式缓存，缓存与数据库数据的一致性问题。同时，在应用服务层采用动静分离的模式，将动态资源与静态资源进行隔离，并进行业务校验与业务隔离，在数据的序列化与反序列化上进行优化。同时在业务处理层面，尽量做到数据精简和简化相关的计算逻辑。
（5）容器化
在容器化层面，会通过 Docker、Swarm 和 Portainer 实现，其中，会基于 Swarm 和 Portainer 对容器化进行管理。
（6）基础支撑服务
基础支撑服务层主要是由一些基础的中间件实现，包括：MySQL 数据库、Redis 缓存、RocketMQ 消息队列、Prometheus 监控和 Portainer 容器管理等基础中间件实现，基础支撑服务会对整个秒杀系统提供最基础的数据、传输、监控和容器管理等服务。
（7）其他功能实现
除了上述分层架构外，对于建设秒杀系统来说，还要考虑异常监控、服务注册与发现、可视化、服务降级与兜底数据、服务限流、服务容灾、容量规划与扩缩容和全链路压测等。
八、DDD 分层业务架构设计
对于秒杀系统的代码业务层，可以借鉴 DDD 的分层架构思想，将代码总体上分成展示层、应用层、领域层和基础设施层四个层次，如图 6-4 所示。
这里，秒杀系统会借鉴 DDD 的设计思想，但是不会完全按照 DDD 的方式进行设计。
（1）展示层
展示层，也叫做用户 UI 层，是 DDD 设计的最上层，对外提供 API 接口，接收客户端请求，解析参数，返回结果数据，并对异常进行处理。
（2）应用层
应用层，也叫做 Application 层，应用层主要处理容易变化的业务场景，可对相关的事件、调度和其他聚合操作进行相关的处理。
（3）领域层
领域层，也叫做 Domain 层，领域层可以说是 DDD 设计的精髓所在，它是将业务系统中相 对不变的部分抽象出来封装成领域模型。
在秒杀系统的设计中，领域层基本不会依赖其他层，也不会依赖基础设施层，这里是与 DDD 设计存在区别的地方。
（4）基础设施层
基础设施层，也叫做 Infrastructure 层，基础设施层会对其他各层提供通用的基础能力，在秒杀系统中，就包括了缓存、通用工具类、消息、系统的持久化机制等。
九、总结
本章，主要对秒杀系统的总体方案目标和架构设计进行了详细的阐述。首先确定了方案的目标并对系统的技术选型进行了描述。在阐述秒杀系统的架构设计时，首先介绍了一般系统的架构设计，指出了一般系统的架构设计在秒杀场景下的不足，并基于一般系统的架构设计升级优化，对秒杀系统的总体架构设计进行了阐述。为了进一步增强秒杀系统的性能、可用性和弹性伸缩性，对秒杀系统的架构设计进行了进一步优化，采用容器化架构设计。最后，在业务代码层面，阐述了 DDD 分层的业务架构设计。