有不少小伙伴希望松哥能整一個微服務(wù)的實(shí)戰(zhàn)項(xiàng)目，微服務(wù)這塊技術(shù)點(diǎn)其實(shí)松哥是講過很多了，圖文版的教程視頻版的教程都有，不過確實(shí)缺乏一個項(xiàng)目，所以我在想等 TienChin 項(xiàng)目搞完之后，和小伙伴們也來一起搞一個微服務(wù)的項(xiàng)目。

今天我想從架構(gòu)的角度來和小伙伴們聊一聊微服務(wù)。不聊具體的技術(shù)點(diǎn)，就單純來看看一個微服務(wù)項(xiàng)目該怎么設(shè)計(jì)。

1. 單體版 TienChin

松哥目前在錄的 TienChin 項(xiàng)目就是一個前后端分離的單體項(xiàng)目，采用了 Spring Boot + Vue3。那么單體版的 TienChin 具有什么樣的特征呢？我從優(yōu)點(diǎn)和缺點(diǎn)兩個方面來和大家分析。

先來看一張簡單的架構(gòu)圖：

可以看到，雖然是單體項(xiàng)目，但是為了開發(fā)方便，項(xiàng)目也細(xì)分為許多不同的模塊，項(xiàng)目中的適配器可以分為兩大類：

入站適配器：就是外部系統(tǒng)來調(diào)用我們的系統(tǒng)，REST API 和 Vue 網(wǎng)頁都算是入站適配器，外部系統(tǒng)通過這兩個接口來調(diào)用我們的系統(tǒng)。

出站適配器：這個主要是我們系統(tǒng)內(nèi)部調(diào)用外部系統(tǒng)的方式，例如我們的項(xiàng)目中需要用到 MySQL、Redis等，那么就通過出站適配器來實(shí)現(xiàn)。

1.1 優(yōu)點(diǎn)

• 開發(fā)簡單：隨便一個 IDE，擼起袖子就可以開寫了。
• 測試簡單：項(xiàng)目啟動之后，直接利用 POSTMAN 等工具就可以測試項(xiàng)目接口了。
• 部署簡單：項(xiàng)目開發(fā)完成之后，打包成一個 jar 或者一個 war，直接部署就行了。
• 橫向擴(kuò)展簡單：當(dāng)項(xiàng)目并發(fā)能力不足的時候，可以方便的結(jié)合 Nginx 等負(fù)載均衡工具進(jìn)行橫向擴(kuò)展。

可以看到，單體項(xiàng)目的優(yōu)勢整體上來說還是非常明顯的。

1.2 缺點(diǎn)

然而缺點(diǎn)也是非常明顯的。

• 項(xiàng)目越來越復(fù)雜

首先就是項(xiàng)目不可能一直這么簡單，我們這個項(xiàng)目中還是細(xì)分了很多不同的模塊。隨著時間的推移，這些模塊會變得越來愈復(fù)雜。修改每一個 BUG 都要小心翼翼，牽一發(fā)而動全身。并且隨著項(xiàng)目組中人員的離職/入職，新接手的人會讓這個項(xiàng)目更加復(fù)雜，每一次 BUG 的修復(fù)或者新功能的添加，都會讓這個項(xiàng)目變得更加“不可捉摸”。

• 開發(fā)進(jìn)度越來越不可控

由于系統(tǒng)越來越復(fù)雜，我們不得不增派人手參與到這個項(xiàng)目的開發(fā)中，以期推進(jìn)項(xiàng)目進(jìn)度。這么多人的協(xié)調(diào)又是一個問題。并且，隨著項(xiàng)目越來越大，每一次編譯運(yùn)行都得數(shù)分鐘、十幾分鐘甚至更久，這也會嚴(yán)重拖慢我們的項(xiàng)目進(jìn)度。

• 發(fā)版周期過長

單體項(xiàng)目發(fā)版很多小伙伴可能都刻骨銘心，發(fā)版當(dāng)天如臨大敵，所有人都加班，等項(xiàng)目上線運(yùn)行都沒問題，各項(xiàng)數(shù)據(jù)都 OK，此時可能已經(jīng)凌晨三四點(diǎn)了，所有人拖著疲憊的身體下班。正是由于每一次發(fā)版都是一個大事，所以一般單體項(xiàng)目不太會頻繁發(fā)版（我說的頻繁是指如一天一版這種），發(fā)版周期普遍比較長。

• 難以擴(kuò)展

當(dāng)系統(tǒng)不同模塊對資源的需求不同的時候，我們想做針對性的硬件擴(kuò)展也并不方便。

舉個簡單例子，有一個模塊需要進(jìn)行大量的運(yùn)算，我們希望能為之提供更好的 CPU；有一個模塊需要更大的內(nèi)存，我們需要擴(kuò)展更大的內(nèi)存。

然而由于所有的模塊都打包在一起，我們只能針對當(dāng)前服務(wù)器做各種硬件升級，無法針對某一個模塊做專門的硬件升級。

• 過期的技術(shù)棧不易更新

我相信很多小伙伴見到的單體項(xiàng)目還有一個特點(diǎn)就是技術(shù)棧普遍比較老舊。這也是因?yàn)閱误w項(xiàng)目時間久了之后，積重難返，想要對基礎(chǔ)框架做版本升級往往牽一發(fā)而動全身，更別提從傳統(tǒng)的 SSM 切換到 Spring Boot 上這種超級繁瑣的工作了。因此大部分的單體項(xiàng)目，在立項(xiàng)的那一刻選用了什么技術(shù)棧、選用了技術(shù)的哪個版本，基本上這個項(xiàng)目未來都是這個版本了。

從上面的介紹中小伙伴們可以看到，單體項(xiàng)目優(yōu)點(diǎn)很明顯，然而缺點(diǎn)也是非常明顯的。而這些缺點(diǎn)，都可以通過微服務(wù)來解決。

2. 微服務(wù)版 TienChin

如果 TienChin 項(xiàng)目是微服務(wù)版呢？我們來看一張簡單的架構(gòu)圖。

簡單畫了張圖，我來解釋下：

• 首先我們基本上是按照業(yè)務(wù)來劃分服務(wù)的。每一個服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫，自己操作自己的庫。
• 假設(shè)在線索管理中，需要調(diào)用商機(jī)管理，那不能直接操作商機(jī)的數(shù)據(jù)庫，必須去調(diào)用商機(jī)管理服務(wù)中提供的 REST API，通過這個 REST API 來操作庫。
• 所有的服務(wù)有一個統(tǒng)一的入口 Gateway，如果前端是手機(jī) App 或者小程序之類的，通過 Gateway 來訪問到系統(tǒng)。
• 有一個后臺管理的 Web UI 項(xiàng)目，提供相應(yīng)的網(wǎng)頁操作。

大致上就是這個樣子。

那么這個微服務(wù)版的 TienChin 跟前面的單體版 TienChin 相比優(yōu)勢體現(xiàn)在哪里呢？

• 容易維護(hù)

首先第一點(diǎn)就是，項(xiàng)目拆分為微服務(wù)之后，每個服務(wù)相對來說都比較小，項(xiàng)目的維護(hù)相對來說也會比較容易。一個比較小的項(xiàng)目，在 IDE 中啟動也會比較快?？梢杂幸粋€很小的團(tuán)隊(duì)來負(fù)責(zé)項(xiàng)目的維護(hù)。

• 服務(wù)可以自由擴(kuò)展

以上圖為例，如果某日搞促銷活動，線索管理這個服務(wù)的并發(fā)量比較大，我們可以非常方便的為線索管理模塊做橫向擴(kuò)展，如下圖這樣：

任何一個服務(wù)，如果有需求，都可以非常方便的進(jìn)行擴(kuò)展，并且可以根據(jù)服務(wù)的特點(diǎn)來選擇合適的硬件，例如這個服務(wù)耗內(nèi)存，那就加大內(nèi)存；另一個服務(wù)耗 CPU，那就選擇一個性能到位的 CPU 等等。

• 解耦后更強(qiáng)的容錯性

通過服務(wù)降級、熔斷等微服務(wù)組件的使用，我們可以實(shí)現(xiàn)各個微服務(wù)具備更強(qiáng)的容錯性。一個服務(wù)出故障，并不會影響其他的服務(wù)。例如合同管理里邊發(fā)生了內(nèi)存泄漏，這個并不會影響到商機(jī)管理服務(wù)。

• 更容易采用新技術(shù)

之前我們在談到單體項(xiàng)目的弊端的時候，提到了單體項(xiàng)目的技術(shù)棧更新非常不易?，F(xiàn)在我們切換成微服務(wù)了，新技術(shù)棧的切換其實(shí)就變得非常容易了。每一個微服務(wù)都可以根據(jù)當(dāng)前項(xiàng)目的情況，選擇是否采用最新的技術(shù)棧，而且一個微服務(wù)在切換最新技術(shù)棧的過程中，如果不幸發(fā)生了問題了，也不會影響到其他的微服務(wù)，只會影響到當(dāng)前的服務(wù)。由于各個微服務(wù)之間基本上都是通過 REST API 進(jìn)行交互的，所以，退一萬步，你甚至可以使用不同的開發(fā)語言來開發(fā)不同的微服務(wù)。

• 更友好的 CI/CD

CI/CD 是 DevOps 的一部分，但是在前面的單體項(xiàng)目中，當(dāng)項(xiàng)目比較大的時候，想做到持續(xù)交付/持續(xù)部署已經(jīng)越來越難了，而微服務(wù)讓一個超大規(guī)模的項(xiàng)目可以非常方便的實(shí)現(xiàn) CI/CD。

現(xiàn)在，我們的每一個服務(wù)都有自己獨(dú)立的團(tuán)隊(duì)、獨(dú)立的代碼倉庫、獨(dú)立的自動化部署流水線，且互不相擾，如下圖這樣：

現(xiàn)在，每一個服務(wù)都可以獨(dú)立的實(shí)現(xiàn)服務(wù)的上線和部署，結(jié)合 DevOps 可以做到非常輕松的發(fā)版，不需要再像以前單體應(yīng)用發(fā)版的時候，如臨大敵一樣。

這樣劃分之后，工程師也可以將自己的精力放在業(yè)務(wù)開發(fā)商，提供更多有價值的功能，而不是像一個救火隊(duì)員一樣，每天忙著四處滅火。

好啦，通過這樣一篇簡單的文章和圖片，希望大家對微服務(wù)有一個基本的認(rèn)知，當(dāng)然，微服務(wù)也不是“銀彈”，微服務(wù)架構(gòu)也存在問題，這個咱們后面有空了松哥再繼續(xù)和小伙伴們分享。