一、簡述
在實際開發中，需要考慮多種因素，決定採取哪種架構模式才適合當前業務發展情況。
比如：業務發展階段-剛開始探索還是高速發展時期，業務的複雜度，業務訪問量是多還是少，使用者量是多還是少，開發人員的組成情況，開發人員的數量 等等都是需要考慮的因素。
二、微服務和單體優缺點對比分析
下面內容是對比微服務架構和單體架構的優缺點：
說明：√ - 優 ， × - 劣
| 序號 | 對比項 | 微服務架構 | 單體架構 | 優劣評比 |
|---|---|---|---|---|
| 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人。
[完]