高并发高可用的分布式电商平台架构研究

耿晓利，张 芒，尹永宏

(广州大学华软软件学院，广东 广州 510990)

0 引 言

微服务[1]具有模块化开发、分布式部署的特性，各个模块独立部署、运行更新，有着灵活的扩展性，适用于海量数据单体应用的解耦[2]。Dubbo[3]是阿里巴巴公司开源的一个高性能和透明化的PRC远程调用框架,搭配Zookeeper[4]作为分布式服务的注册中心，在如今高可用解决方案的技术选型中被广泛使用[5]。

基于分布式的架构技术正在不断发展，各大互联网厂商的分布式框架不断迭代，分布式架构在电商行业应用中蓬勃发展，较多文献对分布式架构下电商平台的构建进行了研究[6-8]，同时也向金融、政务、社交等领域逐步渗透。

该文以电商业务为切入点，以SpringBoot[4]和MyBatis作为实现基础服务单元的企业级基础框架，综合集成分布式开源框架Dubbo、注册中心Zookeeper、百度开源统一配置中心Disconf、消息中间件RabbitMq、Spring安全认证授权框架Spring Security[9]、缓存数据库Redis[10]等，采用前后分离的Restful Api[11]架构风格和Docker[12-13]容器化部署方法，设计并实现了基于B2C的新零售购物平台。系统通过服务化的手段，按照功能维度划分，使各功能服务中心最大限度地解耦，各服务通过注册中心自动完成服务的注册与发现，互相隔离，使用消息中间件技术进行消息订阅、异步处理、流量削峰等。

1 系统架构

本系统有用户中心、商品中心、营销中心、库存中心、物流中心、客服中心以及数据统计中心,各服务中心之间以RPC(远程调用)的方式进行通信，统一在Disconf配置中心下载各自指定的配置文件，同时以服务提供者的角色注册在注册中心Zookeeper上。控制器层作为服务消费者角色向注册中心Zookeeper订阅其需消费的服务，通过Nginx反向代理分发至不同客户端。系统采用Spring Security和Jwt作为安全认证授权框架，客户端登录到用户中心，用户中心将通过此框架向客户端发布带有加密用户信息的授权令牌(token)，并在此后用户访问中拦截其请求，校验令牌信息和验证用户身份是否正确，正确则放行，否则将拒绝此用户访问。

系统架构如图1所示。

图1 系统架构

1.1 应用层

系统架构应用层主要有移动端APP、微信小程序和WEB端后台管理系统。各不同客户端调用Nginx提供的统一接口访问地址，再通过Nginx将请求反向代理至服务层，在应用层中，Nginx将担负着负载均衡和限流的任务，在系统流量突然爆发的时间段，将流量按照调度算法均衡地分发至不同服务器，同时狙击恶意请求流量和恶意攻击；是洪峰流量进入后台服务的一道重要的安检口，也是保护系统平稳运行的重要关卡之一。在该系统设计中，应用层还有一个重要的功能：在高并发处理中使用Nginx降级策略，将牺牲一部分请求来保证系统的稳定，从而保证了系统的高可用性。

1.2 接口层

接口层在系统架构中扮演着服务消费者的角色，是应用层通过Nginx将请求分发的目的地。在接口层中，设计了基于Spring Security和Jwt安全授权访问过滤器，其主要作用是通过解析令牌(token)校验请求的合法性以及是否拥有所访问接口权限，保证接口安全。由于Jwt的认证方式是无状态的，可以在多个服务之间共享，加上生命周期的设置，实现了系统的SSO单点登录功能。

接口层通过订阅注册中心上的已发布的服务，完成应用层的请求和回应。该层提供Restful Api架构风格的调用地址，通过远程调用的方式完成与服务层之间的数据交互。

1.3 服务层

服务隔离是指将系统服务分割开，是为了在系统发生故障时，能限定传播范围和影响范围，即发生故障时不会出现像单体架构一样的滚雪球效应。在该系统架构中，注册中心的一个节点出现故障后，注册中心通过HTTP心跳检测会将该节点排除出服务提供者名单，自动切换其他可用节点，从而保证只有出现故障的节点不可用，其他节点仍然是可用的。该系统服务层是系统功能的具体实现，扮演着服务提供者的角色。按照系统功能维度划分不同的服务中心，各服务相互隔离、独立部署，拥有自己独立的数据库，是系统完成特定功能领域的集合；通过服务化的设计，将单体架构中捆在一起的服务抽离，大大地降低了系统功能耦合度，为系统功能的不断扩展和维护奠定了基调。在秒杀业务场景下，随着接口调用次数不断增高，此时的秒杀服务单节点的负荷率将直线上升，由于服务器资源的有限性，将直接影响到其他非秒杀业务的稳定性。如图2所示，该系统在设计中，将在商品服务中划分出以秒杀业务为核心的单独服务集群，从而解决了在秒杀业务洪峰流量到来之时，保证其他业务的稳定运行，不受其影响。

图2 服务集群分组

2 平台功能实现

2.1 系统基础服务层实现

系统中设计的公共类为基础服务层，在此层中集成了基础工具类、接口统一返回格式、各枚举类、各配置类等，作为系统底层服务提供给各业务服务中心使用。基础服务层最重要的一个功能是与统一配置中心Disconf交互，在项目启动时，将各配置文件从配置中心拉取到配置文件夹中，供各个服务中心使用；在此层中通过.xml文件配置扫描包所在位置以及使用托管方式的Disconf配置，其中包含配置文件名称等。如图3所示，在初始化Disconf项目后通过浏览器WEB界面录入配置文件名，所属模块，版本号，开发环境。此设计将系统繁杂的配置信息从系统内部抽离出，由配置中心统一管理，一旦配置信息如数据库地址改变，在配置中心修改即可，配置中心发生修改会立即通知程序重新拉取配置文件，而不必通过停止程序的运行去一个个地修改配置，从而大大提高了系统的执行效率和维护成本。

图3 统一配置中心Disconf配置录入

2.2 系统服务层实现

系统服务层在系统整体架构中扮演着服务提供者的角色，是系统各功能模块具体实现的汇集地，也是整个系统中业务处理能力要求最高的核心区域。该层使用了分布式搜索引擎ElasticSearch作为商品中心的商品搜索服务快速搜索框架，使用缓存数据库Redis完成商品详情信息、商品维度和用户维度存储等，使用开源中间件RabbitMq作为秒杀业务的通讯组件。

2.2.1 用户中心

在功能模块划分中，用户中心具有用户基础信息管理、用户行为管理、用户角色权限管理、用户地址管理、用户购物车管理、用户登录授权管理等功能。用户通过注册页面录入基础信息，系统根据普通用户和管理员设置不同权限，用户行为管理记录用户每次登录信息、搜索行为等。

2.2.2 商品中心

商品中心在整个服务层占据业务核心地位，根据业务细粒度划分有商品详情服务、购物车服务、订单服务、支付服务，评价服务，秒杀服务和库存服务等，业务详细流程如图4所示。用户浏览商品列表，选择商品查看详情，选择购买或者加入购物车后系统判断登录状态，未登录则完成用户登录流程后选择收货地址以及完成订单支付，订单支付后进入物流服务和评价服务。其中，当订单支付后以消息队列的方式通知库存服务进行库存调整操作。选择消息队列方式进行库存操作，是因为消息队列方式可以保证库存操作的原子性，避免订单数量超过及时库存数，造成负库存情况出现。其中秒杀服务独立于其他商品服务，划分为独立的服务分组，如图5所示，当秒杀业务开始时，用户订单支付后进入消息队列排队，消息队列根据及时库存数的3倍作为进入消息队列的请求数，将排队数量限制在一定的范围内，超过这个范围内的数量将直接返回秒杀结束的状态，成功进入消息队列的请求按照队列先进先出的原理，同时运用分布式事务机制[14]，将订单支付和库存服务作为事务管理，订单支付和库存数的递减同时完成，否则执行回滚操作。这样既减轻了队列的负担，又能保证库存服务的准确性和系统的稳定性。

图4 系统业务流程

图5 秒杀业务流程

2.2.3 营销中心

营销中心主要是为了完成商品优惠券发放、商品预热等功能。后台管理员通过优惠券面额、发放对象、使用期限等信息的填写，将优惠券存入系统表中，系统将以两种方式向用户发放优惠券，一种是以系统通知的方式向用户推送领取通知，用户点击通知跳转至领券页面完成优惠券领取，另一种方式是以用户查看商品详情的方式在商品详情页面放置优惠券领取栏，在用户查看商品的同时就可以领取相应的优惠券完成购买流程。商品预热功能主要是为了向添加在用户购物车里的商品推送商品降价信息，为了刺激商品交易额的增加，商品预热服务还将根据用户中心的用户行为服务获取到用户个人喜好，将通过个人喜好匹配相对应类型的商品，通过首页商品列表展示的方式向不同的用户推送。

2.2.4 物流中心

物流中心对接商品中心中的订单服务，完成用户订单支付后的物流信息跟踪、收货提醒等功能。物流中心对接阿里云物流接口，通过物流订单号以及快递公司名称的输入，获取到阿里云物流信息，将物流信息返回格式转换成系统显示格式以步骤条的形式显示在客户端，当物流信息更新至即将配送的状态，以系统通知的形式向用户推送收货提醒。

2.2.5 客服中心

客服中心使用WebSocket[15]实现，主要完成的功能是用户购买前的客服咨询功能以及购买后的售后功能。分为客服端和用户端，在聊天中支持商品链接发送、商品图片发送等功能。

2.2.6 数据统计中心

数据统计中心体现数据中台思想，主要统计周销量、月销量、季节销量、地区购买力、年龄段购买力等，完成不同维度销量对比，输出对应对比结果，以echart图表显示在后台WEB端，在抢购时间段，还将实时显示各商品销量，供商家进行实时库存调整。数据统计中心还将完成各类报表制作与查询，具体输出报表有销售报表、库存报表、财务报表等。

3 系统部署

为了适用分布式架构高并发高可用原则，系统部署采用Docker容器化部署方法，运行系统统一采用Linux发行版CentOS7.6,选用服务器16台，每台主机为8核3.0 GHz CPU,8 GB内存，阿里云OSS存储对象主要用来存储用户头像、商品图片等系统静态资源。在运行系统CentOS上通过Docker镜像分别配置分布式框架开发环境和上线环境，如图6所示，相应配置集成Tomcat、Nginx、Disconf、Zookeeper、Dubbo、Redis、MySql、RabbitMq等，各服务中心代码打成war包后将放置在对应的Tomcat实例里，保证各服务之间相互隔离，互不影响。

图6为CentOS集成示例。

图6 CentOS集成示例

4 性能测试

接口响应速率、CPU占有率和磁盘I/O是系统高可用性的重要性能指标，系统从这三个方面展开进行测试验证。

4.1 接口响应速率

接口响应速率测试是从同一并发量下不同数量节点接口响应速率和不同并发量下多节点接口响应速率两方面展开。同一并发量不同数量节点请求的商品列表显示效率，主要测试点是商品中心模块的商品详情服务，测试用例为并发量500，通过Jmeter脚本分别向不同节点的商品中心接口同时发起并发请求，结果如图7(a)所示，随着节点数的不断增多，接口平均响应时间不断递减，在节点数为16的时候，接口响应时间达到0.56 s，完全达到了测试要求。在不同并发量下多节点的接口平均响应时间，将测试点选在单个商品详情请求接口，测试用例为并发量500、1 000、2 000，测试接口在这三种并发量下的平均响应时间。结果如图7(b)所示，在节点数为16的相同条件下，接口的平均响应时间随着并发量的增多而不断增多，在测试2 000个并发量的时候，接口平均响应时间达到0.91 s，符合测试高并发原则要求。

(a)同一并发量不同数量节点接口响应速率

4.2 不同并发量下单节点CPU占有率和磁盘I/O

随机抽取一台主机，以商品搜索为测试点，“棉服”为搜索关键字，并发量设置为1 000和2 000，测试分布式架构下CPU占有率和磁盘I/O占有率情况，结果如图8所示。在并发数为1 000的条件下，CPU占有率达到57%，属于中等水平，磁盘I/O占有率低于40%，符合高并发下系统平稳运行的标准。

图8 不同并发量下单节点CPU占有率和磁盘I/O

5 结束语

系统使用分布式软件架构设计并实现了基于B2C的新零售购物平台。开发过程中充分考虑了不同业务流程的高并发处理能力，在威胁系统稳定的节点运用了消息队列、缓存数据库、分布式事务等技术，为系统的平稳运行提供了可靠的保障。通过高可用性的几个重要性能指标，测试并验证了在高并发场景下的功能可用性和性能可靠性，为百万级流量系统的软件架构技术选型提供了一种可行的服务化治理方案。