苍穹外卖项目笔记day01
我已经用了22天完成苍穹外卖后端的全部内容,接下来就是我的内容分享
项目介绍
本项目（苍穹外卖）是专门为餐饮企业（餐厅、饭店）定制的一款软件产品，包括 系统管理后台 和 小程序端应用 两部分。其中系统管理后台主要提供给餐饮企业内部员工使用，可以对餐厅的分类、菜品、套餐、订单、员工等进行管理维护，对餐厅的各类数据进行统计，同时也可进行来单语音播报功能。小程序端主要提供给消费者使用，可以在线浏览菜品、添加购物车、下单、支付、催单等。以下为完整项目的展示
接下来，通过功能架构图来展示管理端和用户端的具体业务功能模块。
1). 管理端功能
员工登录/退出 , 员工信息管理 , 分类管理 , 菜品管理 , 套餐管理 , 菜品口味管理 , 订单管理 ，数据统计，来单提醒。
| 模块 | 描述 |
|---|---|
| 登录/退出 | 内部员工必须登录后,才可以访问系统管理后台 |
| 员工管理 | 管理员可以在系统后台对员工信息进行管理，包含查询、新增、编辑、禁用等功能 |
| 分类管理 | 主要对当前餐厅经营的 菜品分类 或 套餐分类 进行管理维护， 包含查询、新增、修改、删除等功能 |
| 菜品管理 | 主要维护各个分类下的菜品信息，包含查询、新增、修改、删除、启售、停售等功能 |
| 套餐管理 | 主要维护当前餐厅中的套餐信息，包含查询、新增、修改、删除、启售、停售等功能 |
| 订单管理 | 主要维护用户在移动端下的订单信息，包含查询、取消、派送、完成，以及订单报表下载等功能 |
| 数据统计 | 主要完成对餐厅的各类数据统计，如营业额、用户数量、订单等 |
2). 用户端功能
微信登录 , 收件人地址管理 , 用户历史订单查询 , 菜品规格查询 , 购物车功能 , 下单 , 支付、分类及菜品浏览。
移动端应用主要提供给消费者使用。
| 模块 | 描述 |
|---|---|
| 登录/退出 | 用户需要通过微信授权后登录使用小程序进行点餐 |
| 点餐-菜单 | 在点餐界面需要展示出菜品分类/套餐分类, 并根据当前选择的分类加载其中的菜品信息, 供用户查询选择 |
| 点餐-购物车 | 用户选中的菜品就会加入用户的购物车, 主要包含 查询购物车、加入购物车、删除购物车、清空购物车等功能 |
| 订单支付 | 用户选完菜品/套餐后, 可以对购物车菜品进行结算支付, 这时就需要进行订单的支付 |
| 个人信息 | 在个人中心页面中会展示当前用户的基本信息, 用户可以管理收货地址, 也可以查询历史订单数据 |
前端环境搭建
在这里前端环境主要是由黑马老师提供的学习资源包自主下载
其中我们的访问端口号是可以自己修改的,博主这边就把端口改成8081,如果修改了,后续有一些也需要一并修改,避免运行不了… 具体修改步骤如下:
1.点击conf文件夹
2.点击nginx.conf配置文件
3.将配置文件中8081改成你想要的端口号就行,但是切记端口号必须是为空闲状态
后端环境搭建
这里的初始工程也是由资源包提供,我们只需按照步骤导入就行,在技术分享中有详细讲解如何正确导入项目
其中该项目的数据库比较多,有十几个表组成,也是直接导入即可,就不一一赘述
Git版本控制
使用Git工具可以将我们的项目代码传到指定的本地仓库与远程仓库,这里我们使用的是Gitee码云作为我们的远程仓库. 对于仓库的理解:我们可以当成一个游戏的存档,记录我们的游戏进度,方便我们遇见各种意外后的随时返回,或以后的随时查看–>在代码中,就便于我们及时上传我们完善的功能,以及遇见bug时可以及时回到上个环境
- 以下是对Git的一些基本操作与解释
nginx反向代理与负载均衡
这里我们引入一个NGINX的反向代理功能,这是我们在实现前后端请求响应的手段
proxy_pass：该指令是用来设置代理服务器的地址，可以是主机名称，IP地址加端口号等形式。
如上代码的含义是：监听80端口号， 然后当我们访问 http://localhost:80/api/…/…这样的接口的时候，它会通过 location /api/ {} 这样的反向代理到 http://localhost:8080/admin/上来。
nginx 负载均衡策略：
| 名称 | 说明 |
|---|---|
| 轮询 | 默认方式,将请求按顺序逐一分配给不同的后端服务器。 |
| 加权轮询 | 权重方式，默认为1，权重越高，被分配到的请求越多。 |
| IP 哈希(ip_hash) | 根据客户端 IP 地址计算哈希值，将同一个 IP 的请求总是转发到同一台后端服务器 |
| 最少连接(least_conn) | 将请求优先分配给当前连接数最少的后端服务器。适合请求处理时间长短不一的服务。 |
| url_hash | 依据url分配方式，这样相同的url会被分配到同一个后端服务 |
| fair | 依据响应时间方式，响应时间短的服务将会被优先分配 |
正向代理与反向代理区别
| 特性 | 正向代理 (Forward Proxy) | 反向代理 (Reverse Proxy) |
|---|---|---|
| 代理对象 | 客户端 | 服务器 |
| 位置 | 位于客户端之前 | 位于服务器之前 |
| 作用 | 替客户端向外部服务器发送请求，隐藏客户端身份（如：VPN） | 替服务器接收客户端的请求，隐藏服务器身份（如：负载均衡、安全屏障） |
| 知名例子 | VPN、Shadow-socks | Nginx、CDN |
简单比喻：
- 正向代理：我们（客户端）找秘书（正向代理） 帮我们去图书馆（服务器）借书，图书馆不知道是谁想借书。
- 反向代理：我们（客户端）去图书馆前台（反向代理） 说要借书，前台会自己去后面的书库（真实服务器）找书，我们不知道书具体来自哪个书库。
MD5加密方式
在数据库中采用明文存储用户密码这种重要信息是不安全的,因此用MD5加密方式将我们的明文改成密文是我们的首选方式
MD5加密与解密网址:https://www.sojson.com/encrypt_md5.html
在这个方法中,主要实现逻辑:将前端我们输入的明文密码传递过来后,进行MD5加密后,再与数据库中所存储的账户密码(MD5加密格式)进行比对,如果相同则登录
/*** 员工登录** @param employeeLoginDTO* @return*/
public Employee login(EmployeeLoginDTO employeeLoginDTO) {
String username = employeeLoginDTO.getUsername();
String password = employeeLoginDTO.getPassword();//1、根据用户名查询数据库中的数据
Employee employee = employeeMapper.getByUsername(username);//2、处理各种异常情况（用户名不存在、密码不对、账号被锁定）
if (employee == null) {//账号不存在throw new AccountNotFoundException(MessageConstant.ACCOUNT_NOT_FOUND);
}//密码比对
// 对前端传过来的明文密码进行MP5加密处理
password=DigestUtils.md5DigestAsHex(password.getBytes());
if (!password.equals(employee.getPassword())) {//密码错误throw new PasswordErrorException(MessageConstant.PASSWORD_ERROR);
}if (employee.getStatus() == StatusConstant.DISABLE) {//账号被锁定throw new AccountLockedException(MessageConstant.ACCOUNT_LOCKED);
}//3、返回实体对象
return employee;
}
基于Swagger的Knife4j注解
Swagger 是一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务(https://swagger.io/)。 它的主要作用是：
- 使得前后端分离开发更加方便，有利于团队协作
- 接口的文档在线自动生成，降低后端开发人员编写接口文档的负担
knife4j是为Java MVC框架集成Swagger生成Api文档的增强解决方案
- 引入依赖
- 项目中在webMvcConfiguration配置Knife4j：
- 设置静态资源映射，否则接口文档页面无法访问
在浏览器中输入:http://localhost:8080/doc.html#/home 
Yapi与Swagger区别
常用注解
以上为本人整理的第一天笔记内容.如有错误欢迎指导指正,其中有一点需要注意的是在本项目中,最好使用JDK17,这样可以避免很多依赖版本冲突各种问题,接口测试我则是使用Apifox