1.2 微服務架構與整體式架構的區別

如果是一個小型項目，則使用整體式（單體式）架構設計，其好處非常明顯，因為它的設計和開發，以及測試和部署，都可以在一個項目上完成。

如果一個業務復雜的大型項目也使用整體式架構設計，就會存在很多問題。可能剛開始的時候，還感覺不到什么，但是隨著時間的推移，加入的功能越來越多，一個項目就變成了一塊巨大的石頭，笨重而丑陋。

面對一個巨大的項目，開發人員想要弄清楚它的代碼邏輯，就必須花費很多的時間。而針對某一項功能的更改，極有可能“牽一發而動全身”，這會讓實施人員變得舉步維艱。所以這種項目將會變得越來越難以維護，越來越不便更新。

整體式架構的穩定性也不能得到有效的保障，如果其中的一個模塊出現問題，將會影響整個系統的正常運行，甚至造成整個系統的崩潰。而在對問題進行跟蹤時，因為系統龐大，往往難上加難。

另外，一個巨大的項目，也不方便進行持續開發，它不能適應需求的快速變更，無法使用快速迭代的敏捷開發方法，也不便在某些方面進行新技術的更替，所以這樣的項目最終就變成了業務發展的絆腳石。

相比之下，大型項目使用微服務架構的優勢非常明顯。

微服務架構設計，就是把復雜事情進行簡單化處理。它將一個復雜的系統，拆分成一些小型的應用來開發，首先就將問題進行了分層和簡化。因為小型而變得簡單，代碼的邏輯會變得更加清晰，這無疑解放了程序員繁重的勞動；因為簡單，所以能夠專注，能夠將每一件事情都做好，做到極致。

微服務架構中獨立的小型應用，非常適合使用敏捷開發方法，即快速響應需求的變化，進行快速的更新、迭代。

因為每個微服務都是獨立自治的，即一個服務的故障不會影響全局系統的正常運行，或者說可以將這種影響降到最低。并且，微服務架構的容錯設計，可以避免這種情況的發生。

微服務架構高可用的特點，是系統穩定性的最好保障。微服務能夠支持高并發的調用、高流量的訪問，能夠持續滿足平臺規模化發展的要求，可以很容易地使用彈性化設計，所有這些是整體式架構無法做到的。

如果我們用一個六邊形結構來表示整體式架構，則可以繪制出如圖1-1所示的結構圖。

這個六邊形的核心是整體式架構的領域業務模型，它通過系統接口使用各種適配器，如數據庫適配器、文件適配器等，與外部管理系統進行連接；然后又通過接口，使用諸如REST API適配器、Web UI適配器等給外部App和終端用戶提供接口調用和Web訪問等服務。

從圖1-1中可以看出，整體式架構是一個大而全的系統。在微服務架構設計中，我們可以使用一個小正方體來表示每個微服務，它相當于對整體式架構進行拆分之后得到的結果，如圖1-2所示。

小正方體的微服務同樣使用接口，同樣通過各種適配器連接外部管理系統，而微服務之間也可以通過接口，使用REST API適配器進行通信。對于App用戶和終端用戶，將分別由不同的微服務提供相應的適配器及服務。

通過對上面這兩種結構圖形的比較可以非常明顯地看出整體式架構與微服務架構的區別。