一、項目簡介
該項目為《設計一個類似知乎的問答系統（后端）》，該項目與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 進行權限校驗，並識別用戶。如果沒有通過權限檢驗，則用戶的系統功能將會受到限制。
用戶可以根據自身的權限獲得系統提供的查看問題列表、發布回答、修改個人信息等服務，也可以點贊、收藏等，這些操作的執行都像執行視圖中所展示的一樣，如果每一步出現了問題，都會向用戶返回相關錯誤信息，並詳細描述錯誤，以便客戶端軟件和用戶對此處理。