手寫一個Hexo評論系統（二）

接着上一篇文章《手寫一個Hexo評論系統（一）》，本篇文章主要是講述記述評論系統實現的一些具體的設計方案與技術細節，方便之後修改或者重構。還有項目的部署問題，包括域名解析，Nginx配置代理，雲服務器選購的一些問題，選購服務器的坑是真的大，因此仍是儘可能選擇大廠，穩定一點，好用一點就不用在意多幾那塊錢嘛，並且根據本身的須要買配置仍是比較划算的。

<!-- more -->

上次總共列出了以下的一些需求，根據這些需求來構想一下如何設計：

一、無需登陸和驗證碼，直接評論便可

二、支持回覆評論，且可無限遞歸回復

三、支持評論點贊，按照點贊排序，相同則按照時間排序

三、支持文章評分，顯示評分人數和評分的平均分數

四、支持本身的評論被別人回覆後能夠郵件通知

五、支持評論後臺管理系統，能夠設置對應屬性

六、支持評論導出，且高度100%可恢復數據

界面與UI設計

初版得UI就長這樣了，總體看起來風格比較簡單，這也是我比較喜歡的風格。在文章加載後評論者會得到一個隨機的暱稱與頭像，點擊暱稱能夠切換暱稱和頭像，不過都是隨機的而已。而後就是三個輸入框，郵箱輸入框、評論內容、文章評分。因此從總體上分紅了兩部分，一部分是用戶信息和評論框，另外一部分是具體評論展現區域，只要思考清楚了那麼就能夠開始了。

反正是作PC的Web端UI嘛，直接上ElementUI了，其實還真的挺適合的，尤爲是在展現具體評論的時候按照時間線來展現最合適不過了，並且評分組件也很OK，挺好看的，之後有時間再拿其餘的組件庫試試！

交互流程設計

首先用戶要一打開博客就能夠得到隨機頭像和暱稱，而且要保持這個用戶的狀態，因此總體思路以下：

首先對於一個從未打開過某篇博客的頁面的用戶來講，在瀏覽器端存儲的clientID確定是沒有這個字段的，直接能夠斷定爲新用戶，因此去請求後臺給一個ClientID，而且分配隨機的暱稱和頭像，把這個用戶信息給落庫，即便用戶點擊了刷新暱稱和頭像，可是ClientID並無變，用戶信息就這樣得以保存了下來。若是瀏覽器已經存在了ClientID，那麼數據庫裏面也應該有對應的用戶信息，因此就直接請求後臺拿到用戶數據便可。

第二個問題，後端怎麼知道哪些評論是哪些博客的呢？其實這裏使用了一個比較簡略的方式，那就是直接根據URL來判斷，相同的URL確定是同一篇博客，可是這樣作也是有缺陷的，就是在本地調試的時候是localhost:8080開頭，可是遠程是zouchanglin.cn，這樣在本地的測試數據就不會展現在正式的博客評論上。並且zouchanglin.cn和zouchanglin.gitee.io的評論並不相通，其實這是不合理的，應該把域名和剩餘部分URL分離出來，這樣通用性纔會更好，這一點之後有時間了我會進行重構。

第三個問題，用戶設置了郵箱那麼怎麼才能回覆的時候相互通知呢？其實對這樣的Client端設計，只要在用戶填寫了郵箱後，進行評論或者回復的操做，均可以設置郵箱，由於這樣能夠從很大程度上減小業務複雜度，只要你的郵箱出現變動，你的下一次評論想到獲得通知的時候確定會填寫新的郵箱，這樣就能夠直接更新整個用戶的郵箱，很是方便。

數據庫設計

數據庫使用MySQL 8.0。首先是設計客戶端信息表，也就是表明了用戶信息(主要包括了客戶端ID、Email、暱稱、建立時間、頭像、客戶端OS等信息，其餘字段等有須要再添加就OK)：

而後是文章信息表（主要字段是文章URL、文章評論數），一條數據對應着一條博客，其中還有博客的評論總計數目，其實徹底能夠拿URL作主鍵，可是爲了之後改動方便，目前仍是決定自定義生成主鍵比較好一些。

而後是評論表，在這裏我把評論分紅了兩種類型，一種是文章評論（主要字段是文章ID、comment_parent是無效字段、評論客戶端ID、評論內容、點贊數、建立時間、文章評分），也就是直接在文章下面的評論；另外一種是子評論（主要字段是所在的文章評論ID、評論客戶端ID、評論內容、點贊數、回覆的客戶端ID、建立時間），這個就是文章評論的回覆而已，固然不管是文章評論的子評論仍是子評論的回覆評論都被看成子評論來存儲，全部分了兩張表。惟一不一樣之處在於文章評論會存儲本身是那一篇文章下的評論，而子評論會存儲本身位於哪一條文章評論底下，並且會存儲回覆的Client是誰，因此還存儲了reply_client這個字段。

後端系統設計

點擊此處直到後端代碼倉庫：https://gitee.com/zouchanglin/comment-box

後端系統仍是基於SpringBoot搭建的後端服務，其實用的都是比較常見的技術，SpringMVC、SpringDataJPA等，平時用的比較少的就是郵件發送服務，其實使用spring-boot-starter-mail來發送郵件簡直不要太容易。須要注意的就是後端的跨域問題，須要配置一個容許跨域的配置類，可是後面部署的時候推薦使用Nginx同域部署，跨域問題也就不存在了，這是我目前最喜歡的方案。

項目部署問題

一、雲服務購買

仍是比較推薦騰訊雲88/年，百度雲太貴、阿里雲用過了。騰訊雲學生及仍是能夠買一買的，1核2G的配置，其實徹底夠用了。剛開始腦子抽搐了買個天翼雲，雖然才77元/年，可是難用的要死，並且最高速度也就130K/s，這誰受得了這麼慢的速度。仍是寧願多花幾塊錢買個好一點的呀，畢竟大廠靠譜。千萬別買天翼雲呀，千萬別買天翼雲呀，千萬別買天翼雲呀，重要的事情說三遍。

二、解決HTTPS問題

整個代碼其實都已經寫好了，就剩一個部署了，可是因爲個人網站全是HTTPS的，因此評論系統也必須是HTTPS的，不然因爲瀏覽器的安全策略會致使評論模塊沒法加載。因而乎經過域名解析了一個二級域名comment.zouchanglin.cn到服務器上，爲這個二級域名申請一個證書，這樣就徹底OK了。

三、Nginx部署

前端項目打包後直接使用Nginx部署一下，順便把HTTPS證書配置一下，這樣前端項目就能夠HTTPS訪問了，那麼後端呢？不可能有https://comment.zouchanglin.cn:8080這種URL存在吧，因此仍是經過Nginx很輕鬆的解決了這個問題，只要經過Nginx配置一個代理，100%搞定，並且完全、一勞永逸地解決了跨域問題，而且共享域名，還利用反向代理隱藏了後端地址，比較方便集中管理。

因此我我的仍是很是推薦採用Nginx將先後端同域部署的，Nginx真的幫了大忙！

後端項目application.yml配置以下，其實就是訪問路徑都變成了http://127.0.0.1:8080/api/....

server:
    port: 8080
    servlet:
        context-path: /api

前端項目記得關閉History模式，而後請求的基礎URL就寫成了：

axios.defaults.baseURL = 'https://comment.zouchanglin.cn/api/'

Nginx的配置文件以下：

user  root;
worker_processes  2;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    
    sendfile        on;
    keepalive_timeout  65;

    gzip  on;
    
    # HTTPS server
    server {
        listen       443 ssl;
        server_name  comment.zpuchanglin.cn;

        # 配置證書
        ssl_certificate      /opt/ssl_file/cn_chain.crt;
        ssl_certificate_key  /opt/ssl_file/cn_key.key;

        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        location / {           
            root /root/dist;
            try_files $uri $uri/ /index.html;
        }

        location ^~/api/ {
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

須要改進之處

集思廣益，你們也能夠評論留言...

• 支持後臺管理
• 支持自適應移動端(寬高度需調整)
• 支持Docker一鍵部署
• ……

原文地址：《手寫一個Hexo評論系統（二）》