售票系统设计方案
1.架构设计
1. 系统架构选型
从软件架构角度，本系统采用了MVC分层的设计思想，各层级只需要关注本身的设计，而不需要关注其他层级的内部细节，层与层之间定义了良好的交互方式。具体而言，本系统可以分为三个水平层，分别是展示层，业务服务层和数据库层；系统总体结构如下图所示。
2. 软件架构风格
本系统采用浏览器-服务模式（B/S模式），该模式是Web兴起后的一种网络结构模式。相比较传统的C/S模式，B/S结构的重要特征就是分布性强、开发简单、共享性强、总体拥有费用低。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。
BS架构优势总结如下：
● 分布性强，客户端零维护。只需有网络、浏览器，能够随时随地实行查询、浏览等业务处理。
● 业务扩展简单便利，通过添加网页就可以添加服务器功能。
● 维护简单便利，只须要更改网页，就可以完成全部用户的同步更新。
● 开发简单，共享性强。
2. 业务概念原型
1. 用例设计
- 用户主要功能：用户注册、用户信息维护、查找车票、购买车票、改签及退票
- 后台管理员主要功能：列车信息维护、站点信息维护、车次设置
2. UML类图设计
根据业务需求描述，结合面向对象的思想，抽象出类、属性、方法，同时确定概念之间的关系，构建UML类图：
3. 数据库设计
采用关系数据库mysql进行设计
（1）用户表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| userId | int | 主键 |
| account | varchar | 账号 |
| password | varchar | 密码 |
| name | varchar | 姓名 |
| sex | varchar | 性别 |
| phonenum | number | 电话号码 |
| certificate_type | varchar | 证件类型 |
| certificate_num | number | 证件号码 |
| authority | varchar | 权限 |
| info | varchar | 其它信息 |
（2）角色表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| roleId | int | 主键 |
| role_type | varchar | 角色类型 |
| authority | varchar | 权限 |
| descr | varchar | 描述 |
（3） 用户角色关联表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| urId | int | 主键 |
| userId | int | 用户主键【外键】 |
| roleId | int | 角色主键【外键】 |
（4） 车次表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| trainSequenceId | int | 主键 |
| trainNum | number | 车次号 |
| trainId | int | 列车号 |
| start_station | varchar | 起点站 |
| end_station | varchar | 终点站 |
| launch_time | datetime | 启动时间 |
（5） 列车表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| trainId | int | 主键 |
| trainName | varchar | 列车名称【外键】 |
| type | varchar | 列车类型 |
| carriage_num | int | 车厢数 |
| status | int | 状态 |
（6） 车厢表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| carriageId | int | 主键 |
| trainId | int | 列车主键【外键】 |
| carriage_number | int | 车厢号 |
| carriage_type | int | 车厢类型 |
| price_coef | int | 价格系数 |
（7） 座位表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| seatId | int | 座位主键 |
| carriageId | int | 车厢主键【外键】 |
| trainId | int | 列车主键【外键】 |
| seat_number | int | 座位号 |
| bitmap | int | 座位站点状态位图 |
（8） 站点表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| stationId | int | 站点主键 |
| name | varchar | 站点名称 |
| descr | varchar | 站点级别 |
（9） 车次站点表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| train_sta_Id | int | 车次站点主键 |
| trainSequenceId | int | 车次主键【外键】 |
| station_sequence | int | 站点序列 |
| arrive_time | datetime | 到达时间 |
| lanch_time | datetime | 启动时间 |
（10） 订单表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| orderId | int | 订单主键 |
| userId | int | 用户主键【外键】 |
| seatId | int | 座位主键【外键】 |
| order_time | datetime | 时间 |
| status | varchar | 订单状态 |
| descr | varchar | 订单描述 |
（11） 字典表
| 字段名称 | 字段类型 | 字段描述 |
|---|---|---|
| dictionaryId | int | 字典表主键 |
| attributes | varchar | 属性名称 |
| value | varchar | 属性取值 |
4. 分解视图
针对业务模块进行分解
5. 实现视图
项目的目录结构设计
本项目采用MVC分层架构，其中，主流的目录结构设计是按照controller、service、dao层来进行分包。然而，考虑到本项目业务模块较少，且Go web中忌讳包名后缀重复（例如import service.userService），我们根据业务模块进行分包，如图所示：
6. 执行视图
时序图：以用户购票业务为例
7. 部署视图
部署图描述的是系统运行时的结构，展示了硬件的配置及其软件如何部署到网络结构中。
一个系统模型只有一个部署图，部署图通常用来帮助理解分布式系统。部署视图有助于设计人员分析一个设计的质量属性，比如软件处理网络高并发的能力、软件对处理器的计算需求等。
8. API接口
1. 用户注册：
- 功能描述：用户注册个人账号
- 处理流程及要点：用户填写个人基本信息并提交，系统验证用户信息合法性，如果不合法，则返回相应的错误提示信息；否则提示注册成功，向表中插入数据
- 输入：账号，密码，性别，年龄，证件类型，证件号码
- 输出：（1）成功：注册成功 （2） 失败：失败原因
2. 用户登录
- 功能描述：用户登录火车售票平台
- 处理流程及要点：用户输入账号密码并提交，系统进行验证，如果通过则进入主页面；否则登录失败，并返回相应信息
- 输入：账号名，密码
- 输出：（1）成功：登录成功 （2） 失败：失败原因
3. 查票
- 功能描述：普通用户查询车票
- 处理流程及要点：用户输入筛选信息，系统返回满足条件的查找结果
- 输入：起点站，终点站，（可选项：时间，座次，车次）
- 输出：（1）成功：返回查找结果 （2） 失败：返回失败原因
4. 购票
- 功能描述：普通用户购买车票
- 处理流程及要点：用户输入筛选信息进行查票，选择车票购买，系统判断出票条件进行出票，成功出票则生成订单信息
- 输入：车次，座位号
- 输出：（1）成功：车票信息，包括车次，买票人信息，始发站，终点站，时间，座位号 （2） 失败：失败原因
5. 改签、退票
- 功能描述：普通用户改签车票或退票
- 处理流程及要点：用户选择要改签/退票的车票，系统重置该车票的信息及状态
- 输入：车次，座位号，若改签则还需输入改签时间
- 输出：（1）成功：返回车票信息或状态 （2） 失败：返回失败原因
6. 站点信息维护
- 功能描述：管理员用户维护站点信息
- 处理流程及要点：管理员用户维护站点表，主要包括增删改查等操作
- 输入：增删改查相应参数
- 输出：（1）成功：成功信息 （2） 失败：失败原因
7. 列车信息维护
- 功能描述：管理员用户维护列车信息
- 处理流程及要点：管理员用户维护列车表、车厢表、座位表，主要包括增删改查等操作
- 输入：增删改查相应参数
- 输出：（1）成功：成功信息 （2） 失败：失败原因
8. 车次设置
- 功能描述：管理员用户添加车次信息
- 处理流程及要点：管理员用户输入车次信息，系统进行判断和验证，并执行对应业务逻辑
- 输入：列车ID，始末站点，中途站点，各站点区间票价，发车日期和时间
- 输出：（1）成功：该车次信息 （2） 失败：失败原因
9. 技术选型
1. 开发技术
- 编程语言：GoLang
- 后端框架：Gin
- 持久化层：Gorm，Mysql
- 缓存层：Redis
- 部署环境：Linux，Docker
2. 设计模式
- 单例模式：数据库连接池。创建数据库连接是一个很耗时的操作，也容易对数据库造成安全隐患。所以，在程序初始化的时候，集中创建多个数据库连接，并把他们集中管理，供程序使用，可以保证较快的数据库读写速度，还更加安全可靠。
- 管道模式：消息中间件。通过中间件实现业务的解耦，在代码实现时，我们只需要关注各个阶段的实现，最后通过管道方式拼接起来。
- 享元模式：运用共享技术来有效地支持大量细粒度对象的复用，比如线程池。
10. 系统概念原型工作机制
以用户注册和查票为例进行说明
- 用户注册：用户填写注册信息【用户数据模型：账号，密码，姓名，性别，电话号码，证件号码…】，系统进行校验，并返回相应信息。
- 查票：用户输入或选择筛选条件，系统返回车票信息【车票数据模型：车次号，座位号，起点站，终点站，发车时间，到达时间，票价…】