單體的 TienChin 和微服務的 TienChin 有何異同？

有不少小夥伴希望松哥能整一個微服務的實戰專案，微服務這塊技術點其實松哥是講過很多了，圖文版的教程影片版的教程都有，不過確實缺乏一個專案，所以我在想等 TienChin 專案搞完之後，和小夥伴們也來一起搞一個微服務的專案。

今天我想從架構的角度來和小夥伴們聊一聊微服務。不聊具體的技術點，就單純來看看一個微服務專案該怎麼設計。

1. 單體版 TienChin

松哥目前在錄的 TienChin 專案就是一個前後端分離的單體專案，採用了 Spring Boot + Vue3。那麼單體版的 TienChin 具有什麼樣的特徵呢？我從優點和缺點兩個方面來和大家分析。

先來看一張簡單的架構圖：

可以看到，雖然是單體專案，但是為了開發方便，專案也細分為許多不同的模組，專案中的介面卡可以分為兩大類：

1. 入站介面卡：就是外部系統來呼叫我們的系統，REST API 和 Vue 網頁都算是入站介面卡，外部系統透過這兩個介面來呼叫我們的系統。
2. 出站介面卡：這個主要是我們系統內部呼叫外部系統的方式，例如我們的專案中需要用到 MySQL、Redis等，那麼就透過出站介面卡來實現。

1.1 優點

1. 開發簡單：隨便一個 IDE，擼起袖子就可以開寫了。
2. 測試簡單：專案啟動之後，直接利用 POSTMAN 等工具就可以測試專案介面了。
3. 部署簡單：專案開發完成之後，打包成一個 jar 或者一個 war，直接部署就行了。
4. 橫向擴充套件簡單：當專案併發能力不足的時候，可以方便的結合 Nginx 等負載均衡工具進行橫向擴充套件。

可以看到，單體專案的優勢整體上來說還是非常明顯的。

1.2 缺點

然而缺點也是非常明顯的。

1. 專案越來越複雜

首先就是專案不可能一直這麼簡單，我們這個專案中還是細分了很多不同的模組。隨著時間的推移，這些模組會變得越來愈複雜。修改每一個 BUG 都要小心翼翼，牽一髮而動全身。並且隨著專案組中人員的離職/入職，新接手的人會讓這個專案更加複雜，每一次 BUG 的修復或者新功能的新增，都會讓這個專案變得更加“不可捉摸”。

1. 開發進度越來越不可控

由於系統越來越複雜，我們不得不增派人手參與到這個專案的開發中，以期推進專案進度。這麼多人的協調又是一個問題。並且，隨著專案越來越大，每一次編譯執行都得數分鐘、十幾分鍾甚至更久，這也會嚴重拖慢我們的專案進度。

1. 發版週期過長

單體專案發版很多小夥伴可能都刻骨銘心，發版當天如臨大敵，所有人都加班，等專案上線執行都沒問題，各項資料都 OK，此時可能已經凌晨三四點了，所有人拖著疲憊的身體下班。正是由於每一次發版都是一個大事，所以一般單體專案不太會頻繁發版（我說的頻繁是指如一天一版這種），發版週期普遍比較長。

1. 難以擴充套件

當系統不同模組對資源的需求不同的時候，我們想做針對性的硬體擴充套件也並不方便。

舉個簡單例子，有一個模組需要進行大量的運算，我們希望能為之提供更好的 CPU；有一個模組需要更大的記憶體，我們需要擴充套件更大的記憶體。

然而由於所有的模組都打包在一起，我們只能針對當前伺服器做各種硬體升級，無法針對某一個模組做專門的硬體升級。

1. 過期的技術棧不易更新

我相信很多小夥伴見到的單體專案還有一個特點就是技術棧普遍比較老舊。這也是因為單體專案時間久了之後，積重難返，想要對基礎框架做版本升級往往牽一髮而動全身，更別提從傳統的 SSM 切換到 Spring Boot 上這種超級繁瑣的工作了。因此大部分的單體專案，在立項的那一刻選用了什麼技術棧、選用了技術的哪個版本，基本上這個專案未來都是這個版本了。

從上面的介紹中小夥伴們可以看到，單體專案優點很明顯，然而缺點也是非常明顯的。而這些缺點，都可以透過微服務來解決。

2. 微服務版 TienChin

如果 TienChin 專案是微服務版呢？我們來看一張簡單的架構圖。

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

1. 首先我們基本上是按照業務來劃分服務的。每一個服務都有自己獨立的資料庫，自己操作自己的庫。
2. 假設線上索管理中，需要呼叫商機管理，那不能直接操作商機的資料庫，必須去呼叫商機管理服務中提供的 REST API，透過這個 REST API 來操作庫。
3. 所有的服務有一個統一的入口 Gateway，如果前端是手機 App 或者小程式之類的，透過 Gateway 來訪問到系統。
4. 有一個後臺管理的 Web UI 專案，提供相應的網頁操作。

大致上就是這個樣子。

那麼這個微服務版的 TienChin 跟前面的單體版 TienChin 相比優勢體現在哪裡呢？

1. 容易維護

首先第一點就是，專案拆分為微服務之後，每個服務相對來說都比較小，專案的維護相對來說也會比較容易。一個比較小的專案，在 IDE 中啟動也會比較快。可以有一個很小的團隊來負責專案的維護。

1. 服務可以自由擴充套件

以上圖為例，如果某日搞促銷活動，線索管理這個服務的併發量比較大，我們可以非常方便的為線索管理模組做橫向擴充套件，如下圖這樣：

任何一個服務，如果有需求，都可以非常方便的進行擴充套件，並且可以根據服務的特點來選擇合適的硬體，例如這個服務耗記憶體，那就加大記憶體；另一個服務耗 CPU，那就選擇一個效能到位的 CPU 等等。

1. 解耦後更強的容錯性

透過服務降級、熔斷等微服務元件的使用，我們可以實現各個微服務具備更強的容錯性。一個服務出故障，並不會影響其他的服務。例如合同管理裡邊發生了記憶體洩漏，這個並不會影響到商機管理服務。

1. 更容易採用新技術

之前我們在談到單體專案的弊端的時候，提到了單體專案的技術棧更新非常不易。現在我們切換成微服務了，新技術棧的切換其實就變得非常容易了。每一個微服務都可以根據當前專案的情況，選擇是否採用最新的技術棧，而且一個微服務在切換最新技術棧的過程中，如果不幸發生了問題了，也不會影響到其他的微服務，只會影響到當前的服務。由於各個微服務之間基本上都是透過 REST API 進行互動的，所以，退一萬步，你甚至可以使用不同的開發語言來開發不同的微服務。

1. 更友好的 CI/CD

CI/CD 是 DevOps 的一部分，但是在前面的單體專案中，當專案比較大的時候，想做到持續交付/持續部署已經越來越難了，而微服務讓一個超大規模的專案可以非常方便的實現 CI/CD。

現在，我們的每一個服務都有自己獨立的團隊、獨立的程式碼倉庫、獨立的自動化部署流水線，且互不相擾，如下圖這樣：

現在，每一個服務都可以獨立的實現服務的上線和部署，結合 DevOps 可以做到非常輕鬆的發版，不需要再像以前單體應用發版的時候，如臨大敵一樣。

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

好啦，透過這樣一篇簡單的文章和圖片，希望大家對微服務有一個基本的認知，當然，微服務也不是“銀彈”，微服務架構也存在問題，這個我們們後面有空了松哥再繼續和小夥伴們分享。