這是我的第 42 篇原創文章
作者 l 會點代碼的大叔（CodeDaShu）
微服務是這幾年比較火的概念了，很多 IT 公司也都在做微服務轉型，那麼微服務化适合所有的公司麼？微服務架構可以解決一切問題麼？我覺得并不是這樣的，企業是否需要做微服務轉型還是要從實際情況出發。
01
微服務倒逼組織架構
說到微服務，很多人會認為這是個技術架構，但我認為微服務不隻是技術架構這麼簡單，它甚至會涉及到組織架構。
通常 IT 公司的崗位都會分成産品、開發、測試、運維，有些公司甚至會分成不同的部門，一個需求的開發到上線，會從前到後經過四個部門的流轉，而進行微服務的轉型，目的是為了加速業務的響應，快速開發，快速上線，縮短疊代周期，快速試錯并糾正。
如果企業想做服務化轉型，那麼組織架構也需要做相應的調整，否則還像以往一樣，部門和部門之間、崗位和崗位之間需要很大的溝通成本，那麼微服務是“快不起來”的；比較理想的是把不同的崗位揉在一起，一個團隊中包含産品、開發、測試、運維四種角色，團隊成員彼此協作負責一個或幾個微服務的疊代和運維。
02
設計更為複雜
判斷是不是适合微服務化，也要看自己的業務場景，如果服務做拆分，隻是為了拆分而拆分，是沒有意義的，通常要考慮：
拆分之後的服務，能否被複用？
如果一個功能在 A 系統，隻被 A 系統自己使用，那麼沒有拆出來的價值，如果 B/C/D 系統都需要使用這個功能，那麼可以拆分出來複用；微服務的優勢之一，增加複用，減少重複開發，縮短開發時間，進而降低成本；
通路量大還是小？如果通路量不大且平穩，未來很長時間通路量也不會有很大的增長，那就沒必要微服務化，如果有高并發、流量不可預計，那麼可以做微服務化。
微服務在設計上也存在着一定的難度，拆成幾個微服務？新需求來了，是建立一個微服務，還是在老服務上改造？這些設計層面的考慮，也是非常複雜的。
03
技術上的難度
雖然我們的服務容易複用了，一個新需求的開發可能做一個頁面，調幾個接口就完成了，但是微服務的開發和維護，也給 IT 帶來了很大的挑戰。
服務被拆成了多個微服務，每個微服務又會部署很多套，這時候才使用人肉運維就不合适了；
以前 A 系統的一個接口，變成 A->B->C->D 這樣的調用鍊路了，如果一個環節出現問題，可能導緻整個鍊路上的系統都不可用，而且問題的定位也會變得更難；
單個系統做資料的增改删很簡單，通過事務就很容易控制，但微服務化之後，就變成了多個系統的分布式事務，這個難度很大，大多數系統隻能做到資料的最終一緻；
因為一個功能可能會涉及多個系統，那麼測試也變得複雜了。
總之，很多公司不原因做微服務轉型，第一就是微服務化的難度比較大，企業沒有能力做；第二就是，企業可能真正地思考和評估過，現有架構足以滿足業務，沒必要做微服務。