一、项目简介
该项目为《设计一个类似知乎的问答系统（后端）》，该项目与ios客户端部分共同组成了一个完整的问答系统。项目的内容是实现国内知名问答网站知乎的部分功能，为用户提供一个问答社区，用户可以在该社区浏览问题、发布问题、回答问题。社区还提供评论、点赞、点踩、收藏等扩展功能。
二、系统架构
本项目采用 C/S（客户机/服务器模式）架构风格，服务器负责数据的管理，客户机负责完成与用户的交互任务。客户机代码通过 HTTP 协议，以请求和应答的方式访问或者调用服务代码 。客户机/服务器模式中，客户是主动的，服务是被动的。客户知道它向哪个服务发出请求，而服务却不知道它正在为哪个客户提供服务，甚至不知道正在为多少客户提供服务。客户机/服务器模式的架构风格具有典型的模块化特征，降低了系统中客户和服务构件之间耦合度，提高了服务构件的可重用性。
类似于传统的 MVC 软件架构，本项目采用前后端分离的软件架构，在该项目中，前端就是客户端，后端也就是服务端。前端负责 View 和 Controller 层 ，而后端负责Model层，为前端提供一系列的 api 接口，重点关注业务/数据处理等。
前后端分离的优势：
-
实现真正的前后端解耦。页面逻辑，跳转错误，页面样式等问题，全部由前端工程师来负责。接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。双方互不干扰。
-
通过一些代码重构，也可以大量复用接口，提升效率。
-
增加代码的维护性，易读性。
-
提升开发效率，因为可以前后端并行开发，而不是像以前的强依赖。
三、接口API
| 接口名称 | 接口地址 | 请求方式 | 请求参数 | 响应信息 |
|---|---|---|---|---|
| 用户注册 | /user/register | POST | 用户名、密码、确认密码 | 注册成功/失败的信息 |
| 用户登录 | /user/login | POST | 用户名、密码、 | 登录成功/失败的信息 |
| 查看个人信息 | /user/me | GET | token | 用户的个人信息 |
| 发布问题 | /questions | POST | token、问题相关信息 | 发布成功/失败的信息 |
| 查看问题 | /questions/{qid} | GET | token、问题ID | 问题的相关信息 |
| 修改问题 | /questions/{qid} | PUT | token、问题ID、问题相关信息 | 问题的相关信息 |
| 删除问题 | /questions/{qid} | DELETE | token、问题ID | 删除成功/失败的信息 |
| 首页推荐列表 | /questions | GET | limit、offset | 推荐列表信息 |
| 热门问题列表 | /hot_questions | GET | limit、offset | 热门列表信息 |
| 回答问题 | /questions/{qid}/answers | POST | token、问题ID、回答相关信息 | 回答成功/失败的信息 |
| 查看回答 | /questions/{qid}/answers/{aid} | GET | 问题ID、回答ID | 回答的相关信息 |
| 修改回答 | /questions/{qid}/answers/{aid} | PUT | token、问题ID、回答ID、回答相关信息 | 回答的相关信息 |
| 删除回答 | /questions/{qid}/answers/{aid} | DELETE | token、问题ID、回答ID | 删除成功/失败的信息 |
| 获取回答列表 | /questions/{qid}/answers | GET | 问题ID、排序类型、limit、offset | 回答列表信息 |
四、软件系统概念原型的不同视图
4.1 分解视图
分解是构建软件架构模型的关键步骤，分解视图也是描述软件架构模型的关键视图，一般分解视图呈现为较为明晰的分解结构特点。分解视图用软件模块勾划出系统结构，往往会通过不同抽象层级的软件模块形成层次化的结构。
本系统的分解视图如下：
4.2 依赖视图
依赖视图展现了软件模块之间的依赖关系。
本系统的依赖视图如下：
4.3 执行视图
执行视图展示了系统运行时的时序结构特点。
这里展示系统较为通用的执行视图如下：
4.4 实现视图
实现视图是描述软件架构与源文件之间的映射关系。
本系统的实现视图如下：
├── api 控制层，负责处理请求
│ ├── v1 具体API版本
├── cache 缓存相关
├── conf 配置文件相关
├── middleware 中间件
├── model 数据模型相关
├── routes 路由配置
├── serializer 将数据模型进行序列化，用于构建响应信息
├── service 业务层，负责处理复杂业务
├── utils 常用工具类
4.5 部署视图
部署视图是将执行实体和计算机资源建立映射关系。
本系统的部署视图如下：
4.6 工作任务分配视图
工作分配视图将系统分解成可独立完成的工作任务，以便分配给各项目团队和成员。
本系统的工作任务分配视图如下：
五、数据库设计
- 用户表，储存用户信息
| 字段 | 类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| id | bigint(20) | 否 | ||
| username | varchar(32) | 否 | 用户名 | |
| nickname | varchar(32) | 否 | 昵称 | |
| password | varchar(256) | 否 | 密码 | |
| varchar(256) | 否 | 邮箱 | ||
| avatar | text | 否 | 头像 | |
| status | int(11) | 否 | 0 | 状态 |
| create_time | bigint(20) | 否 | 创建时间 | |
| update_time | bigint(20) | 否 | 更新时间 |
- 问题表，储存发布的问题
| 字段 | 类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| id | bigint(20) | 否 | ||
| user_id | bigint(20) | 否 | 问题所属用户 ID | |
| title | varchar(128) | 否 | 标题 | |
| summary | text | 否 | 摘要 | |
| content | longtext | 否 | 内容 | |
| status | int(11) | 否 | 0 | 状态 |
| create_time | bigint(20) | 否 | 创建时间 | |
| update_time | bigint(20) | 否 | 更新时间 |
- 回答表，储存发布的回答
| 字段 | 类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| id | bigint(20) | 否 | ||
| user_id | bigint(20) | 否 | 回答所属用户 | |
| question_id | bigint(20) | 否 | 回答所属问题id | |
| title | varchar(128) | 否 | 标题 | |
| content | longtext | 否 | 内容 | |
| comment_count | bigint(20) | 否 | 0 | 评论数 |
| collect_count | bigint(20) | 否 | 0 | 收藏数 |
| view_count | bigint(20) | 否 | 0 | 浏览数 |
| status | int(11) | 否 | 0 | 状态 |
| create_time | bigint(20) | 否 | 创建时间 | |
| update_time | bigint(20) | 否 | 更新时间 |
- 评论表，储存各种评论
| 字段 | 类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| id | bigint(20) | 否 | ||
| user_id | bigint(20) | 否 | 评论所属用户id | |
| entity_type | int(11) | 否 | 被评论的实体类型 | |
| entity_id | bigint(20) | 否 | 被评论的实体id | |
| target_id | bigint(20) | 否 | 被评论的用户id | |
| content | longtext | 否 | 内容 | |
| status | bigint(20) | 否 | 0 | 状态 |
| create_time | bigint(20) | 否 | 创建时间 |
六、运行环境和技术选型
6.1 运行环境
项目采用 Docker 进行部署，运行在 Linux (Centos7.3) 系统上。
6.2 技术选型
- 开发语言：Golang
- Web 框架：Gin
- ORM 框架：Gorm
- 缓存：Redis
- 关系型数据库：MySQL
- 消息队列中间件：RabbitMQ
- 集成开发环境：Goland
- 接口调试工具：Postman
七、系统概念原型的核心工作机制
之前介绍的各种视图都是从不同的角度对软件架构进行描述和建模，比如从功能的角度、从代码结构的角度、从运行时结构的角度、从目录文件的角度，或者从项目团队组织结构的角度。
软件架构代表了软件系统的整体设计结构，它应该是所有这些视图的集合。但我们不会将不同角度的这些视图整合起来，因为不便于阅读和更新。不过我们会有意识地将不同角度的视图之间的映射关系和重叠部分了然于胸，从而深刻理解软件架构内在的一致性和完整性，这就是系统概念原型。
根据本文上述内容分析可知本项目核心工作机制如下：
用户在 IOS 客户端输入账户密码，IOS客户端将这些数据通过 HTTP 协议发送到后端服务器。后端服务器进行参数校验、建立数据模型、查询数据库、判断能否登录。如果登录成功则返回成功信息，并携带系统分配的 token，用户后续请求都携带 token，中间件可以根据 token 进行权限校验，并识别用户。如果没有通过权限检验，则用户的系统功能将会受到限制。
用户可以根据自身的权限获得系统提供的查看问题列表、发布回答、修改个人信息等服务，也可以点赞、收藏等，这些操作的执行都像执行视图中所展示的一样，如果每一步出现了问题，都会向用户返回相关错误信息，并详细描述错误，以便客户端软件和用户对此处理。