為什么有些公司的server不愿意微服務化？

微服務是這幾年比較火的概念了，很多 IT 公司也都在做微服務轉型，那么微服務化適合所有的公司么？微服務架構可以解決一切問題么？我覺得并不是這樣的，企業是否需要做微服務轉型還是要從實際情況出發。

01. 微服務化倒逼組織架構

說到微服務，很多人會認為這是個技術架構，但我認為微服務不只是技術架構這么簡單，它甚至會涉及到組織架構。

通常 IT 公司的崗位都會分成產品、開發、測試、運維，有些公司甚至會分成不同的部門，一個需求的開發到上線，會從前到后經過四個部門的流轉，而進行微服務的轉型，目的是為了加速業務的響應，快速開發，快速上線，縮短迭代周期，快速試錯并糾正。

如果企業想做服務化轉型，那么組織架構也需要做相應的調整，否則還像以往一樣，部門和部門之間、崗位和崗位之間需要很大的溝通成本，那么微服務是“快不起來”的；比較理想的是把不同的崗位揉在一起，一個團隊中包含產品、開發、測試、運維四種角色，團隊成員彼此協作負責一個或幾個微服務的迭代和運維。

02. 設計更為復雜

判斷是不是適合微服務化，也要看自己的業務場景，如果服務做拆分，只是為了拆分而拆分，是沒有意義的，通常要考慮：

拆分之后的服務，能否被復用？如果一個功能在 A 系統，只被 A 系統自己使用，那么沒有拆出來的價值，如果 B/C/D 系統都需要使用這個功能，那么可以拆分出來復用；微服務的優勢之一，增加復用，減少重復開發，縮短開發時間，進而降低成本；

訪問量大還是小？如果訪問量不大且平穩，未來很長時間訪問量也不會有很大的增長，那就沒必要微服務化，如果有高并發、流量不可預計，那么可以做微服務化。

微服務在設計上也存在著一定的難度，拆成幾個微服務？新需求來了，是新建一個微服務，還是在老服務上改造？這些設計層面的考慮，也是非常復雜的。

03. 技術上的難度

雖然我們的服務容易復用了，一個新需求的開發可能做一個頁面，調幾個接口就完成了，但是微服務的開發和維護，也給 IT 帶來了很大的挑戰。

服務被拆成了多個微服務，每個微服務又會部署很多套，這時候才使用人肉運維就不合適了；

以前 A 系統的一個接口，變成 A->B->C->D 這樣的調用鏈路了，如果一個環節出現問題，可能導致整個鏈路上的系統都不可用，而且問題的定位也會變得更難；

單個系統做數據的增改刪很簡單，通過事務就很容易控制，但微服務化之后，就變成了多個系統的分布式事務，這個難度很大，大多數系統只能做到數據的最終一致；

因為一個功能可能會涉及多個系統，那么測試也變得復雜了。

總之，很多公司不原因做微服務轉型，第一就是微服務化的難度比較大，企業沒有能力做；第二就是，企業可能真正地思考和評估過，現有架構足以滿足業務，沒必要做微服務。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。