淺談單體向微服務架構的演進

一、什么是架構

首先，要理解架構，我們需要先理解幾個有關系又相似的概念，包括：系統和子系統、模塊和組件、框架和架構，
我們以一個學生管理系統為例，

1. 系統和子系統

• 系統：
  • 系統泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的作業的群體，它的意思是“總體”“整體”或“聯盟”，
• 子系統
  • 子系統也是由一群有關聯的個體所組成的系統，多半會是更大系統中的一部分，

一個可用的、完整的學生管理系統便是一個系統，系統一般是具有完整性的，
而學生管理系統又可以包括用戶子系統，學生資訊管理子系統，成績管理子系統等等，我們可以明顯看出其中差距，一個系統一般會有一個或者多個子系統構成，多個子系統相互協作構成較大的系統，劃分子系統的原則往往是按照業務場景來，并不是絕對的，所以子系統也可以再次細分為多個子系統，系統也有可能是其他更大系統的子系統，

2. 模塊和組件

• 模塊：
  • 是一套一致而互相有緊密關連的軟體組織，它分別包含了程式和資料結構兩部分，現代軟體開發往往利用模塊作為合成的單位，模塊的介面表達了由該模塊提供的功能和呼叫它時所需的元素，模塊是可能分開被撰寫的單位，這使它們可再用和允許人員同時協作、撰寫及研究不同的模塊
• 組件
  • 定義為自包含的、可編程的、可重用的、與語言無關的軟體單元，軟體組件可以很容易被用于組裝應用程式中

模塊和組件往往容易被濫用，它們都是系統的組成部分，只是拆分的角度不同， 從邏輯的角度去拆分系統，得到的單元就是模塊，例如學生管理系統可分為成績模塊，學生資訊模塊，而從物理的角度去拆分，又可以拆分為 web服務、MySQL、nosql、NGINX 等，
劃分模塊的目的是對職責進行分離，而劃分組件的目的卻是為了復用，因此組件一般是具有獨立性的，可以替換的，跟一個完整的零件似的，例如我們使用 Apache、Tomcat、NGINX 等

3. 框架和架構

• 框架
  • 通常指的是為了實作某個業界標準或完成特定基本任務的軟體組件規范，也指為了實作某個軟體組件規范時，提供規范所要求之基礎功能的軟體產品，
• 架構
  • 指軟體系統的“基礎結構”，創造這些基礎結構的準則，以及對這些結構的描述，

應該沒有人不熟悉框架了，框架其實主要是提供了規范性和基本的功能代碼包，例如 go 的 gin、beego、go-zero 等框架，主要是定義了基本的目錄結構以及提供了一些基本的代碼處理和工具包，可以幫助開發快速去使用，

架構的定義相比之下比較模糊，不同的角度或者維度，可以將系統劃分為不同的結構（架構），例如從物理部署的角度來說，它的架構可能是這樣的：

我們可以說這是一種純技術選擇的架構，這也是大多數人熟悉的架構定義，使用了哪些技術堆疊（語言、工具、框架），彼此之間的關聯關系是什么，

當然，代碼結構也是一種架構，例如我們常說的 MVC 架構，這可是前幾年校招必問的題目，這是從開發規范的角度來定義的，

而從業務角度來看，這樣的模塊劃分關系圖也是架構

架構的終極定義：
參考李老師的說法，架構的定義應該是軟體系統的頂層結構，首先“系統是一群關聯個體組成”，這些“個體”可以是“子系統”“模塊”“組件”等；架構需要明確系統包含哪些“個體”，其次，系統中的個體需要“根據某種規則”運作，架構需要明確個體運作和協作的規則，

二、單體架構的外貌特征

怎么樣才算是單體架構，像博主身邊有些同學就覺得，不是微服務架構就是單體架構，其實這樣理解是不大正確的，單體架構風格就是簡單地意味著所有應用代碼被部署并運行在單一節點的單一行程中，第一個詞“部署”的意思是運行時代碼的組織方式，無論代碼在物理上是存盤在一個還是多個代碼庫之中，而第二個詞“節點”的意思是即便是在橫向擴展的情況下我們將應用部署到了多個服務器，它依然是一個單體，

以常見的 lmnp 架構為例，就是一個單體架構，所有的應用代碼都是跑在了一個行程里面，內部相關的函式呼叫均在行程內處理，而非行程間通信，例如我司的大單體架構，代碼量也已達到了百萬級別（git clone下來幾個G大小啊），常見的單體架構往往是這樣的，

當然這個圖忽略了負載均衡、cdn 相關的內容，我們可以清晰的看到，基本上，一個系統會包含很多的模塊，并且不同的模塊共用相同的資源（MySQL、Redis…)，整體依賴性是十分的強，并且如果某個模塊代碼出現問題導致MySQL掛了，也就意味著整個系統就掛了，在上一篇《淺談微服務》中，我說明了單體架構和微服務架構的優劣勢，在這里我不在贅述，
重點記住這句話：無能力不微服務化、無能力不微服務化、無能力不微服務化

重點的事情講三遍
微服務所帶來的的技術復雜性、人力成本是一般中小公司無法承受的，

三、微服務架構

3.1 為什么要考慮微服務？

我們可以看看上面這張圖，隨著時間的推移，單體應用的復雜度只會呈線性去增長，而微服務架構確實復雜度呈線性較少，但是要搭起微服務這一套是十分復雜的，寫代碼只是其中的一小部分，想搭起適合公司的微服務體系，往往沒有你想象中那么簡單，當公司慢慢趨于穩定了，有較多的盈利了，這個時候為了后期的發展，就可以（必須）得考慮微服務架構了，找幾個牛逼的技術專家+運維+領域專家+一堆開發，用DDD 去拆分領域，部分人繼續維護老代碼，部分人開始進行重構升級作業（大多數公司都是這么弄的），畢竟不能一刀切，重構的作業往往耗時較久，日常的迭代需求還是要開發的，這也是為什么搞微服務重構的公司會大量的招人，就是為了給重構讓出必要的資源，為了讓重構變的更有業務價值，往往會揪出當前業務的痛點，進行梳理，這樣對公司來說，重構也是對業務有所幫助的，

所以，之所以要考慮微服務，主要是因為領導者預見了未來，并在資源充足的情況下所作出的決策，
用人話來說，就是有錢了為了提升作業效率，就去買了 Mac（當然也可能買其他性能較好的電腦，即選擇其他的架構，不過Mac是開發公認較好的工具了），如果沒錢還是繼續用舊電腦剛吧，

3.2 微服務的核心是什么？

微服務其中一個重要的核心就是去中心化，我們可以看看百度百科對其定義：
去中心化，不是不要中心，而是由節點來自由選擇中心、自由決定中心，簡單地說，中心化的意思，是中心決定節點，節點必須依賴中心，節點離開了中心就無法生存，在去中心化系統中，任何人都是一個節點，任何人也都可以成為一個中心，任何中心都不是永久的，而是階段性的，任何中心對節點都不具有強制性，

中心化容易引發的一個問題就是單點奔潰，比如說我們的網站只有一個網關，如果這個網關掛了，沒有其他的備用網關，那么整個系統也就涼了，在這里又不得聊起分布式，分布式一定是去中心化嗎？
其實不然，去中心化一定是分布式的實作，但是分布式卻不一定是去中心化，我們舉個例子，MySQL的主從集群是去中心化嗎？
一般來講，存在主/從關系的系統是中心化系統，在這類系統中，主節點負責系統的整體運行管理，從節點則負責運行主節點安排的任務，在這種系統中，一般主節點出故障容易引起系統的崩潰，而從節點出問題則一般不會引起系統的崩潰，

這就意味著，由原本的中央集權控制，變成了人民自己當家做主（依靠的規則就是法律）

四、從單體邁向微服務架構

微服務架構在不同的公司有著不同的實作方式，不同的框架和語言，都有著自己的特色，例如 Java 的spring cloud， go 的 go-zero 框架，博主主要涉及的是 go + grpc 的模式，我簡單畫了一下微服務化的架構圖，

4.1 如何拆分服務？

我們通過圖中可以看到，服務是位于最底層的，不同的服務一般擁有自己的資源庫，例如自己的MySQL、Redis，這樣，只要保證向前兼容，就可以隨便的升級改造服務介面，不需要通知呼叫方做調整，拆分服務是微服務設計的最重要的一環，一般來說，沒有絕對的拆分姿勢，不過有一些公認的拆分規則：

• 服務要可以單獨部署，不依賴其他的服務
• 服務盡可能的小，但是不能拆分的太小，拆分的太小容易引發過度設計的問題，拆分的太大就會過于粗糙
• 使用DDD設計，盡量按業務模塊拆分

說起 DDD 就比較煩了，太抽象了，等博主學完一波再來搞它，

4.2 微服務的請求鏈路

以上圖為例（不同公司的設計不同，這里只是舉了一個例子）
實際上，圖示請求鏈路是： 外網-> API GATEAWAY -> frontend -> bff -> microservice

這里要重點說明的是 API GATEAWAY 和 BFF ，

其實這張圖是相對比較成熟的架構了（聽說小破站也是這么搞的），很多公司搞微服務既沒有 API GATEAWAY 和 BFF, 更沒有按服務拆分資料庫，只是單純將原本的后端代碼拆分重構成微服務，對整體的架構并沒有太大的變化，可以說做的并不徹底，
不過這也是受公司組織以及規模來決定的，有能力有資源當然要做徹底一點，

像以前，可能會存在這種直連的模式，

這種方式，雖然是按照 SOA 服務化架構去設計，但是對外暴露了很多微服務，也因為沒有統一的出口容易遇到很多的問題：

• 強耦合
• 需要多次請求，客戶端對資料進行聚合
• 面向端的適配，會讓微服務的涉及耦合很多業務
• 無法進行統一的邏輯收斂，每個服務都要實作一套驗證
• 協議不統一，需要客戶端進行兼容

界內有這么一個說法，當某一層不能實作一些事情的時候，我們就在上面再加一層，
通過 API GATEAWAY 我們可以不再直接對外暴露服務，并且 API GATEAWAY 還可以幫我們實作一些通用的鑒權，限流等操作，這樣就不需要每個服務自己去實作相關的邏輯，

那 bff 到底是干嘛的呢？

BFF 可以認為是一種適配服務，將后端的微服務進行
適配(主要包括聚合裁剪和格式適配等邏輯)，向其他客戶端
設備暴露友好和統一的 API，有了BFF，后端在設計微服務的時候，就可以盡量的避免業務邏輯侵入，業務邏輯讓 bff 那一層去實作，

像我司，bff 是通過 nodejs 實作的，我們后端在實作完微服務后，前端會寫 bff 通過 rpc 呼叫來呼叫我們的后端服務，然后前臺再去呼叫 bff，

同時為了保證系統的高可用，往往這些玩意也都不會進行單節點部署，因此，微服務架構和分布式架構基本是無法分隔的，