设为首页 - 加入收藏
您的当前位置:主页 > 互联世界 > 电商 > 正文

电商网站的搭建方法以及核心代码

来源:csdn 编辑:shlzwl.cn 时间:2022-01-14 15:55

1 绪 论
1.1电商网站起源及发展
上世纪的后40年,电子信息技术和产业给世界带来巨大的影响。
西方工业发达国家结束了以往依靠廉价石油发展工业的历史阶段,先后转向全面接受以微电子为核心的高新科技,依靠适度规模的生产,依靠科学的管理和决策,依靠更多的智能投入。
电子贸易早期发展的电子数据交换喝电子资金转账已显得不能满足发展的需要。
电子数据交换主要依靠“环球银行金融电信协会”所经营的SWIFT网及其开通的业务,由于这些网络的覆盖面有限,跨网传输不便,运作成本较高,于是商界纷纷要求发展一种覆盖面广、使用方便,而且成本低廉的电子商务。
计算机网络技术的重大突破,诞生了商业化的国际互联网Internet。这正好为电子商务在全球的创立提供了一个必不可少的网络平台。
互联网给全世界提供了最强大的网络平台,在互联网上不仅能同时快速传递大量的信息(数据、文件),而且还实现了网络营销、电子支付,提供各种新型的服务。
经济全球化的发展态势和全球经济贸易的规模发展迫切需要一种新型的经济运作模式和商业运营模式。
电子商务作为一种全新的经济运作模式和商业运营模式,大大降低了人类社会活动与经济活动的成本,提高了社会运作效率和企业经济效益,对世界经济格局和贸易体制的变化产生了深刻的影响,有力促进了经济全球化的进程。
近半个世纪以来,全世界形成的多边贸易体制、统一的贸易准则与规范,以及先后建立的相关国际组织,正好为电子商务在全球的有序发展创造了条件。
世界主要的国家和组织对发展电子商务都持积极态度,并且采取重要措施。
1.2电商网站的发展现状
根据国家统计局数据,2017年我国实物商品网上零售总额达5.48万亿元,同比增长28.0%,占社零总额的比重达到15.0%,同比提升2.4个百分点。如下图1.1所示:

在这里插入图片描述
图1.1 几大电商平台份额(2015-2017)

从电商格局看,预计2017年B2C电商交易规模占比已达57.60%,天猫仍以60.90%的市场份额位居B2C市场首位,京东、苏宁位列二、三名,增速方面苏宁易购以近三年(2015-2017)70%的GMV复合增长率处于明显领先。
如下图1.2所示:

在这里插入图片描述
图1.2 几大电商平台GMV增长率(2015-2017)

2电商网站需求分析
2.1消费者群体需求
方案一:随着互联网的普及,还有各大电商平台的崛起,各色各样的商品将在电商上进行出售,消费者将足不出户即可达成交易。先收集消费者数据,针对不同年龄段、不同地区、不同行业推存不同的商品。促进消费者的购买。根据购买记录和游览记录进行数据分析。
方案二:可以直接学习现有大型电商平台设计方案。
方案二与方案一比较,有着明显的优势,所以本设计采用了方案二。
截止2017年上半年我国网购用户为5.16亿人,同比增长7.5%,预计2017年全年达5.4亿人,预计全年同比增长8%,增速较2015年之前出现大幅下降。网购用户增速的大幅下降导致电商引流成本快速上升,据我们测算2017年京东/唯品会新活跃用户获客成本(假设营销费用全部用于新活跃用户获取,新活跃用户获客成本=营销费用/年活跃用户增长数,实际情况应低于测算值)分别高达226.37/522.56元,分别同比大幅增长53.30%/185.44%,如图2.1所示。

在这里插入图片描述
图2.1 我国网购用户数及增速(2007-2017E)
根据数据,消费电子、家电等高标准化产品2017年线上渗透率分别为43.50%与37.20%,已处于较高水平,而包装食品、酒精饮料、生鲜等快消品类线上渗透率普遍处于10%以下,未来存在较大增长空间。因此我们认为电商在保持家电3C、服装等传统电商品类竞争力的同时,必须扩张更多品类以提升网购用户整体消费频次与消费额。同时,以快消品为代表的高频品类的导入亦可提升消费者对电商的购买粘性与复购率,从而带动传统低频品类销量增长,如图2.2所示:


图2.2 我国网购用户人均实物商品网上消费额(2015-2017E)

2.2店铺群体需求
方案一:随着互联网的普及,还有各大电商平台的崛起,各色各样的商品将在电商上进行出售,网上店铺也将形成一个品牌。店铺针对服务质量,客户的评价等客观因素对同类商品的店铺进行优先推存,使店铺与店铺间存在竞争。
方案二:模拟现有电商架构设计,开店资质审核,开店押金收取,开店商品维护,销售量,销售额,信誉度,好评度。
这里我们需要快速搭建所以采用了方案二,直接实现现有业务。

3电商网站的架构及技术
3.1框架和技术
本系统主要以.net框架和C#语言位主要的开发工具,前端使用QUI前端框架。技术插件有Redis集群缓存、RabbitMQ 消息、MySql数据库。
实际上,在电商系统中,大部分数据都是可以缓存的,不能使用缓存的数据很少。这类数据包括涉及到钱、密钥、业务关键性核心数据等。总之,如果你发现,系统里面的大部分数据都不能使用缓存,这说明架构本身出了问题。如何解决一致性和实时性的问题?保证一致性和实时性的办法就是:一旦数据库更新了,就必须把原来的缓存更新,如图3.1所示:

在这里插入图片描述
图3.1 系统架构图

说一说我们的缓存方案:我们目前的缓存系统:Redis(主从)+ RabbitMQ + 缓存清理服务组成。整体代码设计架构如下,如图3.2所示:

在这里插入图片描述
图3.2 系统图表

3.2数据结构
1)系统资源监控,监控各种网络参数和各服务器相关资源(CPU、内存、磁盘读写、网络、访问请求等),保证服务器系统的安全运营,并提供异常通知机制以让系统管理员快速定位/解决存在的各种问题。目前比较流行的应该是Zabbix。
2)服务器监控
服务器的监控,主要是监控各个服务器、网络节点、网关等网络设备的请求响应是否正常。通过定时服务,定时去Ping各个网络节点设备,以确认各网络设备是否正常。如果哪个网络设备出现异常,则发出消息提醒。
3)服务监控
服务监控,指的是各个Web服务、图片服务、搜索引擎服务、缓存服务等平台系统的各项服务是否正常运行。可以通过定时服务,每隔一段时间,就去请求相关的服务,以确保平台的各项服务正常运行。
4)应用异常监控
目前我们平台所有系统的异常记录,都记录在数据库中。通过定时服务,统计分析一段时间之内的异常记录。如果发现有相关重要的模块的系统异常,比如支付、下单模块频繁发生异常,则立即通知相关人员处理,确保服务正常运行。
5)应用性能监控
在API接口和各应用的相关位置进行拦截和记录下程序性能(SQL性能,或是 程序执行效率)。相关重要模块提供性能预警,提前发现问题。 同时统计相关监控信息并显示给开发的人员,以方便后续的性能分析,整体架构图如图3.3所示。

在这里插入图片描述
图 3.3 监听的架构图标

3.3设计交易流程
满足于用户需求,越简单的流程越好。
B2C的经营模式有:
综合商城:如同传统商城一样,它有庞大的购物群体,但线上的商城,人气多。
百货商店:这种商店是有自有仓库,有库存系列产品,以备更快的物流配送和客户服务。这种店甚至会有自己的品牌。垂直商店:这种商城的产品存在着更多的相似性,要么都是满足于某一人群的,要么是满足于某种需要,亦或某种平台的(如电器)。
对于店铺销售者的功能:
1)为企业间的网上交易提供供求信息服务;
2)提供附加信息服务;
3)提供与交易配套的服务;
4)提供客户管理功能。
流程图如图3.4所示:

在这里插入图片描述
图3.4 交易流程图

3.4主要功能介绍
在线销售系统,主要分为首页、零售商品展示、批发商品展示、会员中心、加入我们、店铺后台管理。
页面的设计首先要简介
1.简洁大方,2.要提高用户的体验度,在保证最基本的功能的情况下,操作不要太繁琐。3.购物的分为两个板块,一个是零售,一个是批发4.要有公司的首页,就像我给你的那个首页那样(里边的额内容)可以多加。5.商品介绍时要有本商品所属商家的一个营业时间6.支付方式可以是支付宝7.游客可以在本网站直接购买商品,不需要注册处会员但是这种顾客不能对商家以及商品进行评论只有会员才可以对已购商品进行评论界面分类:前端对外展示:
1.首页:头部:公司log,登入注册入口,导航栏(必须有的) 中间:商品展示(自由设计)底部:联系电话,地址,管理登入的入口。
2.商品展示:中间块自由设计
3.商品详情:中间块自由设计
4.购物车
5.下单,付款
6.会员登入注册
7.会员中心:有历史的订单查询,会员信息的编辑
8.评论后台管理界面:1.公司信息管理2.商家入住管理3.商家商品管理4.商家订单管理5.会员帐号管理6.管理平台登入。
系统管理员:
1.导航菜单管理。(管理前端的主要导航菜单的)
2.公司信息配置。填写公司地址和基本的公司信息
3.会员管理 管理会员的帐号信息
4.店铺管理填写店铺信息 注册店铺
5.商品管理:商品类型管理 : 将需要销售的商品分类,方便销售商品规格管理:商品有尺寸大小颜色等规格,这里给商品进行添加规格商品信息管理 : 商品的主题信息(如图片,名称,价格,备注 等都是在这里维护)商品库存管理:商品的库存量有多少这里进行维护。
6.订单管理:订单管理->这里有每个店铺对自己店铺商品的订单查看。 订单明细管理->订单明细管理 。订单评价->订单评价管理。
实现代码如图3.5所示:

在这里插入图片描述
图3.5 核心代码截图

3.5角色介绍
电商前台:服务对象 :游客,普通客户,VIP客户。
前台客户登入来源:(支持QQ 新浪 微博 邮箱 直接登入 需要接入他们的合作接口)。大气的商品展示界面: (杂货、生活百货);在线的客服支持:(QQ、旺旺 );留言以及评论板块;第三方支付平台:(支持支付宝 、其他待定)
电商后台:服务对象 :管理人员,商品发布人员,仓库,财务人员。
维护系统正常运行:清晰的库存记录。商品展示模版的跟新。活动公告等发布,留言回复删除等功能。
数据分析:服务对象:市场分析人员(根据网址访问量和点击量进行分析 ) ,游客的访问量,普通客户的访问量,VIP客户的访问量。点击查看量,好 ,差评价的统计。
实现代码如图3.6所示:

在这里插入图片描述
图3.6 核心代码截图
4系统软件设计
4.1总体程序开发
在线零售系统是商联达融合移动互联网时代电商特征,支持企业以消费者为核心,跟随顾客的节奏,建立领先的电子商务B2C零售平台,功能强大, 安全便捷,可承载千万级访问量,让企业低成本快速构建在线商城,开启电子商务业务。
消费者行为分析核心指标主要是统计商城的各项核心数据,例如:各终端销售额、访客数、订单数、支付买家数、浏览量、商品访问量、商品销售排行、交易转化率、终端构成等各项数据。
大家都知道是表现层(UI),业务逻辑层(BLL)和数据访问层(DAL),而且每层如何细分也都有很多的方法。但具体代码怎么写,到底那些文件算在哪一层,却是模模糊糊的。下面用一个简单的例子来带领大家实战三层架构的项目,这个例子只有一个功能,就是用户的简单管理。 首先建立一个空白解决方案,添加如下项目及文件
添加ASP.NET Web Application项目,命名为UI,新建Web Form类型文件User.aspx(含User.aspx.cs);添加ClassLibrary项目,命名为BLL;添加ClassLibrary项目,命名为DAL,新建Class类型文;UserDAL.cs添加SQLHelper引用。(这个是微软的数据访问类,也可以不用,直接编写所有的数据访问代码。我一般用自己写的数据访问类DataAccessHelper);添加ClassLibrary项目,命名为Model,新建Class类型文件UserModel.cs;添加ClassLibrary项目,命名为IDAL,新建Interface类型文件IUserDAL.cs;添加ClassLibrary项目,命名为ClassFactory。
相信大家已经看出来了,这个和Petshop的示例没什么区别,而且更简单,因为在下也是通过Petshop学习三层架构的。但一些朋友对于这几个项目所处的层次,以及它们之间的关系,可能比较模糊,这里逐个说明一下:
User.aspx和User.aspx.cs这两个文件(以及文件所属的项目,下面也是如此,不再重复强调了)都属于表现层部分。User.aspx比较好理解,因为它就是显示页面了。User.aspx.cs有些人觉得不应该算,而是要划到业务逻辑层中去。如果不做分层的话,那么让User.aspx.cs来处理业务逻辑,甚至操作数据库都没什么问题,但是做分层的话,这样就不应该了。在分层结构中,User.aspx.cs仅应该处理与显示有关的内容,其它部分都不应该涉及。
我们实现用列表方式显示用户的功能,那么提取信息的工作是由BLL来做的,UI(本例中是User.aspx.cs)调用BLL得到UserInfo后,通过代码绑定到User.aspx的数据控件上,就实现了列表的显示。在此过程中User.aspx.cs对UI没有起到什么作用,仅是用来传递数据,而且因为实际编码中大部分情况都是如此的实现,所以使有些人觉得User.aspx.cs不应该算UI,而应该并入BLL负责逻辑处理。继续往下看,这时提出了一个新需求,要求在每个用户的前面加一个图标,生动地表现出用户的性别,而且不满18岁的用儿童图标表示。这个需求的实现,就轮到User.aspx.cs来做了,这种情况下User.aspx.cs才算有了真正的用途。具体代码如图4.1所示。

在这里插入图片描述
图4.1 核心代码截图

此文件就属于业务逻辑层了,专门用来处理与业务逻辑有关的操作。可能有很多人觉得这一层唯一的用途,就是把表现层传过来的数据转发给数据层。这种情况确实很多,但这只能说明项目比较简单,或者项目本身与业务的关系结合的不紧密(比如当前比较流行的MIS),所以造成业务层无事可做,只起到了一个转发的作用。但这不代表业务层可有可无,随着项目的增大,或者业务关系比较多,业务层就会体现出它的作用来了。
此处最可能造成错误的,就是把数据操作代码划在了业务逻辑层,而把数据库作为了数据访问层。
举例:有些朋友感觉BLL层意义不大,只是将DAL的数据提上来就转发给了UI,而未作任何处理。看一下这个例子
BLL层
SelectUser(UserInfo userInfo)根据传入的username或email得到用户详细信息。
IsExist(UserInfo userInfo)判断指定的username或email是否存在。
然后DAL也相应提供方法共BLL调用
SelectUser(UserInfo userInfo)
IsExist(UserInfo userInfo)
这样BLL确实只起到了一个传递的作用。
但如果这样做,那么DAL就无需实现IsExist()方法了,BLL中也就有了逻辑处理的代码。
3、UserModel.cs
实体类,这个东西,大家可能觉得不好分层。包括我以前在内,是这样理解的:UIßàModelßàBLLßàModelßàDAL,如此则认为Model在各层之间起到了一个数据传输的桥梁作用。不过在这里,我们不是把事情想简单,而是想复杂了。
Model是什么?它什么也不是!它在三层架构中是可有可无的。它其实就是面向对象编程中最基本的东西:类。一个桌子是一个类,一条新闻也是一个类,int、string、doublie等也是类,它仅仅是一个类而已。
这样,Model在三层架构中的位置,和int,string等变量的地位就一样了,没有其它的目的,仅用于数据的存储而已,只不过它存储的是复杂的数据。所以如果你的项目中对象都非常简单,那么不用Model而直接传递多个参数也能做成三层架构。
那为什么还要有Model呢,它的好处是什么呢。下面是思考一个问题时想到的,插在这里:
Model在各层参数传递时到底能起到做大的作用?
在各层间传递参数时,可以这样:
AddUser(userId,userName,userPassword,…,)
也可以这样:
AddUser(userInfo)
这两种方法那个好呢。一目了然,肯定是第二种要好很多。
什么时候用普通变量类型(int,string,guid,double)在各层之间传递参数,什么使用Model传递?下面几个方法:
SelectUser(int UserId)
SelectUserByName(string username)
SelectUserByName(string username,string password)
SelectUserByEmail(string email)
SelectUserByEmail(string email,string password)
可以概括为:
SelectUser(userId)
SelectUser(user)
这里用user这个Model对象囊括了username,password,email这三个参数的四种组合模式。UserId其实也可以合并到user中,但项目中其它BLL都实现了带有id参数的接口,所以这里也保留这一项。
传入了userInfo,那如何处理呢,这个就需要按照先后的顺序了,有具体代码决定。
这里按这个顺序处理
首先看是否同时具有username和password,然后看是否同时具有email和password,然后看是否有username,然后看是否有email。依次处理。
这样,如果以后增加一个新内容,会员卡(number),则无需更改接口,只要在DAL的代码中增加对number的支持就行,然后前台增加会员卡一项内容的表现与处理即可。
4、UserDAL.cs
public IList SelectUsers():返回所有的用户信息列表(返回的一个泛型列表,可以进行序列化等操作)
public UserInfo SelectUser(int UserId):返回指定用户的相信信息(通过ID,返回实体类的实例相关信息)
public bool InsertUser(UserInfo User):新增用户信息(不同于Select,因为增加和更新是不会返回实体数据,只返回一个bool值表明操作是否成功)
public bool UpdateUser(UserInfo User):更新用户信息(同上)
public void DeleteUser(int UserId):移除用户信息(这个)
很多人最闹不清的就是数据访问层,到底那部分才算数据访问层呢?有些认为数据库就是数据访问层,这是对定义没有搞清楚,DAL是数据访问层而不是数据存储层,因此数据库不可能是这一层的。也有的把SQLHelper(或其同类作用的组件)作为数据访问层,它又是一个可有可无的东西,SQLHelper的作用是减少DAL层的重复性编码,提高编码效率,因此如果我习惯在乎效率或使用一个非数据库的数据源时,可以丢弃SQLHelper,一个可以随意弃置的部分,又怎么能成为三层架构中的一层呢。
可以这样定义:与数据源操作有关的代码,就应该放在数据访问层中,属于数据访问层
5、IUserDAL
数据访问层接口,这又是一个可有可无的东西,因为Petshop中带了它和ClassFactory类工厂,所以有些项目不论需不需要支持多数据源,都把这两个东西做了进来,有的甚至不建ClassFactory而只建了IDAL,然后“IUserDAL iUserDal = new UserDAL();”,不知意义何在。这就完全是画虎不成反类犬了。
许多人在这里有一个误解,那就是以为存在这样的关系:BLL-IDAL-DAL,认为IDAL起到了BLL和DAL之间的桥梁作用,BLL是通过IDAL来调用DAL的。但实际是即使你如此编码:“IUserDAL iUserDal = ClassFacotry.CreateUserDAL();”,那么在执行“iUserDal.SelectUsers()”时,其实还是执行的UserDAL实例,而不是IUserDAL实例,所以IDAL在三层中的位置是与DAL平级的关系。 通过上面的介绍,基本上将三层架构的层次结构说明了。其实,本人有一个判断三层架构是否标准的方法,那就是将三层中的任意一层完全替换,都不会对其它两层造成影响,这样的构造基本就符合三层标准了(虽然实现起来比较难_)。例如如果将项目从B/S改为C/S(或相反),那么除了UI以外,BLL与DAL都不用改动;或者将SQLServer改为Oracle,只需替换SQLServerDAL到OracleDAL,无需其它操作等等。
不要因为某个层对你来说没用,或者实现起来特别简单,就认为它没有必要,或者摒弃它,或者挪作它用。只要进行了分层,不管是几层,每一层都要有明确的目的和功能实现,而不要被实际过程所左右,造成同一类文件位于不同层的情况发生。也不要出现同一层实现了不同的功能的情况发生。

4.2 项目部署
数据源统一,全网独立展现,真正实现一套系统全网覆盖
商联达商城系统利用最新技术,完美打通各渠道,实现全终端数据同步,达到全网营销的效果,并将所有管理统一于一个管理平台。
有消费者对应的消费界面,也有店铺管理者的管理店铺界面。支持多平台共享数据。支持支付宝在线收款,微信在线收款。支持快递线上发货服务。支持时时跟踪会计记录服务。
支持APP,PC,整体效果图如图4.2所示。

在这里插入图片描述
图4.2 效果展示图

硬件需求:做电商为避免数据丢失:建议使用云服务器, 自带托管功能,备份。 磁盘:最少10G 内存: 16G 系统:Win7 外网流量:50M-100M。数据库MySQL、域名、邮箱。

5 测试与分析
5.1集成测试
功能拆分测试后,进行业务场景联调测试,多异常场景考虑。
仿真真实用户的行为,实现过程如下:
抓取真实游览器用户在电商网站上的交易过程的URL,URL中包含注册信息、登入、产品代码、账户信息等。
将抓取的URL导入到C1模拟的客户段Action List中,并根据需要进行修改,如重C1的数据库中顺序提取10000个不太的用户/密码用于登陆。
整体流程图如图5.1所示。

在这里插入图片描述
图5.1 测试流程

5.2压力测试
性能测试包括在一定的用户行为混杂模式下,指定用户容量的性能评估、最大顺畅性能和极限性能。
用户行为的混杂方式,页面的访问比例、用户的操作习惯、当前热门的商品等。对指定的容量的性能进行评估,包含指定的并发用户目和用户上线速率。测试网站的响应时间、交易成功率等。测试结果如下图5.2所示:

在这里插入图片描述
图5.2 性能测试

5.3测试分析
由于在当前这个互联网的时代,不管何种网站,对图片的需求量越来越大。尤其是电商网站,几乎都会面临到海量图片资源的存储、访问等相关技术问题。在对图片服务器的架构、扩展、升级的过程中,肯定也会碰到各种各样的问题与需求。当然这并不代表,你就必须得弄一个特别NB的图片服务架构,只要简单、高效、稳定就行。这部分我们来总结一个特别简单、高效的图片服务架构:通过共享存储的方式来实现图片服务架构。
然而,也有一些人问我,现在大型网站的图片服务器的架构已经完全不是这样了,别人家的图片系统比你这个牛逼多了,为啥不直接写那个呢?
事实是:第一,大型牛逼的系统我也不会;第二, 再牛逼的系统也是从小的架构演化过去的,没有一步到位的。这里介绍图片服务器架构虽然比较简单,但也是经过了单机时代的演化了,基本上可以满足中小型分布式网站的需求。这种架构的搭建和学习成本都极低,符合目前“短平快”的开发模式。
通过共享目录的方式实现共享存储 ,在共享目录文件服务器上配置独立域名,这样可以将图片服务器和应用服务器进行分离,来实现独立图片服务器。
优点:

  1. 将图片服务和应用服务分离,缓解应用服务器的I/O负载。

  2. 通过共享目录的方式来进行读写操作,可以避免多服务器之间同步相关的问题。

  3. 相对来讲很灵活,也支持扩容/扩展。支持配置成独立图片服务器和域名访问,方便日后的扩展和优化。

  4. 相对于更加复杂的分布式的NFS系统,这种方式是性价比高,符合目前互联网的“短平快”的开发模式。
    缺点 :

  5. 共享目录配置有些繁琐。

  6. 会造成一定的(读写和安全)性能损失。

  7. 如果图片服务器出现问题,那所有的应用都会受到影响。同时也对存储服务器的性能要求特别高。

  8. 图片上传操作,还是得经过Web服务器,这对Web服务器还是有巨大的压力。
    6总结与展望
    这次毕业设计让我受益匪浅,通过这次设计我对自己所学的知识得到了较全面的回顾,并充分发挥对所学知识的理解和对毕业设计的思考及书面表达能力,分析和解决问题,把知识转化为能力的实际训练。在毕业设计过程中,有几点要注意的地方:
    1.团队协作能力和团队沟通能力这点在整个项目的开发过程中极为重要。
    2.项目的部署。
    3.测试过程中的性能标准恒定和把控,由于没办法准确知道具体要求的并发量,无法判断性能是否达标,只能极限压测,导致过程中部分应用直接挂掉,整个链路全部崩溃。
    4.需要注意的是,以上都是计算单个服务器或是单个集群的容量。实际生产环境是由Web、消息队列、缓存、数据库等等一系列组成的复杂集群。在分布式系统中,任何节点出现瓶颈,都有可能导致雪崩效应,最后导致整个集群垮掉。
    由于时间仓促理论和实践能力不足,系统的设计有一些不如人意的地方,还需要以后对系统进行进一步的研究和不断改进和完善,是电商系统和AI技术进行结合促进整个市场的消费。

相关推荐:

    本文网址:http://www.shlzwl.cn/a/hulianwang/dianshang/177727.html ,喜欢请注明来源。

站长沙龙 www.shlzwl.cn 中国百万站长的福音,一站式服务。网站地图

Copyright © 2002-2019 站长沙龙 客服

Top