博客網(wǎng)站需求設計與方案設計
1 背景與規(guī)劃
很早就想通過寫博客，對自己的技術(shù)進行反思與沉淀，但是由于拖延癥晚期，一直沒有實際執(zhí)行，而且市面上的各種博客系統(tǒng)創(chuàng)建的博客頁面總是有很多第三方的元素，顯得頁面很繁瑣，我個人是很討厭這些多余的東西，所以就有了自己搭一個博客的念頭。
最初是2016年的時候打算用wordpress來搭建，因為整體框架已經(jīng)成熟，api也很完善。但是用起來需要對這些api很熟悉才能靈活的定制博客，否則就會束手束腳，而且當時編程能力還比較差，對前端代碼幾乎一無所知，寫起來十分困難，加上剛換了工作，就沒有更深入的去了解。這兩年以來用業(yè)余時間斷斷續(xù)續(xù)學習了一些前端技術(shù)，而且實際工作中對系統(tǒng)架構(gòu)設計的理解也有了比較大的成長，所以就萌生了從零搭建一個純凈博客系統(tǒng)的念頭，
用最簡單粗暴的代碼實現(xiàn)功能。
支持文章的發(fā)布、修改與查看（離線發(fā)布）。
可以增加刪除文章分類（分類分為主分類和副分類，比如主分類：技術(shù)，下屬有PHP、MySQL、Linux等副分類）。
PC瀏覽美觀，暫不考慮移動端的兼容。
Google、百度等搜索引擎可搜到
兼容移動端，考慮使用bootstrap的響應式布局。
線上線下配置分離
對代碼進行模塊化的封裝：1. 后端代碼抽象出路由模塊、數(shù)據(jù)庫模塊、網(wǎng)絡請求模塊、http響應模塊。2. 前端代碼抽象出網(wǎng)絡請求模塊。
支持評論、訂閱功能
支持線上發(fā)布、修改文章（權(quán)限控制）
多機部署
將文章合成自動生成的js代碼，實現(xiàn)簡單的防爬機制
2 技術(shù)選型
最終選用的技術(shù)棧如下：
前端：Vue
后端：Golang（gin框架） + MySQL + Nginx + Linux
前端：
其實一年前我對前端技術(shù)還是一無所知，大概2017年5月份左右，有了一個想做教育APP的想法，直到17年12月左右工作的壓力才逐漸小了一些，每天大概有兩小時左右的業(yè)余時間可以搞一些小玩意。
當時考慮到做APP的話，無論Andriod還是iOS如果想做原生APP，學習成本太高，而且要做兩套APP，就選了學習成本最低的微信小程序。小程序一旦寫好，甚至不需要安裝就可以獲得媲美原生APP的功能，還有微信的流量，實在是方便。小程序使用的語言又恰好和html、js、css很像，于是這才漸漸有了一些了解。
回到這次開發(fā)博客的技術(shù)棧，在經(jīng)過同學還有同事的安利后，前端框架決定使用Vue，輕量級框架，學習成本較低。
后端服務開發(fā)語言：
后端服務的話，由于我本身是做了三年的PHP開發(fā)，使用PHP開發(fā)博客的話，幾乎沒有什么新的技術(shù)難題，更不用說成長了。PHP屬于動態(tài)腳本語言，所以打算使用一種之前沒用過的靜態(tài)編譯型語言。
近些年來，Golang作為一門新興語言，實在是勁頭火熱，各大公司的許多項目也在向Golang逐漸轉(zhuǎn)型，所以我選擇Golang作為后端開發(fā)語言，雖然可能暫時用不到channel和協(xié)程這些語言特性，但也可以為學習新語言打開一扇大門了。
本來Golang是可以不用框架，直接裸寫服務，不過之前面試羅輯思維的時候，了解過他們框架用的gin，網(wǎng)上查了查發(fā)現(xiàn)這屬于一個輕量級框架，似乎評價還可以，所以就打算拿來用用，正好在博客的第二版可以對框架進行一些二次開發(fā)，增加一些技術(shù)難題和工作量。
反向代理服務器：
Golang的服務器前面我是打算再搭一個Nginx，1是為了后續(xù)流量上升后的負載均衡做準備，2是因為js、css等靜態(tài)資源肯定需要一個web服務器提供服務。反正CDN暫時是不考慮了orz
數(shù)據(jù)庫：
數(shù)據(jù)庫選擇使用MySQL，畢竟MySQL可以說是當前業(yè)界最流行的關系型數(shù)據(jù)庫。
MongoDB這種數(shù)據(jù)庫說實話我還沒用過，從網(wǎng)上的資料看起來的應用場景似乎也不太匹配，這次就不用了，等后續(xù)有時間再看看吧。
Redis暫時也就不用了，一開始似乎也不需要用到這種設備，用了反而增加系統(tǒng)復雜度。
操作系統(tǒng)：
服務器的操作系統(tǒng)不多嗶嗶，就是Linux，其他也不廢話了。
3 數(shù)據(jù)庫設計
第一版主要實現(xiàn)以下幾個功能：方便的增加、修改；瀏覽數(shù)計數(shù)；記錄創(chuàng)建、修改時間；記錄文章分類。
建表語句如下：
CREATE TABLE `article_detail` (
`id`
bigint(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵自增ID',
`uuid` varchar(32) NOT NULL DEFAULT '' COMMENT
'文章ID',
`content` text COMMENT '文章內(nèi)容',
`browser_count` bigint(11) NOT NULL DEFAULT
'0' COMMENT '瀏覽數(shù)',
`create_time` timestamp NOT NULL DEFAULT
'0000-00-00 00:00:00' COMMENT '創(chuàng)建時間',
`main_category_uuid` varchar(32) NOT NULL
DEFAULT '' COMMENT '主類別ID',
`sub_category_uuid` varchar(32) NOT NULL
DEFAULT '' COMMENT '副類別ID',
`title` varchar(255) NOT NULL DEFAULT ''
COMMENT '文章標題',
`update_time` timestamp NOT NULL DEFAULT
CURRENT_TIMESTAMP COMMENT '更新時間',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_uuid` (`uuid`),
KEY
`idx_main_category_uuid` (`main_category_uuid`),
KEY
`idx_sub_category_uuid` (`sub_category_uuid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
表結(jié)構(gòu)就不多說了，加了三個索引，uuid是每個文章的唯一標記，主、副類別ID的索引是為了在篩選文章列表的時候加快查詢速度用的。加索引在數(shù)據(jù)量夠大時，可以增加查詢速度，具體原理以后會寫文章講解。
主副類別表；
建表語句如下：
CREATE TABLE `main_category` (
`id`
bigint(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵自增ID',
`uuid` varchar(32) NOT NULL DEFAULT '' COMMENT
'主類別ID',
`title` varchar(255) NOT NULL DEFAULT ''
COMMENT '類別名稱',
`create_time` timestamp NOT NULL DEFAULT
'0000-00-00 00:00:00' COMMENT '創(chuàng)建時間',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_uuid` (`uuid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `sub_category` (
`id`
bigint(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵自增ID',
`uuid` varchar(32) NOT NULL DEFAULT '' COMMENT
'副類別ID',
`title` varchar(255) NOT NULL DEFAULT ''
COMMENT '類別名稱',
`create_time` timestamp NOT NULL DEFAULT
'0000-00-00 00:00:00' COMMENT '創(chuàng)建時間',
`main_uuid` varchar(32) NOT NULL DEFAULT ''
COMMENT '對應的主類別ID',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_uuid` (`uuid`),
KEY
`idx_main_uuid` (`main_uuid`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT
CHARSET=utf8
??其實這么建表我是有點糾結(jié)的，很多地方，為了父子節(jié)點的拓展方便，可能會只建一張表，然后表內(nèi)有一個父節(jié)點ID的字段，就可以實現(xiàn)無限多級的父子關系，不過我覺著這里沒必要有無限多級的父子關系，而且建兩張表的話，父子關系會更清晰。
文章內(nèi)容來源于網(wǎng)絡，侵刪
