建站
咨詢
售后
建站咨詢
新聞中心
有不少小伙伴希望松哥能整一個(gè)微服務(wù)的實(shí)戰(zhàn)項(xiàng)目，微服務(wù)這塊技術(shù)點(diǎn)其實(shí)松哥是講過很多了，圖文版的教程視頻版的教程都有，不過確實(shí)缺乏一個(gè)項(xiàng)目，所以我在想等 TienChin 項(xiàng)目搞完之后，和小伙伴們也來一起搞一個(gè)微服務(wù)的項(xiàng)目。
今天我想從架構(gòu)的角度來和小伙伴們聊一聊微服務(wù)。不聊具體的技術(shù)點(diǎn)，就單純來看看一個(gè)微服務(wù)項(xiàng)目該怎么設(shè)計(jì)。
1. 單體版 TienChin
松哥目前在錄的 TienChin 項(xiàng)目就是一個(gè)前后端分離的單體項(xiàng)目，采用了 Spring Boot + Vue3。那么單體版的 TienChin 具有什么樣的特征呢？我從優(yōu)點(diǎn)和缺點(diǎn)兩個(gè)方面來和大家分析。
先來看一張簡(jiǎn)單的架構(gòu)圖：
可以看到，雖然是單體項(xiàng)目，但是為了開發(fā)方便，項(xiàng)目也細(xì)分為許多不同的模塊，項(xiàng)目中的適配器可以分為兩大類：
入站適配器：就是外部系統(tǒng)來調(diào)用我們的系統(tǒng)，REST API 和 Vue 網(wǎng)頁都算是入站適配器，外部系統(tǒng)通過這兩個(gè)接口來調(diào)用我們的系統(tǒng)。
出站適配器：這個(gè)主要是我們系統(tǒng)內(nèi)部調(diào)用外部系統(tǒng)的方式，例如我們的項(xiàng)目中需要用到 MySQL、Redis等，那么就通過出站適配器來實(shí)現(xiàn)。
1.1 優(yōu)點(diǎn)
- 開發(fā)簡(jiǎn)單：隨便一個(gè) IDE，擼起袖子就可以開寫了。
- 測(cè)試簡(jiǎn)單：項(xiàng)目啟動(dòng)之后，直接利用 POSTMAN 等工具就可以測(cè)試項(xiàng)目接口了。
- 部署簡(jiǎn)單：項(xiàng)目開發(fā)完成之后，打包成一個(gè) jar 或者一個(gè) war，直接部署就行了。
- 橫向擴(kuò)展簡(jiǎn)單：當(dāng)項(xiàng)目并發(fā)能力不足的時(shí)候，可以方便的結(jié)合 Nginx 等負(fù)載均衡工具進(jìn)行橫向擴(kuò)展。
可以看到，單體項(xiàng)目的優(yōu)勢(shì)整體上來說還是非常明顯的。
1.2 缺點(diǎn)
然而缺點(diǎn)也是非常明顯的。
- 項(xiàng)目越來越復(fù)雜
首先就是項(xiàng)目不可能一直這么簡(jiǎn)單，我們這個(gè)項(xiàng)目中還是細(xì)分了很多不同的模塊。隨著時(shí)間的推移，這些模塊會(huì)變得越來愈復(fù)雜。修改每一個(gè) BUG 都要小心翼翼，牽一發(fā)而動(dòng)全身。并且隨著項(xiàng)目組中人員的離職/入職，新接手的人會(huì)讓這個(gè)項(xiàng)目更加復(fù)雜，每一次 BUG 的修復(fù)或者新功能的添加，都會(huì)讓這個(gè)項(xiàng)目變得更加“不可捉摸”。
- 開發(fā)進(jìn)度越來越不可控
由于系統(tǒng)越來越復(fù)雜，我們不得不增派人手參與到這個(gè)項(xiàng)目的開發(fā)中，以期推進(jìn)項(xiàng)目進(jìn)度。這么多人的協(xié)調(diào)又是一個(gè)問題。并且，隨著項(xiàng)目越來越大，每一次編譯運(yùn)行都得數(shù)分鐘、十幾分鐘甚至更久，這也會(huì)嚴(yán)重拖慢我們的項(xiàng)目進(jìn)度。
- 發(fā)版周期過長(zhǎng)
單體項(xiàng)目發(fā)版很多小伙伴可能都刻骨銘心，發(fā)版當(dāng)天如臨大敵，所有人都加班，等項(xiàng)目上線運(yùn)行都沒問題，各項(xiàng)數(shù)據(jù)都 OK，此時(shí)可能已經(jīng)凌晨三四點(diǎn)了，所有人拖著疲憊的身體下班。正是由于每一次發(fā)版都是一個(gè)大事，所以一般單體項(xiàng)目不太會(huì)頻繁發(fā)版（我說的頻繁是指如一天一版這種），發(fā)版周期普遍比較長(zhǎng)。
- 難以擴(kuò)展
當(dāng)系統(tǒng)不同模塊對(duì)資源的需求不同的時(shí)候，我們想做針對(duì)性的硬件擴(kuò)展也并不方便。
舉個(gè)簡(jiǎn)單例子，有一個(gè)模塊需要進(jìn)行大量的運(yùn)算，我們希望能為之提供更好的 CPU；有一個(gè)模塊需要更大的內(nèi)存，我們需要擴(kuò)展更大的內(nèi)存。
然而由于所有的模塊都打包在一起，我們只能針對(duì)當(dāng)前服務(wù)器做各種硬件升級(jí)，無法針對(duì)某一個(gè)模塊做專門的硬件升級(jí)。
- 過期的技術(shù)棧不易更新
我相信很多小伙伴見到的單體項(xiàng)目還有一個(gè)特點(diǎn)就是技術(shù)棧普遍比較老舊。這也是因?yàn)閱误w項(xiàng)目時(shí)間久了之后，積重難返，想要對(duì)基礎(chǔ)框架做版本升級(jí)往往牽一發(fā)而動(dòng)全身，更別提從傳統(tǒng)的 SSM 切換到 Spring Boot 上這種超級(jí)繁瑣的工作了。因此大部分的單體項(xiàng)目，在立項(xiàng)的那一刻選用了什么技術(shù)棧、選用了技術(shù)的哪個(gè)版本，基本上這個(gè)項(xiàng)目未來都是這個(gè)版本了。
從上面的介紹中小伙伴們可以看到，單體項(xiàng)目?jī)?yōu)點(diǎn)很明顯，然而缺點(diǎn)也是非常明顯的。而這些缺點(diǎn)，都可以通過微服務(wù)來解決。
2. 微服務(wù)版 TienChin
如果 TienChin 項(xiàng)目是微服務(wù)版呢？我們來看一張簡(jiǎn)單的架構(gòu)圖。
簡(jiǎn)單畫了張圖，我來解釋下：
- 首先我們基本上是按照業(yè)務(wù)來劃分服務(wù)的。每一個(gè)服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫，自己操作自己的庫。
- 假設(shè)在線索管理中，需要調(diào)用商機(jī)管理，那不能直接操作商機(jī)的數(shù)據(jù)庫，必須去調(diào)用商機(jī)管理服務(wù)中提供的 REST API，通過這個(gè) REST API 來操作庫。
- 所有的服務(wù)有一個(gè)統(tǒng)一的入口 Gateway，如果前端是手機(jī) App 或者小程序之類的，通過 Gateway 來訪問到系統(tǒng)。
- 有一個(gè)后臺(tái)管理的 Web UI 項(xiàng)目，提供相應(yīng)的網(wǎng)頁操作。
大致上就是這個(gè)樣子。
那么這個(gè)微服務(wù)版的 TienChin 跟前面的單體版 TienChin 相比優(yōu)勢(shì)體現(xiàn)在哪里呢？
- 容易維護(hù)
首先第一點(diǎn)就是，項(xiàng)目拆分為微服務(wù)之后，每個(gè)服務(wù)相對(duì)來說都比較小，項(xiàng)目的維護(hù)相對(duì)來說也會(huì)比較容易。一個(gè)比較小的項(xiàng)目，在 IDE 中啟動(dòng)也會(huì)比較快?？梢杂幸粋€(gè)很小的團(tuán)隊(duì)來負(fù)責(zé)項(xiàng)目的維護(hù)。
- 服務(wù)可以自由擴(kuò)展
以上圖為例，如果某日搞促銷活動(dòng)，線索管理這個(gè)服務(wù)的并發(fā)量比較大，我們可以非常方便的為線索管理模塊做橫向擴(kuò)展，如下圖這樣：
任何一個(gè)服務(wù)，如果有需求，都可以非常方便的進(jìn)行擴(kuò)展，并且可以根據(jù)服務(wù)的特點(diǎn)來選擇合適的硬件，例如這個(gè)服務(wù)耗內(nèi)存，那就加大內(nèi)存；另一個(gè)服務(wù)耗 CPU，那就選擇一個(gè)性能到位的 CPU 等等。
- 解耦后更強(qiáng)的容錯(cuò)性
通過服務(wù)降級(jí)、熔斷等微服務(wù)組件的使用，我們可以實(shí)現(xiàn)各個(gè)微服務(wù)具備更強(qiáng)的容錯(cuò)性。一個(gè)服務(wù)出故障，并不會(huì)影響其他的服務(wù)。例如合同管理里邊發(fā)生了內(nèi)存泄漏，這個(gè)并不會(huì)影響到商機(jī)管理服務(wù)。
- 更容易采用新技術(shù)
之前我們?cè)谡劦絾误w項(xiàng)目的弊端的時(shí)候，提到了單體項(xiàng)目的技術(shù)棧更新非常不易?，F(xiàn)在我們切換成微服務(wù)了，新技術(shù)棧的切換其實(shí)就變得非常容易了。每一個(gè)微服務(wù)都可以根據(jù)當(dāng)前項(xiàng)目的情況，選擇是否采用最新的技術(shù)棧，而且一個(gè)微服務(wù)在切換最新技術(shù)棧的過程中，如果不幸發(fā)生了問題了，也不會(huì)影響到其他的微服務(wù)，只會(huì)影響到當(dāng)前的服務(wù)。由于各個(gè)微服務(wù)之間基本上都是通過 REST API 進(jìn)行交互的，所以，退一萬步，你甚至可以使用不同的開發(fā)語言來開發(fā)不同的微服務(wù)。
- 更友好的 CI/CD
CI/CD 是 DevOps 的一部分，但是在前面的單體項(xiàng)目中，當(dāng)項(xiàng)目比較大的時(shí)候，想做到持續(xù)交付/持續(xù)部署已經(jīng)越來越難了，而微服務(wù)讓一個(gè)超大規(guī)模的項(xiàng)目可以非常方便的實(shí)現(xiàn) CI/CD。
現(xiàn)在，我們的每一個(gè)服務(wù)都有自己獨(dú)立的團(tuán)隊(duì)、獨(dú)立的代碼倉庫、獨(dú)立的自動(dòng)化部署流水線，且互不相擾，如下圖這樣：
現(xiàn)在，每一個(gè)服務(wù)都可以獨(dú)立的實(shí)現(xiàn)服務(wù)的上線和部署，結(jié)合 DevOps 可以做到非常輕松的發(fā)版，不需要再像以前單體應(yīng)用發(fā)版的時(shí)候，如臨大敵一樣。
這樣劃分之后，工程師也可以將自己的精力放在業(yè)務(wù)開發(fā)商，提供更多有價(jià)值的功能，而不是像一個(gè)救火隊(duì)員一樣，每天忙著四處滅火。
好啦，通過這樣一篇簡(jiǎn)單的文章和圖片，希望大家對(duì)微服務(wù)有一個(gè)基本的認(rèn)知，當(dāng)然，微服務(wù)也不是“銀彈”，微服務(wù)架構(gòu)也存在問題，這個(gè)咱們后面有空了松哥再繼續(xù)和小伙伴們分享。
文章標(biāo)題：?jiǎn)误w的TienChin和微服務(wù)的TienChin有何異同？
網(wǎng)頁路徑：http://www.dlmjj.cn/article/dppcihh.html
