【內(nèi)附源碼和文檔】基于Vue+SpringCloud博客的設(shè)計(jì)與實(shí)現(xiàn)

一、摘 要

博客是用來(lái)分享自己的心情和動(dòng)態(tài)拉近人與人之間的距離，它改變了人們的在網(wǎng)上的交流方式，也增強(qiáng)了互聯(lián)網(wǎng)的趣味性。 “微服務(wù)”是最近兩年開(kāi)始流行起來(lái)，但是其實(shí)早在20年前都有專(zhuān)家提出過(guò)，只不過(guò)當(dāng)時(shí)的用戶(hù)量并不像現(xiàn)在那么高。例如：一個(gè)系統(tǒng)的功能越豐富就會(huì)導(dǎo)致技術(shù)債務(wù)越多，但是基于單體應(yīng)用(一個(gè)war包)開(kāi)發(fā)的代碼庫(kù)越來(lái)越臃腫，可維護(hù)性差，代碼“不壞不修”。為此，引入“微服務(wù)”架構(gòu)的方式可以改善這個(gè)狀況，每個(gè)微服務(wù)中心均在獨(dú)立的進(jìn)程中負(fù)責(zé)每種功能的業(yè)務(wù)，由一系列獨(dú)立運(yùn)行的微服務(wù)中心共同構(gòu)建整個(gè)系統(tǒng)?，F(xiàn)在web的前后端分離是企業(yè)的一種趨勢(shì)，前后端分離同樣也是技術(shù)創(chuàng)新的一種體現(xiàn)。得益于開(kāi)發(fā)分離的趨勢(shì)，Vue與SpringCloud的組合方式在如今的Web網(wǎng)站開(kāi)發(fā)中占據(jù)重要的位置。

關(guān)鍵字: 微服務(wù),Vue,SpringCloud.

二、博客的相關(guān)理論與技術(shù)

4.1 博客系統(tǒng)理論分析
本次設(shè)計(jì)使用的是JavaWeb開(kāi)發(fā)中主流的微服務(wù)架構(gòu)方式，微服務(wù)一定會(huì)涉及分布式，一般提到微服務(wù)大多在系統(tǒng)邏輯與物理結(jié)構(gòu)設(shè)計(jì)上，而分布式則涉及到的都是一些機(jī)器或者實(shí)現(xiàn)技術(shù)，閱讀本章可以理解整個(gè)博客用到的理論及其技術(shù)。

4.1.1 博客的微服務(wù)分析
目前來(lái)說(shuō)，微服務(wù)(SpringCloud)是軟件開(kāi)發(fā)中的一個(gè)主流的熱門(mén)技術(shù)，而SpringCloud只是微服務(wù)的一個(gè)重要子集。微服務(wù)的概念可以這樣被定義：微服務(wù)之間通過(guò)HTTP等一些輕量通信進(jìn)行交互數(shù)據(jù)，而每一個(gè)微服務(wù)都存在自己的進(jìn)程中，獨(dú)立承擔(dān)著某些業(yè)務(wù)功能，最終所有微服務(wù)聚合共同架起整個(gè)系統(tǒng)。

設(shè)計(jì)一個(gè)微服務(wù)系統(tǒng)需要遵守以下原則：

微服務(wù)的單一原則：一般指的是一個(gè)類(lèi)中只負(fù)責(zé)一個(gè)完整的功能，與其相關(guān)性不大的功能最好不要放進(jìn)去，對(duì)以后的功能擴(kuò)展不太友好。

微服務(wù)的隔離原則：指每一個(gè)微服務(wù)中心的功能代碼塊獨(dú)立地運(yùn)行在一個(gè)模塊包中，多個(gè)微服務(wù)則有多個(gè)模塊包，它們一起獨(dú)立運(yùn)行，并且不會(huì)發(fā)生互相干擾，從微服務(wù)的邏輯設(shè)計(jì)到開(kāi)發(fā)設(shè)計(jì)都是獨(dú)立在一個(gè)包中。

微服務(wù)的通信原則：當(dāng)多個(gè)微服務(wù)發(fā)生數(shù)據(jù)交互時(shí)，它們之間應(yīng)該使用輕量的通信服務(wù)來(lái)進(jìn)行交互，輕量通信需要具備跨語(yǔ)言，跨平臺(tái)的特點(diǎn)。

微服務(wù)的控制原則：每一個(gè)微服務(wù)都需要把控服務(wù)的代碼量，在設(shè)計(jì)邏輯結(jié)構(gòu)時(shí)要考慮周當(dāng)，并不是一味地把代碼量減少，使微服務(wù)變小容易控制。因?yàn)槊總€(gè)微服務(wù)的功能特性不同，所要要編寫(xiě)的代碼量也不同。因此在邏輯結(jié)構(gòu)設(shè)計(jì)時(shí)，就需要應(yīng)該確定業(yè)務(wù)的邊界，保持相對(duì)獨(dú)立且松耦的關(guān)系。

微服務(wù)修復(fù)原則：微服務(wù)最好編寫(xiě)完整且穩(wěn)定的高可用組件，除了微服務(wù)組件的高可用，還需要考慮“熔斷”微服務(wù)的業(yè)務(wù)來(lái)保護(hù)系統(tǒng)。

4.1.2 博客的分布式分析
博客系統(tǒng)除了會(huì)涉及到微服務(wù)，還會(huì)涉及到分布式，分布式系統(tǒng)的定義大多從程序來(lái)看的，可以是相同的程序，例如“集群”方式。也可以不是相同的程序，通過(guò)遠(yuǎn)程調(diào)用來(lái)完成交互，分布式可以認(rèn)為是一種對(duì)機(jī)器的有效管理方式。

關(guān)于分布式需要了解五個(gè)重要的特性：

內(nèi)聚和透明性：分布式系統(tǒng)是利用計(jì)算機(jī)網(wǎng)絡(luò)構(gòu)建的協(xié)作系統(tǒng)，所以分布式系統(tǒng)通常都具備內(nèi)聚性與透明性的特性。

獨(dú)立擴(kuò)展性：其一是垂直擴(kuò)展即優(yōu)化服務(wù)器的性能或者升級(jí)服務(wù)器硬件；其二，增加服務(wù)器水平擴(kuò)展，即增加服務(wù)器的數(shù)量。

可靠性與可用性：可靠性是在指定的時(shí)間內(nèi)，系統(tǒng)無(wú)錯(cuò)誤和障礙的平均運(yùn)行時(shí)間，可用性則是某個(gè)時(shí)間段內(nèi)無(wú)錯(cuò)誤和障礙的總運(yùn)行時(shí)間。

高性能：對(duì)于高并發(fā)的平均處理時(shí)間越少越好，單位時(shí)間內(nèi)處理的人物越多越好，利用更多的機(jī)器來(lái)實(shí)現(xiàn)更高的計(jì)算與存儲(chǔ)能力。

致性：多節(jié)點(diǎn)部署下，保證計(jì)算與存儲(chǔ)的數(shù)據(jù)只有一份。

由于分布式與微服務(wù)涉及到的面會(huì)有一些相似，但是兩者的核心本質(zhì)是不一樣的，在此需要詳細(xì)說(shuō)明一下微服務(wù)與分布式兩者的具體區(qū)別：

微服務(wù)是架構(gòu)設(shè)計(jì)方式，例如：博客的邏輯設(shè)計(jì)需要涉及到某些功能，功能要怎么劃分，需要考慮到“高并發(fā)”的問(wèn)題，最終系統(tǒng)該如何拆分，功能如何劃分比較合理，再為以后的系統(tǒng)擴(kuò)展打下基礎(chǔ)，而分布式是系統(tǒng)部署方式，系統(tǒng)拆分后，把功能放到某個(gè)機(jī)器上，若是采用了微服務(wù)的架構(gòu)方式，利用的是分布式部署。若不是微服務(wù)架構(gòu)方式則可以采用“集群部署”或者分布式部署，“集群部署”相當(dāng)于同一個(gè)業(yè)務(wù)，部署在多個(gè)服務(wù)器上。

不管微服務(wù)還是分布式都有兩個(gè)共同的缺點(diǎn)，第一個(gè)就是網(wǎng)絡(luò)的的問(wèn)題，例如：網(wǎng)路延遲，丟包和信息丟失，所以需要編寫(xiě)補(bǔ)償機(jī)制來(lái)保護(hù)用戶(hù)的體驗(yàn)。第二個(gè)就是節(jié)點(diǎn)故障，微服務(wù)節(jié)點(diǎn)故障或者分布式系統(tǒng)的某個(gè)節(jié)點(diǎn)故障，節(jié)點(diǎn)故障不一定可以完全避免，但是可以人為的操作干預(yù)，相比第一個(gè)缺點(diǎn)產(chǎn)生的網(wǎng)絡(luò)通信還是有可操作性，但是動(dòng)手起來(lái)有不小的挑戰(zhàn)難度，需要仔細(xì)打磨每一個(gè)細(xì)節(jié)。

4.1.3 關(guān)于分布式鎖分析
關(guān)于分布式鎖的詳解可以自行查找了解，在此只介紹分布式鎖的概念和博客采用的分布式鎖。簡(jiǎn)而言之，對(duì)Java分布式鎖來(lái)說(shuō)，對(duì)于不同的機(jī)器產(chǎn)生的不同JVM虛擬機(jī)之間需要資源共享，這個(gè)時(shí)候就需要用到分布式鎖來(lái)進(jìn)行控制。

如果程序中使用了Synchronized關(guān)鍵字，Lock并發(fā)接口，并發(fā)工具類(lèi)或并發(fā)集合，這些操作也可以完成多線程的“共享資源”，但這只是單體應(yīng)用的服務(wù)實(shí)例，對(duì)于分布式系統(tǒng)來(lái)說(shuō)，獨(dú)立的JDK和主機(jī)Host，兩者區(qū)別就是在于單體并發(fā)控制到分布式跨JVM之間的差別，分布式鎖也是基于跨JVM來(lái)進(jìn)行“共享資源”的控制。

對(duì)于分布式鎖有五點(diǎn)要求：

排他性：一個(gè)資源只允許在一個(gè)時(shí)間段被一個(gè)JVM上的一個(gè)線程執(zhí)行。

避免死鎖：需要人為釋放鎖，可以設(shè)置鎖的失效時(shí)間。

公平鎖：不同機(jī)器爭(zhēng)奪資源時(shí)的幾率是一樣的，但不是必要的。

高可用鎖：獲取與釋放鎖的機(jī)制需要保證性能符合設(shè)計(jì)。

可重入鎖：設(shè)置鎖的可重入次數(shù)或者時(shí)間，若是發(fā)生獲取失敗，則可以等待一個(gè)時(shí)間段或者設(shè)置一個(gè)時(shí)間段獲取鎖的次數(shù)。

博客使用了基于Redis實(shí)現(xiàn)的分布式鎖（關(guān)于Redis的分析可看標(biāo)題2-7，在此只提一下Redis的分布式鎖的要點(diǎn)），Redis提供了原子操作SETNX與EXPIRE，SETNX表示當(dāng)key在Redis中不存在時(shí)才能設(shè)置成功，key間接當(dāng)作“鎖”，并用EXPIRE來(lái)釋放獲取的鎖，Redisson可以看作內(nèi)置了這些特性，封裝好給我們使用。

由上可知，重要的操作就是SETNX，關(guān)于SETNX的操作有三個(gè)要點(diǎn)：

使用SETNX操作獲取鎖，如果返回0則說(shuō)明已經(jīng)存在且被其它線程獲取，出現(xiàn)了1則說(shuō)明獲取成功。

需要為鎖設(shè)置合理的失效時(shí)間，若是發(fā)生了程序異常，鎖不釋放就會(huì)導(dǎo)致死鎖，時(shí)間需要合理且符合程序的流程。

與多線程操作的理念相似，執(zhí)行完鎖后需要釋放獲取到的鎖。

4.1.4 博客的高可用分析
高可用是微服務(wù)架構(gòu)中一個(gè)重要的設(shè)計(jì)元素，一般指的是系統(tǒng)減少微服務(wù)不能提供的時(shí)間。博客的高可用的需要做到服務(wù)自治，當(dāng)一個(gè)微服務(wù)出現(xiàn)無(wú)法響應(yīng)，而另一個(gè)微服務(wù)就可以替代它，所以在設(shè)計(jì)博客高可用系統(tǒng)時(shí)，需要從許多方面去考慮，遠(yuǎn)不止一個(gè)高可用，最重要的就是自我修復(fù)避免系統(tǒng)的無(wú)法響應(yīng)。

博客中一共涉及到Eureka，Zuul的高可用，后續(xù)標(biāo)題中會(huì)提到，在此不做介紹，高可用的分布式系統(tǒng)需要遵守微服務(wù)的開(kāi)發(fā)準(zhǔn)則，也需要遵守以下微服務(wù)運(yùn)行機(jī)制(括號(hào)中是博客使用到的技術(shù)，會(huì)在后續(xù)的標(biāo)題中一一詳細(xì)介紹，在此作為理解)：

擴(kuò)展機(jī)制：水平與垂直擴(kuò)展，與分布式的擴(kuò)展相似

隔離機(jī)制：避免博客的一個(gè)業(yè)務(wù)占用太多資源導(dǎo)致服務(wù)的無(wú)法響應(yīng)，會(huì)對(duì)其他博客業(yè)務(wù)造成影響，添加容錯(cuò)機(jī)制即可。

解耦原則：盡可能地使用合成復(fù)用原則來(lái)代替繼承關(guān)系。

限流機(jī)制(Zuul)：限流可以在路由網(wǎng)關(guān)上面體現(xiàn)出來(lái)，根據(jù)不同的算法可以實(shí)現(xiàn)不同的負(fù)載均衡。

降級(jí)機(jī)制：在核心業(yè)務(wù)運(yùn)行時(shí)，犧牲一部分非核心的業(yè)務(wù)保證核心業(yè)務(wù)功能

穩(wěn)定運(yùn)行，當(dāng)系統(tǒng)不可用時(shí)，需要給予用戶(hù)一些提示。

熔斷機(jī)制(Hystrix)：在調(diào)用微服務(wù)請(qǐng)求時(shí)，添加回退保護(hù)即可。

跟蹤機(jī)制(Zipkin)：博客API會(huì)產(chǎn)生數(shù)據(jù)指標(biāo)，產(chǎn)生的數(shù)據(jù)需要用來(lái)觀測(cè)，然后再做數(shù)據(jù)分析，對(duì)系統(tǒng)做個(gè)深度分析以便以后的功能擴(kuò)充。

維護(hù)機(jī)制：博客的系統(tǒng)維護(hù)比較需要方便，壓力與微服務(wù)的數(shù)量成正比。

補(bǔ)償機(jī)制：如果發(fā)生網(wǎng)絡(luò)問(wèn)題導(dǎo)致博客業(yè)務(wù)數(shù)據(jù)不一致性的問(wèn)題，需要補(bǔ)償機(jī)制彌補(bǔ)用戶(hù)。例如：RabbitMQ異步消息，補(bǔ)償表和定時(shí)任務(wù)檢測(cè)。

監(jiān)控機(jī)制(Hystrix+Turbine)：更多的是通過(guò)Hystrix監(jiān)控各個(gè)微服務(wù)的運(yùn)行指標(biāo)，通過(guò)HTTP轉(zhuǎn)遞給開(kāi)發(fā)者觀看。

演練機(jī)制：算是一種未雨綢繆，在測(cè)試博客功能時(shí)，適當(dāng)關(guān)閉個(gè)微服務(wù)中心，把博客的異?；蛘哐a(bǔ)償都要測(cè)試一下，防止在真實(shí)情況下出現(xiàn)業(yè)務(wù)炸裂情況，盡可能的在某個(gè)機(jī)器或某個(gè)微服務(wù)掛掉時(shí)，盡量不影響博客系統(tǒng)整體的高可用性。

完整的源碼和詳細(xì)的文檔，上傳到了 【W(wǎng)RITE-BUG數(shù)字空間】，需要的請(qǐng)自?。?/strong>