苍穹外卖技术框架
- 网关层：
- Nginx:反向代理+负载均衡
- nginx学习，看这一篇就够了：下载、安装。使用：正向代理、反向代理、负载均衡。常用命令和配置文件,很全-CSDN博客
- Nginx:反向代理+负载均衡
- 应用层：
- Spring Boot：简化spring程序的创建和开发过程，简化配置过程
- SpringBoot框架-CSDN博客
- Spring MVC：MVC是一种软件架构思想，把软件按照模型，视图，控制器来划分。Spring Web MVC是基于Servlet API构建的原始Web框架，也是Spring框架的一部分。它提供了灵活可扩展的MVC架构，方便开发者构建高性能的Web应用程序，并与 Spring 生态系统无缝集成。
- 【框架篇】Spring MVC 介绍及使用（详细教程）_springmvc-CSDN博客
- Spring Task： 由Spring提供的定时任务框架。
- httpclient：主要实现了对http请求的发送。
- Spring Cache： 由Spring提供的数据缓存框架
- JWT： 用于对应用程序上的用户进行身份验证的标记。
- 阿里云OSS： 对象存储服务，在项目中主要存储文件，如图片等。
- Swagger： 可以自动的帮助开发人员生成接口文档，并对接口进行测试。
- POI: 封装了对Excel表格的常用操作。
- WebSocket: 一种通信网络协议，使客户端和服务器之间的数据交换更加简单，用于项目的来单、催单功能实现。
- Spring Boot：简化spring程序的创建和开发过程，简化配置过程
- 数据层：
-
MySQL： 关系型数据库, 本项目的核心业务数据都会采用MySQL进行存储。
-
Redis： 基于key-value格式存储的内存数据库, 访问速度快, 经常使用它做缓存。
-
Mybatis： 本项目持久层将会使用Mybatis开发。
-
pagehelper: 分页插件。
-
spring data redis: 简化java代码操作Redis的API。
-
-
工具
-
git: 版本控制工具, 在团队协作中, 使用该工具对项目中的代码进行管理。
-
maven: 项目构建工具。
-
junit：单元测试工具，开发人员功能实现完毕后，需要通过junit对功能进行单元测试。
-
postman: 接口测工具，模拟用户发起的各类HTTP请求，获取对应的响应结果。
-
开发环境搭建
开发环境搭建主要包含前端环境和后端环境两部分。作为服务端开发工程师， 我们课程学习的重心应该放在后端的业务代码上， 前端的页面我们只需要导入资料中的nginx， 前端页面的代码我们只需要能看懂即可。
前端环境搭建
前端工程基于 nginx
从资料中找到前端运行环境的nginx，移动到非中文目录下。
sky目录中存放了管理端的前端资源，具体如下：
启动nginx，访问测试
双击 nginx.exe 即可启动 nginx 服务，访问端口号为 80
http://localhost:80
后端环境搭建
后端模块介绍
后端工程基于 maven 进行项目构建，并且进行分模块开发。
对工程的每个模块作用说明：
| 序号 | 名称 | 说明 |
|---|---|---|
| 1 | sky-take-out | maven父工程，统一管理依赖版本，聚合其他子模块 |
| 2 | sky-common | 子模块，存放公共类，例如：工具类、常量类、异常类等 |
| 3 | sky-pojo | 子模块，存放实体类、VO、DTO等 |
| 4 | sky-server | 子模块，后端服务，存放配置文件、Controller、Service、Mapper等 |
对项目整体结构了解后，接下来我们详细分析上述的每个子模块：
sky-common: 模块中存放的是一些公共类，可以供其他模块使用
分析sky-common模块的每个包的作用：
| 名称 | 说明 |
|---|---|
| constant | 存放相关常量类 |
| context | 存放上下文类 |
| enumeration | 项目的枚举类存储 |
| exception | 存放自定义异常类 |
| json | 处理json转换的类 |
| properties | 存放SpringBoot相关的配置属性类 |
| result | 返回结果类的封装 |
| utils | 常用工具类 |
-
sky-pojo: 模块中存放的是一些 entity、DTO、VO
分析sky-pojo模块的每个包的作用：
名称 说明 Entity 实体，通常和数据库中的表对应 DTO 数据传输对象，通常用于程序中各层之间传递数据 VO 视图对象，为前端展示数据提供的对象 POJO 普通Java对象，只有属性和对应的getter和setter -
sky-server: 模块中存放的是 配置文件、配置类、拦截器、controller、service、mapper、启动类等
分析sky-server模块的每个包的作用：
名称 说明 config 存放配置类 controller 存放controller类 interceptor 存放拦截器类 mapper 存放mapper接口 service 存放service类 SkyApplication 启动类
git版本控制
使用Git进行项目代码的版本控制，具体操作：
1). 创建Git本地仓库
VCS：version control system
当Idea中出现：
说明本地仓库创建成功。
2). 创建Git远程仓库
访问Gitee - 基于 Git 的代码托管和研发协作平台，新建仓库
点击 创建
数据库环境搭建
| 序号 | 数据表名 | 中文名称 |
|---|---|---|
| 1 | employee | 员工表 |
| 2 | category | 分类表 |
| 3 | dish | 菜品表 |
| 4 | dish_flavor | 菜品口味表 |
| 5 | setmeal | 套餐表 |
| 6 | setmeal_dish | 套餐菜品关系表 |
| 7 | user | 用户表 |
| 8 | address_book | 地址表 |
| 9 | shopping_cart | 购物车表 |
| 10 | orders | 订单表 |
| 11 | order_detail | 订单明细表 |
1. employee
employee表为员工表，用于存储商家内部的员工信息。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| name | varchar(32) | 姓名 | |
| username | varchar(32) | 用户名 | 唯一 |
| password | varchar(64) | 密码 | |
| phone | varchar(11) | 手机号 | |
| sex | varchar(2) | 性别 | |
| id_number | varchar(18) | 身份证号 | |
| status | int | 账号状态 | 1正常 0锁定 |
| create_time | datetime | 创建时间 | |
| update_time | datetime | 最后修改时间 | |
| create_user | bigint | 创建人id | |
| update_user | bigint | 最后修改人id |
2. category
category表为分类表，用于存储商品的分类信息。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| name | varchar(32) | 分类名称 | 唯一 |
| type | int | 分类类型 | 1菜品分类 2套餐分类 |
| sort | int | 排序字段 | 用于分类数据的排序 |
| status | int | 状态 | 1启用 0禁用 |
| create_time | datetime | 创建时间 | |
| update_time | datetime | 最后修改时间 | |
| create_user | bigint | 创建人id | |
| update_user | bigint | 最后修改人id |
3. dish
dish表为菜品表，用于存储菜品的信息。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| name | varchar(32) | 菜品名称 | 唯一 |
| category_id | bigint | 分类id | 逻辑外键 |
| price | decimal(10,2) | 菜品价格 | |
| image | varchar(255) | 图片路径 | |
| description | varchar(255) | 菜品描述 | |
| status | int | 售卖状态 | 1起售 0停售 |
| create_time | datetime | 创建时间 | |
| update_time | datetime | 最后修改时间 | |
| create_user | bigint | 创建人id | |
| update_user | bigint | 最后修改人id |
4. dish_flavor
dish_flavor表为菜品口味表，用于存储菜品的口味信息。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| dish_id | bigint | 菜品id | 逻辑外键 |
| name | varchar(32) | 口味名称 | |
| value | varchar(255) | 口味值 |
5. setmeal
setmeal表为套餐表，用于存储套餐的信息。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| name | varchar(32) | 套餐名称 | 唯一 |
| category_id | bigint | 分类id | 逻辑外键 |
| price | decimal(10,2) | 套餐价格 | |
| image | varchar(255) | 图片路径 | |
| description | varchar(255) | 套餐描述 | |
| status | int | 售卖状态 | 1起售 0停售 |
| create_time | datetime | 创建时间 | |
| update_time | datetime | 最后修改时间 | |
| create_user | bigint | 创建人id | |
| update_user | bigint | 最后修改人id |
6. setmeal_dish
setmeal_dish表为套餐菜品关系表，用于存储套餐和菜品的关联关系。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| setmeal_id | bigint | 套餐id | 逻辑外键 |
| dish_id | bigint | 菜品id | 逻辑外键 |
| name | varchar(32) | 菜品名称 | 冗余字段 |
| price | decimal(10,2) | 菜品单价 | 冗余字段 |
| copies | int | 菜品份数 |
7. user
user表为用户表，用于存储C端用户的信息。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| openid | varchar(45) | 微信用户的唯一标识 | |
| name | varchar(32) | 用户姓名 | |
| phone | varchar(11) | 手机号 | |
| sex | varchar(2) | 性别 | |
| id_number | varchar(18) | 身份证号 | |
| avatar | varchar(500) | 微信用户头像路径 | |
| create_time | datetime | 注册时间 |
8. address_book
address_book表为地址表，用于存储C端用户的收货地址信息。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| user_id | bigint | 用户id | 逻辑外键 |
| consignee | varchar(50) | 收货人 | |
| sex | varchar(2) | 性别 | |
| phone | varchar(11) | 手机号 | |
| province_code | varchar(12) | 省份编码 | |
| province_name | varchar(32) | 省份名称 | |
| city_code | varchar(12) | 城市编码 | |
| city_name | varchar(32) | 城市名称 | |
| district_code | varchar(12) | 区县编码 | |
| district_name | varchar(32) | 区县名称 | |
| detail | varchar(200) | 详细地址信息 | 具体到门牌号 |
| label | varchar(100) | 标签 | 公司、家、学校 |
| is_default | tinyint(1) | 是否默认地址 | 1是 0否 |
9. shopping_cart
shopping_cart表为购物车表，用于存储C端用户的购物车信息。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| name | varchar(32) | 商品名称 | |
| image | varchar(255) | 商品图片路径 | |
| user_id | bigint | 用户id | 逻辑外键 |
| dish_id | bigint | 菜品id | 逻辑外键 |
| setmeal_id | bigint | 套餐id | 逻辑外键 |
| dish_flavor | varchar(50) | 菜品口味 | |
| number | int | 商品数量 | |
| amount | decimal(10,2) | 商品单价 | |
| create_time | datetime | 创建时间 |
10. orders
orders表为订单表，用于存储C端用户的订单数据。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| number | varchar(50) | 订单号 | |
| status | int | 订单状态 | 1待付款 2待接单 3已接单 4派送中 5已完成 6已取消 |
| user_id | bigint | 用户id | 逻辑外键 |
| address_book_id | bigint | 地址id | 逻辑外键 |
| order_time | datetime | 下单时间 | |
| checkout_time | datetime | 付款时间 | |
| pay_method | int | 支付方式 | 1微信支付 2支付宝支付 |
| pay_status | tinyint | 支付状态 | 0未支付 1已支付 2退款 |
| amount | decimal(10,2) | 订单金额 | |
| remark | varchar(100) | 备注信息 | |
| phone | varchar(11) | 手机号 | |
| address | varchar(255) | 详细地址信息 | |
| user_name | varchar(32) | 用户姓名 | |
| consignee | varchar(32) | 收货人 | |
| cancel_reason | varchar(255) | 订单取消原因 | |
| rejection_reason | varchar(255) | 拒单原因 | |
| cancel_time | datetime | 订单取消时间 | |
| estimated_delivery_time | datetime | 预计送达时间 | |
| delivery_status | tinyint | 配送状态 | 1立即送出 0选择具体时间 |
| delivery_time | datetime | 送达时间 | |
| pack_amount | int | 打包费 | |
| tableware_number | int | 餐具数量 | |
| tableware_status | tinyint | 餐具数量状态 | 1按餐量提供 0选择具体数量 |
11. order_detail
order_detail表为订单明细表，用于存储C端用户的订单明细数据。具体表结构如下：
| 字段名 | 数据类型 | 说明 | 备注 |
|---|---|---|---|
| id | bigint | 主键 | 自增 |
| name | varchar(32) | 商品名称 | |
| image | varchar(255) | 商品图片路径 | |
| order_id | bigint | 订单id | 逻辑外键 |
| dish_id | bigint | 菜品id | 逻辑外键 |
| setmeal_id | bigint | 套餐id | 逻辑外键 |
| dish_flavor | varchar(50) | 菜品口味 | |
| number | int | 商品数量 | |
| amount | decimal(10,2) | 商品单价 |
前后端联调
后端的初始工程中已经实现了登录功能，直接进行前后端联调测试即可
实现思路：
nginx反向代理和负载均衡
对登录功能测试完毕后，接下来，我们思考一个问题：前端发送的请求，是如何请求到后端服务的？
前端请求地址：http://localhost/api/employee/login
后端接口地址：http://localhost:8080/admin/employee/login
1). nginx反向代理
nginx 反向代理，就是将前端发送的动态请求由 nginx 转发到后端服务器。
那为什么不直接通过浏览器直接请求后台服务端，需要通过nginx反向代理呢？
nginx 反向代理的好处：
-
提高访问速度
因为nginx本身可以进行缓存，如果访问的同一接口，并且做了数据缓存，nginx就直接可把数据返回，不需要真正地访问服务端，从而提高访问速度。
-
进行负载均衡
所谓负载均衡,就是把大量的请求按照我们指定的方式均衡的分配给集群中的每台服务器。
-
保证后端服务安全
因为一般后台服务地址不会暴露，所以使用浏览器不能直接访问，可以把nginx作为请求访问的入口，请求到达nginx后转发到具体的服务中，从而保证后端服务的安全。
-
nginx 反向代理的配置方式：
在nginx.conf这个配置文件中配置
前端请求地址：http://localhost/api/employee/login
后端接口地址：http://localhost:8080/admin/employee/login
server{listen 80;server_name localhost;location /api/{proxy_pass http://localhost:8080/admin/; #反向代理}
}
proxy_pass：该指令是用来设置代理服务器的地址，可以是主机名称，IP地址加端口号等形式。
如上代码的含义是：监听80端口号， 然后当我们访问 http://localhost:80/api/../..这样的接口的时候，它会通过 location /api/ {} 这样的反向代理到 http://localhost:8080/admin/上来。
接下来，进到nginx-1.20.2\conf，打开nginx配置
# 反向代理,处理管理端发送的请求
location /api/ {proxy_pass http://localhost:8080/admin/;#proxy_pass http://webservers/admin/;
}
当在访问http://localhost/api/employee/login，nginx接收到请求后转到http://localhost:8080/admin/，故最终的请求地址为http://localhost:8080/admin/employee/login，和后台服务的访问地址一致。
2). nginx 负载均衡
当如果服务以集群的方式进行部署时，那nginx在转发请求到服务器时就需要做相应的负载均衡。其实，负载均衡从本质上来说也是基于反向代理来实现的，最终都是转发请求。
nginx 负载均衡的配置方式：
upstream webservers{server 192.168.100.128:8080;server 192.168.100.129:8080;
}
server{listen 80;server_name localhost;location /api/{proxy_pass http://webservers/admin;#负载均衡}
}
upstream：如果代理服务器是一组服务器的话，我们可以使用upstream指令配置后端服务器组。
如上代码的含义是：监听80端口号， 然后当我们访问 http://localhost:80/api/../..这样的接口的时候，它会通过 location /api/ {} 这样的反向代理到 http://webservers/admin，根据webservers名称找到一组服务器，根据设置的负载均衡策略(默认是轮询)转发到具体的服务器。
注：upstream后面的名称可自定义，但要上下保持一致。
nginx 负载均衡策略：
| 名称 | 说明 |
|---|---|
| 轮询 | 默认方式 |
| weight | 权重方式，默认为1，权重越高，被分配的客户端请求就越多 |
| ip_hash | 依据ip分配方式，这样每个访客可以固定访问一个后端服务 |
| least_conn | 依据最少连接方式，把请求优先分配给连接数少的后端服务 |
| url_hash | 依据url分配方式，这样相同的url会被分配到同一个后端服务 |
| fair | 依据响应时间方式，响应时间短的服务将会被优先分配 |
具体配置方式：
轮询：
upstream webservers{server 192.168.100.128:8080;server 192.168.100.129:8080;
}
weight:
upstream webservers{server 192.168.100.128:8080 weight=90;server 192.168.100.129:8080 weight=10;
}
ip_hash:
upstream webservers{ip_hash;server 192.168.100.128:8080;server 192.168.100.129:8080;
}
least_conn:
upstream webservers{least_conn;server 192.168.100.128:8080;server 192.168.100.129:8080;
}
url_hash:
upstream webservers{hash &request_uri;server 192.168.100.128:8080;server 192.168.100.129:8080;
}
fair:
upstream webservers{server 192.168.100.128:8080;server 192.168.100.129:8080;fair;
}
