电商话术正式版

1.项目介绍

2.项目功能描述

3.项目架构:

传统架构模式:

存在的问题：
1、 开发、维护代码比较困难
2、 系统内部的功能模块之间的耦合度太高了
3、 无法针对每个模块的特性做优化
4、 无法做服务器的水平扩展
5、 无法存储海量数据

分布式的架构:

已经解决以上存在的问题，但是，带来了新问题：
1、 系统间的服务的调用变得复杂
如何解决错综复杂的服务调用关系：服务注册中心。

4.人员配置:

5.开发流程:

6.开发技术:

7.开发环境:

话术思路

首先描述自己所做项目有哪些功能模块[O1]

举例：
最近做的电商项目，我负责的模块包括前台系统，搜索系统，还有订单系统。

描述其中单个模块有哪些功能[O2]

举例：
首先前台系统的大部分功能类似于淘宝京东的首页，主要的功能有左侧商品类目的回显，广告位，楼层数据的回显，以及完成这些数据在后台的管理，包括页面静态化。

拆分单独功能进行描述[O3]

举例：
其中左侧商品类目回显的功能类似于淘宝京东的左侧类目，在首页的左侧有很多商品的一级目录，比如手机，电脑之类的。鼠标放在一级目录上会触发一个事件弹出一个窗口显示二级目录，以此类推总共有三级目录。

描述功能中碰到的问题

举例：
在做这个商品类目回显的时候我们发现数据从后台抓取过来，前台页面解析不了。。。。。（后面的内容下面有）

介绍技术，对比技术

举例：
对于商品类目数据解析不了的问题是因为跨域，对于跨域我们先是采用了**jsonp来解决，它的优点是什么？缺点是什么？由于这个技术的缺点我们引入了新的技术，httpclient，这个技术是什么？优点是什么？缺点是什么**？

介绍完技术，再介绍功能，循环嵌套。

8.后台管理系统

8.1功能介绍:

CMS后台管理系统的主要功能:
8.1.1 实现商品信息后台管理化:在后台可以对前台的商品数据进行增删改查/实现商品规格参数的增删改查
8.1.2 实现前台网站内容管理:在后台可以实现对前台模块数据的管理,确保各个系统之间各司其职(后台系统只负责数据的增删改查.前台系统只负责对页面的数据的回显)

8.2 商品表的设计:

商品是电商的基础,没有商品,谈何电商,而我们需要让用户看到最详细的商品信息,那么我们在设计表的结构的时候就必须考虑的很详细,因为在商品的众多信息中有很多信息是经常查询的,比如商品的卖点,标题,名称,价格等,对于这些经常查询到的数据,我们需要单独放在一张表中,并对其进行分词(关于solr的相关技术问题在搜索系统中单独拿出来讲解),而对于不会经常更改的一些商品信息,比如商品描述等,我们将其放在另外一张表中,这样做的优点就是方便查询,但是缺点也很明显,修改商品的时候需要修改多张表.

最佳实践:商品价格以最小单位进行存储可以避免很多问题,存入时需要放大,显示时需要缩小.

8.3 规格参数模版表的设计:

同一个商品类目下的商品的规格参数的格式（内容）一样，只是具体的数据不同。而不同的类目的商品规格参数的格式是不同的。如果说我们对于每一件商品都得设计一张表,这种做法可行,但是维护起来相当的困难.因此我们引入了规格参数模版表,首先需要2张表,模版表跟商品类目关联生成模版,规格参数数据表跟商品关联,并套用模版生成商品的规格数据.(ps:模版存储的格式为json格式)

9前台系统

9.1功能介绍

9.1.1首页商品类目的回显（适当对功能进行描述，可以与京东或者淘宝的功能做对比）
9.1.2大广告、小广告、快报、导航栏、楼层数据的后台实现
9.1.3页面静态化

9.2 跨域请求的解决:[F4]

我们在完成首页商品类目回显(描述一下什么是商品类目,类似京东的左侧类目功能,鼠标悬停在一级目录会触发一个事件,跳出二级目录)的时候发现后台数据传输到前台,前台虽然拿到了数据,但是在解析的时候发生了错误,在通过百度的情况下,我们找到了问题的所在,浏览器在对于ajax请求的限制是不允许跨域请求的(面试官有可能会问什么是跨域:不同的域名或不同的端口都是跨域请求).
我们一开始采用了jsonp跨域,我们知道，在页面上有三种资源是可以与页面本身不同源的。它们是：js脚本/css样式文件/图片，而jsonp就是利用了