微服務架構學習與思考(05)：微服務架構適用場景分析

一、簡述

在實際開發中，需要考慮多種因素，決定採取哪種架構模式才適合當前業務發展情況。
比如：業務發展階段-剛開始探索還是高速發展時期，業務的複雜度，業務訪問量是多還是少，使用者量是多還是少，開發人員的組成情況，開發人員的數量 等等都是需要考慮的因素。

二、微服務和單體優缺點對比分析

下面內容是對比微服務架構和單體架構的優缺點：

說明：√ - 優 ， × - 劣

序號	對比項	微服務架構	單體架構	優劣評比
1	呼叫難度	API 介面呼叫	資料庫共享或本地程式呼叫	API都是遠端呼叫，出問題情況更多，微服務：× 單體：√
2	系統設計-可擴充套件性	每個業務可以獨立一個微服務，用api進行通訊，可擴充套件性強	由於是一個單體應用，整個應用都在一起，耦合度高，可擴充套件性下降	微服務：√ 單體：×
3	系統設計-可維護性	每個團隊獨立負責一個或者幾個微服務，業務複雜度降低，可維護性高	所有開發人員都在一個單體上進行開發，所以業務整合在一起，可維護性差	微服務：√ 單體：×
4	系統設計-高效能	一個微服務可能呼叫幾個其他的微服務，網路通訊變多，效能下降	在單體內進行通訊，效能高	微服務：× 單體：√
5	業務開發複雜度	由於把單體拆分成多個微服務，業務複雜度也隨著分解到多個服務中	在一個單體裡，業務都糅合在一起，容易牽一髮而動全身	微服務：√ 單體：×
6	開發效率	早期設計和溝通的工作量加大，隨著專案規模和時間的推移，效率變化不大	早期工作量小，隨著專案規模和時間的推移，效率大幅度下降	隨著時間複雜度上升：微服務 √，簡單專案：單體 √ ， 複雜專案：微服務 √
7	需求變更響應速度	各個微服務只負責自己的業務部分，獨立變更，敏捷開發更好	單體變更，有可能牽一髮而動全身，導致其他模組出事故	微服務：√ 單體：×
8	運維難度	大系統拆分成多個小系統，導致系統變多，服務一多，部署和運維難度就加大，所以需要DevOps	由於是單體，運維相對來說簡單	微服務：× 單體：√
9	交付效率	拆分成多個小系統，小系統打包編譯快，交付也隨之變快。配合DevOps會更快	大單體比較大，編譯打包慢，導致交付也慢	微服務：√ 單體：×
10	服務治理	服務變多，治理複雜	單體應用治理簡單	微服務：× 單體：√
11	業務複用性	微服務更好	單體複用性差	微服務：√ 單體：×
12	程式碼複用性	可以用元件形式複用，微服務形式複用	一般是共享庫形式複用	微服務：√ 單體：×
13	開發成本	前後期開發成本一樣	前期開發成本低，後期業務複雜度上來成本變高	一個變化的過程，前期：單體 √ 後期：微服務 √
14	職責劃分	由於每個微服務由獨立團隊負責，職責劃分明確	開發人員都在一個單體上開發，功能交叉，職責模糊，容易產生丟鍋行為	微服務：√ 單體：×
15	開發人數	由於劃分為多個微服務，1個或幾個微服務由獨立團隊負責，開發人數會上升	人數增加沒有微服務那麼明顯	微服務：× 單體：√
16	風險	由於劃分為多個獨立的微服務，風險被分擔給各個服務，控制在各個小系統內	單體系統是一個整體，一個小錯誤可能導致整個系統不可用，牽一髮而費全身	微服務：√ 單體：×
17	分散式開發情況	困難增加，比如分散式事務，分散式一致性，資料庫拆分之後的聯合查詢	資料庫拆分後的聯合查詢	微服務：× 單體：√
18	系統整體複雜度	整體複雜度變高，因為拆分微服務比較多	整體複雜度稍低	微服務：× 單體：√

從上面各項分析，可以看出，對於微服務和單體，各有優缺點。
業務簡單專案：單體優勢為開發效率、呼叫難度、服務治理、運維難度、開發成本。 比如剛開始展開業務，還不知道業務是否可行，需要驗證業務模型時候，可以用單體快速簡單開發驗證業務模型，跑通業務模型。

業務複雜專案：微服務的優勢就開始上升了。優勢明顯增多。但是治理複雜度也隨著上升。

所以微服務也不是銀彈，它也有很多缺點，所以它也有不適用的場景。

三、微服務適用場景

從上面的單體和微服務對比的優缺點分析來看，微服務架構也不是“包治百病”，它也有適用的場景。怎麼判斷這個適用場景？對著上面的專案對比來看，就可以判斷當前專案是否適合微服務架構。這也是架構選型所要考慮的情況。

微服務適用場景也可以簡化下：

• 專案需要長期迭代維護，至少一年以上。
• 專案複雜度變高，應用達到3個或3個以上，或者模組達到5個或以上
• 團隊人數變多，開發至少有5人以上，運維至少2人。

[完]