共计 3483 个字符，预计需要花费 9 分钟才能阅读完成。
接着上一篇文章《手写一个 Hexo 评论零碎（一）》，本篇文章次要是讲述记述评论零碎实现的一些具体的设计方案与技术细节，不便当前批改或者重构。还有我的项目的部署问题，包含域名解析，Nginx 配置代理，云服务器选购的一些问题，选购服务器的坑是真的大，所以还是尽量抉择大厂，稳固一点，好用一点就不必在乎多几那块钱嘛，而且依据本人的须要买配置还是比拟划算的。
<!– more –>
上次总共列出了如下的一些需要，依据这些需要来构想一下如何设计：
1、无需登录和验证码，间接评论即可
2、反对回复评论，且可有限递归回复
3、反对评论点赞，依照点赞排序，雷同则依照工夫排序
3、反对文章评分，显示评分人数和评分的均匀分数
4、反对本人的评论被他人回复后能够邮件告诉
5、反对评论后盾管理系统，能够设置对应属性
6、反对评论导出，且高度 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 同域部署，跨域问题也就不存在了，这是我目前最喜爱的计划。
我的项目部署问题
1、云服务购买
还是比拟举荐腾讯云 88/ 年，百度云太贵、阿里云用过了。腾讯云学生及还是能够买一买的，1 核 2G 的配置，其实齐全够用了。刚开始脑子抽搐了买个天翼云，尽管才 77 元 / 年，然而难用的要死，而且最高速度也就 130K/s，这谁受得了这么慢的速度。还是宁愿多花几块钱买个好一点的呀，毕竟大厂靠谱。千万别买天翼云呀，千万别买天翼云呀，千万别买天翼云呀，重要的事件说三遍。
2、解决 HTTPS 问题
整个代码其实都曾经写好了，就剩一个部署了，然而因为我的网站全是 HTTPS 的，所以评论零碎也必须是 HTTPS 的，否则因为浏览器的安全策略会导致评论模块无奈加载。于是乎通过域名解析了一个二级域名 comment.zouchanglin.cn 到服务器上，为这个二级域名申请一个证书，这样就齐全 OK 了。
3、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 评论零碎（二）》