苍穹外卖学习笔记（一）开发环境搭建

苍穹外卖技术框架

•  网关层：
  • Nginx:反向代理+负载均衡
    • nginx学习，看这一篇就够了：下载、安装。使用：正向代理、反向代理、负载均衡。常用命令和配置文件,很全-CSDN博客
• 应用层：
  • 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: 一种通信网络协议，使客户端和服务器之间的数据交换更加简单，用于项目的来单、催单功能实现。
• 数据层：

  • 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;
}