【《购物商城系统设计与实现》20000字（论文）】

PAGE1购物商城系统设计与实现摘要 1第1章绪论 31.1购物商城系统开发背景 31.2国内外研究现状 31.3研究内容 31.4论文结构 4第2章购物商城系统技术选型 52.1业务系统技术选型介绍 52.1.1Mysql 52.1.2Redis 52.1.3SpringCloud 52.1.4Mybatis 52.1.5RocketMq 52.1.5ElasticSearch 52.1.6Nginx 5第3章购物商城系统需求分析 53.1购物商城系统概述 53.1.2购物商城系统项目说明 53.1.3购物商城整体系统整体概述 53.2购物商城系统功能性需求分析 73.2.1购物商城系统后台管理端需求分析 73.2.2购物商城系统前台用户端需求分析 73.3购物商城系统非功能性需求分析 7第4章购物商城系统设计 94.1购物商城系统技术架构设计 94.1.1购物商城系统物理架构 94.1.2购物商城系统逻辑架构 94.2购物商城系统数据库设计 94.2.1用户服务数据库结构设计 94.2.2商品服务数据库结构设计 94.2.3订单服务数据库结构设计 94.2.4仓库服务数据库结构设计 94.3购物商城系统业务功能设计与实现 94.3.1购物商城商品门户模块设计实现 94.3.2购物商城后台管理模块设计实现 94.3.3购物商城商品搜索模块设计实现 94.3.4购物商城商品详情展示模块设计实现 94.3.5购物商城单点登录模块设计实现 94.3.6购物商城购物车模块设计实现 94.3.7购物商城订单模块设计实现 9第5章购物商城系统测试 105.1购物商城门户模块测试 105.2购物商城门户模块测试 105.3购物商城门户模块测试 105.4购物商城门户模块测试 105.5购物商城门户模块测试 105.6购物商城门户模块测试 105.7购物商城门户模块测试 10第6章总结与展望 116.1总结 116.2展望 12摘要随着计算机互联网软件设计技术的推进，各式各样的的网站小程序已经逐渐浸入到民众的平常生活中。以购物为例，在过去，人们为了买到想要的商品，需要经过实地的精挑细选后最终找到属于自己想要的商品，在这个过程中，往往用户会因为规格不齐全等问题而无法买到想要的商品。相反在现在，用户在网络购物通过检索分类，规格属性筛选，智能推荐等方式获取到自己想要的商品，也节省了大量的对比挑选出行时间。同样，网上购物逐渐兴起的潮流，对于平台而言，随着用户群体的逐渐扩大，各种技术问题也随之而来，庞大的用户群体一拥而入，服务器由于性能变得卡顿迟缓，甚至宕机，给用户带来了非常差的体验。高并发的问题便是商城系统的一大挑战。与此同时，大量的用户在系统上也会留有很多有价值的信息，包括但不限于一个用户的访问记录，下单记录等，这些数据在如今的大数据时代下也有着非常大的价值，如何利用这些数据来洞察平台的用户行为情况甚至结合算法完成对于用户购买的精细化推荐，进而帮助用户更好地获取到想要地商品也是现在购物平台的一大挑战。本文将结合现有的商城系统的簇形，采用分布式可扩展大流量的开发模式，在技术上采用微服务的设计思想进行实现，系统采用BS架构方式，同时系统将接入日志收集服务，完成系统的数据化，便于系统的运维和观察。同时，系统将采用智能推荐技术，为用户自动化地找出属于自己意愿中的商品。关键词：网上购物；高并发；微服务；BS架构ABSTRACTWiththeadvancementofsoftwaredesigntechnique,allkindsofwebsiteandsmallprogramshavebecomepartofpeople’slifegradually,thispaperbasesonthediscussingofCRMsystemfortobaccoindustry,analysesthefunctionalandnon-functionalrequirement,anddescribesparticularlythesystemrequirementbytheflowchartandusecase.Accordingtotherequirementanalyzing,thispapergivesthesystemarchitecturedesign.Basedonthesystemrequirements,thispaperputsupthesystemdesigngoalsandprinciples,andthenseparatelydiscussesthetechnologyandfunctionalstructures.Technologystructureisabouttheextensibility,themaintenanceandtheperformanceofsystem.SothispaperadoptstheJ2EEarchitecture,andanalyseseachlayer’sfunction.Inthefunctionalstructure,thispaperdiscussesthecompositionofeachpart,andfinallyputsupadynamicsystemfunctionflow.Followingthearchitecturedesign,thispaperparticularlydesignsthisCRMsystem.Accordingtothediversitymanagementandtheintegrativemanagement,thispaperdescribeseverymodule’sdesign.Inthesystemmodeling,forthesakeofsufficiencycomprehensiontoCRMmanagement,thispapersimplyintroducesthetobaccoindustrye-commercialsystem,andanalyzestheCRMsystem’sfunctionandpositioninthewholesystem.AndthenweputupthewholestructureofthisCRMsystem.Afterrealizingthewholestructure,thispaperparticularlydiscusseseachmodules’design,accordingtothediversitymanagementandtheintegrativemanagementofferedbytherequirementanalyzingpart.Atlast,thispaperintroducestheapplicationoftheCRMsystem,andproposesanadviceforfurtherimprovement.Keyword:TobaccoIndustry;CustomerRelationshipManagement;BostonMatrix;NeuralNetworkForecast第1章绪论1.1购物商城系统开发背景随着互联网技术的飞速发展，传统的商家与消费者面对面的交易模式已逐渐被网络购物平台所取代。商家希望尽可能地完成自己商品的快速、大规模销售，而买家也希望用简单、快捷、高效的方法找到和购买自己想要的商品，而商城在这个过程中便扮演着重要的角色，商家和消费者通过平台完成对话。用户可以登录，浏览商品，加入购物车，下订单付款，最后得到想要的商品。为了满足用户的购物需求，构建一个能够支持大量用户和大量并发用户的商城系统。同时，平台可以通过系统观察商品的销售排名和用户的活动情况，为平台的进一步发展提供更好的决策支持。对于用户来说，用户可以依托这个平台，大大节省了购买商品的时间和空间成本。针对以上需求，开发一个能够实现上述愿景的购物中心。1.2国内外研究现状商城系统在如今已经逐渐成熟，采用CS架构的商城系统由于稳定性，扩展性较差，这样的架构在面对大量的用户时扩展性和可变动性较差，在如今的国内外的购物商城，包括但不限于京东，淘宝，天猫，shopee等购物平台都采用BS的架构方式来设计系统。以淘宝为例，在早期的系统设计中，由于需要急于占领市场，加上在当时的国内环境，技术的发展尚未成熟，系统的设计采用了单体式地架构方式，可后来随着系统面对地的商家数逐渐增多，商品的信息存储数量也在飞速地增长，系统的用户也在逐年指数爆炸式地递增，对于早期的单体架构而言根本无法应对如此高地并发量，系统开始逐渐地进行拆分扩展，上层的服务提供方进行拆分，通过注册中心进行统一地注册管理，对于下层数据的存储端，以往的单库单表也不能够很好地满足系统的数据量，这才有了分库分表，但对于数据库来说，大量的并发用户访问系统的性能也会逐渐下降，缓存的出现便大大地提高了用户相应地时效性。对于平台而言，每天有着大量的用户交易数据，用户浏览访问数据，这些数据一些是存储在关系型数据库中如Mysql结构化的数据，另外一些数据，如用户的浏览访问数据，这些非业务的核心数据往往通过日志的方式加以存储，如何对这些数据进行有效地利用和挖掘，通过这些数据找到潜在的价值便是平台要进一步考虑的事情。对于上述需求，国内各大公司通过搭建属于自己的数据仓库平台来实现，如阿里巴巴内部使用的ODPS便是完成了对于大量数据的存储和计算能力。购物商城除了能够帮助用户从中检索商品，完成相应购买流程，对于平台而言，不断地提高商品的销量，将一些合适的商品推销给想要购买这些商品的用户，进而提高用户的购买意愿，减少用户探寻需品的时间消耗。在这个过程中，推荐系统便起到了非常大的作用。对于购物商城的推荐，在早期，一个简单的处理方式便是通过将整个平台的热销量最高的商品进行推荐给用户，这样的方式并不能够满足大部分用户的需求，所有的用户看到的商品都是一模一样的，对于不同年龄段，不同性别的用户而言，显然没有很好地做到千人千面。后来便逐渐衍生出了个性化推荐，如当下比较热门地协同过滤已经成为了很多智能推荐的首选。1.3研究内容本文研究的是购物商城系统的设计开发，主要研究内容如下：熟悉电商领域的基本模型，对现有的购物商城架构进行研究，基于微服务的设计理念开发出能够支撑大量用户的平台，平台可以根据用户量不断地调整资源，不同的服务在变更时相互之间没有影响。构建系统独有的数据仓库平台，包括不限于对平台商品销售量，用户访问量等指标的计算分析，用于平台的数据化运营和统计分析决策。完成能够实现千人千面的推荐系统，系统能够根据不用的用户的喜好特征去为用户精准推荐用户可能喜欢的商品。1.4论文结构

第2章购物商城系统技术选型2.1业务系统技术选型介绍2.1.1MysqlMysql是一个开源的数据库管理系统，现归属于Oracle公司。由于支持跨平台，运行速度快，支持面向对象，支持各种开发语言等特性，相比于收费版本的Oracle来说，被得以广泛的应用。2.1.2Redis非关系型数据库的一种，通过KV的方式来存储访问数据，能够支持持久化，通常被作为缓存应用在项目中，相比与关系型数据库而言，具有更快的访问速度，能够支持更高的并发请求，支持strin,list,set,zset,hash等多种数据结构的存储。2.1.3SpringCloudSpringCloud是微服务开发和治理框架，提供了一整套微服务的治理方案，包括服务的发现和注册，分布式配置中心，负载均衡等组件。使用SpringCloud,开发人员可以方便快捷地建立实现这些模式的服务和应用程序，在任何分布式环境下都能很好地工作。2.1.4MybatisMybatis是apache开源项目，持久层框架之一，简化了传统JDBC建立释放连接，手动获取结果参数并解析映射对象等一系列繁琐的过程，使用者可以通过XML或者注解再加上基本SQL语句的编写就能完成对于数据库的访问操作，相比于hibernate全自动框架来说，简单容易上手，速度快，解除了SQL与程序代码的耦合。2.1.4RocketMq分布式消息中间件，由阿里巴巴消息中间件团队研发并应用在生产系统中，基于高可用分布式集群技术，提供低延时，高可靠的消息发布与订阅服务，作为消息队列的一种，可以起到异步解耦消峰作用。2.1.5Elasticsearch分布式搜索引擎，能够用于执行处理多中类型的搜索，包括结构化的数据和非结构化的数据，基于倒排索引实现，常被应用与系统的检索模块，能够帮助用户快速地查找出用户想要的内容。2.1.6Nginx随着互联网在中国的发展，巨大的访问量给网站带来了巨大的压力，相当多的网站在用户集中访问时，由于服务器压力过大，无法提供正常的服务，给网站管理员和用户带来了很多不便，甚至造成了巨大的用户流失。Nginx作为一个高性能的HTTP和反向代理服务器，它对于网站在高并发下的负载能力的解决提供了巨大的帮助。第3章购物商城系统需求分析3.1购物商城系统概述3.1.1购物商城系统说明购物商城是一个惠利卖家平台和客户买家的一个平台，对于买家来说，该平台加速了用户寻找购物商品的时间消耗，提高了用户找寻商品的效率，商城包括品牌，分类和相应的搜索功能。同时，商城可以根据用户的个人喜好为用户智能推荐出相应用户可能购买的商品；对于卖家平台来说，平台通过推销商品来实现盈利，平台能够根据自己所售卖商品的数量，排名，各商品的热度等指标进行相应调整，通过购物系统的实现，完成互联网购物的连接。3.1.2购物商城系统整体概述购物商城系统属于面向用户端的系统，为了应对前问提到的高并发大流量所带来的挑战，系统的架构采用B/S架构，对于前端系统，采用vue技术实现，对于服务端，整体采用分层的架构实现。以传统的单体项目来说，服务的提供方，底层数据存储支持都是部署在一台机器上，这样的优点是服务与服务之间的调用是本地方法的调用，速度快，部署和运维相对简单。但对于面向能够承载大量用户的系统来说，上述设计带来的一个问题便是为了应对大流量，必须通过加机器的方式实现，所有的服务在每一个机器上部署，一旦一个服务发生修改，必须要所有的机器重新部署，服务与服务之间的耦合度过高，为开发和运维都带来了不便。鉴于上述问题，购物商城系统借鉴微服务的设计思想，服务与服务之间独立开发，独立部署，这样的开发方式的一大优势是为了应对大流量，并不需要，所有的服务一齐扩展部署，只需要将流量大的服务进行机器的扩展即可。同时，采用分布式微服务的设计方式也带来了弊端，服务之间的调用由原来的本地方法调用变成了远程调用，这个过程就需要进行网络和IO通信的传输。除此之外，一个服务调用另一服务需要知道另一个服务的网络通信地址，对此一个通用的解决方案便是引入注册中心，应用中所有的服务在启动的时候注册到注册中心，服务与注册中心通过心跳机制维持连接，如果服务发生了宕机或者故障，服务与注册中心的心跳机制就会断开，当服务调用方从注册中心调用其它服务时候，便能够及时动态地感知到上述过程，对于注册中心，在购物商城系统中采用SpringCloudAlibaba中的Nacos实现。上述解决了对于面向大量用户，高并发的不同服务之间地拆分和调用问题解决，对于前端系统来说，为用户展示数据结果需要与服务端通信获取数据，在传统地单体项目中，可以通过前端项目写死固定的服务端的通信地址，通过这样的方式可以完成后续对于服务请求的调用。可面对分布式系统来说，有大量的服务提供方，前端无法指明具体的地址，另一方面，将服务端通信地址直接暴露在前台系统，系统的安全性没有很大的保障，而API网关便能够解决上述问题，在分布式系统中，API网关提供了唯一的系统入口，所有的客户端都应该通过网关的方式接入，通过网关的方式路由到内部其它服务。在系统引入网关后，网关通过与注册中心的通信来完成对于服务调用方的结果处理，但网关在应对高并发的场景下仍然会存在单点问题，对于网关的单点问题可以通过参考服务的单点问题来解决，通过部署在多台机器上部署网关服务来达到应对更大的请求，但系统这个时候便缺少了对外的统一入口，以及对于网关调用的选择也是一个问题，nginx的出现便可以解决上述问题，nginx作为负载均衡服务，可以对HTTP完成代理，通过nginx的负载均衡策略选择相应的网关服务进行调用，通过网关在调用到具体的服务。对于nginx的高可用可以通过Keepalived构建，高可用通过VRRP协议实现多台机器之间的故障转移服务，对外通过暴露统一的虚拟IP来提供服务。上述为购物商城在负载均衡，微服务网关和服务注册发现在应对大流量的实现方案，作为为用户提供服务的系统来说，必然离不开底层数据存储的支持，在购物商城系统中，系统按照服务进行拆分，可将其拆分为用户服务，商品服务，订单服务，购物车服务等等，在存储层如果采用单一的数据库来应对，在大量的流量下，数据库便是很大的性能瓶颈，对此，按照微服务数据自治原则，可以对数据库进行拆分，不同的服务分别连接不同的数据库，这样不同服务之间的数据彼此互不干扰，如果用户顺时请求量依然非常大，这个时候可以考虑对数据库进行分库分表，来应对大量的请求访问。如上是购物商城在业务层的整体概述，对于购物商城一个拥有大量用户的系统来讲，每天系统都会产生大量的数据，这些数据一方面来自关系型数据库Mysql，如用户的下单数据，发布的商品数据，另一方面可能来自非结构化的日志数据，如用户的浏览记录，用户A访问了商品B,该信息以log日志的形式存放在磁盘中；从数据的来源来讲，可能是来自多种途径，包括但不限于上文提到的关系型数据库和日志文件，甚至非关系性数据库如Redis也会产生高价值的数据。在2014年，互联网已经进入了DT时代，用户每时每刻产生的数据对于系统的决策有着重要的意义，对于互联网拥有着大量用户的系统来说，衡量一个系统最重要的指标往往是系统的日活跃量，月活跃量，用户回流等指标，通过对这些指标的观察能够帮助我们正确的认识和分析系统的走向，以对未来的发展做出重要的决策。除此之外，购物商城平台中哪些商品的销量位居前列，哪些品种在当下的季节被哪些地区的用户大量购买等等。对于上述互联网产品的需求，一个可以解决的方案便是通过对关系型数据库MySQL进行SQL分析，这里便衍生出了很多问题，第一个便是并不是所有的数据都存储在Mysql中，对于用户的登录信息，浏览信息等等，这些并非存储在Mysql中。其次，Mysql作为业务系统的底层存储支持，本身就面临着巨大的流量考验，如果将数据分析决策的任务也运行在Mysql上，势必会加重整个业务系统的负担，与此同时，对于很多数据分析的决策需求来说，往往设计到全部的数据进行计算，这就需要大量的计算资源，如果没有单独的计算资源，那如此大的计算量也是无法完成的。对此，购物商城接入了Hadoop技术，通过hive引擎，底层执行MapReduce批量计算任务完成上述流程。对于关系型数据库系统中的数据，将Mysql同步到Hadoop中HDFS分布式文件系统可以借助Sqoop实现，对于log日志文件的收集采集，可以采用Flume采集器完成对文件的监控，日志采集器通常和业务服务器部署在相同的机器上来完成对于日志的采集实现。通过如上的操作，完成了对于业务数据和日志数据的采集至HDFS，接下来可以通过数据的处理流程，完成对于数据表的建立，对于采集来的数据，往往会存在很多垃圾数据，只有基于对准确的数据进行分析，才能活得可信的分析结果，进而做出可性的决策，如果对垃圾数据也进行处理和计算，势必会对数据的结果产生巨大的影响。3.2购物商城系统功能性需求分析购物商城系统在整体上分为两大部分，分别为后台管理端和前台用户端，对于后台管理端来说，管理员用户可以在系统中对于平台支持的商品分类，品牌进行维护，对商品的规格属性和商品的发布等信息进行管理维护；对于前台用户端主要是面向消费者用户使用，对于该部分能够对消费者进行商品的展示，消费者能够根据相应的条件去筛选商品，并对商品进行加入购物车，下单支付等，完成整个商品的购买流程操作。3.2.1购物商城系统后台管理端需求分析购物商城系统的后台管理端包括了整个购物商城系统需要维护的全部信息，具体用例图如下对于后台管理端的用例图如上，具体主要包含如下几个部分商品分类维护：对于购物商城系统来说，商城面向用户出售的商品不仅仅只有一种，如图书学习类和电子产品手机类型便属于不同的分类，对于分类管理来说，应该具备层次性，如电子产品既包括电脑，也包括手机，这里采用三级分类的方式来对商品的分类信息进行维护管理，在购物商城系统种，每一个商品一定隶属于一个三级分类。在分类管理种，系统管理员可以在系统种进行分类的添加，分类信息的更新，分类的删除等操作。商品品牌维护：对于商品来说，一个商品分类下可以有多个品牌，如手机分类下可以有华为手机，也有小米手机，苹果手机。同时一个品牌下也可能会有多个商品分类，如苹果品牌下既有苹果电脑，也有苹果手机。对于品牌维护，系统管理员可以新增品牌，修改品牌的信息，删除品牌，同时可以与分类建立相应的映射关系。商品属性维护：商品的属性包括两大类，规格属性和销售属性。规格属性指在商品前台首页中展示在规格与包装中的信息，以手机为例，通常会包括主体，基本信息，屏幕等几大规格分组，而这些信息便是通过属性分组来进行维护管理，在每一个属性分组下，又存在很多规格属性，如上文提到的手机分类中主体分组下通常会有产品名称，上市月份，上市年份，品牌等信息，这些隶属于某一个属性分组下用于展示商品的具体细节信息的属性便是规格属性，在管理系统中，管理员可以对它们进行维护管理，包括添加删除，划分至某一规格分组或在规格分组中关联某一个规格属性。同时商品还具有销售属性最直观的便是手机的颜色，版本等便于用户进行筛选一个品种下有多种可以挑选的属性便是销售属性，系统管理员在平台种也可以完成对它们的维护和管理。商品维护：用户在前台首页中看到的每一个商品都需要经过后台系统进行添加并上架后才能出现在用户消费者一侧。系统管理员可以在平台中发布新的商品，并对新的商品完成上架操作等，同时对于众多的商品，管理端也支持依据商品标题分类等信息对商品的快速检索功能。用户维护：系统可以分页展示已经注册在购物商城平台中的用户，便于对用户进行相关管理。订单管理：系统能够对已经下单的订单进行查看和处理，便于后续相关问题的人工介入和排查。3.2.2购物商城系统前台用户端需求分析对于消费者端来说，用户消费者可以浏览商品，根据商品类别，名称来检索商品，商品浏览，商品加入购物车，商品下单，商品支付等，完成整个商品的购物流程，该部分的用例图如下对于系统前台用户端，主要包含如下几个部分登录系统：系统包含登录功能，对于平台的一些功能如商品浏览，用户以游客的身份便可以完成，但是对于商品的下单支付等操作，需要用户完成登录后才可以进行相关操作，同时对于面向用户的分布式系统而言，系统应该支持单点登录。检索商品：检索商品是用户购买商品的必经一环，用户通过首页根据分类进行某一具体分类商品的挑选，进而用户能够直接进入该分类下的商品展示页面，同时系统也支持根据商品名称等关键信息的检索，能够对检索出来的结果进行按照价格，按照品牌等信息的进一步过滤。浏览商品：该部分的实现完成主要依靠商品详情页来实现，在商品详情页面中，系统可以展示商品的标题，副标题，价格，可以挑选的销售属性，同时也包括商品的描述信息，进行分组后的商品规格信息。商品加入移除购物车：用户在对一个商品下单前的必经之路便是将商品加入购物车，对于购物车来说，用户可以将商品加入，也可以随时移除，之后用户便可以完成后续的下单操作。下单支付商品：用户通过对购物车中的商品进行下单，之后通过付款完成对商品的购买。3.3购物商城系统非功能性需求3.3.1系统可靠性购物商城系统面向大量的用户，系统的稳定可靠性是系统的最关键的保障，系统应该保证全年百分之99.99的时间系统能够维持正常运转，当系统发生架构改变，系统扩容等情况时，系统不应对用户使用有较大的影响。3.3.2系统扩展性对于飞速发展的购物平台而言，系统的用户发展速度和迭代速度较快，为了能够使系统能够面对未来的业务飞速变化，系统应该具有较好的扩展性，当新的功能出现的时候，系统可以通过增加新的模块功能来完成功能的扩展而不需要对原有的模块进行大量的改变。3.3.3系统易使用性对于拥有大量用户的购物系统来说，系统的容易使用，易上手，易操作，易学习对于用户而言有着重要的作用尤其对于很多没有相关使用经验的人来说，一个简单朴实的界面，合理的布局体系，对核心功能的突出等都能够让系统的使用者快速的熟悉并快速上手系统。第4章购物商城系统设计4.1购物商城系统技术架构设计4.1.1购物商城系统物理架构上图为购物商城业务系统的整体物理架构图，用户通过PC机器进行访问，经过第一层Nginx进行负载均衡，Nginx通过keepalived的方式构建集群主从模式来完成高可用实现，当一台Nginx宕机，备Nginx仍然可以提供服务。Nginx中通过Server的配置，当用户访问购物商城系统网站时候，通过域名访问到nginx机器，nginx通过配置找到对应Server中location中地址，通过nginx.conf中httpupstream中对应的网关的地址配置将请求转发至网关。网关提供了系统的唯一入口点，作为所有API请求服务请求的接入点，用来加强和控制对于API服务的访问，API网关方法的核心是，所有的客户端和消费者都统一通过网关来访问微服务，并在网关处理所有非业务功能。第三层便是服务层，在购物商城系统中存在多种服务如用户服务，商品服务，搜索服务，订单服务，通用模块等等，这些服务通过注册中心进行注册，服务与服务之间彼此互不依赖，通过Feign进行远程调用。服务之间的部署通过集群方式完成，当某一服务的流量变大时，通过水平扩展机器的方式来完成对于服务的扩容。4.1.2购物商城系统逻辑架构购物商城系统基于模型视图控制器模式即MVC的架构进行设计，该设计将视图和数据模型进行分离，将视图和表现逻辑进行分离，具有极高的重用性和较低的耦合性，对软件的工程化管理具有很大的意义。Controller层：处理用户的请求，根据用户请求URL进行调用不同的Controller方法进行处理，通常意义来说，在设计系统的时候会将具有相同或者相似的请求划分到一个相同的Controller中进行处理，在该层中会调用业务逻辑处理Service层中的方法，对该处理结果进行一定的处理并将结果通过视图的方式进行返回给用户。Model层：该层用于负责具体业务逻辑的处理和各个功能的具体实现，它由Controller层进行调用，模型使用JavaBean来实现，负责完成对于特定逻辑的处理和对数据库的访问等操作。View层：视图层，负责进行页面展示工作的实现，是用户在交互中的主要部分，如信息的填写提交等，通常该层使用到的有html,css,js等前端技术。4.2购物商城系统数据库设计购物商城系统数据库设计建立在电商领域的模型之上进行构建，经过架构设计，对于分布式微服务系统而言，通常来说一个服务对应于自己独立的数据库，购物商城存在用户服务，商品服务，购物车服务，订单服务，仓库服务等，这些都将分别对应独立的数据库。在此基础上，进一步分析系统的模型结构和数据库结构。4.2.1用户服务数据库结构设计对于面向用户的系统而言，系统用户需要具备登录功能，用户需要有用户名，密码，昵称包括邮箱手机号等其它基础信息，除此外，用户在购买商品后需要设置收货地址，关于地址的设置并不是每次都需要用户手动输入，更好的设计需要支持过往记录的回显，过用户的收货地址信息也需要维护管理。综上，对于用户服务对应的两张数据库表分别为用户基础信息表user_info和用户收货地址表user_receive_address,具体表结构如下：用户基础信息表user_info字段名称字段说明是否主键字段类型id用户id是bigintusername用户名否varcharpassword密码否varcharnickname昵称否varcharmobile手机号否varcharemail邮箱否varchargender性别否tinyintcreate_time创建时间否datetimeupdate_time更新时间否datetime用户收货地址表user_receive_address字段名称字段说明是否主键字段类型id主键是bigintuser_id用户id否bigintname收货人姓名否varcharphone手机号否varcharpost_code邮编否varcharprovince收货省份否varcharcity收货城市否varcharregion收货城市区域否varchardetail_address地址详细信息否varcharareacode区域代码否varchardefault_status是否默认地址否tinyint4.2.2商品服务数据库结构设计购物商城系统中商品是最为重要的核心维度，一个商品隶属于一个分类，而分类具有层次性，商品最终归属于最底层分类，在该购物系统中，商品分类有三层，商品除了具有分类外，还具有品牌划分，如一个手机可以是属于品牌华为，也可以属于小米品牌，品牌与分类也具有关联性质，如手机分类下关联了华为，小米，oppo等品牌。除去分类和品牌两个特征外，商品还具有属性，如规格属性和销售属性，在商品的界面展示上，规格属性通常会按照分组来进行展示，销售属性通常应用于售卖时用户可以进行挑选的属性，如手机的颜色，内存大小等特征。商品还具有一些基础信息如标题，副标题，价格等信息的维护。综上分析，对于商品服务，一共有12张表，具体信息如下。商品品牌表product_brand字段名称字段说明是否主键字段类型brand_id品牌id是intname品牌名称否varcharimg品牌图片否varchardescript品牌描述否varchardelete_status品牌是否删除否intcreate_time创建时间否datetimeupdate_time更新时间否datetime商品类别表product_category字段名称字段说明是否主键字段类型id商品分类id是intname商品分类名称否varcharparent_category_id商品父分类id否intlevel商品分类层级否intsort排序否intdelete_status删除状态否intcreate_time创建时间否datetimeupdate_time更新时间否datetime商品分类品牌关联表product_category_brand字段名称字段说明是否主键字段类型id商品分类品牌关联表id是intbrand_id品牌id否intcategory_id分类id否intcreate_time创建时间否datetimeupdate_time更新时间否datetimedelete_status删除状态否int商品规格属性分组表product_attr_group字段名称字段说明是否主键字段类型id商品规格属性分组id是intname分组名称否varcharcategory_id分类id否intsort排序否intcreate_time创建时间否datetimeupdate_time更新时间否datetime商品属性表product_attr字段名称字段说明是否主键字段类型id属性id是intname属性名称否varcharvalue属性可选值否varcharvalue_type属性值类型，是否支持多选否intattr_type属性类型属性类型0-销售属性，1-基本属性否intcategory_id所属类别否intshow_status展示状态否intdelete_status删除状态否intcreate_time创建时间否datetimeupdate_time更新时间否datetimesearch_type是否支持搜索否int商品基本属性与分组关联表product_attr_attrgroup字段名称字段说明是否主键字段类型id商品基本属性与分组关联id是intattr_id属性id否intattr_group_id属性分组id否intcreate_time创建时间否datetimeupdate_time更新时间否datetime商品spu基本信息表product_spu_info字段名称字段说明是否主键字段类型id商品spuid是intname商品名称否varchardescripton商品描述否varcharcategory_id商品所属分类否intbrand_id商品品牌id否intpublish_status发布状态否intdelete_status商品是否删除否intcreate_time创建时间否datetimeupdate_time更新时间否datetimeintroduct商品介绍否varchar商品spu图集表product_spu_images字段名称字段说明是否主键字段类型id主键是intspu_idspuId否intimg_url图片URL否varcharcreate_time创建时间否datetimeupdate_time更新时间否datetime商品spu基本属性取值表product_spu_attr_value字段名称字段说明是否主键字段类型id主键是intspu_id商品spuId否intattr_id属性id否intattr_name属性名称否varcharattr_value属性值否varcharsort排序否intcreate_time创建时间否datetimeupdate_time更新时间否datetime商品sku基本信息表product_sku_info字段名称字段说明是否主键字段类型id主键是intspu_id商品spuId否intnamesku名称否varchartitlesku标题否varcharsubTitlesku子标题否varcharprice价格否decimalcategory_id商品分类id否intbrand_id商品品牌id否intdefault_img默认图片否varcharcreate_time创建时间否datetimeupdate_time更新时间否datetime商品sku图集表product_sku_images字段名称字段说明是否主键字段类型id主键是intsku_id商品skuId否intimg_url图片地址否varcharsort排序否intdefault_img是否为默认图片否intcreate_time创建时间否datetimeupdate_time更新时间否datetime商品sku销售属性值表product_sku_attr_value字段名称字段说明是否主键字段类型id主键是intsku_id商品skuId否intattr_id属性id否intattr_name属性名称否varcharattr_value属性值否varcharsort排序否varcharcreate_time创建时间否datetimeupdate_time更新时间否datetime4.2.3订单服务数据库结构设计订单在购物系统的产生发生与用户在登录后对购物车中的商品进行下单后随之产生的记录，对于订单维度设计需要有订单表和订单明细表，其中订单表负责存储订单的下单用户，下单时间，商品总价等概括信息，订单明细表负责存储订单中每一个具体的商品的购买信息包括商品单价，购买数量等信息，当用户收到货物后，用户可以对某个订单下的某个商品进行评价，该信息的维护通过订单评论表构建，用户可以对具体表结构设计如下。订单基本信息表order_info字段名称字段说明是否主键字段类型id订单主键是bigintuser_id用户id否bigintorder_number订单号否chartotal_amount订单商品总金额否decimalfreight_amount订单运费金额否decimalpay_amount需支付金额否decimalpay_type支付类型否tinyintsource_type订单来源否tinyintstatus订单状态否tinyintdelivery_company物流公司否varchardelivery_sn物流单号否varcharauto_confirm_day自动确认时间否intreceiver_name收货者姓名否varcharreceiver_phone收货者手机号否varcharreceiver_post_code收货者邮政编码否varcharreceiver_province收货者省份否varcharreceiver_city收货者城市否varcharreceiver_region收货者区域否varcharreceiver_detail_address收货者详细地址信息否varcharconfirm_status确认状态否tinyintpayment_time支付时间否datetimedelivery_time发货时间否datetimereceive_time收货时间否datetimecreate_time确认时间否datetimemodify_time更新时间否datetime订单明细表order_infoitem字段名称字段说明是否主键字段类型id订单明细主键是bigintorder_id订单id否bigintorder_number订单号否charspu_id商品spuId否bigintspu_name商品spu标题否varcharspu_pic商品spu图片否varcharspu_brand商品spu品牌否varcharcategory_id商品分类id否bigintsku_id商品skuid否bigintsku_name商品sku标题否bigintsku_price商品价格否decimalsku_quantity购买商品数目否intsku_attrs_vals商品销售属性否varcharreal_amount最终价格否decimal订单评价表order_comment字段名称字段说明是否主键字段类型id订单评价主键是intsku_id商品skuid否intspu_id商品spuid否intorderId订单id否intsku_name商品sku标题否varcharuser_id用户id否intuser_name用户名否varcharcomment评价内容否varcharstar几星评价否intcreate_time创建时间否datetime4.2.4仓库服务数据库结构设计购物商城出售的每一种类的商品都需要对应的仓储区域进行存储，在实际中未来高效，全国范围内通常会有多个仓库用于存放商品，在用户下单购买商品时，可以选择离用户收货区域最近的仓库进行发货这个时候效率是最高的，在仓库系统中，一张表用于维护每一个仓库的基本信息，此外还需要维护每一个仓库下每一个sku商品的库存以及被锁定的库存量。同时，为了完成对于超时关单等功能的实现，仓库系统中还需要记录每一笔订单中在每一个仓库的被锁定商品的明细信息，具体设计如下。仓库基本信息表ware_info字段名称字段说明是否主键字段类型id仓库主键是bigintname仓库名否varcharaddress仓库地址否varcharareacode区域编码否varchar仓库商品表ware_info字段名称字段说明是否主键字段类型id仓库商品主键是bigintsku_id商品skuid否bigintware_id仓库id否bigintstock库存否intsku_name商品名称否varcharstock_locked商品锁定库存否int订单仓库锁定表ware_order_task字段名称字段说明是否主键字段类型id仓库订单锁定表主键是bigintorder_sn订单号否varchar订单仓储锁定明细表ware_order_task_detail字段名称字段说明是否主键字段类型id仓库订单锁定明细表主键是bigintsku_id商品skuid否bigintsku_name商品名称否varcharsku_num购买个数否inttask_id仓库订单锁定工作单id否bigintware_id仓库id否bigintlock_status锁定状态否int4.3购物商城系统功能设计与实现4.3.1购物商城商品门户模块设计与实现在本模块中将重点设计购物商城的门户模块的设计实现，门户对于用户来说起着导购，导引用户可以快速找寻所需商品的作用，商品的分类信息便是门户模块中对用户起到导购作用的部分。另一方面，对于商城的门户页面来说，考虑到用户对于首页的访问量比较大，因此在商城首页内容的展示中，使用了redis服务缓存，这样只要在首次访问商城门户的时候从数据库中读取数据，后面便可以从缓存中获取首页的内容信息，可以在很大程度上提高首页的响应速度。以门户系统中商品分类导航的展示为例，商品的分类信息存储在商品服务中对应的Mysql数据库product_category表中，而商品的分类信息在页面中是以树状层级结构进行展开，这就加大了对系统的计算能力的要求，在不使用缓存的情况下，一个请求到来最高效的方式是将数据库中所有的分类信息加载到内存中，通过将每一个分类按照父分类进行划分并返回数据给前台显示，这对于门户这样一个具有非常高的并发量首页来说无疑会对关系型数据库Mysql带来巨大的压力，对此的改进流程图如下。通过上述的改进，在很大程度上缓解了门户页面分类等重要信息频繁的查询对于数据库Mysql来说带来的巨大压力，用户通过直接查询内存型数据库redis便可以进行快速的数据访问，但由于分类热点信息并不是一成不变的，在本系统中对于这些并不频繁被改变的数据存储在redis中采用了过期时间进行失效，当redis中的数据失效后，大量的用户将无法通过缓存查询到数据，这个时候将会有大量的流量打到数据库中进行大量数据的读取，这将会造成缓存击穿。对此，当缓存数据失效后，采用了同步加分布式锁的方式进行处理，改进后方案流程图如下。4.3.2购物商城商品搜索模块设计与实现购物商城商品搜索模块主要用于帮助商城系统用户快速地检索商品，根据商品的标题等关键信息将用户感兴趣的商品进行筛选，通过搜索模块完成对于用户想要的结果的过滤需求，该模块的具体采用Elasticsearch数据库实现，具体分析设计思路如下确定搜索需求：商城用户根据标题进行检索，这里的标题是指SKU标题，搜索模块将返回所有符合要求的商品信息，包括商品的标题，图片和价格等信息，除此之外，系统将根据搜索出来的结果进行聚合属性的展示分析，在商品对应SPU中，有一些规格属性可以用来检索，用户可以根据规格属性进行再次的检索，也可以根据品牌，分类的信息进行再次检索，要求上述品牌，分类或属性应该包含在检索的结果中。设计ES数据结构：由上述需求分析可知，在ES存储数据时需要存储商品要展示的基本信息如商品的sku标题用于分词检索。对于商品图片，商品价格等信息，如果这些信息没有存储在ES中，那么后台系统需要依据检索服务查询出来的商品列表再次查询数据库来获取图片和价格等信息，这将带来巨大的性能损耗，所以在设计中商品图片和价格信息也存储在ES结构中，对于属性，品牌和分类的聚合分析展示需要，这些结构也需要存储在ES中，最终ES设计结构如下{

"mappings"

:

{

"properties"

:

{

"attrs"

:

{

"type"

:

"nested",

"properties"

:

{

"attrId"

:

{

"type"

:

"long"

},

"attrName"

:

{

"type"

:

"keyword"

},

"attrValue"

:

{

"type"

:

"keyword"

}

}

},

"brandId"

:

{

"type"

:

"long"

},

"brandImg"

:

{

"type"

:

"keyword"

},

"brandName"

:

{

"type"

:

"keyword"

},

"categoryId"

:

{

"type"

:

"long"

},

"categoryName"

:

{

"type"

:

"keyword"

},

"skuId"

:

{

"type"

:

"long"

},

"skuImg"

:

{

"type"

:

"keyword"

},

"skuPrice"

:

{

"type"

:

"long"

},

"skuTitle"

:

{

"type"

:

"text",

"analyzer"

:

"ik_smart"

},

"spuId"

:

{

"type"

:

"keyword"

}

}

}}ES商品数据存储流程设计：用户可以通过商城的检索栏输入关键字得到商品的检索结果，对于这些数据的来源在商品通过后台系统发布时需要同步到ES数据库，具体发布流程如下，通过对spu进行发布，该spu下的所有sku商品信息中每一个商品的品牌，分类，价格，标题和可以检索的属性被保存在了ES中，后续用于检索。商品检索流程设计：当用户通过输入框输入关键字后，ES通过对sku标题进行模糊匹配分词取得结果，后台系统将结果中的表图部分按照搜索关键字进行高亮显示，并进行聚合分析，根据上述分析，聚合分析的主要指标有品牌，分类和属性，最终呈现给用户的有两大部分，一部分是商品结果数据，另一部分是聚合分析后的分类品牌和属性结果，用户可以在这些结果中按照自己的需求进行进一步的筛选。具体详细流程如下：4.3.3购物商城商品详情展示模块设计与实现商品详情模块是分布式购物平台的核心模块之一，用于向用户展示商品的详情信息，包括商品SKU标题，价格，销售属性组合，图片和规格属性，商品介绍等信息，具体流程如下：展示后具体效果如下图：4.3.4购物商城单点登录模块设计与实现系统登录是系统权限控制的关键步骤，在购物商城系统中，浏览首页，浏览商品详情页不需要登录即可进行，当用户需要下单的时候必须先登录后才能正常进行，以传统的单体项目来说，一个简单的登录校验判断流程可能是如下流程所示上述流程在传统的单体项目中可以支持，在分布式项目中，一个服务会以集群的方式进行部署，用户每次访问的机器都是随机的，用户登录的session信息只会被保存在当前用户访问的tomcat机器中，当用户下一次访问该服务其它机器时，用户便需要重新登录，这便带来了很差的用户体验。对于上述问题的一个解决方案有四种，分别如下session复制。Web服务器tomcat原生支持，通过简单的修改配置文件即可完成，但该方案中session的同步需要依赖于网络的数据传输，需要消耗大量的网络贷宽，任意一台web服务器保存的数据是所有的web服务器的总和，无法进行很好的扩展。客户端存储。服务器不保存session信息，用户将session信息保存在cookie中，但由于cookie存在长度限制，加上session数据保存在cookie中，存在泄漏，被篡改的安全风险，该方案在实际中通常也不会使用。Hash一致性。该方案中相同的用户通过userid等可以唯一区分用户的标识来进行hash处理，相同的用户每次访问到的都是一台机器，该方案在水平扩展时会出现一部分用户路由不到初始的正确机器，用户需要重新登录的问题产生。统一存储。将session信息统一由原来的存储在每台机器中，变为统一存储在中间方，如redis。该方案在获取session信息时会增加一次网络的调用，但解决了web服务器的水平扩容问题。在购物商城系统中采用方案4统一存储的方式来解决分布式中session共享的问题，具体结构图如下：4.3.5购物商城购物车模块设计与实现在商品的详细展示页面中，用户可以将商品加入购物车中即使用户没有登录，当用户登录后系统会将用户未登录状态时加入的商品信息转移至登录用户中，同时用户也可以对购物车进行管理，购物车模块的具体设计如下。数据库设计：购物车操作对于使用用户来说属于高频操作，用户随时可以将商品加入购物车，将商品从购物车移除，改变购物车中商品的数量等操作，同时对于用户在购物车的商品如果长时间没有进行后续处理，系统需要进行自动释放，采用关系型数据库的自动过期实现繁琐同时对于高频的购物车修改操作性能较差，这里采用内存型数据库redis作为用户购物车的存储介质，具体结构为hash结构，如下：功能流程设计：当用户登录时，redis中的key为用户id，对购物车的操作均为在以用户id为键的Value进行操作；当用户未登录时，redis中的key为用户临时key，操作时则以临时key为键的Value进行操作。当用户未登录时，系统会为该未登录的用户分配临时key，该key以cookie的形式保存在用户端，当用户登录时，系统会将该临时key中保存在redis中的数据转移到登录用户userid为键的数据中，并清楚临时key在redis中的数据，具体流程如下：4.3.6购物商城订单模块设计与实现订单在购物商城中连接着购物车与支付功能，用户在购物车中选择商品后提交订单，并在订单确认页面显示用户购买的商品列表，配送地址和支付方式等信息，用户需要登录后才能进行下单操作，订单模块的主要功能和设计如下：订单防重提交：在购物商城系统中，当用户点击提交订单操作时，系统应保证该操作最多只能够被成功完成一次，即成功下单一次或下单失败用户重试，系统不能因用户连续点击两次下单的按钮而发生重复下单问题的发生，对订单的提交要具备幂等性。对于幂等的解决有多种方案，这里采用token机制解决幂等问题。服务端提供了发送token的接口，当该业务需要幂等支持时，系统会先获取token,服务器把token存放在内存数据库如redis中，当执行业务流程时，服务器判断该token是否存在，如果存在，则代表是第一次请求，则删除token，再执行业务逻辑，当用户第二次请求该逻辑时，由于token已经被删除，第二次则无法得到成功执行，进而解决了订单重复提交带来的问题，该方案的具体流程如下：上述流程中需要保证判断token是否存在和删除token两步必须为原子性，否则在并发下依然存在业务逻辑被执行两次的结果，对于上述需要，通过redis的lua脚本实现，脚本内容如下：ifredis.call('get',KEYS[1])==ARGV[1]thenreturnredis.call('del',KEYS[1])elsereturn0end如此便保证了下单操作最多只能被成功执行一次的业务语义。保存订单和订单项：用户提交订单通过了第一步的token校验后，接下来便是订单和订单项的保存，订单中包含了订单号，订单总价，运费，下单用户等关键信息，订单项中则保存了与该订单关联的每一个商品的具体购买信息，包括商品标题，购买数量，商品单价等信息，该部分通过spring事务控制数据的一致性。锁定库存：锁定库存发生在订单和订单项被保存完毕后，订单服务在保存了订单和订单项的数据后通过远程RPC调用库存服务进行库存的锁定，当该sku商品的库存被锁定后，商品的真实库存即为商品总库存量减去商品被锁定库存量，关于库存的锁定和订单和订单项的保存必须要保证一致性，当库存锁定失败库存服务可以抛出异常被订单服务得以感知，订单可以顺利回滚，但当库存服务顺利对库存扣减完成后，由于订单服务的后续出现异常订单被回滚而库存无法得到回滚的问题。这里需要采用rocketmq的延迟队列的方式解决事务的一致性问题，具体流程如下锁定库存服务流程图当延迟消息被消费时，通过对消息解析取出订单号，如果该订单不存在说明订单服务因为后续异常发生了回滚，这个时候需要对该商品的库存锁定进行回补，进而保证了数据的一致性问题。定时关单的实现。用户在商城系统下订单后若未能在规定的时间内支付，该订单需要被顺利关闭，定时关单的实现采用延迟消息实现，具体流程如下rocketmq延迟消息消费流程如下当解锁库存消息被消费后，完成相应商品库存的释放工作，到此，定时关单实现完成。4.3.7购物商城推荐模块设计与实现推荐系统在购物商城系统中并非必须模块，但在提高平台售卖量，帮助用户发现自己可能购买的商品节省用户的挑选时间上起到了巨大的作用，传统的推荐系统通常以基于用户的协同过滤，通过寻找相似的用户，与用户A相似的用户B，推荐用户A喜欢的商品给用户B；或者基于物品的协同过滤，如用户A购买了某商品，便推荐与该商品相近的商品给A。上述推荐算法均单方面的基于用户或者商品的维度进行考量，没有对用户和商品的特征进行紧密的相互关联，对于一些具有特殊品味的用户不能进行很好的推荐，在本系统中采用基于模型的协同过滤的思想，通过讲用户的特征和商品的特征进行关联，用户可以有多个特征，商品也可以有多个特征，用户之所以选择某一个商品，是由于该用户的特征与商品的特征相互匹配，该推荐模型的具体思想如下 用户特征矩阵用户／特征特征１特征２特征３特征４用户１2521用户２0310用户３-1261商品特征矩阵特征/商品商品A商品B商品C特征1211特征2110特征3154特征4613如上是用户特征矩阵和商品特征矩阵示例，每一个用户具有N个特征，数值越大表明该用户的该特征越大，越具有该特征，数值越小表明该用户越不具有该特征。同理每一个商品也具有N个特征，对应数值越大表明该商品的对应的特征越明显，反之说明该商品的该特征不够显著。将入上所示用户特征矩阵和商品特征矩阵进行相乘，得到结果如下：用户/商品商品A商品B商品C用户1171813用户2484用户3123226如上所示用户商品特征矩阵的结果便是每一个用户的每一个特征与该商品对应的该特征值相乘后相加得到，如果用户具有显著的某个特征，该商品也具有较为显著的该特征，那用户对该商品的兴趣度就会越高，反之则会越低，该模型通过构建N个潜在的特征将用户和商品进行关联，在该系统中，使用订单商品评价表中用户对商品评价的星数用来代表用户对各个商品的兴趣程度，但用户并不会购买所有的商品，在实际的用户商品评价表矩阵可能是如下所示，为稀疏矩阵。用户/商品商品A商品B商品C用户11713用户284用户312如果能够根据用户已经做出的评价的商品推测出用户用户没有购买过的商品的潜在评分，那便可以根据评价的高低为用户推荐可能感兴趣的商品，在上述用户特征矩阵和商品特征矩阵相乘后可以看到，每一用户对每一个商品都有一个评价得分，如果对于用户商品评分稀疏矩阵中已有的数据和通过模型得到的评分矩阵对应的数值都很接近，那么我们认为用户在为未购买评价过的商品的评分也是较为准确接近的。上述算法模型为ALS算法，具体应用部分代码示例如下：SparkConfrecommendconf=newSparkConf().setAppName("SparkMysql").setMaster("local[5]");JavaSparkContextrecommendsparkContext=newJavaSparkContext(recommendconf);SQLContextsqlContext=newSQLContext(recommendsparkContext);//连接Mysql然后读取用户商品评价表并转换数据为ScoreJavaRDDJavaRDD<Score>scoreDataset=readMySQL(sqlContext);Function<Score,Rating>scoreToRatingMapFunction=newFunction<Score,Rating>(){publicRatingcall(Scorevalue)throwsException{IntegeruserId=value.getUserId();IntegerskuId=value.getSkuId();Integerstar=value.getStar();returnnewRating(userId,skuId,star);}};RDD<Rating>ratingRDD=scoreDataset.map(scoreRatingMapFunction).rdd();MatrixFactorizationModelmodel=ALS.train(ratingRDD,10,10);Rating[]predictProducts=model.recommendProducts(570,3);for(Ratingr1:predictProducts){System.out.println("userId:"+r1.user()+",productId:"+duct()+",score:"+r1.rating());}通过读取用户商品评价表中的评价星数构建用户评分稀疏矩阵，使用ALS算法训练得到每一个用户为每一个商品的评价得分，服务器根据该用户对所有商品得分进行从高到低排序取前N进行推荐。

购物商城系统测试上一章具体展示了购物商城系统的功能模块的具体设计与实现，本章将根据对购物商城系统的需求分析中的场景构建测试用例，通过