春节引流活动百万级高并发、高性能下单系统架构设计和实现

摘要

百万级高并发规模是整个电信行业前所未见的，放眼整个互联网行业这种规模也是极少出现的量级，高并发架构设计不能简单的根据已有的其他行业的经验进行借鉴，需要根据实际业务功能进行设计和实现。业务上，对各功能模块进行拆分、解耦是整个设计的基础，技术上，需要根据业务尽量将流程设计成异步化、服务化，数据存储和处理方面引入分布分表、读写分离、缓存技术，总体设计上考虑分布式、云化、容器化部署方式，同时为了防止出现故障引入监控功能和熔断机制。所有的系统都不是万无一失的，所以设计过程还需要考虑故障的自动恢复以及应急预案处理。

关键词：高并发；架构设计；分布式；容器化；缓存

一、背景

为更好的推动联通移网用户的发展，2019年底总部电子商务中心牵头与腾讯、阿里、快手、字节跳动等各大头部互联网公司合作，利用各互联网业务触点进行引流，分享春节期间流量红利。各大互联网公司的引流活动集中在小年到初一的9天时间内，大多数活动都是集中曝光，仅快手一家公司预计的曝光量为20亿人次，预估联通引流页面的QPS至少170万次，所有活动累加总QPS预估300万次，这个规模是开发人员从未接触到的，在整个电信行业是前所未见的，放眼整个互联网行业这种规模也是极少出现的量级。

除了面临解决超高并发系统结构设计的重量级任务外，电商中心的开发人员还面临这时间紧急的问题，从接到任务到全面上线只有1个月的时间，这就要求整体的高并发设计不能过于复杂，要考虑到短时间内实现的可用性。

二、架构设计

（1） 业务描述

春节引流活动旨在发展联通新用户，主业务流程主要涉及到的系统为下单系统、订单系统、交付系统（码上购等），同时需要调用软研院的选号系统的选号和占号外围服务，同时涉及到相关联的监控系统、报表系统、短信等相关外围系统能力。主要业务模式为互联化通过各类春节活动，如腾讯手机QQ的福袋活动、快手春节联欢晚会的红包活动、支付宝的集五福活动等，聚集大量用户流量，吸引用户到达相关的APP等互联网触点，联通通过与大互联网公司合作将自有的号卡下单页放置于大流量的触点上，从而达到发展用户的效果。

（2） 原系统现状

原系统主要部署在西红门的本地机房，承载这常规下单、审单及交付功能，系统能力可承载5万QPS。相较于内部其他系统，5万QPS已达到了不错的系统性能，但距离预估的300万QPS的目标还有很大的差距。

（3） 高并发设计关键流程

3.1 业务分析，对业务功能进行拆分、解耦

通过业务分析，我们认为主要承担超高并发的子系统为下单系统，因后续的订单系统不需要太高的数据实时性，用户下单后可通过异步的方式将数据传输到订单系统进行生产。而在下单系统中，再继续拆分，相对于下单应用服务，下单页面需要承担最原始的300万QPS，而从下单也到下单服务肯定会有一定的衰减。所以我们将整体的业务拆分成下单页面、下单服务、后续生产系统，承载的并发量由高到低，之后在技术分析层面有针对性的进行设计和优化。

我们将下单系统进行拆分，拆分主要涉及到页面和服务两个方面。

3.1.1 系统页面

系统的主要页面拆分为四个：落地页、信息填写页、选号页、下单成功页。

① 落地页只是对于活动和产品的说明，主要为静态的文字和图片资源，最下方一个按钮可跳转至信息填写页。

② 信息填写页主要是用户相关信息的输入框，如姓名、身份证号、联系方式、邮寄地址等，最下方一个按钮可进行下单，该下单过程调用下单服务中的意向单下单接口，将相关用户信息入库，同时调用号卡系统的选号服务，号卡系统会返回当前可选的手机号码，最终跳转到选号页。

③ 选号页可显示用户当前可选的号码，用户可在选号页进行选号、搜索、翻页等操作，最下方有确定键按钮，当用户选定号码后点击确定键，则调用系统的选号服务，选号服务外部调用号卡系统的选占接口，选占成功后调用系统的下单服务的正式单下单接口，将所选号码相关的数据入库，成功后跳转至下单成功页。

④ 下单成功页是简单的成功提示页面，没有交互功能。

3.1.2 应用服务

系统的主要服务拆分为两个：选号服务和下单服务。

① 选号服务主要功能为调用外围号卡系统的选占接口，因可能存在大量的恶意刷号行为，所以需单独成为独立的服务。

② 下单服务主要有选占子服务、意向单下单子服务和正式单下单子服务，其中选占子服务是调用外围号卡系统的选号接口。

3.2 技术分析，多个环节提升系统性能

经过业务分析对业务系统进行的拆分，按照业务特点，遵循分层设计原则，从以下12个方面进行高并发、高性能系统设计。具体架构如见图1。

图1 高并发系统架构设计图

3.2.1 CDN资源缓存，提升静态资源访问效率

考虑到春节活动参与人数之多、并发量之高，活动页面需要大量静态加速资源，如图片、html页面文件、css/js文件等，经过数轮页面调整、压测和评估，最终确认预估带宽使用量3Tbps~5Tbps，面对如此巨大的带宽资源，必须将这些静态资源需放置到CDN服务中。

CDN的全称是Content Delivery Network，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

CDN服务是整个活动的第一道关卡，是承担带宽、用户访问量最大的一环。因活动支撑启动较晚，协调CDN资源时才得知快手、抖音、央视等互联网公司两三个月之前已将全国的CDN资源提前锁定，市场CDN资源严重紧缺。于是最终采用多家CDN厂商提供的服务，每个厂商提供500Gbps~1Tbps的资源，按CDN厂商分配多个活动域名进行资源缓存。同时，动态请求也经过CDN厂商提供的动态加速服务，保证动态请求的最佳路由。

3.2.2 DNS轮询，实现公网出口负载均衡

在DNS服务器中配置一个域名对应解析到多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。因引入了CDN服务，这个配置严格意义上来说不是在联通相关域名的DNS服务器中配置的，DNS服务器只是配置了相关域名对应的CNAME，而实际的IP轮询是在CDN服务的DNS服务器中配置的。

当用户访问下单页面进行下单操作时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问，此方式能实现机房间的负载均衡。

至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。

3.2.3 反向代理，实现应用负载均衡

我们在多台服务器上分别部署应用服务，使用反向代理软件把请求均匀分发到每个应用服务中。后续将介绍系统整体大部分部署在阿里云上，所以反向代理软件选用SLB服务。

系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理。当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。

此处假设单个应用服务最多支持100个并发，SLB最多支持50000个并发，那么理论上SLB把请求分发到500个应用服务上，就能抗住50000个并发。

其中涉及的技术包括：Nginx、HAProxy，两者都是工作在网络第七层的反向代理软件，主要支持http协议，还会涉及session共享、文件上传下载的问题。

3.2.4 应用服务与数据库分开部署，提升应用服务效率

应用服务与数据库分开部署，可显著提高两者各自的性能。一般来说应用服务是做一些逻辑运算处理，数据库做数据的查询、插入和更新，一般来说应用服务的效率是高于数据库的，二者统一部署数据库将成为应用服务的瓶颈，所以应用服务与数据库分开部署，能够有效提升应用服务的效率。

3.2.5 应用服务分布式部署，提升应用服务吞吐能力

单个应用由于自身物理机的CPU、I/O、内存等限制，终将达到能力的极限，多台物理机、多个应用服务可增加整体的物理资源和服务能力，通过前边提到的负载均衡的配合，可以有效分配资源，提升应用服务吞吐能力。

3.2.6 大应用拆分为小应用，提升单应用的处理能力

按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。之前提到的将下单系统的应用服务拆分为选号服务和下单服务即为此策略的实现，避免了两个服务在系统中的相互影响，提升了单应用的处理能力。

3.2.7 数据库分布式、读写分离、分库分表，提升数据库读写效率

把数据库划分为读库和写库，读库可以有多个，通过同步机制把写库的数据同步到读库。对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过缓存获得最新数据。

我们选用了阿里云RDS数据库和DRDS数据库中间件来实现数据库分布式，通过DRDS组织数据库的读写分离和分库分表，客户端通过它来访问下层数据库，还会涉及数据同步，数据一致性的问题。

业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能。数据库按业务分库，把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑。我们把下单业务的数据库单独拿出来，与后续生产和交付的数据库完全独立。

使用sharding-jdbc实现了分库分表，大大降低了数据库运维的成本，并且使数据库也能够实现水平扩展，可支撑的并发大幅提高。

3.2.8 日志及数据传输异步化，较少日志系统及后续主流程系统的并发量

对于没有实时性要求的业务，我们选用异步化处理，比如日志输出和到后续生产系统的数据传输。日志主要是为问题定位提供方便的，同时在我们的下单系统中也承担着备用数据源的作用，该功能不是必须同步和实时的，所以选择异步日志处理。下单数据传输至后续的生产系统按照之前的业务分析，该过程也不是必须实时的，即使数据实时传输，后续的生产人力也无法实时完成处理，所以数据传输的异步处理既增加的下单系统的处理能力，又较少了后续生产系统的并发压力。

3.2.9 引入容器化技术，实现运行环境隔离与动态服务管理

目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)，应用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署和运维变得简单。我们也选用了Docker来部署相关应用服务，同时使用K8S来进行容器管理，实现了运行环境隔离与动态服务管理。

3.2.10 以云平台承载系统，提升系统部署效率

使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，由于时间紧迫，不能保证在短时间内采购到足量的物理主机，所以选择了使用阿里云来承载系统，一方面解决了机器数量不够的问题，另一方面也提升了系统的部署效率。

因后续的生产系统都部署在本地机房，下单数据首先落在阿里云上的数据中，之后通过数据抽取将数据传输到本地机房，进行后续的生产流程。具体网络部署图见图2。

图2 系统网络部署图

3.2.11 引入监控功能和熔断机制，保障系统的运行稳定性

我们使用了阿里云的ARMS和AHAS服务来实现针对系统的监控和熔断功能。我们配置监控了系统的全流程，用来试试观察系统的健康状况，通过监控发现问题来及时应用防止系统崩溃。我们在主服务入口配置了流量控制，防止系统雪崩，避免应用被瞬时的流量高峰冲垮，从而保障应用的高可用性，同时在外部服务调用配置了熔断降级，即限制不稳定资源的调用，让请求快速失败，避免影响到其它的资源而导致级联错误。

3.2.12 应急预案处理，故障出现后快速切换恢复

整体活动系统架构方案必须确保万无一失，一旦出现不可控因素导致出现系统故障，都应该及时进行切换，恢复系统，这就要求必须在系统架构设计时考虑到所有的故障点，提前设计好所有的应急预案，同时也在本地机房部署一套系统用于备用。我们在架构设计的同时，总结和演练了80余个故障点的应急处理，如CND服务切换、本地应用服务切换等。

三、分析总结

随着移动互联网的不断发展，流量成为越来越重要的资源，与之相匹配的，必须保证互联网系统的高性能，才可以满足日益增长的流量需求，因此高并发、高性能系统架构的设计在当今互联网行业应用中占有举足轻重的作用。

此次春节引流活动系统架构，最终在2020年春晚当天成功持续稳定运行，承担了瞬时200万QPS的系统压力，完成了近300万订单的用户发展，一个多月的加班、熬夜、通宵的架构设计、技术演练为此次活动奠定了坚实的基础。

通过此次百万级高并发、高性能的系统架构设计，也让联通在整个通信行业异军突起，不断顺应互联网行业的快速发展，不但积累了超高并发系统架构设计经验，也在中国联通的互联网化转型的路上走出了坚实的一大步。