從0開始學架構4 - 可擴充篇

從0開始學架構.可擴充篇

32 | 可擴充架構的基本思想和模式

今天我們進入架構可擴充模式的學習，這部分内容包括分層架構、SOA 架構、微服務和微核心等，先來聊聊架構的可擴充模式。

可擴充的基本思想

幸運的是，可擴充性架構的設計方法很多，但萬變不離其宗，所有的可擴充性架構設計，背後的基本思想都可以總結為一個字：拆！

按照不同的思路來拆分軟體系統，就會得到不同的架構。常見的拆分思路有如下三種。

• 面向流程拆分：将整個業務流程拆分為幾個階段，每個階段作為一部分。
• 面向服務拆分：将系統提供的服務拆分，每個服務作為一部分。
• 面向功能拆分：将系統提供的功能拆分，每個功能作為一部分。

我再以一個簡單的學生資訊管理系統為例（幾乎每個技術人員讀書時都做過這樣一個系統），拆分方式是：

• 面向流程拆分

展示層 → 業務層 → 資料層 → 存儲層

最終的架構如下：

• 面向服務拆分

将系統拆分為注冊、登入、資訊管理、安全設定等服務，最終架構示意圖如下：

• 面向功能拆分

最終架構圖如下：

可擴充方式

不同的拆分方式，将得到不同的系統架構，典型的可擴充系統架構有：

• 面向流程拆分：分層架構。
• 面向服務拆分：SOA、微服務。
• 面向功能拆分：微核心架構。

33 | 傳統的可擴充架構模式：分層架構和SOA

分層架構

分層架構是很常見的架構模式，它也叫 N 層架構，通常情況下，N 至少是 2 層。例如，C/S 架構、B/S 架構。常見的是 3 層架構（例如，MVC、MVP 架構）、4 層架構，5 層架構的比較少見，一般是比較複雜的系統才會達到或者超過 5 層，比如作業系統核心架構。

C/S 架構、B/S 架構

劃分的對象是整個業務系統，劃分的次元是使用者互動，即将和使用者互動的部分獨立為一層，支撐使用者互動的背景作為另外一層。例如，下面是 C/S 架構結構圖。

MVC 架構、MVP 架構

劃分的對象是單個業務子系統，劃分的次元是職責，将不同的職責劃分到獨立層，但各層的依賴關系比較靈活。例如，MVC 架構中各層之間是兩兩互動的：

邏輯分層架構

劃分的對象可以是單個業務子系統，也可以是整個業務系統，劃分的次元也是職責。雖然都是基于職責劃分，但邏輯分層架構和 MVC 架構、MVP 架構的不同點在于，邏輯分層架構中的層是自頂向下依賴的。典型的有作業系統核心架構、TCP/IP 架構。例如，下面是 Android 作業系統架構圖。

典型的 J2EE 系統架構也是邏輯分層架構，架構圖如下：

針對整個業務系統進行邏輯分層的架構圖如下：

無論采取何種分層次元，分層架構設計最核心的一點就是需要保證各層之間的差異足夠清晰，邊界足夠明顯，讓人看到架構圖後就能看懂整個架構，這也是分層不能分太多層的原因。

分層架構的特點

• 分層架構之是以能夠較好地支撐系統擴充，本質在于隔離關注點（separation of concerns），即每個層中的元件隻會處理本層的邏輯。
• 分層時要保證層與層之間的依賴是穩定的，才能真正支撐快速擴充。
• 分層結構的另外一個特點就是層層傳遞，也就是說一旦分層确定，整個業務流程是按照層進行依次傳遞的，不能在層之間進行跳躍。分層結構的這種限制，好處在于強制将分層依賴限定為兩兩依賴，降低了整體系統複雜度。

分層架構的缺點

分層架構另外一個典型的缺點就是性能，因為每一次業務請求都需要穿越所有的架構分層，有一些事情是多餘的，多少都會有一些性能的浪費。當然，這裡所謂的性能缺點隻是理論上的分析，實際上分層帶來的性能損失，如果放到 20 世紀 80 年代，可能很明顯；但到了現在，硬體和網絡的性能有了質的飛越，其實分層模式理論上的這點性能損失，在實際應用中，絕大部分場景下都可以忽略不計。

SOA

SOA 的全稱是 Service Oriented Architecture，中文翻譯為“面向服務的架構”。

為了應對傳統 IT 系統存在的問題，SOA 提出了 3 個關鍵概念。

• 服務。所有業務功能都是一項服務，服務就意味着要對外提供開放的能力，當其他系統需要使用這項功能時，無須定制化開發。
• ESB。ESB 的全稱是 Enterprise Service Bus，中文翻譯為“企業服務總線”。從名字就可以看出，ESB 參考了計算機總線的概念。計算機中的總線将各個不同的裝置連接配接在一起，ESB 将企業中各個不同的服務連接配接在一起。因為各個獨立的服務是異構的，如果沒有統一的标準，則各個異構系統對外提供的接口是各式各樣的。SOA 使用 ESB 來屏蔽異構系統對外提供各種不同的接口方式，以此來達到服務間高效的互聯互通。
• 松耦合。松耦合的目的是減少各個服務間的依賴和互相影響。因為采用 SOA 架構後，各個服務是互相獨立運作的，甚至都不清楚某個服務到底有多少對其他服務的依賴。如果做不到松耦合，某個服務一更新，依賴它的其他服務全部故障，這樣肯定是無法滿足業務需求的。

SOA 解決了傳統 IT 系統重複建設和擴充效率低的問題，但其本身也引入了更多的複雜性。SOA 最廣為人诟病的就是 ESB，ESB 需要實作與各種系統間的協定轉換、資料轉換、透明的動态路由等功能。

為什麼網際網路企業很少采用 SOA 架構？

SOA是把多個系統整合，而微服務是把單個系統拆開來，方向正好相反

34 | 深入了解微服務架構：銀彈 or 焦油坑？

微服務與 SOA 的關系

SOA 和微服務本質上是兩種不同的架構設計理念，隻是在“服務”這個點上有交集而已，是以兩者的關系應該是上面第三種觀點

微服務的陷阱

我們看一下微服務具體有哪些坑：

• 服務劃分過細，服務間關系複雜
• 服務數量太多，團隊效率急劇下降
• 調用鍊太長，性能下降
• 調用鍊太長，問題定位困難
• 沒有自動化支撐，無法快速傳遞
• 沒有服務治理，微服務數量多了後管理混亂

35 | 微服務架構最佳實踐 - 方法篇

專欄上一期，我談了實施微服務需要避免踩的陷阱，簡單提煉為：

• 微服務拆分過細，過分強調“small”。
• 微服務基礎設施不健全，忽略了“automated”。
• 微服務并不輕量級，規模大了後，“lightweight”不再适應。

服務粒度

針對微服務拆分過細導緻的問題，我建議基于團隊規模進行拆分，類似貝索斯在定義團隊規模時提出的“兩個披薩”理論（每個團隊的人數不能多到兩張披薩都不夠吃的地步），分享一個我認為微服務拆分粒度的“三個火槍手”原則，即一個微服務三個人負責開發。

“三個火槍手”的原則主要應用于微服務設計和開發階段，如果微服務經過一段時間發展後已經比較穩定，處于維護期了，無須太多的開發，那麼平均 1 個人維護 1 個微服務甚至幾個微服務都可以。當然考慮到人員備份問題，每個微服務最好都安排 2 個人維護，每個人都可以維護多個微服務。

拆分方法

• 基于業務邏輯拆分

這是最常見的一種拆分方式，将系統中的業務子產品按照職責範圍識别出來，每個單獨的業務子產品拆分為一個獨立的服務。

• 基于可擴充拆分

将系統中的業務子產品按照穩定性排序，将已經成熟和改動不大的服務拆分為穩定服務，将經常變化和疊代的服務拆分為變動服務。穩定的服務粒度可以粗一些，即使邏輯上沒有強關聯的服務，也可以放在同一個子系統中，例如将“日志服務”和“更新服務”放在同一個子系統中；不穩定的服務粒度可以細一些，但也不要太細，始終記住要控制服務的總數量。

• 基于可靠性拆分

将系統中的業務子產品按照優先級排序，将可靠性要求高的核心服務和可靠性要求低的非核心服務拆分開來，然後重點保證核心服務的高可用。具體拆分的時候，核心服務可以是一個也可以是多個，隻要最終的服務數量滿足“三個火槍手”的原則就可以。

• 基于性能拆分

基于性能拆分和基于可靠性拆分類似，将性能要求高或者性能壓力大的子產品拆分出來，避免性能壓力大的服務影響其他服務。常見的拆分方式和具體的性能瓶頸有關，可以拆分 Web 服務、資料庫、緩存等。例如電商的搶購，性能壓力最大的是入口的排隊功能，可以将排隊功能獨立為一個服務。

以上幾種拆分方式不是多選一，而是可以根據實際情況自由排列組合，例如可以基于可靠性拆分出服務 A，基于性能拆分出服務 B，基于可擴充拆分出 C/D/F 三個服務，加上原有的服務 X，最後總共拆分出 6 個服務（A/B/C/D/F/X）。

基礎設施

微服務基礎設施如下圖所示：

雖然建設完善的微服務基礎設施是一項龐大的工程，但也不用太過灰心，認為自己團隊小或者公司規模不大就不能實施微服務了。第一個原因是已經有開源的微服務基礎設施全家桶了，例如大名鼎鼎的 Spring Cloud 項目，涵蓋了服務發現、服務路由、網關、配置中心等功能；第二個原因是如果微服務的數量并不是很多的話，并不是每個基礎設施都是必須的。通常情況下，我建議按照下面優先級來搭建基礎設施：

1. 服務發現、服務路由、服務容錯：這是最基本的微服務基礎設施。
2. 接口架構、API 網關：主要是為了提升開發效率，接口架構是提升内部服務的開發效率，API 網關是為了提升與外部服務對接的效率。
3. 自動化部署、自動化測試、配置中心：主要是為了提升測試和運維效率。
4. 服務監控、服務跟蹤、服務安全：主要是為了進一步提升運維效率。

以上 3 和 4 兩類基礎設施，其重要性會随着微服務節點數量增加而越來越重要，但在微服務節點數量較少的時候，可以通過人工的方式支撐，雖然效率不高，但也基本能夠頂住。

36 | 微服務架構最佳實踐 - 基礎設施篇

• 自動化測試
• 自動化部署
• 配置中心
• 接口架構
• API 網關
• 服務發現。服務發現主要有兩種實作方式：自理式和代理式。
• 服務路由
• 服務容錯
• 服務監控
• 服務跟蹤
• 服務安全

37 | 微核心架構詳解

基本架構

微核心架構包含兩類元件：核心系統（core system）和插件子產品（plug-in modules）。核心系統負責和具體業務功能無關的通用功能，例如子產品加載、子產品間通信等；插件子產品負責實作具體的業務邏輯，例如專欄前面經常提到的“學生資訊管理”系統中的“手機号注冊”功能。

微核心的基本架構示意圖如下：

上面這張圖中核心系統 Core System 功能比較穩定，不會因為業務功能擴充而不斷修改，插件子產品可以根據業務功能的需要不斷地擴充。微核心的架構本質就是将變化部分封裝在插件裡面，進而達到快速靈活擴充的目的，而又不影響整體系統的穩定。

設計關鍵點

微核心的核心系統設計的關鍵技術有：插件管理、插件連接配接和插件通信。

OSGi 架構簡析

OSGi 的全稱是 Open Services Gateway initiative，本身其實是指 OSGi Alliance。現在我們談到 OSGi，如果沒有特别說明，一般都是指 OSGi 的規範。

OSGi 架構的邏輯架構圖如下：

規則引擎架構簡析

規則引擎從結構上來看也屬于微核心架構的一種具體實作，其中執行引擎可以看作是微核心，執行引擎解析配置好的業務流，執行其中的條件和規則，通過這種方式來支援業務的靈活多變。

例如電商促銷，常見的促銷規則，規則引擎卻能夠很靈活的應對這種需求，主要原因在于：

• 可擴充
• 易了解
• 高效率