更新文档
This commit is contained in:
Junling Bu
24
doc/FAQ.md
24
doc/FAQ.md
@@ -127,6 +127,30 @@ mvn clean
|
||||
mvn package
|
||||
```
|
||||
|
||||
### 2.2 登录连接超时，联系管理员
|
||||
|
||||
现象：
|
||||
|
||||
管理后台登录时，出现报错信息：登录连接超时
|
||||
|
||||
原因：
|
||||
|
||||
1. 首先，需要明白这是前后端分离项目，前端会向后端发送请求；
|
||||
2. 其次，需要明白报错的地方，是litemall-admin/src/utils/request.js文件中;
|
||||
3. 最后，连接超时是说发送给后端的请求长时间未反应。这里存在两个可能性：
|
||||
* 真连接超时，目前request.js文件中设置请求超时时间是5s，因此真的可能5s后端
|
||||
未及时返回数据；
|
||||
* 假连接超时，例如向一个不存在的地址请求数据，那自然是返回连接失败。
|
||||
|
||||
解决方案：
|
||||
|
||||
通常是开发者设置不正确引起的假连接超时。
|
||||
|
||||
1. 首先，用chrome的开发者工具查看登录页面向后端请求的具体地址；
|
||||
2. 然后，测试后端的服务是否已启动，请求地址是否可以访问。
|
||||
3. 最后，如果设置正确，用chrome的开发者工具查看登录页面向后端请求返回数据信息；
|
||||
如果设置不正确，请启动相应的后端服务。
|
||||
|
||||
## 3. 基础系统
|
||||
|
||||
这里主要是指litemall-d、litemall-core和litemall-all模块三个模块的相关问题。
|
||||
|
||||
BIN
doc/pic1/1-13.png
Normal file
BIN
doc/pic1/1-13.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
BIN
doc/pic1/1-14.png
Normal file
BIN
doc/pic1/1-14.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.1 KiB |
BIN
doc/pic1/1-15.png
Normal file
BIN
doc/pic1/1-15.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.7 KiB |
@@ -1154,4 +1154,98 @@ litemall-admin编译得到的前端文件在第一次加载时相当耗时，这
|
||||
|
||||
目前不支持
|
||||
|
||||
### 1.7.3 Spring Boot配置方案
|
||||
### 1.7.3 项目代码风格
|
||||
|
||||
由于本项目涉及三种技术栈，因此针对这三种技术栈也存在三种代码风格。
|
||||
|
||||
如果开发者想要贡献代码，建议尽可能保证代码符合这里的规范。
|
||||
|
||||
#### 1.7.3.1 Spring Boot技术栈代码风格
|
||||
|
||||
这里的代码风格采用IDEA默认代码风格。
|
||||
|
||||
修改代码后，利用`Code`菜单的`Reformat Code`即可格式化代码。
|
||||
|
||||
#### 1.7.3.2 小程序技术栈代码风格
|
||||
|
||||
这里的代码风格采用微信开发者工具默认代码风格。
|
||||
|
||||
修改代码以后，利用`编辑`菜单的`格式化代码`即可格式化代码。
|
||||
|
||||
#### 1.7.3.3 Vue技术栈代码风格
|
||||
|
||||
这里的代码风格采用ESLint配置代码风格，具体参考vue-element-admin下项目的
|
||||
[ESLint文档](https://panjiachen.github.io/vue-element-admin-site/zh/guide/advanced/eslint.html),
|
||||
特别是`vscode 配置 ESLint`内容。
|
||||
|
||||
注意：
|
||||
> Visual Studio Code编辑器中右键存在`格式化代码`的选项，但是请不要使用这种方式，
|
||||
> 因为VSC自带的格式化代码风格和ESLint代码风格可能不完全一致。
|
||||
|
||||
### 1.7.4 Spring Boot多模块多阶段配置
|
||||
|
||||
目前后端服务采用Spring Boot多模块方案，结构清晰、易于测试。
|
||||
|
||||
但是存在一个问题，即多模块配置依赖。
|
||||
例如，litemall-db模块存在数据库配置信息，那么其他模块如何引入
|
||||
litemall-db模块的配置信息呢？
|
||||
|
||||
最简单的方式，就是其他模块把litemall-db模块的配置信息拷贝到自己的
|
||||
application配置文件中，但是问题就是数据库信息一旦改变则其他模块又要
|
||||
再次手动修改，非常不方便。
|
||||
|
||||
目前本项目采用一种基于`spring.profiles.active`的方式，细节如下：
|
||||
1. litemall-db模块存在application.yml和application-db.yml两个配置文件，
|
||||
在application-db.yml配置文件中存放数据库配置信息；
|
||||
2. litemall-core模块也存在application.yml和application-core.yml两个配置文件,
|
||||
在application-core.yml配置文件中存放core模块的一些配置信息，而在application.yml
|
||||
中存在这样一个配置：
|
||||
```
|
||||
spring:
|
||||
profiles:
|
||||
active: core, db
|
||||
```
|
||||
因此，如果单独启动litemall-core模块，则会先读取application.yml配置文件，然后基于
|
||||
系统会根据`spring.profiles.active`读取application-db.yml和application-core.yml配置文件，
|
||||
因此就会自动读取litemall-db模块的配置文件。
|
||||
3. 以此类推，在litemall-all模块中存在application.yml配置文件，其中内容是
|
||||
```
|
||||
spring:
|
||||
profiles:
|
||||
active: db, core, admin, wx
|
||||
```
|
||||
因此，系统启动litemall-all模块以后，则会先读取application.yml配置文件，然后基于
|
||||
`spring.profiles.active`进一步读取application-db.yml、application-core.yml、
|
||||
application-admin.yml和application-wx.yml四个模块的配置文件。
|
||||
|
||||
但是，虽然以上方案解决了多模块配置依赖问题，但是又会导致另外一个问题，如何支持不同profile，
|
||||
也就是开发阶段、测试阶段和上线阶段配置不同。
|
||||
|
||||
这里介绍本项目的思路，就是基于Spring Boot的配置加载顺序，采用外部配置文件覆盖jar包内部配置文件。
|
||||
1. 开发阶段，系统的配置信息在模块的resources目录配置文件中；
|
||||
2. 测试或者部署阶段，系统打包成一个litemall.jar二进制jar包，jar包内部配置文件是之前
|
||||
开发阶段的配置文件，此时在litemall.jar的同级目录创建相同的配置文件，在这些配置文件则
|
||||
保存了测试或者部署阶段的配置信息。启动litemall.jar时，系统会读取当前目录的配置文件，而
|
||||
不再读取jar包内部的配置文件。
|
||||
3. 上线阶段，同样地，在litemall.jar包同级目录创建上线配置文件。
|
||||
|
||||
此外，这里还可以采用另外一种思路，如下图：
|
||||
|
||||
|
||||
|
||||
其实原理也很简单，就是配置文件采用application-{module}-{profile}.yml来支持不同模块不同阶段的配置需求。
|
||||
|
||||
### 1.7.5 前后端校验
|
||||
|
||||
本项目是前后端分离项目，当用户或者管理员在系统中输入数据时，
|
||||
数据需要进行两层校验。
|
||||
|
||||
* 第一层是前端校验，是对参数格式校验。
|
||||
* 第二层是后端校验，不仅对参数校验，还会根据业务场景进行校验。
|
||||
|
||||
注意
|
||||
> 目前项目校验思路是这样，但是实际代码的校验还不完善，
|
||||
> 例如前端校验很好
|
||||
|
||||
### 1.7.6 后端校验返回码
|
||||
|
||||
|
||||
225
doc/wxmall.md
225
doc/wxmall.md
@@ -93,251 +93,70 @@ litemall
|
||||
|
||||
### 3.1.1 授权服务
|
||||
|
||||
#### 3.1.1.1 账号登录
|
||||
|
||||
#### 3.1.1.2 微信登录
|
||||
|
||||
#### 3.1.1.3 账号注册
|
||||
|
||||
目前账号注册只是简单的根据用户名和密码新建一个账号。
|
||||
|
||||
这里缺失一个重要的属性，即用户邮箱或者手机号，来限制用户随意注册。
|
||||
|
||||
#### 3.1.1.6 密码找回
|
||||
见WxAuthController类。
|
||||
|
||||
### 3.1.2 首页服务
|
||||
|
||||
见WxHomeController类。
|
||||
|
||||
### 3.1.3 类目服务
|
||||
|
||||
见WxCatelogController类。
|
||||
|
||||
### 3.1.4 商品服务
|
||||
|
||||
#### 3.1.4.1 商品新品
|
||||
|
||||
#### 3.1.4.2 商品热品
|
||||
|
||||
#### 3.1.4.3 商品列表
|
||||
|
||||
* 关键字搜索
|
||||
|
||||
用户的搜索采用和商品的关键字属性匹配来查找商品。
|
||||
因此需要管理员添加商品时设置关键字值。
|
||||
|
||||
这里只是简单的搜索，更好地做法可能是进一步搜索商品的名字、简介。
|
||||
或者采用更为专业的搜索算法。
|
||||
|
||||
|
||||
#### 3.1.4.4 商品详情
|
||||
|
||||
#### 3.1.4.5 同类商品
|
||||
|
||||
#### 3.1.4.6 商品总数
|
||||
|
||||
#### 3.1.4.7 相关商品
|
||||
见WxGoodsController类。
|
||||
|
||||
### 3.1.5 品牌服务
|
||||
|
||||
#### 3.1.5.1 品牌列表
|
||||
|
||||
#### 3.1.5.2 品牌详情
|
||||
见WxBrandController类。
|
||||
|
||||
### 3.1.6 专题服务
|
||||
|
||||
#### 3.1.6.1 专题列表
|
||||
|
||||
#### 3.1.6.2 专题详情
|
||||
|
||||
#### 3.1.6.3 相关专题
|
||||
见WxTopicController类。
|
||||
|
||||
### 3.1.7 搜索服务
|
||||
|
||||
#### 3.1.7.1 搜索关键字
|
||||
|
||||
#### 3.1.7.2 搜索帮助
|
||||
|
||||
#### 3.1.7.3 搜索历史清除
|
||||
|
||||
#### 3.1.7.4 搜索结果
|
||||
见WxSearchController类。
|
||||
|
||||
### 3.1.8 购物车服务
|
||||
|
||||
#### 3.1.8.1 购物车商品详情
|
||||
|
||||
#### 3.1.8.2 添加商品到购物车
|
||||
|
||||
#### 3.1.8.3 立即购物
|
||||
|
||||
#### 3.1.8.4 更新购物车商品
|
||||
|
||||
#### 3.1.8.5 删除购物车商品
|
||||
|
||||
#### 3.1.8.6 设置购物车商品选中状态
|
||||
|
||||
#### 3.1.8.7 购物车商品数量
|
||||
|
||||
#### 3.1.8.8 购物车下单前确认
|
||||
见WxCartController类。
|
||||
|
||||
### 3.1.9 订单服务
|
||||
|
||||
#### 3.1.9.1 提交订单
|
||||
|
||||
* 运费计算
|
||||
|
||||
订单费用小于88时，则需要运费8元；
|
||||
否则运费0元。
|
||||
|
||||
目前运费8元是写在后台代码中，未来可能允许设置管理员设置其他值；
|
||||
或者采用更加符合实际情况的运费计算方式。
|
||||
|
||||
#### 3.1.9.2 取消订单
|
||||
|
||||
* 用户手动取消
|
||||
|
||||
用户下单以后但是未付款，
|
||||
|
||||
* 用户超时取消
|
||||
|
||||
这里，订单超时未付款则系统会自动取消订单。
|
||||
|
||||
在实现上，则是采用Spring定时功能查询数据库内订单的时间和状态，
|
||||
如果发现超时了，则自动取消订单，而取消订单的具体操作可以简单
|
||||
采用“用户手动取消”相同的操作。
|
||||
|
||||
目前这里取消状态码是一样的，因此最终可能并不能分别订单取消是因为
|
||||
何种原因而取消的。
|
||||
|
||||
#### 3.1.9.3 取消订单并退款
|
||||
|
||||
用户付款以后再申请取消订单比较复杂，涉及微信退款操作，因此这里并没有
|
||||
简单作为“取消订单”，而是一种独立的功能。
|
||||
|
||||
#### 3.1.9.4 删除订单
|
||||
#### 3.1.9.5 订单确认发货
|
||||
#### 3.1.9.6 订单超时确认收货
|
||||
|
||||
用户收到货物以后可能并不会积极地进行“确认收货”操作，因此有必要实现
|
||||
一定时间以后订单自动确认收货。
|
||||
|
||||
“订单超时确认”的起始时间如何来设计
|
||||
|
||||
#### 3.1.9.6 可评价订单商品信息
|
||||
#### 3.1.9.7 订单列表
|
||||
#### 3.1.9.8 订单详情
|
||||
|
||||
见WxOrderController类。
|
||||
|
||||
### 3.1.10 评价服务
|
||||
|
||||
#### 3.1.10.1 评论列表
|
||||
见WxCommentController类。
|
||||
|
||||
#### 3.1.10.2 评论总数
|
||||
注意：
|
||||
> 订单商品评价功能见WxOrderController类的comment方法。
|
||||
|
||||
#### 3.1.10.3 提交评论
|
||||
### 3.1.11 团购服务
|
||||
|
||||
### 3.1.11 支付服务
|
||||
|
||||
准备采用weixin-java-tools工具简化微信支付代码的开发。
|
||||
由于需要商户相关信息，目前没有开发。
|
||||
见WxGrouponController类。
|
||||
|
||||
### 3.1.12 收藏服务
|
||||
|
||||
#### 3.1.12.1 收藏列表
|
||||
|
||||
#### 3.1.12.2 收藏设置
|
||||
见WxCollectController类。
|
||||
|
||||
### 3.1.13 足迹服务
|
||||
|
||||
#### 3.1.13.1 足迹列表
|
||||
|
||||
#### 3.1.13.2 删除足迹
|
||||
见WxFootprintController类。
|
||||
|
||||
### 3.1.14 收货地址服务
|
||||
|
||||
#### 3.1.14.1 收货地址列表
|
||||
|
||||
#### 3.1.14.2 收货地址详情
|
||||
|
||||
#### 3.1.14.3 收货地址添加
|
||||
|
||||
#### 3.1.14.4 收货地址删除
|
||||
见WxAddressController类。
|
||||
|
||||
### 3.1.15 区域服务
|
||||
|
||||
见WxRegionController类。
|
||||
|
||||
### 3.1.16 安全
|
||||
|
||||
#### 3.1.16.1 Token
|
||||
|
||||
用户登录成功以后，后端会返回`token`，之后用户的请求都会携带token。
|
||||
|
||||
目前token的失效和跟新机制没有涉及。
|
||||
|
||||
#### 3.1.16.2 CROS
|
||||
|
||||
如果litemall-admin-api不配置CROS，则Spring Boot会失败。
|
||||
但是，这里litemall-wx-api没有配置CROS，Spring Boot却不会报错，需要进一步研究。
|
||||
|
||||
#### 3.1.16.3 账号密码加盐
|
||||
|
||||
如果是微信登录，那么无需账号和密码。
|
||||
|
||||
而如果用户采用了账号和密码的形式登录，那么后端需要把用户密码加盐。
|
||||
|
||||
#### 3.1.16.4 限制登录
|
||||
|
||||
如果采用账号密码登录，那么登录失败一定次数，应该限制登录。
|
||||
|
||||
进一步地，如果项目启用了短信功能，应该短信提醒用户，防止他人登录。
|
||||
|
||||
目前这里没有实现，仅列出。
|
||||
|
||||
### 3.1.17 定时任务
|
||||
|
||||
目前有些业务需要定时任务：
|
||||
* 订单未付款超时自动取消订单
|
||||
* 订单未确认超时自动确认订单
|
||||
|
||||
定时任务技术上采用Spring的任务机制，即`@EnableScheduling`和`@Scheduled`注解。
|
||||
|
||||
目前需要讨论存在的限制或者问题：
|
||||
1. 定时任务带来的延时问题
|
||||
|
||||
定时任务是定时启动，而不是针对任务中具体的工作定时处理，因此会带来延时问题。
|
||||
|
||||
例如，订单未付款工作检测是基于半小时超时时间，但是因为订单是相隔半个小时才启动，
|
||||
因此会导致实际最长一个小时才能检测订单超时。
|
||||
|
||||
当然，这个问题可能并不严重。
|
||||
* 可以结合其他机制来减轻这个问题。例如订单未付款超时可以在用户查询自身订单时
|
||||
也启动，从而提前完成检测工作，给用户的感觉也是最长半小时的超时时间。
|
||||
* 这个延时是可以接收的，或者说定时任务中的工作是延时不敏感的。例如，订单未确认
|
||||
虽然希望是七天确认，但是延时带来的八天也是可以接受的。
|
||||
* 如果需要严格的时间管理，可能不应该采用定时任务机制。
|
||||
|
||||
2. 定时任务中数据库查询问题
|
||||
|
||||
目前这里的两个定时任务都是简单的查询数据库以后处理所有符合情况的订单。
|
||||
理论上可能存在大量符合情况的订单，这样在定时任务处理大量工作可能不是很好。
|
||||
但是，本项目的场景是小微型企业，因此设想的订单业务量不会很大，因此这里简化。
|
||||
|
||||
3. 分布式环境下相同定时任务问题
|
||||
|
||||
如果两台云主机都部署小商城后台服务，那么这里也会出现两个相同的定时任务。
|
||||
虽然相同定时任务导致的并发问题可以通过锁机制解决，对系统实际业务不会造成影响，
|
||||
但是相同定时任务同时存在仍然是不合理的，因此应该避免。可行做法是从小商场后台
|
||||
模块中剥离这些定时任务形成一个独立任务模块，然后单独部署，从而保证分布式环境
|
||||
下定时任务是唯一存在的。通常，这个任务模块是基于quartz技术。
|
||||
|
||||
但是目前本项目设想场景是小商场后台仅部署一台主机，同时系统中定时任务不是很多，
|
||||
因此这里定时任务仍然是耦合在小商城后台服务模块中。因此开发者需要注意到这里
|
||||
存在的潜在问题。
|
||||
|
||||
### 3.1.18 并发控制
|
||||
|
||||
参考`2.2.8 乐观锁`
|
||||
|
||||
当乐观锁更新失败时采用多次尝试方案。
|
||||
|
||||
### 3.1.19 事务管理
|
||||
|
||||
### 3.1.20 开发技巧
|
||||
### 3.1.16.1 开发技巧
|
||||
|
||||
当小商城后台服务开发中因为测试或者debug可能需要经常性重启应用，此时
|
||||
一旦重启，将导致小商场的小程序段的token失效，因此要求用户再次登录。
|
||||
|
||||
Reference in New Issue
Block a user