通常企業的數字化轉型和系統的微服務化改造很容易被放在一起討論，這樣的說法是把微服務放到了一個系統級別，也就成為了一個部門或一個團隊的任務。 這其實就是一個企業剛開始做微服務轉型的最大誤區。

微服務化轉型是企業級的改造工程，而具體的落實才是系統的改造，只關注於系統的微服務化改造，難免會“守一隅而遺萬方”。其實，企業微服務化轉型的很多誤區都是這樣產生的。

博雲一直為企業提供微服務拆分的諮詢服務，所以經常會接到微服務拆分的專案。 有些客戶通常只要諮詢、只要方法論、只要單個系統拆分的服務，這樣的方式其實都走入了微服務建設的誤區。例如，我們之前遇到一個大企的微服務化轉型專案，涉及近百個業務系統的微服務改造建設。面對這麼大的微服務化建設，客戶的想法卻很簡單，計劃整體改造分成三步：

1. 業務系統由近百個變成近千個，完全顛覆了原來的管理模式。 以前只需要在資源層面、網路層面的監控運維，而對於現在服務層面的觀測簡直束手無策。

2. 如果只是單系統的考慮拆分，那麼微服務帶來的消耗是會增加的 。微服務的拆分將一個執行程式拆成了十幾個，還要依賴於必要的元件，如註冊中心、配置中心、閘道器，當然每個都需要考慮高可用，那麼在資源消耗上，將增加不止一倍的消耗，這樣算來，整個企業的微服務改造，將可能會多改造出一個機房來。

3. 剛剛提到監控運維， 其實運維層面還有更多的問題 。上百個系統，近千個服務，再加上分散式的部署方式，將有幾千個執行程式的部署和升級迭代，這絕對不容小覷。

   
   

4. 每個改造、建設，或者變革，都會被問到一個收益的問題，投入大量的人力、物力、財力，我們想要看到的是回報， 而這種方式的拆分將只有投入 。

談到這裡似乎應該說：“不要為了微服務而微服務”，但實際上為了微服務而建設微服務也不是問題，因為雲原生理念與技術的普及已經如火如荼，所以熟悉相關技術也是勢在必行。

很多企業看到了微服務的前景，也開始在架構、研發等部門中，建設一些微服務治理平臺或者微服務執行觀測平臺， 但是通常這類的試驗性質的專案都存在很多誤區。

經常遇到的疑問：微服務是用來解決什麼問題的，或者能帶來什麼樣收益？於是企業從各方面尋找可以最佳化的點，比如效能最佳化、資源節省、運維成本、管理難度，但是這一圈下來發現收益全部是負增長。效能由於加入檢測探針，增加效能消耗；資源由於增加很多治理元件，增加資源消耗；運維和管理更是幾何倍增長。 因此，有些企業在建設一期的微服務平臺之後，遷入或者甚至都沒有遷入一個微服務系統的時候，就認為微服務化沒有成果，從此中斷。

另外，企業在做微服務化嘗試的時候，通常都會拆分一個不是很關鍵的業務系統，以此來測試微服務化是否真的如網際網路上炒得那麼火熱，那麼有用。然而，這個很不關鍵的業務系統在嘗試微服務化之後，企業會輕易地得出一些 “ 結 論”：

    ·   微服務的分散式似乎也沒什麼特別，反而帶來了分散式的各種問題。

    ·   微服務的限流熔斷一般用不著，用了還有可能影響正常業務。

    ·   微服務的觀測也沒啥用，如果不是出問題，平常根本沒人看。

不僅是上面的兩個理解誤區，我們在做微服務類的專案時也遇到過很多比較有前瞻性的客戶，但是完全按照客戶的要求去建設的平臺，卻似乎不是很實用。等過兩年之後，客戶發現建設微服務還是很必要，於是總結之前的經驗，覺得還是需要大廠來建設，因此只好花幾倍的錢找大廠來做，而實際上再次建設可能還會遇到之前同樣的問題，反而 “ 勞民傷財” 。 其實主要原因還是沒有把握住微服務的根本。

微服務解決的根本問題，總結一下其實是業務系統執行中由量變引起的一系列問題，量變引起質變，最終透過微服務的架構解決。 如果業務訪問量不夠，那就不會用到限流熔斷；如果應用服務數量不多，那就不需要統一管理和執行觀測；如果服務變更不頻繁，那也就不需要持續釋出、灰度釋出等。

微服務的優勢在單一且沒有業務量的系統中，完全不能發揮其長處，反而單體應用的優勢更明顯。 這也正是微服務建設中最大的誤區。

當我們聊到微服務的時候，很多人第一印象就是拆分，一個拆成多個，這就是微服務。那麼微服務治理、或者微服務執行平臺，就是用來解決微服務拆成多個以後帶來的問題。

具體問題有通訊互訪、流量保障、關係網路、執行狀態、分散式事務、效能觀測、故障定位、灰度釋出等，很多方案都是由開源技術提供，比如微服務框架、APM 一些開源元件。

那麼微服務治理平臺就是開源元件的聯合嗎？ 在微服務治理中，開源元件有：

• 微服務框架（其實不屬於元件）： 在治理方面主要提供微服務的通訊、負載均衡等，如 SpringCloud、Dubbo；

  
  

• 註冊中心： 提供服務註冊發現機制，如 Nacos、Consul 等。

  
  

• 服務流量限制： 通常有限流、熔斷、降級等功能，如使用 Hystrix 元件。

  
  

• 配置中心： 提供統一的配置管理，尤其是分散式服務下，服務配置的統一變更，如 Apollo。

  
  

• 服務觀測： 主要是 API 維度、服務維度的效能監控，服務間關係拓撲，鏈路追蹤、日誌追蹤等功能，目前使用最多的是 Skywalking。

當然還有閘道器、分散式任務排程、分散式事務等元件，這些元件都是微服務執行所依賴的。

那這些元件的聯合就可以做到微服務的治理了嗎？ 其實微服務治理平臺，主要還是管理， 以業務視角的系統、應用的管理是治理平臺最大的價值 。註冊中心提供的是全量的服務資訊，配置中心也有全量的服務配置，但全都是技術角度的依賴工具，而不是管理工具。

我們剛剛提到微服務的量變引起的管理困難，在所有的開源工具中，都不能得到解決。無論是服務列表、服務配置、服務拓撲， 我們要的不是技術角度的功能實現，而是業務角度的管理觀測 。開源的工具不是治理，如果立項，可別踩這坑。

綜上所述，微服務化轉型所有的誤區，其實都是因為對微服務的認識不夠和對微服務的規劃不明確導致的。那麼微服務化建設應該從哪些方面入手才是正確的建設方向，才能保證持續的進步，才能少踩坑，少走彎路？我們將在之後的文章中為大家分享正確的微服務轉型的建設思路，敬請期待。