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

微服務架構學習系列文章：

• 微服務架構學習與思考(01)：什么是微服務？微服務的優勢和劣勢
• 微服務架構學習與思考(02)：微服務實施的前提條件？有哪些問題需要思考？
• 微服務架構學習與思考(03)：微服務總體架構圖解
• 微服務架構學習與思考(04)：微服務技術體系
• 微服務架構學習與思考(05)：微服務架構適用場景分析

一、簡述

在實際開發中，需要考慮多種因素，來決定采取哪種架構模式才適合當前業務發展情況。

畢竟微服務也不能“包治百病”，不要把它當做萬能葯。企業研發哪里得病了，覺得只要把“微服務”這服葯給用上，就葯到病除。哪有這么簡單的事情。
微服務有它自身的特點，優點和缺點，有其適用范圍，微服務並不能解決所有問題。

你需要綜合考慮一些情況：

比如 業務所處發展階段：

1. 剛開始探索
2. 高速發展期
3. 還是成熟期

業務的復雜度：

1. 業務訪問量是多還是少
2. 用戶量是多還是少

開發人員：

1. 開發人員素質，是初級還是高級
2. 開發人員的數量

產品的形態：

1. APP
2. web
3. 小程序
   是否3者都有

等等都是需要綜合考慮的因素。

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

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

說明：√ - 優 ， × - 劣

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

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

業務復雜項目：微服務的優勢就開始上升了。優勢明顯增多。但是治理復雜度也隨着上升。

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

三、微服務適用場景

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

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

• 響應需求變慢，需求開發時間變長。
• 交付的效率變差，bug數越來越多。
• 業務復雜度變高，應用達到3個或3個以上，或者模塊達到5個或以上。
• 團隊人數變多，開發至少有5人以上，運維至少2人。
• 項目需要長期迭代維護，至少一年以上。

上面只是為了判斷簡化對比項目，是一個簡單模型，但請務必參考上面詳細的對比項目來認真思考。

什么時候適合引入微服務的考量因素：

• 業務角度
  • 業務需求開發是否經常延遲
  • 產品交付是否能跟上業務發展
  • 業務維護周期長
  • 業務復雜度
  • 業務量有多少
• 研發質量
  • 代碼是否因為修改而經常出現bug
  • 代碼臃腫龐大，變得越來越臃腫
  • 響應需求變化時間變長
  • 交付時間變長
• 技術人員
  • 有技術，有意願
  • 團隊人數足夠
• 業務發展期
  • 剛創立公司初期
  • 高速發展期
  • 成熟期

最后：微服務架構不是銀彈 。

[完]